Java开发网 - jsp/servlet中文问题解决办法

Topic: jsp/servlet中文问题解决办法

1.jsp/servlet中文问题解决办法

Posted by: haifeng345
Posted on: 2004-09-16 11:13

jsp/servlet中文问题解决办法

引言：
我想要是世界上所有人都用同一种语言来沟通，用共同的符号来交流信息，那么我们的工作会简单多了，可是，那只能停留在理想中了，因为世界太大了。那么我们开发程序的也麻烦不少，但是问题，我们就会有办法。好了，言归正转，我们开始讨论我们的问题： jsp/servlet中文问题解决办法。正如我们所知道的那样，每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展 ASCII码, 中国的GB2312-80,日本的 JIS 等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为 SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了 LANG, Codepage 等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为 Locale 信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode。
现在大部分具有国际化特征的软件核心字符处理都是以 Unicode 为基础的，在软件运行时根据当时的Locale/Lang/Codepage 设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现 Unicode 和本地字符集的相互转换，甚或以 Unicode 为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。
Java 语言内部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序无论是从/往文件系统以字符流读/写文件，还是往 URL 连接写 HTML 信息，或从 URL 连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode 和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。

我们把问题的分析一下：
其实解决 JAVA 程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需要了解现有的汉字编码和编码转换。GB2312-80 是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和 9 区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是 0xa1-0xfe；汉字从 0xb0a1 开始，结束于 0xf7fe；GBK 是 GB2312-80 的扩展，是向上兼容的。它包含了 20902个汉字，其编码范围是 0x8140-0xfefe，剔除高位 0x80 的字位。其所有字符都可以一对一映射到 Unicode 2.0，也就是说 JAVA 实际上提供了GBK 字符集的支持。这是现阶段 Windows 和其它一些中文操作系统的缺省字符集，但并不是所有的国际化软件都支持该字符集，感觉是他们并不完全知道 GBK 是怎么回事。值得注意的是它不是国家标准，而只是规范。随着 GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。GBK2K 从根本上解决了字位不够，字形不足的问题。它有几个特点,它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。编码是变长的，其二字节部分与 GBK 兼容；四字节部分是扩充的字形、字位，其编码范围是首字节0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39。它的推广是分阶段的，首先要求实现的是能够完全映射到 Unicode 3.0 标准的所有字形。它是国家标准，是强制性的。现在还没有任何一个操作系统或软件实现了 GBK2K 的支持，这是现阶段和将来汉化的工作内容。 Unicode 的介绍......就免了吧。JAVA 支持的encoding中与中文编程相关的有：(有几个在JDK文档中未列出)ASCII 7-bit, 同 ascii7 ISO8859-1 8-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 UTF8 UTF-8
GB18030 (如：IBM JDK1.5有支持), 同Cp1392,1392 JAVA 语言采用Unicode处理字符. 但从另一个角度来说，在java程序中也可以采用非Unicode的转码，重的是保证程序入口和出口的汉字信息不失真。如完全采用ISO-8859-1来处理汉字也能达到正确的结果。网络上流行的许多解决方法，都属于这种类型。为了不致引起混淆，本文不对这种方法作讨论。

我们再对问题进一步分析：
乱码的由来，两个方向转换都有可能得到错误的结果：Unicode-->Byte, 如果目标代码集不存在对应的代码，则得到的结果是0x3f. 如："u00d6u00ecu00e9u0046u00bbu00f9".getBytes("GBK") 的结果是 "?ìéF?ù", Hex 值是3fa8aca8a6463fa8b4. 仔细看一下上面的结果，你会发现u00ec被转换为0xa8ac, u00e9被转换为xa8a6... 它的实际有效位变长！这是因为GB2312符号区中的一些符号被映射到一些公共的符号编码，由于这些符号出现在ISO-8859-1或其它一些SBCS字符集中，故它们在Unicode中编码比较靠前，有一些其有效位只有8位，和汉字的编码重叠(其实这种映射只是编码的映射，在显示时仔细不是一样的。Unicode 中的符号是单字节宽，汉字中的符号是双字节宽) . 在Unicodeu00a0--u00ff 之间这样的符号有20个。了解这个特征非常重要！由此就不难理解为什么JAVA编程中，汉字编码的错误结果中常常会出现一些乱码(其实是符号字符), 而不全是'?'字符, 就比如上面的例子。Byte-->Unicode, 如果Byte标识的字符在源代码集不存在，则得到的结果是0xfffd. 如：Byte ba[] = {(byte)0x81,(byte)0x40,(byte)0xb0,(byte)0xa1}; new String(ba,"gb2312"); 结果是"?啊", hex 值是"ufffdu554a". 0x8140 是GBK字符，按GB2312转换表没有对应的值，取ufffd. (请注意：在显示该uniCode时，因为没有对应的本地字符，所以也适用上一种情况，显示为一个"?".)实际编程中，JSP/Servlet 程序得到错误的汉字信息，往往是这两个过程的叠加，有时甚至是两个过程叠加后反复作用的结果. 常见的 encoding 问题的现象网上常出现的 JSP/Servlet encoding 问题一般都表现在 browser 或应用程序端，如: 浏览器中看到的 Jsp/Servlet 页面中的汉字怎么都成了 ’?’ ? 浏览器中看到的 Servlet 页面中的汉字怎么都成了乱码？ JAVA 应用程序界面中的汉字怎么都成了方块？ Jsp/Servlet 页面无法显示 GBK 汉字。 JSP 页面中内嵌在,等Tag包含的 JAVA code 中的中文成了乱码，但页面的其它汉字是对的。 Jsp/Servlet 不能接收 form 提交的汉字。JSP/Servlet 数据库读写无法获得正确的内容。隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为 Java font 设置错误引起的）。解决类似的字符 encoding 问题，需要了解 Jsp/Servlet 的运行过程，检查可能出现问题的各个点。JSP/Servlet web 编程时的 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的语言环境，或者将内嵌在JSP JAVA Code 中的静态汉字转为 Unicode, 要么静态文本输出不要放在 JAVA code 中。对于Servlet, javac 编译时手工指定-encoding 参数就可以了。Servlet 需要将 HTML 页面内容转换为 browser 可接受的 encoding 内容发送出去。依赖于各 JAVAApp Server 的实现方式，有的将查询 Browser 的 accept-charset 和 accept-language 参数或以其它猜的方式确定 encoding 值，有的则不管。因此采用固定encoding 也许是最好的解决方法。对于中文网页，可在 JSP 或 Servlet 中设置 contentType="text/html; charset=GB2312"；如果页面中有GBK字符，则设置为contentType="text/html; charset=GBK"，由于IE 和 Netscape对GBK的支持程度不一样，作这种设置时需要测试一下。因为16位 JAVA char在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的和servlet运行过程中得到的）是期望的内码，可以用 PrintWriter out=res.getWriter() 取代 ServletOutputStream out=res.getOutputStream(). PrinterWriter 将根据contentType中指定的charset作转换 (ContentType需在此之前指定！); 也可以用OutputStreamWriter封装 ServletOutputStream 类并用write(String)输出汉字字符串。对于 JSP，JAVA Application Server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。这是解释 URL 字符 encoding 问题。如果通过 get/post 方式从 browser 返回的参数值中包含汉字信息， servlet 将无法得到正确的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析参数时根本没有考虑 browser 的语言设置，而是将得到的值按 byte 方式解析。这是网上讨论得最多的 encoding 问题。因为这是设计缺陷，只能以 bin 方式重新解析得到的字符串；或者以 hack HttpUtils 类的方式解决。

编程中解决乱码的办法总是有的，三种：
1．用JavaBean直接转换编码：
在中文的系统中:
用com.chinalean.util.TranslateTypes.java 的 ISO8859_1Togb2312(String)和 gb2312ToISO8859_1(String)两个函数，在JavaBean中转换函数：gb2312ToISO8859_1 (String )是把传入的gb2312编码格式的字符串转换成ISO8859-1编码格式的字符串传出。ISO8859_1Togb2312(String) 是把传入的ISO8859-1编码格式的字符串转换成gb2312编码格式的字符串传出。
com.chinalean.util.TranslateTypes.java//源码
package com.chinalean.util;
public class TranslateTypes {
public TranslateTypes() {
}
public static String ISO8859_1Togb2312(String ISO) throws Exception {
if (ISO == null) {
return "";
}
else {
return new String(ISO.trim().getBytes("ISO8859_1"), "gb2312");
}
}
public static String gb2312ToISO8859_1(String gb) throws Exception {
if (gb == null) {
return "";
}
else {
return new String(gb.trim().getBytes("gb2312"), "ISO8859_1");
}
}
}
用法：
在jsp页面中即：<%@ page contentType="text/html;charset=ISO8859_1" %>
表示页面显示编码方式是ISO8859-1编码方式。
在页面提交到服务端的数据都用ISO8859_1Togb2312（String）转换在处理，服务端传给页面显示的变量数据都要通过gb2312ToISO8859_1（String）转换才显示。
优缺点：
在服务端用gb2312编码，在客户端（浏览器端）用ISO8859-1编码，清晰，
但是编成麻烦，每个地方都要加转换函数，程序代码增多。
2．Servlet2.3后直接调用输出流转换函数的方式：
在jsp中的用request.SetCharacterEncoding("GB2312");明确声明输入流编码方式是GB2312 ，页面中用charset= GB2312编码方式显示，即：<%@ page contentType="text/html;charset= GB2312 " %>
优缺点：
比第一种方式编成相对简单，只虽在jsp或servlet中声明输入流是GB2312的方式，在页面中显示的编码方式也是GB2312就可以了，不过必须在Servlet2.3后才有setCharacterEncodeing(“GB2312”)函数。
3．运用滤器Filter转换编码方式
可以编写字符过滤器Filter来解决中文问题。
在web.xml对这个Filter进行配置：
<filter>
<filter-name>Encoding</filter-name>
<filter-class>com.chinalean.util.EncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GB2312</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>Encoding</filter-name>
<servlet-name>action</servlet-name>
</filter-mapping>
<filter-mapping>
<filter-name>Encoding</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
滤器Filter com.chinalean.util.EncodingFilter的源代码

package com.chinalean.util;
public class EncodingFilter implements Filter {
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
request.setCharacterEncoding("GBK"); // 要求是 servlet2.3
chain.doFilter(request, response);
}
}
优缺点：
比第一第二种方式都简单，在jsp，servlet不必考虑中文转换问题，把所有转换中文问题让filterl来做了，同时也必须在servlet2.3后才支持过滤器filter。

对于以上三中方法我推荐现在使用方法3
方法1过于烦琐，增加JavaBean，jsp，EJB的工作，不利于开发JavaBean的工作。
方法3是在良好框架开发程序的最好选择。

冯仕海
2004-9-14

2.Re:jsp/servlet中文问题解决办法 [Re: haifeng345]	Copy to clipboard
Posted by: creal Posted on: 2004-09-22 15:13 比较有用，谢谢