[转-整理]JSP和Servlet对中文的处理
汉字是双字节的。所谓双字节是指一个双字要占用两个BYTE的位置(即16位)，分别称为高位和低位。中国规定的汉字编码为GB2312，这是强制性的，目前几乎所有的能处理中文的应用程序都支持GB2312
另外有一种编码，叫做GBK，但这是一份规范，不是强制的
Unicode有一个特性：它包括了世界上所有的字符字形。所以，各个地区的语言都可以建立与Unicode的映射关系，而Java正是利用了这一点以达到异种语言之间的转换
JSP：源文件为GB2312格式的文本文件，且JSP源文件中有“中文”这两个汉字
假如指定了＜JSP-charset＞为GB2312，转化进程如下表。
表4 JSP-charset = GB2312时的变化进程
| 序号 | 步骤说明 | 后果 |
| 1 | 编写JSP源文件，且存为GB2312格式 | D6 D0 CE C4 （D6D0=中 CEC4=文） |
| 2 | JSPc把JSP源文件转化为临时Java文件，并把字符串按照GB2312映照到Unicode，并用UTF格式写入JAVA文件中 | E4 B8 AD E6 96 87 |
| 3 | 把临时JAVA文件编译成CLASS文件 | E4 B8 AD E6 96 87 |
| 4 | 运转时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码 | 4E 2D 65 87（在Unicode中4E2D=中 6587=文） |
| 5 | 根据Jsp-charset=GB2312把Unicode转化为字节流 | D6 D0 CE C4 |
| 6 | 把字节流输出到IE中，并设置IE的编码为GB2312（作者按：这个消息躲藏在HTTP头中） | D6 D0 CE C4 |
| 7 | IE用“简体中文”检查后果 | “中文”（正确显现） |
假如指定了＜JSP-charset＞为ISO8859-1，转化进程如下表。
表5 JSP-charset = ISO8859-1时的变化进程
| 序号 | 步骤说明 | 后果 |
| 1 | 编写JSP源文件，且存为GB2312格式 | D6 D0 CE C4 （D6D0=中 CEC4=文） |
| 2 | JSPc把JSP源文件转化为临时Java文件，并把字符串按照ISO8859-1映照到Unicode，并用UTF格式写入JAVA文件中 | C3 96 C3 90 C3 8E C3 84 |
| 3 | 把临时JAVA文件编译成CLASS文件 | C3 96 C3 90 C3 8E C3 84 |
| 4 | 运转时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码 | 00 D6 00 D0 00 CE 00 C4 （啥都不是！！！） |
| 5 | 根据JSP-charset=ISO8859-1把Unicode转化为字节流 | D6 D0 CE C4 |
| 6 | 把字节流输出到IE中，并设置IE的编码为ISO8859-1（作者按：这个消息躲藏在HTTP头中） | D6 D0 CE C4 |
| 7 | IE用“西欧字符”检查后果 | 乱码，其实是四个ASCII字符，但由于大于128，所以显现出来的怪模怪样 |
| 8 | 改变IE的页面编码为“简体中文” | “中文”（正确显现） |
奇异了！为什么把＜JSP-charset＞设成GB2312和ISO8859-1是一个样的，都能正确显现？由于表4表5中的第2步和第5步互逆，是相互“抵消”的。只不过当指定为ISO8859-1时，要增加第8步操作，殊为不便。
再看看不指定＜JSP-charset＞ 时的情况。
表6 未指定JSP-charset 时的变化进程
| 序号 | 步骤说明 | 后果 |
| 1 | 编写JSP源文件，且存为GB2312格式 | D6 D0 CE C4 （D6D0=中 CEC4=文） |
| 2 | JSPc把JSP源文件转化为临时Java文件，并把字符串按照ISO8859-1映照到Unicode，并用UTF格式写入JAVA文件中 | C3 96 C3 90 C3 8E C3 84 |
| 3 | 把临时JAVA文件编译成CLASS文件 | C3 96 C3 90 C3 8E C3 84 |
| 4 | 运转时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码 | 00 D6 00 D0 00 CE 00 C4 |
| 5 | 根据Jsp-charset=ISO8859-1把Unicode转化为字节流 | D6 D0 CE C4 |
| 6 | 把字节流输出到IE中 | D6 D0 CE C4 |
| 7 | IE用发出请求时的页面的编码检查后果 | 视情况而定。假如是简体中文，则能正确显现，否则，需施行表5中的第8步 |
Servlet：源文件为Java文件，格式是GB2312，源文件中含有“中文”这两个汉字
假如＜Compile-charset＞＝GB2312，＜Servlet-charset＞=GB2312
表7 Compile-charset=Servlet-charset=GB2312 时的变化进程
| 序号 | 步骤说明 | 后果 |
| 1 | 编写Servlet源文件，且存为GB2312格式 | D6 D0 CE C4 （D6D0=中 CEC4=文） |
| 2 | 用Javac –encoding GB2312把JAVA源文件编译成CLASS文件 | E4 B8 AD E6 96 87 （UTF） |
| 3 | 运转时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码 | 4E 2D 65 87 (Unicode) |
| 4 | 根据Servlet-charset=GB2312把Unicode转化为字节流 | D6 D0 CE C4 (GB2312) |
| 5 | 把字节流输出到IE中并设置IE的编码属性为Servlet-charset=GB2312 | D6 D0 CE C4 (GB2312) |
| 6 | IE用“简体中文”检查后果 | “中文”（正确显现） |
假如＜Compile-charset＞＝ISO8859-1，＜Servlet-charset＞=ISO8859-1
表8 Compile-charset=Servlet-charset=ISO8859-1时的变化进程
| 序号 | 步骤说明 | 后果 |
| 1 | 编写Servlet源文件，且存为GB2312格式 | D6 D0 CE C4 （D6D0=中 CEC4=文） |
| 2 | 用Javac –encoding ISO8859-1把JAVA源文件编译成CLASS文件 | C3 96 C3 90 C3 8E C3 84 （UTF） |
| 3 | 运转时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码 | 00 D6 00 D0 00 CE 00 C4 |
| 4 | 根据Servlet-charset=ISO8859-1把Unicode转化为字节流 | D6 D0 CE C4 |
| 5 | 把字节流输出到IE中并设置IE的编码属性为Servlet-charset=ISO8859-1 | D6 D0 CE C4 (GB2312) |
| 6 | IE用“西欧字符”检查后果 | 乱码（缘由同表5） |
| 7 | 改变IE的页面编码为“简体中文” | “中文”（正确显现） |
假如不指定Compile-charset或Servlet-charset，其默许值均为ISO8859-1。
当Compile-charset=Servlet-charset时，第2步和第4步能互逆，“抵消”，显现后果均能正确。读者可试着写一下Compile-charset＜＞Servlet-charset时的情况，肯定是不正确的。
当输出对象是数据库时
输出到数据库时，原理与输出到阅读器也是一样的。本节只是Servlet为例，JSP的情况请读者自行推导。
假定有一个Servlet，它能接纳来自客户端（IE，简体中文）的汉字字符串，然后把它写入到内码为ISO8859-1的数据库中，然后再从数据库中取出这个字符串，显现到客户端。
表9 输出对象是数据库时的变化进程（1）
| 序号 | 步骤说明 | 后果 | 域 |
| 1 | 在IE中输出“中文” | D6 D0 CE C4 | IE |
| 2 | IE把字符串改变成UTF，并送入传输流中 | E4 B8 AD E6 96 87 | |
| 3 | Servlet接纳到输出流，用readUTF读取 | 4E 2D 65 87(unicode) | Servlet |
| 4 | 编程者在Servlet中必需把字符串根据GB2312复原为字节流 | D6 D0 CE C4 | |
| 5 | 编程者根据数据库内码ISO8859-1生成新的字符串 | 00 D6 00 D0 00 CE 00 C4 | |
| 6 | 把重生成的字符串提交给JDBC | 00 D6 00 D0 00 CE 00 C4 | |
| 7 | JDBC检测到数据库内码为ISO8859-1 | 00 D6 00 D0 00 CE 00 C4 | JDBC |
| 8 | JDBC把接纳到的字符串按照ISO8859-1生成字节流 | D6 D0 CE C4 | |
| 9 | JDBC把字节流写入数据库中 | D6 D0 CE C4 | |
| 10 | 完成数据存储任务 | D6 D0 CE C4 数据库 | |
|
以下是从数据库中取出数的进程
|
|||
| 11 | JDBC从数据库中取出字节流 | D6 D0 CE C4 | JDBC |
| 12 | JDBC按照数据库的字符集ISO8859-1生成字符串，并提交给Servlet | 00 D6 00 D0 00 CE 00 C4 (Unicode) | ? |
| 13 | Servlet获得字符串 | 00 D6 00 D0 00 CE 00 C4 (Unicode) | Servlet |
| 14 | 编程者必需根据数据库的内码ISO8859-1复原成原始字节流 | D6 D0 CE C4 | ? |
| 15 | 编程者必需根据客户端字符集GB2312生成新的字符串 | 4E 2D 65 87 （Unicode） |
? |
|
Servlet预备把字符串输出到客户端
|
|||
| 16 | Servlet根据＜Servlet-charset＞生成字节流 | D6D0 CE C4 | Servlet |
| 17 | Servlet把字节流输出到IE中，假如已指定＜Servlet-charset＞，还会设置IE的编码为＜Servlet-charset＞ | D6 D0 CE C4 | |
| 18 | IE根据指定的编码或默许编码检查后果 | “中文”（正确显现） | IE |
注释一下，表中第4第5步和第15第16步是用白色标志的，表示要由编码者来作转换。第4、5两步其实就是一句话：“new String(source.getBytes("GB2312"), "ISO8859-1")”。第15、16两步也是一句话：“new String(source.getBytes("ISO8859-1"), "GB2312")”。亲爱的读者，你在这样编写代码时能承认识到了其中的每一个细节呢？
至于客户端内码和数据库内码为其它值时的流程，和输出对象是零碎掌握台时的流程，请读者本人想吧。明白了上述流程的原理，相信你能够紧张地写出来。
行文至此，已可告一段落了。起点又回到了起点，关于编程者而言，几乎是什么影响都没有。
由于我们早就被告之要这么做了。
以下给出一个结论，作为开头。
1、 在JSP文件中，要指定contentType，其中，charset的值要与客户端阅读器所用的字符集一样；关于其中的字符串常量，不需做任何内码转换；关于字符串变量，请求能根据ContentType中指定的字符集复原成客户端能辨认的字节流，简单地说，就是“字符串变量是基于＜Jsp-charset＞字符集的”；
2、 在Servlet中，必需用HttpServletResponse.setContentType()设置charset，且设置成与客户端内码一致；关于其中的字符串常量，需求在Javac编译时指定encoding，这个encoding必需与编写源文件的平台的字符集一样，普通说来都是GB2312或GBK；关于字符串变量，与JSP一样，必需“是基于＜Servlet-charset＞字符集的”。