JSP中文乱码问题的解决

湘里妹子

文章主题: JSP中文乱码问题的解决
发表时间: 2002年07月07日 06时01分  
发表作者: 计算机世界报  
发表内容:
JSP中文乱码问题的解决
彭文波 撰
2002/07/07
计算机世界报 第24期 C22、C23）
来源：青藤书屋
-----------------------------------------------------------------------------------------------

和Java一样，JSP是目前比较热门的一个话题。它是一种在服
务器端编译执行的Web设计语言，因为脚本语言采用了Java
，所以JSP继承了Java的所有优点。可是在使用JSP程序的过
程中，常遇到中文乱码问题，很多人为此头疼不已，笔者就
深受其害，而且使用平台不同，中文乱码问题的解决方法也
不同，无形中增加了学习JSP的难度。其实，在彻底了解相关
原因后，问题还是比较容易解决的。笔者结合自己的工作实
践，对中文显示问题进行了一定的研究，并在不同的环境下
进行了相关测试，以下是笔者总结的解决方法，相信对读者
会有一定的借鉴意义。

字符内码

每个国家（或区域）都规定了计算机信息交换用的字符编码
集，如美国的扩展ASCII码、中国的GB2312-80、日本的 JIS
等，作为该国家(区域)信息处理的基础，有着统一编码的重
要作用。由于各本地字符集代码范围重叠，相互间信息交换
困难，软件本地化版本独立维护成本较高。因此有必要将本
地化工作中的共性抽取出来，做一致性处理，将特殊的本地
化处理内容降低到最少，这就是所谓的国际化（I18N）。各
种语言信息被规范为本地信息，而底层字符集采用包含了所
有字符的Unicode。

字符内码(character code)指的是用来代表字符的内码。我们在
输入和存储文档时都要使用内码，内码分为单字节内码和双
字节内码。单字节内码的英文全称是Single-Byte Character Sets
(SBCS)，可以支持256个字符编码；双字节内码的英文全称是
Double-Byte Character Sets(DBCS)，可以支持65000个字符编码
，主要用来对大字符集的东方文字进行编码。

CodePage指的是一个经过挑选的以特定顺序排列的字符内码
列表，对于早期的单字节内码的语种，CodePage中的内码顺
序使得系统可以按照此列表来根据键盘的输入值给出一个对
应的内码。对于双字节内码，给出的是MultiByte到Unicode的
对应表，这样就可以把以Unicode形式存放的字符转化为相应
的字符内码。引入对CodePage的支持主要是为了访问多语种
文件名，目前在NTFS和FAT32/VFAT下的文件系统上都使用
Unicode，这需要系统在读取这些文件名时动态地将其转换为
相应的语言编码。

相信了解JSP代码的读者对ISO8859-1一定不陌生，ISO8859-1是
我们平时使用比较多的一个CodePage，它属于西欧语系。
GB2312-80 是在国内计算机汉字信息技术发展初始阶段制订
的，其中包含了大部分常用的一、二级汉字和9区的符号。该
字符集是几乎所有的中文系统和国际化的软件都支持的中文
字符集，这也是最基本的中文字符集。

GBK 是 GB2312-80 的扩展，是向上兼容的。它包含了20902个
汉字，其编码范围是 0x8140～0xFEFE，剔除高位 0x80 的字位
，其所有字符都可以一对一映射到 Unicode 2.0，也就是说
Java 实际上提供了对 GBK 字符集的支持。

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

不同开发平台的区别

1．Tomcat 4开发平台

Windows 98／2000下的Tomcat 4以上版本都会出现中文问题
（而在Linux下和Tomcat 3.x中则没有问题），主要表现是页
面显示乱码。在IE中调整字符集为GB2312，就可以正常显示
了。

为解决这个问题，可在每个JSP的页面开始处加上。不过，
这还不够，虽然这时显示了中文，但是发现从数据库读出的
字段变成了乱码。经过分析发现: 在数据库中保存的中文字
符是正常的，数据库用ISO8859-1字符集存取数据，而Java程
序在处理字符时默认采用统一的ISO8859-1字符集(这也体现
了Java国际化思想)，所以在数据添加的时候Java和数据库都
是以ISO8859-1方式处理，这样不会出错。但是在读取数据的
时候就出现问题了，因为数据读出也采用ISO8859-1字符集，
而 JSP的文件头中有语句，这说明页面采用GB2312的字符集
显示，这样就和读出的数据不一样。这时页面显示从数据库
中读出的字符是乱码，解决的方法是对这些字符转码，从
ISO8859-1转成GB2312，就可以正常显示了。这个解决办法对
很多平台具有通用性，读者可以灵活运用。

2．Tomcat 3.x、Resin及Linux平台

在Tomcat 3.x、Resin中或是在Linux下，没有加入语句，而页
面中的语句起了作用，此时可以正常显示。相反，如果加上
系统会报错，说明Tomcat 4以上版本的引擎在处理JSP时还是
有差别的。

另外，对于不同的数据库如SQL Server，Oracle，Mysql，
Sybase等，字符集的选择很重要。如果考虑多语言版本，数
据库的字符集就应该统一采用ISO8859-1，需要输出的时候在
不同的字符集之间做转换就可以了。

以下是针对不同平台的总结：

(1)
JSWDK只适合于普通开发，稳定性和其他问题可能不如商
业软件。 由于JDK 1.3版性能要好于JDK 1.2.2很多，并且对中
文的支持也较好，所以应该尽量采用。

(2)
作为免费的商业软件，Resin不仅速度快、稳定、自动编译，
还可以指出出错行，并可在服务器端支持使用JavaScript等，
而且对中文的支持也很好。

(3)
Tomcat仅仅是一个对JSP 1.1、Servlet 2.2标准的实现, 我们不应
该要求这个免费软件在细节和性能上都面面俱到, 它主要考
虑英文用户, 这也是为什么不做特殊转换，汉字用URL方法传
递就有问题的原因。大部分IE浏览器缺省始终以UTF-8发送,
这似乎是Tomcat的一个不足, 另外Tomcat不管当前的操作系统
是什么语言, 都按ISO8859去编译JSP, 似乎也欠妥。

JSP代码的中文处理

在JSP代码中以下几处经常需要涉及到中文处理:

1.
在URL中附带中文参数。这里中文参数通常可以直接读取，
例如:

2.
在JSWDK中读取HTML表单提交的中文值这时需要加以编码
，较为简洁的写法是：

String name1=new String(request.getParameter(“user_id”).
getBytes(“ISO8859_1”))。

另外，在JDK 1.3的支持下，不需加入 ，而在JDK 1.2.2 以下，
即使以上两种方法同时运用也很不稳定。但在Resin平台，情
况较好，只要在页面第一行加入：即可正确处理中文，如果
再加代码则反而不对。

3．
在JSWDK中Session包含的中文，如果从表单中读出的值经过
编码可正确显示，但直接赋予中文值则不行，而Resin平台则
很好。

4.
在编译Servlet和JSP时加入代码选项。在编译Servlet时使用
Java-Encoding ISO8859-1 myservlet.java；在JSP的ZONE配置文
件中，修改编译参数为：Compiler=builtin - javac- encoding
ISO8859-1。使用这种方法后，不需要做其他的改动就可以
正常显示中文了。

另外，流行的关系数据库系统都支持数据库Encoding，也就
是说在创建数据库时可以指定它自己的字符集设置，数据库
的数据以指定的编码形式存储。当应用程序访问数据时，在
入口和出口处都会有 Encoding 转换。对于中文数据，数据库
字符编码的设置应当保证数据的完整性。 GB2312、GBK、
UTF-8 等都是可选的数据库 Encoding，也可以选择 ISO8859-1
(8-bit)， 但会增加了编程的复杂度，ISO8859-1不是推荐的数
据库 Encoding。在JSP/Servlet编程时，可以先用数据库管理系
统提供的管理功能检查其中的中文数据是否正确。

处理方法实例

下面是两个具体的中文乱码解决实例，读者仔细研究后可能
会有所收获。

1．常见的字符转换方法

将Form 中 的 值 传 送 到 数 据 库 中 再 取 出 来 后 全 变 成
了“？”。Form用POST提交数据，代码中使用了语句：
String st=new(request.getParameter(“name”).getBytes(“ISO8859_1”))， 而且也声明了charset=gb2312。

要处理Form中传递的中文参数，应该在JSP中加入下面的代
码，另外定义一个专门解决这个问题的getStr类，然后对接
收到的参数进行转换：

String keyword1=request.getParameter(“keyword1”);
keyword1=getStr(keyword1);

这样就可以解决问题了，代码如下：

2. JDBC Driver的字符转换

目前大多数JDBC Driver采用本地编码格式来传输中文字符，
例如中文字符“0x4175”会被转成“0x41”和“0x75”进行
传输。因此需要对JDBC Driver返回的字符以及要发给JDBC
Driver的字符进行转换。当用JDBC Driver向数据库中插入数
据时，需要先将Unicode转成Native code; 当 JDBC Driver从数
据库中查询数据时，则需要将Native code转换成Unicode。下
面给出了这两种转换的实现:

String native2Unicode(String s) {
if (s == null || s.length() == 0) {
return null;
}
byte[] buffer = new byte[s.length()];
for (int i = 0; i s.length(); i++) { if (s.charAt(i)>= 0x100) {
c = s.charAt(i);
byte []buf = (“”+c).getBytes();
buffer[j++] = (char)buf[0];
buffer[j++] = (char)buf[1];
}
else {buffer[j++] = s.charAt(i);}
}
return new String(buffer, 0, j);
}

要注意的是，有些JDBC Driver如果通过JDBC Driver Manager
设置了正确的字符集属性，以上方法就不需要了。具体情况
可参考相关JDBC的资料。
------------

相关资料

1.相关标准组织及标准

国际标准组织Unicode(http://www.icode.org)提供了以下转换表:

GB和Unicode转换表:ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/GB;
BIG5和Unicode转换表: ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/OTHER
JIS和Unicode转换表: ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/JIS
KSC和Unicode转换表: ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/KSC

由于GBK不是国家标准，所以Unicode并没有提供GBK到
Unicode的转换表，而只是采用了Microsoft的CodePage的一个
版本:ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/
WINDOWS/CP{936，950}.TXT。

２.相关软件下载

JDK 1.3 http://java.sun.com
Resin 2.0.1 http://www.caochu.com
Apache 1.3.20 http://www.apache.org
MySQL 3.23 http://www.mysql.org
MySQL 3.23 http://www.mysql.org
DBTools 1.0.12 http://www.dbtools.com.dr