在java中怎么把一个字符串编译为指定编码格式（如:unicode）的输出

很多种方法request.setCharacterEncoding("utf-8"); //设置输入编码格式

response.setContentType("text/html;charset=utf-8"); //设置输出编码格式

一般写个Servlet的过滤器

(getByte("ISO-8859-1"),"utf-8");在配置文件里面过滤.

java课程设计例子

Java如何获取文件编码格式

1：简单判断是UTF-8或不是UTF-8，因为一般除了UTF-8之外就是GBK，所以就设置默认为GBK。

按照给定的字符集存储文件时，在文件的最开头的三个字节中就有可能存储着编码信息，所以，基本的原理就是只要读出文件前三个字节，判定这些字节的值，就可以得知其编码的格式。其实，如果项目运行的平台就是中文操作系统，如果这些文本文件在项目内产生，即开发人员可以控制文本的编码格式，只要判定两种常见的编码就可以了：GBK和UTF-8。由于中文Windows默认的编码是GBK，所以一般只要判定UTF-8编码格式。

对于UTF-8编码格式的文本文件，其前3个字节的值就是-17、-69、-65，所以，判定是否是UTF-8编码格式的代码片段如下：

File file = new File(path);

InputStream in= new java.io.FileInputStream(file);

byte[] b = new byte[3];

in.read(b);

in.close();

if (b[0] == -17 && b[1] == -69 && b[2] == -65)

System.out.println(file.getName() + "：编码为UTF-8");

else

System.out.println(file.getName() + "：可能是GBK，也可能是其他编码");

2：若想实现更复杂的文件编码检测，可以使用一个开源项目cpdetector，它所在的网址是：。它的类库很小，只有500K左右，cpDetector是基于统计学原理的，不保证完全正确，利用该类库判定文本文件的代码如下：

读外部文件(先利用cpdetector检测文件的编码格式，然后用检测到的编码方式去读文件):

/**

* 利用第三方开源包cpdetector获取文件编码格式

*

* @param path

*            要判断文件编码格式的源文件的路径

* @author huanglei

* @version 2012-7-12 14:05

*/

public static String getFileEncode(String path) {

/*

* detector是探测器，它把探测任务交给具体的探测实现类的实例完成。

* cpDetector内置了一些常用的探测实现类，这些探测实现类的实例可以通过add方法 加进来，如ParsingDetector、

* JChardetFacade、ASCIIDetector、UnicodeDetector。

* detector按照“谁最先返回非空的探测结果，就以该结果为准”的原则返回探测到的

* 字符集编码。使用需要用到三个第三方JAR包：antlr.jar、chardet.jar和cpdetector.jar

* cpDetector是基于统计学原理的，不保证完全正确。

*/

CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();

/*

* ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于

* 指示是否显示探测过程的详细信息，为false不显示。

*/

detector.add(new ParsingDetector(false));

/*我爱编程网

* JChardetFacade封装了由Mozilla组织提供的JChardet，它可以完成大多数文件的编码

* 测定。所以，一般有了这个探测器就可满足大多数项目的要求，如果你还不放心，可以

* 再多加几个探测器，比如下面的ASCIIDetector、UnicodeDetector等。

*/

detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar

// ASCIIDetector用于ASCII编码测定

detector.add(ASCIIDetector.getInstance());

// UnicodeDetector用于Unicode家族编码的测定

detector.add(UnicodeDetector.getInstance());

java.nio.charset.Charset charset = null;

File f = new File(path);

try {

charset = detector.detectCodepage(f.toURI().toURL());

} catch (Exception ex) {

ex.printStackTrace();

}

if (charset != null)

return charset.name();

else

return null;

}

String charsetName = getFileEncode(configFilePath);

System.out.println(charsetName);

inputStream = new FileInputStream(configFile);

BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));

读jar包内部资源文件(先利用cpdetector检测jar内部的资源文件的编码格式，然后以检测到的编码方式去读文件)：

/**

* 利用第三方开源包cpdetector获取URL对应的文件编码

*

* @param path

*            要判断文件编码格式的源文件的URL

* @author huanglei

* @version 2012-7-12 14:05

*/

public static String getFileEncode(URL url) {

/*

* detector是探测器，它把探测任务交给具体的探测实现类的实例完成。

* cpDetector内置了一些常用的探测实现类，这些探测实现类的实例可以通过add方法 加进来，如ParsingDetector、

* JChardetFacade、ASCIIDetector、UnicodeDetector。

* detector按照“谁最先返回非空的探测结果，就以该结果为准”的原则返回探测到的

* 字符集编码。使用需要用到三个第三方JAR包：antlr.jar、chardet.jar和cpdetector.jar

* cpDetector是基于统计学原理的，不保证完全正确。

*/

CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();

/*

* ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于

* 指示是否显示探测过程的详细信息，为false不显示。

*/

detector.add(new ParsingDetector(false));

/*

* JChardetFacade封装了由Mozilla组织提供的JChardet，它可以完成大多数文件的编码

* 测定。所以，一般有了这个探测器就可满足大多数项目的要求，如果你还不放心，可以

* 再多加几个探测器，比如下面的ASCIIDetector、UnicodeDetector等。

*/

detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar

// ASCIIDetector用于ASCII编码测定

detector.add(ASCIIDetector.getInstance());

// UnicodeDetector用于Unicode家族编码的测定

detector.add(UnicodeDetector.getInstance());

java.nio.charset.Charset charset = null;

try {

charset = detector.detectCodepage(url);

} catch (Exception ex) {

ex.printStackTrace();

}

if (charset != null)

return charset.name();

else

return null;

}

URL url = CreateStationTreeModel.class.getResource("/resource/" + "配置文件");

URLConnection urlConnection = url.openConnection();

inputStream=urlConnection.getInputStream();

String charsetName = getFileEncode(url);

System.out.println(charsetName);

BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));

3：探测任意输入的文本流的编码，方法是调用其重载形式：

charset=detector.detectCodepage(待测的文本输入流,测量该流所需的读入字节数);

上面的字节数由程序员指定，字节数越多，判定越准确，当然时间也花得越长。要注意，字节数的指定不能超过文本流的最大长度。

4：判定文件编码的具体应用举例：

属性文件(.properties)是Java程序中的常用文本存储方式，象STRUTS框架就是利用属性文件存储程序中的字符串资源。它的内容如下所示：

#注释语句

属性名=属性值

读入属性文件的一般方法是：

FileInputStream ios=new FileInputStream(“属性文件名”);

Properties prop=new Properties();

prop.load(ios);

String value=prop.getProperty(“属性名”);

ios.close();

利用java.io.Properties的load方法读入属性文件虽然方便，但如果属性文件中有中文，在读入之后就会发现出现乱码现象。发生这个原因是load方法使用字节流读入文本，在读入后需要将字节流编码成为字符串，而它使用的编码是“iso-8859-1”,这个字符集是ASCII码字符集，不支持中文编码，

方法一：使用显式的转码：

String value=prop.getProperty(“属性名”);

String encValue=new String(value.getBytes(“iso-8859-1″),”属性文件的实际编码”);

方法二：象这种属性文件是项目内部的，我们可以控制属性文件的编码格式，比如约定采用Windows内定的GBK，就直接利用”gbk”来转码，     如果约定采用UTF-8，就使用”UTF-8″直接转码。

方法三：如果想灵活一些，做到自动探测编码，就可利用上面介绍的方法测定属性文件的编码，从而方便开发人员的工作

补充：可以用下面代码获得Java支持编码集合：

Charset.availableCharsets().keySet();

可以用下面的代码获得系统默认编码：

Charset.defaultCharset();

这种编码问题真是很tricky的问题。说它tricky是因为这至少涉及到以下4种编码选取的排列组合(有时甚至更多)，更有时乃至会发生错进错出，负负得正，中间过程错了但反而到不是乱码的情况。

(1)源代码的编码

(2)编译时告诉java编译器的源代码编码

(3)运行时jvm参数file.encoding

(4)输出终端对输出字节流的解码所采用的码组

在这简单情况下(1)和(2)一致，(3)和(4)一致就不会因为编解码映射错误(当然字符向终端字体映射的错误是另一回事，如字体缺失之类)。而(1)(2)和(3)(4)不必一致，这样就使得不必强求开发编译环境和运行应用环境的编码必须一致。

源代码的录入与编译若在在一个平台上时，大多数情况没有问题(反而用聪明的Idea IDE设置错误时会乱套，越是简陋的开发环境越不太会错)。但是如果你在中文GBK编码平台上的源代码在别人的unicode编码平台上编译，就有问题了。所以和别人，特别是和不同母语的人合作编程时，建议要么约定一律用unicode作为源文件编码;要么只用ASCII字符，反正其他编码一般都和ASCII兼容的，对于非ASCII字符，用Java的/uxxxx表示机制，比如"中国"就表示为"\u4e2d\u56fd"。4e2d和56fd分别是中国二字的unicode十六进制编码。

但我认为楼主在这里其实主要关心的是运行时的编码一致问题，即(3)和(4)。所以言归正传，让我们来检查它们是否一致。

由于正如上述，iso8859-1编码集其实是被其他所有公认的编码集所兼容的，也就是说它是所有公认编码集的公共子集。所以以iso8859-1为基础可以外延到任何一个公认编码集。事实上大多数情况也是这样做的。比如java System property里设定了encoding为iso8859-1，事实上不仅仅是一个Latin字母的映射，在非Latin区域按JVM宿主操作系统的编码扩展。即选iso8859-1其实是选择了宿主操作系统的默认编码。

假设楼主的操作系统编码是GBK,那么file.encoding=iso8859-1相当于选择了file.encoding=GBK。那么System.out.println(...)这个核心类方法会将china字符转换为file.encoding指定的编码(GBK)字节由out流输出给最终out所绑定的终端。比如console一般采用系统默认编码也是GBK的话，那就和file.encoding一致，能正常解码，不会乱码。

至于System.out.write()直接写字节流。由于该字节流是由china.getBytes()得到的，在不指定编码的时候使用file.encoding指定的默认值的(即GBK)，因此Str->Byte的编码方法GBK和console采用的解码方法GBK又是一致的，所以也不是乱码。

但是这时候用toHexString打印出的两个字节串是不一样的。先直接把china逐字强行转换为int的情况，不涉及输出编码，总是unicode的。(JVM规范规定class里字串必须unicode编码)只要上述(1) (2)匹配，java编译器会自动从各种编码的源文件正确转成class文件里统一unicode编码的字串。相反，作为一个题外话提一下，当(1)(2)不匹配时会在特定的一种配合(1)(2)的(3)(4)也不匹配的情况下会负负得正输出正常，但这是绝对错误的做法，因为任何要求(1)(2)和(3)(4)有匹配关系的要求都是在应用中可能无法满足的。java编译器对这种情况也会报告warning，但不fail。

综上，一旦file.encoding设成宿主操作系统默认而系统consle也采用操作系统默认编解码的话，(3)(4)总是一致的，无论系统选择的是GBK还是utf-8等等。

那么如果file.encoding不选系统默认呢?比如utf-8。那就很可能出现乱码了。但是，慢着，试验的结果还是没有乱码。那是因为file.encoding是静态的JVM系统参数，在程序里像楼主那样设定是不起作用的(我不知道有没有办法发一个什么通知让这种程序改变生效的)。必须作为JVM参数直接传给java程序让它构造虚拟机的时候就得到这个参数，否则JVM会去拿宿主系统的默认值，就相当于又回到设file.encoding=iso8859-1了。

java -Dfile.encoding=utf-8 A

这下终于乱码了，而且两个都乱了。打印出的字节串一个还是unicode，另一个从GBK变到utf-8了。

如果你发现试验的现象和我上面说的正好相反，请注意检查console的编码设置，我们上面假设它也采用了宿主系统默认编码，但有些console很高级的嘞，可以设置成不通编码的(其实几乎所有的都可以)。那么分析的方法和上面一样，结果可能正好相反。