JSP/Servlet 中的汉字编码问题

JSP/Servlet 中的汉字编码问题【转载】

关键字: 编码 jsp

1.问题的起源

每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展ASCII码,中国的GB2312-80，日本的JIS等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了LANG,Codepage等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为Locale信息。处理的底层字符集变成了几乎包含了所有字形的Unicode。

现在大部分具有国际化特征的软件核心字符处理都是以Unicode为基础的，在软件运行时根据当时的Locale/Lang/Codepage设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现Unicode和本地字符集的相互转换，甚或以Unicode为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。

Java语言内部是用Unicode表示字符的，遵守UnicodeV2.0。Java程序无论是从/往文件系统以字符流读/写文件，还是往URL连接写HTML信息，或从URL连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。

从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。

2.GB2312-80，GBK，GB18030-2000汉字字符集及Encoding

其实解决JAVA程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需要了解现有的汉字编码和编码转换。

GB2312-80是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和9区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是0xa1-0xfe；汉字从0xb0a1开始，结束于0xf7fe；

GBK是GB2312-80的扩展，是向上兼容的。它包含了20902个汉字，其编码范围是0x8140-0xfefe，剔除高位0x80的字位。其所有字符都可以一对一映射到Unicode2.0，也就是说JAVA实际上提供了GBK字符集的支持。这是现阶段Windows和其它一些中文操作系统的缺省字符集，但并不是所有的国际化软件都支持该字符集，感觉是他们并不完全知道GBK是怎么回事。值得注意的是它不是国家标准，而只是规范。随着GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。

GB18030-2000(GBK2K)在GBK的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。GBK2K从根本上解决了字位不够，字形不足的问题。它有几个特点，

它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。
编码是变长的，其二字节部分与GBK兼容；四字节部分是扩充的字形、字位，其编码范围是首字节0x81-0xfe、二字节0x30-0x39、三字节0x81-0xfe、四字节0x30-0x39。
它的推广是分阶段的，首先要求实现的是能够完全映射到Unicode3.0标准的所有字形。
它是国家标准，是强制性的。
现在还没有任何一个操作系统或软件实现了GBK2K的支持，这是现阶段和将来汉化的工作内容。
Unicode的介绍......就免了吧。

JAVA支持的encoding中与中文编程相关的有：(有几个在JDK文档中未列出)

ASCII7-bit,同ascii7
ISO8859-18-bit,同8859_1,ISO-8859-1,ISO_8859-1,latin1...
GB2312-80同gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381,1383,Cp1383,ISO2022CN,ISO2022CN_GB......
GBK(注意大小写),同MS936
UTF8UTF-8
GB18030(现在只有IBMJDK1.3.?有支持),同Cp1392,1392

JAVA语言采用Unicode处理字符.但从另一个角度来说，在java程序中也可以采用非Unicode的转码，重要的是保证程序入口和出口的汉字信息不失真。如完全采用ISO-8859-1来处理汉字也能达到正确的结果。网络上流行的许多解决方法，都属于这种类型。为了不致引起混淆，本文不对这种方法作讨论。

3.中文转码时'?'、乱码的由来

两个方向转换都有可能得到错误的结果：

Unicode-->;Byte,如果目标代码集不存在对应的代码，则得到的结果是0x3f.
如：
"\u00d6 \u00ec\u00e9\u0046\u00bb \u00f9".getBytes("GBK")的结果是"?ìéF?ù",Hex值是3fa8aca8a6463fa8b4.
仔细看一下上面的结果，你会发现\u00ec被转换为0xa8ac,\u00e9被转换为\xa8a6...它的实际有效位变长了！这是因为GB2312符号区中的一些符号被映射到一些公共的符号编码，由于这些符号出现在ISO-8859-1或其它一些SBCS字符集中，故它们在Unicode中编码比较靠前，有一些其有效位只有8位，和汉字的编码重叠(其实这种映射只是编码的映射，在显示时仔细不是一样的。Unicode中的符号是单字节宽，汉字中的符号是双字节宽).在Unicode\u00a0--\u00ff之间这样的符号有20个。了解这个特征非常重要！由此就不难理解为什么JAVA编程中，汉字编码的错误结果中常常会出现一些乱码(其实是符号字符),而不全是'?'字符,就比如上面的例子。

Byte-->;Unicode,如果Byte标识的字符在源代码集不存在，则得到的结果是0xfffd.
如：
Byteba[]={(byte)0x81,(byte)0x40,(byte)0xb0,(byte)0xa1}&#59;newString(ba,"gb2312")&#59;
结果是"?啊",hex值是"\ufffd \u554a".0x8140是GBK字符，按GB2312转换表没有对应的值，取\ufffd.(请注意：在显示该 uniCode时，因为没有对应的本地字符，所以也适用上一种情况，显示为一个"?".)

实际编程中，JSP/Servlet程序得到错误的汉字信息，往往是这两个过程的叠加，有时甚至是两个过程叠加后反复作用的结果.

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

4.1常见的encoding问题的现象
网上常出现的JSP/Servletencoding问题一般都表现在browser或应用程序端，如:
浏览器中看到的Jsp/Servlet页面中的汉字怎么都成了’?’?
浏览器中看到的Servlet页面中的汉字怎么都成了乱码？
JAVA应用程序界面中的汉字怎么都成了方块？
Jsp/Servlet页面无法显示GBK汉字。
JSP页面中内嵌在<%...%>;,<%=...%>;等Tag包含的JAVAcode中的中文成了乱码，但页面的其它汉字是对的。
Jsp/Servlet不能接收form提交的汉字。
JSP/Servlet数据库读写无法获得正确的内容。
隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为Javafont设置错误引起的）。解决类似的字符encoding问题，需要了解Jsp/Servlet的运行过程，检查可能出现问题的各个点。

4.2JSP/Servletweb编程时的encoding问题
运行于Java应用服务器的JSP/Servlet为Browser提供HTML内容，其过程如下图所示：



其中有字符编码转换的地方有:

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


Java需要被编译为.class才能在JVM中执行，这个过程存在与a.同样的file.encoding问题。从这里开始servlet和jsp的运行就类似了，只不过Servlet的编译不是自动进行的。对于 JSP程序,对产生的JAVA中间文件的编译是自动进行的(在程序中直接调用sun.tools.javac.Main类).因此如果在这一步出现问题的话,也要检查encoding和OS的语言环境，或者将内嵌在JSPJAVACode中的静态汉字转为Unicode,要么静态文本输出不要放在JAVAcode中。对于Servlet,javac编译时手工指定-encoding参数就可以了。


Servlet需要将HTML页面内容转换为browser可接受的encoding内容发送出去。依赖于各JAVAAppServer的实现方式，有的将查询Browser的accept-charset和accept-language参数或以其它猜的方式确定encoding值，有的则不管。因此采用固定encoding也许是最好的解决方法。对于中文网页，可在JSP或Servlet中设置contentType=&quot;text/html&#59;charset=GB2312&quot;；如果页面中有GBK字符，则设置为contentType=&quot;text/html&#59;charset=GBK& quot;，由于IE和Netscape对GBK的支持程度不一样，作这种设置时需要测试一下。
因为16位JAVAchar在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的和servlet运行过程中得到的）是期望的内码，可以用PrintWriterout=res.getWriter()取代ServletOutputStreamout=res.getOutputStream().PrinterWriter将根据 contentType中指定的charset作转换(ContentType需在此之前指定！)&#59;也可以用 OutputStreamWriter封装ServletOutputStream类并用write(String)输出汉字字符串。
对于JSP，JAVAApplicationServer应当能够确保在这个阶段将嵌入的汉字正确传送出去。


这是解释URL字符encoding问题。如果通过get/post方式从browser返回的参数值中包含汉字信息，servlet将无法得到正确的值。SUN的J2SDK中，HttpUtils.parseName在解析参数时根本没有考虑browser的语言设置，而是将得到的值按byte方式解析。这是网上讨论得最多的encoding问题。因为这是设计缺陷，只能以bin方式重新解析得到的字符串；或者以hackHttpUtils类的方式解决。参考文章2均有介绍，不过最好将其中的中文encodingGB2312、CP1381都改为GBK，否则遇到GBK汉字时，还是会有问题。
ServletAPI2.3提供一个新的函数HttpServeletRequest.setCharacterEncoding用于在调用request.getParameter(“param_name”)前指定应用程序希望的encoding，这将有助于彻底解决这个问题。

-----------------------------------------------

我是在日文操作系统下做的一套中文的管理系统。
注意jsp的输出content-type为utf-8,html标记内容的头的content-type也设定为utf-8。
1。servlet接收客户请求信息时，在调用getParameter()之前掉一次request.setCharacterEncoding("UTF-8");就可了。之后接收的信息可以直接存入SQLSERVER,不会出现乱码。
2。从数据库读出地汉字不用作任何转换，直接OUT.PRINTLN即可。
很简单吧。
用得着那么繁琐一大堆吗。
注意UTF-8可是国际编码。

----------------------------------------------

我也碰到类似问题，一开始用：

response.setContentType("text/html;charset=GB2312");
request.setCharacterEncoding("GB2312");
PrintWriterout=response.getWriter();
.
.
.
//name是一个开始时外部url传入，后来由表单的Get,Post传入的参数，可为中文
Stringname=request.getParameter("name");

以上代码可正常显示表单GET,POST编码的数据，但对于自己手工形成的经编码后的中文参数，则不能正常显示，改成以下代码后一切显示正常。


response.setContentType("text/html;charset=GB2312");
request.setCharacterEncoding("ISO-8859-1");
PrintWriterout=response.getWriter();
.
.
.
//name是一个开始时外部url传入，后来由表单的Get,Post传入的参数，可为中文
Stringname=newString(request.getParameter("name").getBytes("ISO-8859-1"),"GB2312");

//即可正常显示汉字


造成以上差异的原因在于：使用第一种编码，当手工输入url时，因还没有调用【request.setCharacterEncoding("GB2312");】，系统默认按"iso-8859-1"参数由java解释成单字节，故显示为问号及乱码，第二次经由表单的GET或POST编码，则已按照【request.setCharacterEncoding("GB2312");】设置后的"GB2312"解释，故又能正常显示。

第二种代码则统一按“iso-8859-1”接收，并统一转换成GB2312,故都可正常显示。