JSP数据库Tomcat 产生乱码解决方案总结及原因（转三）

jsp中文问题解决之道[转载]

和Java一样，JSP是目前比较热门的一个话题。它是一种在服务器端编译执行的Web设计语言，因为脚本

语言采用了Java，所以JSP继承了Java的所有优点。可是在使用JSP程序的过程中，常遇到中文乱码问题

，很多人为此头疼不已，初学的时候我就深受其害，而且使用平台不同，中文乱码问题的解决方法也不

同，无形中增加了学习JSP的难度。其实，在彻底了解相关原因后，问题还是比较容易解决的。，以下

是我总结的解决方法，相信对读者会有一定的借鉴意义。  (因为我使用得最多的是Tomcat环境，所以

主要是以Tomcat为例，其它的环境只会提及一下，但解决办法也是差不多的!
每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展ASCII码、中国的GB2312

-80、日本的  JIS  等，作为该国家(区域)信息处理的基础，有着统一编码的重要作用。由于各本地字

符集代码范围重叠，相互间信息交换困难，软件本地化版本独立维护成本较高。因此有必要将本地化工

作中的共性抽取出来，做一致性处理，将特殊的本地化处理内容降低到最少，这就是所谓的国际化

（I18N）。各种语言信息被规范为本地信息，而底层字符集采用包含了所有字符的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中则没有问

题），主要表现是页面显示乱码。
为解决这个问题，最简单的方法就是在每个JSP的页面开始处加上<%@  page  language=“Java” 

contentType=“text/html;  charset=gb2312”%>。不过，这还不够，虽然这时显示了中文，但是发现

从数据库读出的字段变成了乱码。经过分析发现:  在数据库中保存的中文字符是正常的，数据库用

ISO8859-1字符集存取数据，而Java程序在处理字符时默认采用统一的ISO8859-1字符集(这也体现了

Java国际化思想)，所以在数据添加的时候Java和数据库都是以ISO8859-1方式处理，这样不会出错。但

是在读取数据的时候就出现问题了，因为数据读出也采用ISO8859-1字符集，而  JSP的文件头中有语句

<%@  page  language=“Java”  contentType=“text/html;  charset=gb2312”%>，这说明页面采用

GB2312的字符集显示，这样就和读出的数据不一样。这时页面显示从数据库中读出的字符是乱码，解决

的方法是对这些字符转码，从ISO8859-1转成GB2312，就可以正常显示了。这个解决办法对很多平台具

有通用性，读者可以灵活运用。具体的方法会在以下详细讲解。另外，对于不同的数据库如SQL 

Server，Oracle，Mysql，Sybase等，字符集的选择很重要。如果考虑多语言版本，数据库的字符集就

应该统一采用ISO8859-1，需要输出的时候在不同的字符集之间做转换就可以了。 
以下是针对不同平台的总结： 
(1)  JSWDK只适合于普通开发，稳定性和其他问题可能不如商业软件。  由于JDK  1.3版性能要好于

JDK  1.2.2很多，并且对中文的支持也较好，所以应该尽量采用。  现在jdk已经出到1.4版本了，所以

如果允许最好升级到最新的版本，这样对中文的也会较好，而且还可以得到更多的支持。 
(2)  Tomcat仅仅是一个对JSP  1.1、Servlet  2.2标准的实现,  我们不应该要求这个免费软件在细节

和性能上都面面俱到,  它主要考虑英文用户,  这也是为什么不做特殊转换，汉字用URL方法传递就有

问题的原因。大部分IE浏览器缺省始终以UTF-8发送,  这似乎是Tomcat的一个不足,  另外Tomcat不管

当前的操作系统是什么语言,  都按ISO8859去编译JSP,  似乎也欠妥。 
2.JSP代码的中文处理
(1)如果与数据无关的操作，可以在页面首行加入
(2)将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); 
这样就可以解决问题了，代码如下： 
<%@  page  contentType=“text/html;charset=gb2312”%> 
<%! 
public  String  getStr(String  str){ 
try{String  temp_p=str; 
byte[]  temp_t=temp_p.getBytes(“ISO8859-1”); 
String  temp=new  String(temp_t); 
return  temp; 
} 
catch(Exception  e){  } 
return  “NULL”; 
} 
%> 
<%--http://www.cndes.com测试--%> 
<%  String  keyword=“创联网络技术中心欢迎您的到来”; 
String  keyword1=request.getParameter(“keyword1”); 
keyword1=getStr(keyword1); 
out.print(keyword); 
out.print(keyword1); 
%> 
另外，流行的关系数据库系统都支持数据库Encoding，也就是说在创建数据库时可以指定它自己的字符

集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有 

Encoding  转换。对于中文数据，数据库字符编码的设置应当保证数据的完整性。  GB2312、GBK、

UTF-8  等都是可选的数据库  Encoding，也可以选择  ISO8859-1  (8-bit)，  但会增加了编程的复

杂度，ISO8859-1不是推荐的数据库  Encoding。在JSP/Servlet编程时，可以先用数据库管理系统提供

的管理功能检查其中的中文数据是否正确。 

(3)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的资料。 
其实理解了，中文乱码就这么一回事!反复使用就会摸出一定的门道了!我觉得以上的三种方法，只要你

真的能弄懂，在遇到中文问题时，在这三种方法多试尝，我保证你不再会使这种中文问题所烦!
以上只是自己的一些经验所谈，如果有什么不对，希望能提出，共同学习!  

//

 

 我的乱码之路——JSP与MySQL交互的中文乱码解决方案及总结
     首先实现了一个StringConvert bean（GBtoISO()和ISOtoGB()两个方法），解决了与MySQL数据库

交互的时候的部分中文乱码问题：在JSP程序中读取MySQL的中文内容，用这两个方法可以解决乱码问题

。

    但是从JSP写入到MySQL的中文内容都成了乱码，并且再读出来的时候也显示为“？？”，在这里应

该出现了编码转换过程中的字符信息丢失。郁闷的是，我在命令行窗口中登陆到MySQL后，执行如

“INSERT INTO customerVALUES('字符',...)”这样的语句时，写入到数据表中的中文内容又是显示正

常的！！！数据库使用的字符集是utf8。

 

     碰壁多次，终于发现一条解决问题的路径：查看MySQL手册的时候，看到一条这样的语句：

Toallow multiple character sets to be sent from the client, the "UTF-8"encoding should be

used, either by configuring "utf8" as the defaultserver character set, or by configuring

the JDBC driver to use "UTF-8"through the characterEncoding property.

 

     此外，在查阅《MySQL权威指南》时，发现在查询语句中可以使用这样的语法将字符串转换到一个

给定的字符集：_charset str。

     其中charset必须是服务器支持的某个字符集。在本例中，shopdb数据库使用的默认字符集是utf8

，于是开始测试：

     先输入INSERT INTO　publish Values('8',_gb2312 '高等教育出版社')  写入后中文变成“？？

”

     再试INSERT INTO　publish Values('8',_gbk '高等教育出版社') 结果同上

     INSERT INTO　publish Values('8',_utf8 '高等教育出版社') 这下更干脆，什么都没有！！

 

     　　快疯了!!没办法，用show character set;命令查看MySQL支持的字符集，心想我都试一遍总

有一个能成功吧。浏览了一下，发现没有几个熟悉的字符集，就只剩下一个latin1(ISO-8859-1)比较常

见了，不会是它吧，一试之下果然便是。

     INSERT INTO　publish Values('8',_latin1 '高等教育出版社') 输入中文能够正确显示。

 

     　　这下总算找到方法了，把Tomcat下配置的数据库连接池的url改为

＂...characterEncoding=UTF-8＂，然后把写入数据库的中文内容用

     String s2 = new String(s1.getBytes("gb2312"),"ISO-8859-1")进行转码，其中s1为中文字符

串．然后再写入到数据库一切显示正常。

 

     　　为解决这个问题查看了n多资料，现作一个总结：由于字符集和字符编码方式的不同，在OS以

及程序之间传递数据（尤其是multiple character sets中的数据）时便会产生乱码以及字符信息的丢

失．解决这个问题的关键便是了解数据输出端和接收端使用的字符集和字符编码方式，如果这两种编码

方式不同，便需要在数据出口或入口处进行 转码。一般的说，在编写代码,编译，以及运行期间都会字

符数据的传递，因此需要特别小心。

      在编写代码的时候，你可能会使用某种开发工具，例如我正在使用的Eclipse．或许在写的时候

一切正常，可是一旦保存后再次打开文档，所有的中文字符都变成了乱码。这是因为在编写的时候，这

些字符数据都在内存的某个stream中，ok，这没问题，可是保存的时候这个stream中的数据会被写入到

硬盘，使用的就是你的开发工具默认的编码方式，如果很不幸你的开发工具默认编码方式是ISO-8859-1

，中文字符信息就不能正确地存储。Eclipse中可以这样查看并修改默认字符编码方式：Project-

>Properties->info，这里有＂default encoding for text file＂。如果设置为GBK，那么编写代码

并保存这关就过了。

     　对于JSP程序而言，编写完代码后就交给Container，首先它们会被转成.java文件，然后编译成

.class才能提交给服务器执行．这个过程也存在字符编码问题．java编译器(javac)使用操作系统的语

言环境作为默认的字符编码方式，JRE(Java Runtime Environment)也是这样。只有当编译和运行环境

的字符编码方式与存储源文件的编码方式相同时，中文字符才能正确地显示。否则就需要在运行时进行

转码，使它们使用兼容的编码。这里的设置可以分为几个层次：操作系统层支持的语言，这是最重要的

，因为它会影响ＪＶＭ的默认字符编码方式，同时对字符的显示，如字体等有直接影响；J2EE服务器层

，大多数服务器都可以对字符编码进行自定义的配置，例如Tomcat就可以通过web.xml中设置

javaEncoding参数设置字符编码，默认是UTF-8．

     IE也可以设置成总是使用UTF-8编码来发送请求．应用程序层，每个配置在服务器下的程序都可以

设置自己的编码方式，这个我目前还没有用到，以后再学习。

     运行时的转码，运行时期，应用程序很可能需要与外部系统进行交互，例如对数据库进行读写

，对外部文件进行读写．在这些情况下，应用程序免不了要和外部系统进行数据交换。那么对于中文字

符， 数据出入口的编码方式就显得特别重要了。一般外部系统都有自己的字符编码方式，我的例子中

配置的MySQL就是使用的UTF-8编码。JSP页面通过设定＂charset=gb2312＂,

    使用gb2312编码，在它与数据库交互的时候就需要进行显式的转码才能正确处理中文字符。