Java/JSP中文乱码问题解决心得（转）

From：http://www.xici.net/u9206704/d56632455.htm

自从接触Java和JSP以来，就不断与Java的中文乱码问题打交道，现在终于得到了彻底的解决，现将我们的解决心得与大家共享。

一、Java中文问题的由来

Java的内核和class文件是基于unicode的，这使Java程序具有良好的跨平台性，但也带来了一些中文乱码问题的麻烦。原因主要有两方面，Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。

首先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基于字节流的，如果Java和JSP编译成class 文件过程中，使用的编码方式与源文件的编码不一致，就会出现乱码。基于这种乱码，建议在Java文件中尽量不要写中文（注释部分不参与编译，写中文没关 系），如果必须写的话，尽量手动带参数－ecoding GBK或－ecoding gb2312编译；对于JSP，在文件头加上<%@ page contentType="text/html;charset=GBK"%>或<%@ page contentType="text/html;charset=gb2312"%>基本上就能解决这类乱码问题。

本文要重点讨论的是第二类乱码，即Java程序与其他存储媒介交互时产生的乱码。很多存储媒介，如数据库，文件，流等的存储方式都是基于字节流的，Java程序与这些媒介交互时就会发生字符(char)与字节(byte)之间的转换，具体情况如下：

从页面form提交数据到java程序 byte－>char
从java程序到页面显示 char—>byte

从数据库到java程序 byte—>char
从java程序到数据库 char—>byte

从文件到java程序 byte－>char
从java程序到文件 char－>byte

从流到java程序 byte－>char
从java程序到流 char－>byte

如果在以上转换过程中使用的编码方式与字节原有的编码不一致，很可能就会出现乱码。

二、解决方法

前面已经提到了Java程序与其他媒介交互时字符和字节的转换过程，如果这些转换过程中容易产生乱码。解决这些乱码问题的关键在于确保转换时使用的编码方式与字节原有的编码方式保持一致，下面分别论述（Java或JSP自身产生的乱码请参看第一部分）。

1、JSP与页面参数之间的乱码
JSP获取页面参数时一般采用系统默认的编码方式，如果页面参数的编码类型和系统默认的编 码类型不一致，很可能就会出现乱码。解决这类乱码问题的基本方法是在页面获取参数之前，强制指定request获取参数的编码方式： request.setCharacterEncoding("GBK")或request.setCharacterEncoding ("gb2312")。
如果在JSP将变量输出到页面时出现了乱码，可以通过设置response.setContentType ("text/html;charset=GBK")或response.setContentType("text/html;charset= gb2312")解决。
如果不想在每个文件里都写这样两句话，更简洁的办法是使用Servlet规范中的过虑器指定编码，过滤器的在web.xml中的典型配置和主要代码如下：
web.xml:

<filter>
<filter-name>CharacterEncodingFilter</filter-name>
<filter-class>net.vschool.web.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CharacterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

CharacterEncodingFilter.java:

public class CharacterEncodingFilter implements Filter
{

protected String encoding = null;

public void init(FilterConfig filterConfig) throws ServletException
{
this.encoding = filterConfig.getInitParameter("encoding");
}

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
request.setCharacterEncoding(encoding);
response.setContentType("text/html;charset="+encoding);
chain.doFilter(request, response);
}

}


2、Java与数据库之间的乱码
大部分数据库都支持以unicode编码方式，所以解决Java与数据库之间的乱 码问题比较明智的方式是直接使用unicode编码与数据库交互。很多数据库驱动自动支持unicode，如Microsoft的SQLServer驱动。其他大部分数据库驱动，可以在驱动的url参数中指定，如如mm的mysql驱动：jdbc:mysql://localhost/WEBCLDB? useUnicode=true&characterEncoding=GBK。

3、Java与文件/流之间的乱码
Java读写文件最常用的类是 FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream 和FileOutputStream是基于字节流的，常用于读写二进制文件。读写字符文件建议使用基于字符的FileReader和 FileWriter，省去了字节与字符之间的转换。但这两个类的构造函数默认使用系统的编码方式，如果文件内容与系统编码方式不一致，可能会出现乱码。在这种情况下，建议使用FileReader和FileWriter的父类： InputStreamReader/OutputStreamWriter，它们也是基于字符的，但在构造函数中可以指定编码类型： InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter(OutputStream out, Charset cs)。

4、其他
上面提到的方法应该能解决大部分乱码问题，如果在其他地方还出现乱码，可能需要手动修改代码。解决Java乱码问 题的关键在于在字节与字符的转换过程中，你必须知道原来字节或转换后的字节的编码方式，转换时采用的编码必须与这个编码方式保持一致。我们以前使用 Resin服务器，使用smartUpload组件上传文件，上传文件同时传递的中文参数获取没有乱码问题。当在Linux中把Resin设置成服务后， 上传文件同时的中文参数获取出现了乱码。这个问题困扰了我们很久，后来我们分析smartUpload组件的源文件，因为文件上传采用的是字节流的方式，里面包含的参数名称和值也是字节流的方式传递的。smartUpload组件读取字节流后再将参数名称和值从字节流中解析出来，问题就出现在 smartUpload将字节流转换成字符串时采用了系统默认的编码，而将Resin设置成服务后，系统默认的编码可能发生了改变，因此出现了乱码。后来，我们更改了smartUpload的源文件，增加了一个属性charset和setCharset(String)方法，将upload()方法中提 取参数语句：
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1 );
改成了
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1, charset );
终于解决了这个乱码问题。

三、后记
接触Java和JSP已经有一年多了，这一年来最大的收获是越来越喜欢上了Java，开始把问题当作乐事去研究， 没有了以前的恐惧心理，我相信我会继续坚持下去。这一年来，从网上学习了很多同行的宝贵经验，在此表示感谢。这是我第一篇自己总结的Java学习心得，由于水平有限，本文中偏颇和错误之处，欢迎指正。如果对你有些价值，在保留作者信息和文章原始出处的前提下可以随处转载。
撰写该文之前已参考了很多关于Java中文问题的文章，其中影响比较大的有owen1944在“Java研究组织”中发表的《这是我们公司总结的一些关于中文乱码问题的一些解决方案和经验和大家分享！》等。本文谈到的解决方法已应用到“基于网络的协作学习系统－WebCL”等项目中，并通过资源绑定的方式实现了该平台中文文两个版本的即时切换。Google根据浏览器自动选择语言，一个页面同时显示多种语言的国际化应用和车东的《Java中文处理学习笔记——Hello Unicode》一文引起了我极大的兴趣，日后想将继续探讨Java的国际化问题，欢迎大家一起讨论。


from：http://hi.baidu.com/lsjlym/blog/item/d50914af2d6f86fffbed5014.html
汉字问题深入谈

一、主题：关于JAVA的中文问题
    JAVA的中文问题比较突出，主要表现在控制面板输出，JSP页面输出和数据库访问上。
本文尽量避开字体问题，而只谈编码。通过本文，你可以了解JAVA中文问题的由来，问题
的解决方法，其中提了一下用JDBC访问数据库的方法。

二、问题描述：
1）在中文W2000中文窗口编译和运行，用的是国际版的JDK，连接的是中文W2000下的Cp936
编码的SQL SERVER数据库：

J:\exercise\demo\encode\HelloWorld>make
   Created by XCompiler. PhiloSoft All Rights Reserved.
   Wed May 30 02:54:45 CST 2001

J:\exercise\demo\encode\HelloWorld>run
   Created by XRunner. PhiloSoft All Rights Reserved.
   Wed May 30 02:51:33 CST 2001
中文
[B@7bc8b569
[B@7b08b569
[B@7860b569
中文
中文
????
中文
中文
????
??
??
??

2）如果在中文W2000的西文窗口（编码为437）下编译，用JAVA运行则由于无字体而无法正
常显示，如果象上面一样在中文W2000的中文窗口运行，输出为：

J:\exercise\demo\encode\HelloWorld>run
   Created by XRunner. PhiloSoft All Rights Reserved.
   Wed May 30 02:51:33 CST 2001
????
[B@7bc0b66a
[B@7b04b66a
[B@7818b66a
????
????
????
????
????
????
中文
中文
????

三）分析

1）出现有乱码（也就是？）。由于只出现？而没出现小方框，说明只是编码有问题，而不
是字体问题。 在编码中，如果从一种字符集转换到别一种字符集，比较典型的是从GB2312
转换到ISO8859_1（即ASCII），那么很多汉字（半个汉字）是无法映射到西文字符中去的
，在这种情形下，系统就把这些字符用？代替。同样，也存在小字符集无法到大字符集的
情况，具体原因这里就不详谈了。

2）出现了中文环境编译，中文环境运行时汉字显示有正确也有不正确的地方，同样，在西
文环境下编译，在中文环境下运行时也出现类似情况。这是由于自动（默认）或手工（也
就new String(bytes[,encode])和bytes getBytes([encode])）转码的结果。

2.1）在JAVA源文件-->JAVAC-->Class-->Java-->getBytes()-->new String()-->显示的过
程中，每一步都有编码的转换过程，这个过程总是存在的，只是有的时候用默认的参数进
行。下面我们一步一步分析为什么出现上面的情形。

2.2）这里是源代码：

HelloWorld.java:
------------------------
public class HelloWorld
{
public static void main(String[] argv){
    try{
System.out.println("中文");//1
System.out.println("中文".getBytes());//2
System.out.println("中文".getBytes("GB2312"));//3
System.out.println("中文".getBytes("ISO8859_1"));//4

System.out.println(new String("中文".getBytes()));//5
System.out.println(new String("中文".getBytes(),"GB2312"));//6
System.out.println(new String("中文".getBytes(),"ISO8859_1"));//7

System.out.println(new String("中文".getBytes("GB2312")));//8
System.out.println(new String("中文".getBytes("GB2312"),"GB2312"));//9
System.out.println(new

String("中文".getBytes("GB2312"),"ISO8859_1"));//10

System.out.println(new String("中文".getBytes("ISO8859_1")));//11
System.out.println(new

String("中文".getBytes("ISO8859_1"),"GB2312"));//12
System.out.println(new

String("中文".getBytes("ISO8859_1"),"ISO8859_1"));//13
}
catch(Exception e){
e.printStackTrace();
}
}
}

为了方便起见，在每个转换的后面加了操作序号，分别为1,2,...,13。

2.3）需要说明的是，JAVAC是以系统默认编码读入源文件，然后按UNICODE进行编码的。在
JAVA运行的时候，JAVA也是采用UNICODE编码的，并且默认输入和输出的都是操作系统的默
认编码，也就是说在new String(bytes[,encode])中，系统认为输入的是编码为encode的
字节流，换句话说，如果按encode来翻译bytes才能得到正确的结果，这个结果最后要在JA
VA中保存，它还是要从这个encode转换成Unicode，也就是说有bytes-->encode字符-->Uni
code字符的转换；而在String.getBytes([encode])中，系统要做一个Unicode字符-->enco
de字符-->bytes的转换。

在这个例子中，除那个英文窗口编码的时候除外，其实情形下默认编码都是GBK（在本例中
，我们暂且把GBK和GB2312等同看待）。

2.4）由于在未指明在上面的两个用代码实现的转换中，如果未指定encode，系统将采用默
认的编码（这里为GBK），我们认为上面的5,6,7和8,9,10是一样的，8和9、11和12也是一
样的，所以我们在讨论中将只讨论1,9,10,12,13。其中的2,3,4只是用于测试，不在我们的
讨论范围之内。

2.5）下面我们来跟踪程序中的“中”字的转换历程，我们先说在中文窗口下作的编译和运
行过程，注意在下面的字母下标中，我有意识地使用了一些数字，以表示相同，相异还是
相关2.5.1)我们先以上面的13个代码段中的的代码9为例：

步骤 内容 地点 说明
01： C1 HelloWorld.java C1泛指一个GBK字符
02： U1 JAVAC读取 U1泛指一个Unicode字符
03： C1 getBytes()第一步 JAVA先和操作系统交流
04： B1,B2 getBytes()第二步 然后返回字节数组
05： C1 new String()第一步 JAVA先和操作系统交流
06： U1 new String()第二步 然后返回字符
07： C1 println(String) 能显示“中”字，内容和原来的相同

2.5.2）然后再以代码段10为例，我们注意到只是：

步骤 内容 地点 说明
01： C1 HelloWorld.java C1泛指一个GBK字符
02： U1 JAVAC读取 U1泛指一个Unicode字符
03： C1 getBytes()第一步 JAVA先和操作系统交流
04： B1,B2 getBytes()第二步 然后返回字节数组
05： C3,C4 new String()第一步 JAVA先和操作系统交流，这时解析错误
06： U5,U6 new String()第二步 然后返回字符
07： C3,C4 println(String) 由于中字给分成了两半，在ISO8859_1中刚好也没有字符

能映射上，所以显示为“??”。在上面的示例中，
“中文”两个字就显示为“？？？？”
2.5.3）在完全中文模式下的其它情形类似，我就不多说了

2.6）我们接着看为什么在西文DOS窗口下编译出来的类在中文窗口下也出现类似情形，特
别是为什么居然有的情形下还能正确显示汉字。

2.6.1）我们还是先以代码段9为例：

步骤 内容 地点 说明
01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开
02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符
03： C5C6 getBytes()第一步 JAVA先和操作系统交流，这时解析错误
04： B5B6B7B8 getBytes()第二步 然后返回字节数组
05： C5C6 new String()第一步 JAVA先和操作系统交流
06： U3U4 new String()第二步 然后返回字符
07： C5C6 println(String) 虽然同是两个字符，但已不是最初的“两个ISO8859_1字

符”，而是“两个BGK字符”，“中”显示成了“？？”
而“中文”就显示成了“？？？？”

2.6.2）下面我们以代码段12为例，因为它能正确显示汉字

步骤 内容 地点 说明

01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开
02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符
03： C1C2 getBytes()第一步 JAVA先和操作系统交流（注意还是正确的哦！）
04： B5B6 getBytes()第二步 然后返回字节数组（这是很关键的一步！）
05： C12 new String()第一步 JAVA先和操作系统交流（这是更关键的一步，JAVA已经知
道B5B6要解析成一个汉字！）
06： U7 new String()第二步 然后返回字符（真是一个项两！U7包含了U3U4的信息）
07： C12 println(String) 这就原来的“中”字，很委屈被JAVAC冤枉了一回，不过被程
序员拨乱反正了一下！当然，“中文”两个字都能正确显示了！

3）那为什么有的时候用JDBC的
new String(Recordset.getBytes(int)[,encode])
Recordset.getSting(int)
Recordset.setBytes(String.getBytes([encode]))
和
Recordset.setString(String)
的时候会出现乱码了呢？

其实问题就出现在编写JDBC的的也考虑了编码问题，它从数据库读取数据后，可能自作主
张做了一个从GB2312（默认编码）到Unicode的转换，我的这个WebLogic For SQL Server
的JDBC Driver就是这样的，当我读字串的时候，发出读到的不是正确的汉字，可恨的是我
却可以直接写汉字字串，这让人多少有点难以接受！
也就是说，我们不得不在读或写的时候进行转码，尽管这个转码有的时候不是那么明显，
这是因为我们使用了默认的编码进行转码。JDBC Driver所做的操作，我们只有进入到源代
码内部才能清楚，不是吗？