http://liuwentao.iteye.com/blog/61438
许多人用 Java 处理到中文数据时，常会出现乱码。关于 Java 和中文兼容性的问题，实在让许多程序员为此伤透脑筋，相关的问题每隔几天就会出现在网络上。为了舒缓您紧蹙的眉头，我特别写了这系列文章，解说 Java 牵涉到文字时的内部处理方式，供读者参考。读完本系列文章之后，不求甚解者可以治标，充分理解者可以治本。本文贵在原理解说，别光是囫囵吞枣。
快速解决之道
如果你目前正遭遇到 Java 和中文不兼容的问题，请你注意下面这几点，说不定问题能马上迎刃而解：
1. 检查操作系统设定：先检查你的操作系统，确定国籍语言数据是「Traditional Chinese（*）」。国籍语言数据的设定会影响 Java 编译器与JRE的判断。我之前就是因为国籍数据设定不正确，出了一堆 Java 和中文不兼容的怪事。
2. 更新 Java 环境版本：改用最新版的 JDK，新版本的 JDK 说不定已经解决你原有的问题。请注意：某些 Java IDE 所用的编译器和 JRE 是不兼容于中文的（我遇过这样的情形），你最好能把 Java IDE 的 JDK 指到新版的 JDK。另外，如果数据库取回的数据是乱码，换别套或者更新 JDBC 驱动程序试试看。
如果还是无法解决，请详细阅读下面各小节的内容，仔细推敲你的错误所在。
Unicode、UTF-16、UTF-8
Java 内部处理字符使用的字序方式是 Unicode，这是一种通行全球的编码方式。Unicode 因为必须将中、韩、日、英、法、阿拉伯……等许多国家所使用的文字都纳入，目前已经包含了六万多个字符，所以 Unicode 使用了 16 个位来为字符编码。因为 Unicode 使用了 16 位编码，所以每个字符都用 16 位来储存或传输是很自然的事，这种储存或传输的格式称为 UTF-16（是不是很像战斗机的名字）。如果你使用到的字符都是西方字符，那么你一定不会想用 UTF-16 的格式，因为体积比 8 位的 Latin-1（一种扩充 ASCII 的编码）多了一倍。所以 Unicode 另有一种储存或传输的格式，叫做 UTF-8。UTF-8 的格式在编码英文时，只需要 8 位，但是中文则是 24 位，所以中文字出现比例高的地方还是使用 UTF-16 比较节省空间。Java 的 Class File（也就是 bytecode）中有一字段叫做常数区（Constant Pool），一律使用 UTF-8 为字符编码。
关于 Unicode 的编码，请查阅「The Unicode Standard, Version 3.0」一书（Addison-Wesley 出版）；关于 UTF-8 编码，请查阅「Java I/O」一书的 399 页（O'Reilly 出版）。关于 Java Class File 的格式与 Constant Pool，请查阅「Java Virtual Machine」一书（O'Reilly出版）。
Unicode 与繁体中文编码的互转
虽然 Java 内部完整地使用 Unicode，但是你所使用的操作系统可不见得。以繁体中文版的 Windows 98 来说，预设的编码方式是 MS950，这是一种兼容于 Big 5的编码方式。字符串数据从 Windows 一送进 JRE，JRE 的转码系统马上先把字符串编码由 MS950 转成 Unicode，才能进行处理。字符串数据由 JRE 一送出给 Windows，JRE 的转码系统马上先将其由 Unicode 转成 MS950，操作系统才能处理。
想知道你的 JDK 或 JRE 会用什么样的编码方式来和操作系统沟通，请执行下面的 Java 程序：
public class ShowNativeEncoding {
public static void main(String[] args) {
String enc = System.getProperty(“file.encoding”);
System.out.println(enc);
}
}
如果执行结果不是下面的字符串之一，那么你的操作系统国籍语言设定可能就有问题了：
Big5：这是繁体中文 de facto 标准。
CNS11643：*的官方标准繁体中文编码。
Cp937：繁体中文加上 6204 个使用者自定的字符
Cp948：繁体中文版 IBM OS/2 用的编码方式。
Cp964：繁体中文版 IBM AIX 用的编码方式。
EUC_TW：*的加强版 Unicode。
ISO2022CN：编码中文的一套标准。
ISO2022CN_CNS：编码中文的一套标准，繁体版，袭自 CNS11643。
MS950 或 Cp950：ASCII + Big5，用于*和香港的繁体中文 MS Windows操作系统。
Unicode：有次序记号的 Unicode。次序记号占用两个 byte，如果其值是0xFEFF，表示使用 big-endian（由大到小）的次序为 Unicode 编码；如果其值是 0xFFFF，表示使用 little-endian（由小到大）的次序为 Unicode 编码。
UnicodeBig：使用 big-endian（由大到小）的次序为 Unicode 编码。
UnicodeLittle：使用 little-endian（由小到大）的次序为 Unicode 编码。
UTF8：使用 UTF-8 为 Unicode 编码。
关于 Big 5 编码，请查阅「CJKV Information Processing」一书的附录 H（O'Reilly出版）。
编译时的注意事项
编译的时候，如果你不说明原始文件编码方式的话， javac 编译器在读进此原始程序文件，开始编译之前，会先去询问操作系统档案预设的编码方式为何。以繁体中文 Windows 98 来说，javac 会先询问 Windows 98，得知档案是用 MS950 的方式编码。然后就可以将档案由 MS950 转成 Unicode 编码方式，开始进行编译。
通常在编译阶段，会造成的错误有下列几种可能：
如果操作系统的国籍数据设定错误，会造成 javac 编译器取得的编码信息是错的。
较差劲的编译器可能没有主动询问操作系统的编码方式，而是采用编译器预设的编码方式。
如果原始程序不是用编译当时操作系统预设的编码方式存盘的，也会造成错误。比方说，原始程序文件是*程序员写的，在繁体中文版的 Windows上以 MS950 编码存盘，再经由网络传送到泰国，在泰文版的 Windows 上编译（泰文版 Windows 预设的档案编码方式是 MS874）。
这种因为原始程序文件编码方式和编译器无法匹配所造成的问题，轻则编译成功但执行时文字出现乱码或出现 Error/Exception，重则无法成功编译。这时候，你需要主动透过「-encoding」选项来指定原始程序的编码方式，编译器会以你指定的编码为主，不会再去询问操作系统。下面的例子，我们告诉编译器「*Class.java」是以繁体中文版 Windows 的「MS950」编码的：
javac –encoding MS950 *Class.java
如果你手上只有某 class 文件，没有原始程序文件，而且你确定其 constant pool 的UTF-8 字段编码错误，你有两种方式可以用来修正编码：
先反编译，取得原始程序，再修改，编译。
或者直接利用 bytecode 编辑软件，直接修改 class 文件。
I/O 转码
Java 现行的 IO 一律使用 Stream 的方式，相关的类别都放在 java.io 中。输出 binary 的数据使用 OutputStream 的子类别，输入 binary 的数据使用 InputStream 的子类别，输出文字的数据使用 Writer 的子类别，输入文字的数据使用 Reader 的子类别。
你可能会觉得很奇怪：「有必要用不同的方式来处理文字和 binary 吗？文字数据不也是 binary 的一种？」没错，其实他们非常类似，最大的差异在于，InputStream/OutputStream 会原封不动地传送数据，但是 Reader/Writer 会将数据当作文字对待，所以 Reader/Writer 在「必要时」会把（文字）数据转码。什么时候才是所谓的「必要时」呢？
Java 的 Stream（包括 Reader 和 Writer）是可以互相串接的。当 Reader 的资料来源是另一个 Reader 时，不转码，当 Reader 的资料来源是一个 InputStream 时，就会转码。当 Writer 的数据去处是另一个 Writer 时，不转码，当 Writer 的数据去处是一个 OutputStream 时，就会转码。
由什么码转成什么码？这是可以指定的。因为转码只发生在 Reader/InputStream 的交界处与 Writer/OutputStream 的交界处，所以正是由 InputStreamReader 和 OutputStreamWriter 此二类别负责，下面两个 constructor 的第二个参数，正是用来指定转码的方式。
public InputStreamReader(InputStream in, String enc)
throws UnsupportedEncodingException;
public OutputStreamWriter(OutputStream out, String enc)
throws UnsupportedEncodingException;
InputStreamReader 负责将 enc 的编码方式转成 Unicode（因为数据是从「外部」送过来给「内部」的），OutputStreamWriter 负责将 Unicode 的编码方式转成 enc（因为数据要从「内部」送给「外部」）。JRE 内部当然都一定是用 Unicode 编码，而外部的编码就不一定，要看当时的环境为何。你可以透过 getEncoding() 的 method，来得知 InputStreamReader 与 OutputStreamWriter 的编码方式。
请注意：即使你没用到 InputStreamReader 与 OutputStreamWriter，只有用到其它的 Reader 和 Writer，但是这些 Reader 和 Writer 内部也很有可能（但非绝对）是直接或间接通到 InputStreamReader 与 OutputStreamWriter。比方说：FileReader 内部其实是透过一个 InputStreamReader 的中介来将数据从 FileInputStream 取过来的，此时 InputStreamReader 的转码方式是采用 OS 的文字编码（以繁体中文的 Windows 为例，就是「MS950」）转成 Unicode。
如果你清楚地知道你要读写的档案（或数据来源 / 去处）是采用某种编码方式，你也可以主动指定编码方式。但是，请记得抓取可能导致的 UnsupportedEncodingException，并务必处理之，不可对此例外置之不理，因为该 JRE 有可能没有附上此种编码表（也有可能你的编码名称给错）。
档案 I/O 转码
如果你是在泰文版的 Windows 上，想读取用 MS950 编码的繁体中文文字文件，你就必须主动指定编码，不可以直接用 FileReader，否则无法成功读取。方法如下：
FileInputStream fis = new FileInputStream(fileName);
InputStreamReader reader = new InputStreamReader(fis, "MS950");
然后，透过 Reader 读出来的就会是正确的中文。
网络 I/O 转码
如果你的网络程序采用 TCP，那么你可以透过 Socket 类别所提供的 getInputStream() 和 getOutputStream() 来得到 InputStream 和 OutputStream 对象。如果你是在泰文版的 Windows 上，想读取用 MS950 编码的繁体中文文字 TCP 网络串流，你可以用类似上面的技巧来转码。方法如下：
InputStream is = mySocket.getInputStream();
InputStreamReader reader = new InputStreamReader(is, "MS950");
如果你的网络程序采用 UDP，你必须把中文字符串转成（或转自）byte 数组。请看下一节「 字符串和 byte 数组的转码 」。
如果你的网络程序采用 RMI，那你完全不用为这部分的转码操心，字符串直接用 Unicode 在网络上传递给另一个 JRE，不需要转码。
保持刑案现场
如果你不知道你的 I/O 数据来源或去处是用何种编码方式，那么你最好不要用 Reader 和 Writer，而应该直接用 InputStream 和 OutputStream，因为与其被 Reader 和 Writer 胡乱编码之后造成信息遗失或错乱，不如保持数据的完整不变，留待以后进一步解读。
字符串和 byte 数组的转码
java.lang.String 类别是 Java 字符串对象的类别，Java 字符串对象既然是活在 JRE 内部，当然就一定是用 Unicode 编码。如果你需要将 String 对象和 byte 数组互转，你可以使用：
String(byte[] bytes, int offset, int length, String enc);
或
String(byte[] bytes, String enc);
来将用 enc 编码的 byte 数组，转成 Unicode 的 String 物件。你也可以使用 String 对象所提供的：
byte[] getBytes(String enc)
来将 String 对象转成 byte 数组。
另外，你也可以透过 ByteArrayInputStream 或 ByteArrayOutputStream 串接到 InputStreamReader 或 OutputStreamWriter，来达到转码的目的。
现在 Java 编程语言已经广泛应用于互联网世界，早在 Sun 公司开发 Java 语言的时候，就已经考虑到对非英文字符的支持了。Sun 公司公布的 Java 运行环境（JRE）本身就分英文版和国际版，但只有国际版才支持非英文字符。不过在 Java 编程语言的应用中，对中文字符的支持并非如同 Java Soft 的标准规范中所宣称的那样完美，因为中文字符集不只一个，而且不同的操作系统对中文字符的支持也不尽相同，所以会有许多和汉字编码处理有关的问题在我们进行应用开发中困扰着我们。有很多关于这些问题的解答，但都比较琐碎，并不能够满足大家迫切解决问题的愿望，关于 Java 中文问题的系统研究并不多，本文从汉字编码常识出发，分析 Java 中文问题，希望对大家解决这个问题有所帮助。
汉字编码的常识
我们知道，英文字符一般是以一个字节来表示的，最常用的编码方法是 ASCII 。但一个字节最多只能区分256个字符，而汉字成千上万，所以现在都以双字节来表示汉字，为了能够与英文字符分开，每个字节的最高位一定为1，这样双字节最多可以表示64K格字符。我们经常碰到的编码方式有 GB2312、BIG5、UNICODE 等。关于具体编码方式的详细资料，有兴趣的读者可以查阅相关资料。我肤浅谈一下和我们关系密切的 GB2312 和 UNICODE。GB<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="True" sourcevalue="2312" unitname="码"></chmetcnv>2312 码，*国家标准汉字信息交换用编码，是一个由*国家标准总局发布的关于简化汉字的编码，通行于*地区及新加坡，简称国标码。两个字节中，第一个字节（高字节）的值为区号值加32（20H），第二个字节（低字节）的值为位号值加32（20H），用这两个值来表示一个汉字的编码。UNICODE 码是微软提出的解决多国字符问题的多字节等长编码，它对英文字符采取前面加“0”字节的策略实现等长兼容。如 “A” 的 ASCII 码为0x41，UNICODE 就为0x00，0x41。利用特殊的工具各种编码之间可以互相转换。
Java 中文问题的初步认识
我们基于 Java 编程语言进行应用开发时，不可避免地要处理中文。Java 编程语言默认的编码方式是 UNICODE，而我们通常使用的数据库及文件都是基于 GB2312 编码的，我们经常碰到这样的情况：浏览基于 JSP 技术的网站看到的是乱码，文件打开后看到的也是乱码，被 Java 修改过的数据库的内容在别的场合应用时无法继续正确地提供信息。
String sEnglish = “apple”;
String sChinese = “苹果”;
String s = “苹果 apple ”;
sEnglish 的长度是5，sChinese的长度是4，而 s 默认的长度是14。对于 sEnglish来说， Java 中的各个类都支持得非常好，肯定能够正确显示。但对于 sChinese 和 s 来说，虽然 Java Soft 声明 Java 的基本类已经考虑到对多国字符的支持（默认 UNICODE 编码），但是如果操作系统的默认编码不是 UNICODE ，而是国标码等。从 Java 源代码到得到正确的结果，要经过 “Java 源代码-%26gt; Java 字节码-%26gt; ;虚拟机-%26gt;操作系统-%26gt;显示设备”的过程。在上述过程中的每一步骤，我们都必须正确地处理汉字的编码，才能够使最终的显示结果正确。
“ Java 源代码-%26gt; Java 字节码”，标准的 Java 编译器 javac 使用的字符集是系统默认的字符集，比如在中文 Windows 操作系统上就是 GBK ,而在 Linux 操作系统上就是ISO-8859-1，所以大家会发现在 Linux 操作系统上编译的类中源文件中的中文字符都出了问题，解决的办法就是在编译的时候添加 encoding 参数，这样才能够与平台无关。用法是
javac ?Cencoding GBK。
“ Java 字节码-%26gt;虚拟机-%26gt;操作系统”， Java 运行环境 （JRE）分英文版和国际版，但只有国际版才支持非英文字符。 Java 开发工具包 （JDK）肯定支持多国字符，但并非所有的计算机用户都安装了 JDK 。很多操作系统及应用软件为了能够更好的支持 Java ，都内嵌了 JRE 的国际版本，为自己支持多国字符提供了方便。
“操作系统-%26gt;显示设备”，对于汉字来说，操作系统必须支持并能够显示它。英文操作系统如果不搭配特殊的应用软件的话，是肯定不能够显示中文的。
还有一个问题，就是在 Java 编程过程中，对中文字符进行正确的编码转换。例如，向网页输出中文字符串的时候，不论你是用
out.println(string);还是用
%26lt;%=string%%26gt;，都必须作 UNICODE 到 GBK 的转换，或者手动，或者自动。在 JSP 1.0中，可以定义输出字符集，从而实现内码的自动转换。用法是
%26lt;%@page contentType=”text/html;charset=gb<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="2312" unitname="”"></chmetcnv>2312” %%26gt;
但是在一些 JSP 版本中并没有提供对输出字符集的支持，（例如 JSP 0.92），这就需要手动编码输出了，方法非常多。最常用的方法是
String s1 = request.getParameter(“keyword”);
String s2 = new String(s1.getBytes(“ISO-8859<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="True" hasspace="False" sourcevalue="1" unitname="”"></chmetcnv>-1”),”GBK”);
getBytes 方法用于将中文字符以“ISO-8859<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="True" hasspace="False" sourcevalue="1" unitname="”"></chmetcnv>-1”编码方式转化成字节数组，而“GBK” 是目标编码方式。我们从以ISO-8859-1方式编码的数据库中读出中文字符串 s1 ，经过上述转换过程，在支持 GBK 字符集的操作系统和应用软件中就能够正确显示中文字符串 s2 。
Java 中文问题的表层分析及处理
背景
开发环境 JDK1.15 Vcafe2.0 JPadPro
服务器端 NT IIS Sybase System Jconnect（JDBC）
客户端 IE5.0 Pwin98 ?span %26gt;
.CLASS 文件存放在服务器端，由客户端的浏览器运行 APPLET ， APPLET 只起调入 FRAME 类等主程序的作用。界面包括 Textfield ，TextArea，List，Choice 等。
I.用 JDBC 执行 SELECT 语句从服务器端读取数据（中文）后，将数据用 APPEND 方法加到 TextArea（TA） ，不能正确显示。但加到 List 中时，大部分汉字却可正确显示。
将数据按“ISO-8859<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="True" hasspace="False" sourcevalue="1" unitname="”"></chmetcnv>-1” 编码方式转化为字节数组，再按系统缺省编码方式 （Default Character Encoding）转化为 STRING ，即可在 TA 和 List 中正确显示。
程序段如下：
dbstr2 = results.getString(1);
//After reading the result from DB server，converting it to string.
dbbyte1 = dbstr2.getBytes(“iso-8859<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="True" hasspace="False" sourcevalue="1" unitname="”"></chmetcnv>-1”);
dbstr1 = new String(dbbyte1);
在转换字符串时不采用系统默认编码方式，而直接采用“ GBK” 或者 “GB2312” ,在 A 和 B 两种情况下，从数据库取数据都没有问题。
II.处理方式与“取中文”相逆，先将 SQL 语句按系统缺省编码方式转化为字节数组，再按“ISO-8859<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="True" hasspace="False" sourcevalue="1" unitname="”"></chmetcnv>-1”编码方式转化为 STRING ，最后送去执行，则中文信息可正确写入数据库。
程序段如下：
sqlstmt = tf_input.getText();
//Before sending statement to DB server，converting it to sql statement.
dbbyte1 = sqlstmt.getBytes();
sqlstmt = newString(dbbyte1,”iso-8859<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="True" hasspace="False" sourcevalue="1" unitname="”"></chmetcnv>-1”);
_stmt = _con.createStatement();
_stmt.executeUpdate(sqlstmt);
……
问题：如果客户机上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 时（称为 A 情况），上述程序代码可正确执行。但是如果客户机只有浏览器，而没有 JDK 和 CLASSPATH 时（称为 B 情况），则汉字无法正确转换。
我们的分析：
1.经过测试，在 A 情况下，程序运行时系统的缺省编码方式为 GBK 或者 GB2312 。在 B 情况下，程序启动时浏览器的 JAVA 控制台中出现如下错误信息：
Can't find resource for sun.awt.windows.awtLocalization_zh_CN
然后系统的缺省编码方式为“8859-1”。
2.如果在转换字符串时不采用系统缺省编码方式，而是直接采用 “GBK” 或“GB2312”，则在 A 情况下程序仍然可正常运行，在 B 情况下，系统出现错误：
UnsupportedEncodingException。
3.在客户机上，把 JDK 的 CLASSES.ZIP 解压后，放在另一个目录中， CLASSPATH 只包含该目录。然后一边逐步删除该目录中的 .CLASS 文件，另一边运行测试程序，最后发现在一千多个 CLASS 文件中，只有一个是必不可少的，该文件是：
sun.io.CharToByteDoubleByte.class。
将该文件拷到服务器端和其它的类放在一起，并在程序的开头 IMPORT 它，在 B 情况下程序仍然无法正常运行。
4.在 A 情况下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，则程序运行时测得默认编码方式为“8859-1”，否则为 “GBK” 或 “GB2312” 。
如果 JDK 的版本为1.2以上的话，在 B 情况下遇到的问题得到了很好的解决，测试的步骤同上，有兴趣的读者可以尝试一下。
Java 中文问题的根源分析及解决
在简体中文 MS Windows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 运行环境的一些基本属性，类 PoorChinese 可以帮助我们得到这些属性。
类 PoorChinese 的源代码：
public class PoorChinese {
}
执行 java PoorChinese 后，我们会得到:
系统变量 file.encoding 的值为 GBK ，user.language 的值为 zh ， user.region 的值为 CN ，这些系统变量的值决定了系统默认的编码方式是 GBK 。
在上述系统中，下面的代码将 GB2312 文件转换成 Big5 文件，它们能够帮助我们理解 Java 中汉字编码的转化:
?
import java.io.*;
import java.util.*;
?
public class gb2big5 {
?
static int iCharNum=0;
?
public static void main(String[] args) {
System.out.println("Input GB2312 file, output Big5 file.");
if (args.length!=2) {
System.err.println("Usage: jview gb2big5 gbfile big5file");
System.exit(1);
String inputString = readInput(args[0]);
writeOutput(inputString,args[1]);
System.out.println("Number of Characters in file: "+iCharNum+".");
}
?
static void writeOutput(String str, String strOutFile) {
try {
FileOutputStream fos = new FileOutputStream(strOutFile);
Writer out = new OutputStreamWriter(fos, "Big5");
out.write(str);
out.close();
}
catch (IOException e) {
e.printStackTrace();
e.printStackTrace();
}
}
?
static String readInput(String strInFile) {
StringBuffer buffer = new StringBuffer();
try {
FileInputStream fis = new FileInputStream(strInFile);
InputStreamReader isr = new InputStreamReader(fis, "GB2312");
Reader in = new BufferedReader(isr);
int ch;
while ((ch = in.read()) %26gt; -1) {
iCharNum += 1;
buffer.append((char)ch);
}
in.close();
return buffer.toString();
}
catch (IOException e) {
e.printStackTrace();
return null;
}
}
}
?
编码转化的过程如下：
GB2312------------------%26gt;Unicode-------------%26gt;Big5
执行 java gb2big5 gb.txt big5.txt ，如果 gb.txt 的内容是“今天星期三”，则得到的文件 big5.txt 中的字符能够正确显示；而如果 gb.txt 的内容是“情人节快乐”，则得到的文件 big5.txt 中对应于“节”和“乐”的字符都是符号“？”（0x<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="3" unitname="F"></chmetcnv>3F），可见 sun.io.ByteToCharGB2312 和 sun.io.CharToByteBig5 这两个基本类并没有编好。
正如上例一样， Java 的基本类也可能存在问题。由于国际化的工作并不是在国内完成的，所以在这些基本类发布之前，没有经过严格的测试，所以对中文字符的支持并不像 Java Soft 所声称的那样完美。前不久，我的一位技术上的朋友发信给我说，他终于找到了 Java Servlet 中文问题的根源。两周以来，他一直为 Java Servlet 的中文问题所困扰，因为每面对一个含有中文字符的字符串都必须进行强制转换才能够得到正确的结果（这好象是大家公认的唯一的解决办法）。后来，他确实不想如此继续安分下去了，因为这样的事情确实不应该是高级程序员所要做的工作，他就找出 Servlet 解码的源代码进行分析，因为他怀疑问题就出在解码这部分。经过四个小时的奋斗，他终于找到了问题的根源所在。原来他的怀疑是正确的， Servlet 的解码部分完全没有考虑双字节，直接把 %XX 当作一个字符。（原来 Java Soft 也会犯这幺低级的错误！）
如果你对这个问题有兴趣或者遇到了同样的烦恼的话，你可以按照他的步骤 对Servlet.jar 进行修改：
找到源代码 HttpUtils 中的 static private String parseName ，在返回前将 sb（StringBuffer） 复制成 byte bs[] ，然后 return new String(bs,”GB<chmetcnv w:st="on" tcsc="0" numbertype="1" negative="False" hasspace="False" sourcevalue="2312" unitname="”"></chmetcnv>2312”)。作上述修改后就需要自己解码了：
HashTable form=HttpUtils .parseQueryString(request.getQueryString())或者
form=HttpUtils.parsePostData(……)
千万别忘了编译后放到 Servlet.jar 里面。
关于 Java 中文问题的总结
Java 编程语言成长于网络世界，这就要求 Java 对多国字符有很好的支持。 Java 编程语言适应了计算的网络化的需求，为它能够在网络世界迅速成长奠定了坚实的基础。 Java 的缔造者 （Java Soft） 已经考虑到 Java 编程语言对多国字符的支持，只是现在的解决方案有很多缺陷在里面，需要我们付诸一些补偿性的措施。而世界标准化组织也在努力把人类所有的文字统一在一种编码之中，其中一种方案是 ISO10646 ，它用四个字节来表示一个字符。当然，在这种方案未被采用之前，还是希望 Java Soft 能够严格地测试它的产品，为用户带来更多的方便。
附一个用于从数据库和网络中取出 中文乱码的处理函数，入参是有问题的字符串，出参是问题已经解决了的字符串。