3、JSP/Servlet 汉字编码问题及在 WAS 中的解决办法

3.1 常见的 encoding 问题的现象

网上常出现的 JSP/Servlet encoding 问题一般都表现在 browser 或应用程序端，如:

●浏览器中看到的 Jsp/Servlet 页面中的汉字怎么都成了 ’?’ ?
　　●浏览器中看到的 Servlet 页面中的汉字怎么都成了乱码？
　　●JAVA 应用程序界面中的汉字怎么都成了方块？
　　●Jsp/Servlet 页面无法显示 GBK 汉字。
　　●Jsp/Servlet 不能接收 form 提交的汉字。
　　●JSP/Servlet 数据库读写无法获得正确的内容。

隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为Javafont设置错误引起的）。解决类似的字符encoding问题，需要了解 Jsp/Servlet 的运行过程，检查可能出现问题的各个点。

3.2 JSP/Servlet web 编程时的 encoding 问题

运行于Java 应用服务器的 JSP/Servlet 为 Browser 提供 HTML 内容，其中有字符编码转换的地方有：

a.JSP 编译。Java 应用服务器将根据 JVM 的 file.encoding 值读取 JSP 源文件，并转换为内部字符编码进行 JSP 编译，生成 JAVA 源文件，根据file.encoding值写回文件系统。如果当前系统语言支持GBK，那么这时候不会出现encoding问题。如果是英文的系统，如LANG 是 en_US的Linux,AIX或Solaris，则要将JVM的file.encoding值置成GBK。系统语言如果是GB2312，则根据需要，确定要不要设置file.encoding，将 file.encoding 设为 GBK 可以解决潜在的 GBK 字符乱码问题

b.Java需要被编译为.class才能在JVM中执行，这个过程存在与a.同样的file.encoding问题。从这里开始servlet和jsp的运行就类似了，只不过 Servlet 的编译不是自动进行的。

c.Servlet需要将HTML页面内容转换为browser可接受的encoding内容发送出去。依赖于各JAVAAppServer的实现方式，有的将查询 Browser的accept-charset和accept-language参数或以其它猜的方式确定encoding值，有的则不管。因此constant-encoding也许是最好的解决方法。对于中文网页，可在JSP或Servlet中设置contentType="text/html;charset=GB2312"；如果页面中有GBK字符，则设置为contentType="text/html; charset=GBK"，由于IE 和 Netscape对GBK的支持程度不一样，作这种设置时需要测试一下。

因为16位JAVAchar在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的和servlet运行过程中得到的）是期望的内码，可以用PrintWriterout=res.getWriter()取代ServletOutputStreamout=res.getOutputStream(),PrinterWriter将根据contentType中指定的charset作转换(ContentType需在此之前指定！);也可以用OutputStreamWriter封装ServletOutputStream类并用write(String)输出汉字字符串。对于 JSP，JAVA Application Server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。

d.这是URL字符encoding问题。如果通过get/post方式从browser返回的值中包含汉字信息，servlet将无法得到正确的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析参数时根本没有考虑 browser 的语言设置，而是将得到的值按 byte 方式解析。这是网上讨论得最多的 encoding问题。因为这是设计缺陷，只能以bin方式重新解析得到的字符串；或者以hackHttpUtils类的方式解决。参考文章2、3均有介绍，不过最好将其中的中文 encoding GB2312、 CP1381 都改为 GBK，否则遇到 GBK 汉字时，还是会有问题。

ServletAPI2.3提供一个新的函数HttpServeletRequest.setCharacterEncoding用于在调用request.getParameter(“param_name”) 前指定应用程序希望的 encoding，这将有助于彻底解决这个问题。

WebSphere Application Server 对标准的 Servlet API 2.x 作了扩展，提供较好的多语言支持。上述c,d情况，WAS 都要查询 Browser 的语言设置，在缺省状况下zh、zh-cn 等均被映射为 JAVA encoding CP1381（注意：CP1381 只是等同于 GB2312 的一个 codepage，没有 GBK 支持）。这样做我想是因为无法确认 Browser 运行的操作系统是支持GB2312, 还是 GBK，所以取其小。但是实际的应用系统还是要求页面中出现 GBK 汉字，最著名的是朱总理名字中的“?”(rong2 ，0xe946，\u9555)，所以有时还是需要将 Encoding/Charset 指定为 GBK。当然 WAS 中变更缺省的 encoding 没有上面说的那么麻烦，针对 a,b，参考文章 5 ），在 Application Server 的命令行参数中指定-Dfile.encoding=GBK即可；针对d，在ApplicationServer的命令行参数中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情况下可以不再指定charset。

3.3 数据库读写时的 encoding 问题

JSP/Servlet 编程中经常出现 encoding 问题的另一个地方是读写数据库中的数据。流行的关系数据库系统都支持数据库 encoding，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有 encoding 转换。对于中文数据，应当保证数据的完整性。GB2312，GBK，UTF-8 等都是可选的数据库 encoding；如果选择 ISO8859-1(8-bitSBCS)，那么应用程序在写数据之前须将16Bit的一个汉字或Unicode拆分成两个8-bit的字符，读数据之后则需将两个字节合并起来，同时还有判别其中的 SBCS 字符。没有充分利用数据库 encoding 的作用，反而增加了编程的复杂度，ISO8859-1不是推荐的数据库 encoding。JSP/Servlet编程时，可以先用数据库管理系统提供的功能检查其中的中文数据是否正确。

然后应当注意的是读出来的数据的 encoding，JAVA 程序中一般得到的是 Unicode。写数据时则相反。

3.4 定位问题时常用的技巧

定位中文encoding问题通常采用最笨的也是最有效的办法——在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字符串的内码，你可以发现什么时候中文字符被转换成Unicode，什么时候Unicode被转回中文内码，什么时候一个中文字成了两个Unicode字符，什么时候中文字符串被转成了一串问号，什么时候中文字符串的高位被截掉了……

取用合适的样本字符串也有助于区分问题的类型。如：”aa啊aa?aa”等中英相间、GB、GBK特征字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，可以尝试着增加连续的英文字母长度）。