乱码的解决方法（新）

jsp乱码解决大全 2007-06-12 20:45

jsp中文显示乱码解决方案2006-12-27 22:56

一、JSP页面显示乱码 二、表单提交中文时出现乱码

三、数据库连接

大家在JSP的开发过程中，经常出现中文乱码的问题，可能一至困扰着您，我现在把我在

JSP开发中遇到

的中文乱码的问题及解决办法写出来供大家参考。

一、JSP页面显示乱码

下面的显示页面(display.jsp)就出现乱码：

<%

out.print(\的中文处理\

%>

对不同的WEB服务器和不同的JDK版本，处理结果就不一样。原因：服务器使用的编码

方式不同和浏览器

对不同的字符显示结果不同而导致的。解决办法：在JSP页面中指定编码方式(gb2312),即在

页面的第一

行加上：<%@ page contentType=\，就可以消除乱码了。完整页

面如下

：

<%@ page contentType=\

<%

out.print(\的中文处理\

%>

二、表单提交中文时出现乱码

下面是一个提交页面(submit.jsp)，代码如下：

下面是处理页面(process.jsp)代码：

<%@ page contentType=\

<%=request.getParameter(\

如果submit.jsp提交英文字符能正确显示，如果提交中文时就会出现乱码。原因：浏览器默

认使用UTF

-8编码方式来发送请求，而UTF- 8和GB2312编码方式表示字符时不一样，这样就出现了

不能识别字符。

解决办法:通过request.seCharacterEncoding (\对请求进行统一编码，就实现了中文的

正常

显示。修改后的process.jsp代码如下：

<%@ page contentType=\

<%

request.setCharacterEncoding(\

%>

<%=request.getParameter(\

三、数据库连接出现乱码

只要涉及中文的地方全部是乱码，解决办法：在数据库的数据库URL中加上

useUnicode=true&characterEncoding=GBK 就OK了。

四、数据库的显示乱码

在mysql4.1.0中,varchar类型，text类型就会出现中文乱码，对于varchar类型把它设为binary

属性就

可以解决中文问题，对于text类型就要用一个编码转换类来处理，实现如下：

public class Convert {

/** 把ISO-8859-1码转换成GB2312

*/

public static String ISOtoGB(String iso){

String gb; try{

if(iso.equals(\

return \

} else{ iso = iso.trim();

gb = new String(iso.getBytes(\

return gb;

} }

catch(Exception e){

System.err.print(\编码转换错误：\

return \

} } }

把它编译成class，就可以调用Convert类的静态方法ISOtoGB()来转换编码。

如果你还有什么不懂之处：我给大家推荐一个好的JSP-JAVA网站：

http://www.phy.hbnu.edu.cn/dsp/

总结：

1. 在jsp中<%@ page contentType=\如果指定了，那么在改jsp中所

有构造

的String（不是引用），如果沒有指定编码，那么这些String的编码是A的。 从request的得到的String如果沒有指定request的编码的话，他是iso-8859-1的 从别的地方得到的String是使用原來初始的编码的，比如从数据库得到String,如果数据

库的编码

是B,那么该String的编码是B而不是A的，也不是系统默认的。

此时，如果要输出的String的编码不是A,那么，很可能显示乱码的，所以首先要将String

正確转化

为编码A的String,然后输出。

2. 在jsp中<%@ page contentType=\沒有指定，那么相当于指定了

<%@

page contentType=\

3． Servelte中如果执行了像 response.setContentType(\説明将response

的

字符输出流编码设臵为A,所有要输出的String的编码要转化为A的，否則会得到乱码的。 Servelet中从request得到的String的编码和jsp中一样的，但是在servlet java文件中构造

的

String是使用的系统默认的编码的。在servelt中从外部得到的String 是使用原来的编码的，

比如从编

码为B的数据库得到的数据是编码为B的,不是A,也不是系统默认的编码。

//////////////////////////////////////////////////////////////////////////////////////////

转载：JSP中文乱码问题解决方法小结

在使用JSP的过程中，最使人头疼的一个问题就是中文乱码问题，以下是我在软件开发

中遇到的乱 码问题以及解决方法。 1、JSP页面乱码

这种乱码的原因是应为没有在页面里指定使用的字符集编码，解决方法：只要在页面开

始地方用下

面代码指定字符集编码即可，

2、数据库乱码

这种乱码会使你插入数据库的中文变成乱码，或者读出显示时也是乱码，解决方法如下：

在数据库连接字符串中加入编码字符集 String Url=\

user=root&password=root&useUnicode=true&characterEncoding=GB2312\

并在页面中使用如下代码：

response.setContentType(\

request.setCharacterEncoding(\

3、中文作为参数传递乱码

当我们把一段中文字符作为参数传递个另一页面时，也会出现乱码情况，解决方法如下：

在参数传递时对参数编码，比如

RearshRes.jsp?keywords=\

然后在接收参数页面使用如下语句接收

keywords=new String(request.getParameter(\

4、JSP页面乱码加这句

<%@ page contentType=\

errorPage=\

/////////////////////////////////////////////////////////////////////////////////////////

JSP/JDBC MySQL乱码问题~~~

作者：佚名 来源：本站整理 发布时间：2005-7-1 12:24:30

綠起：

JSP的request 默认为ISO8859_1，所以在处理中文的时候，

要显示中文的话，必须转成GBK的，如下

String str=new String(request.getParameter(\

out.println(str); 这样就可以显示中文了 MYSQL操作时的中文问题：

这个要看MySQL的默认编码了，一般不调整的话为latin1其实和ISO8859_1一样，所以操

作的时候要处理 和他一致，不然就会乱码的

1.插入中文：

String sql2=\

stmt.executeUpdate(sql2); 不用编码就可以插入了 2.显示插入的中文：

因为存入的是latin，所以显示的时候就要GBK一下

String x=new String((rs.getString(\

out.println(x); 3.设定存储编码：

当然在MySQL为latin1编码时，也可以存的时候用GBK了

Connection con=DriverManager.getConnection(\

useUnicode=true&characterEncoding=GBK\

str1=\中文\

String sql2=\

这样也可以很成功的插入了，呵呵

////////////////////////////////////////////////////////////////////////////////////////

JSP/Servlet 中的汉字编码问题

（作者：张建芳，转自IBM DeveloperWorks 中国网站 2001年04月18日 15:08） 网上就 JSP/Servlet 中 DBCS 字符编码问题有许多优秀的文章和讨论，本文对它们作

一些整理，

并结合 IBM WebSphere Application Server 3.5（WAS）的解决方法作一些说明，希望它不是

多余的。 1.问题的起源

每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的 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 和各个本地字符集的补充、完善，以及系统或应用程序实

现的不规范

，转码时出现的问题时时困扰着程序员和用户。 2.GB2312-80，GBK，GB18030-2000 汉字字符集

其实解决 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 的支持，这是现阶段和将来汉化

的工作内容。

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

3.1 常见的 encoding 问题的现象

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

●浏览器中看到的 Jsp/Servlet 页面中的汉字怎么都成了 ’?’ ? ●浏览器中看到的 Servlet 页面中的汉字怎么都成了乱码？

●JAVA 应用程序界面中的汉字怎么都成了方块？

●Jsp/Servlet 页面无法显示 GBK 汉字。 ●Jsp/Servlet 不能接收 form 提交的汉字。 ●JSP/Servlet 数据库读写无法获得正确的内容。

隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为 Java font 设

臵错误引

起的）。解决类似的字符 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 内容发送出去。

依赖于各

JAVA App Server 的实现方式，有的将查询 Browser 的 accept-charset 和 accept-language

参数或

以其它猜的方式确定 encoding 值，有的则不管。因此 constant-encoding 也许是最好的解决

方法。

对于中文网页，可在 JSP 或 Servlet 中设臵 contentType=\；如

果页面

中有GBK字符，则设臵为contentType=\，由于IE 和 Netscape对

GBK的支持程

度不一样，作这种设臵时需要测试一下。

因为16位 JAVA char在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉

字（包括内嵌的

和servlet运行过程中得到的）是期望的内码，可以用 PrintWriter ōut=res.getWriter() 取代 ServletOutputStream ōut=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 方式重新解析得到的字符串；或者以 hack HttpUtils 类

的方式解

决。参考文章 2、3 均有介绍，不过最好将其中的中文 encoding GB2312、 CP1381 都改为

GBK，否则

遇到 GBK 汉字时，还是会有问题。

Servlet API 2.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，

\镕)，所

以有时还是需要将 Encoding/Charset 指定为 GBK。当然 WAS 中变更缺省的 encoding 没

有上面说的

那么麻烦，针对 a,b，参考文章 5 ），在 Application Server 的命令行参数中指定 - Dfile.encoding=GBK 即可； 针对 d，在 Application Server 的命令行参数中指定- 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-bit SBCS)，那么应用程序在写数据之前须将 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特征

字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，

可以尝试着

增加连续的英文字母长度）。

4.结束语

其实 JSP/Servlet 的中文encoding 并没有想像的那么复杂，虽然定位和解决问题没有定

规，各种

运行环境也各不尽然，但后面的原理是一样的。了解字符集的知识是解决字符问题的基础。

不过，随着

中文字符集的变化，不仅仅是 java 编程，中文信息处理中的问题还是会存在一段时间的。

5.参考文章

1) Character Problem Review

2) Java 编程技术中汉字问题的分析及解决

3) NLS Characters in WebSphere: SBCS/DBCS display on same page

4) GB18030

5) Setting language encoding in web applications: Websphere applications Server

作者简介

张建芳，软件工程师，毕业于北京理工大学计算机应用学院，有多年中文本地化经验。

您可通过

jfzhang@usa.net 与他联系。

/////////////////////////////////////////////////////////////////////////////////////

关于jsp乱码问题的解决。 1 最基本的乱码问题。

这个乱码问题是最简单的乱码问题。一般新会出现。就是页面编码不一致导致的乱码。

<%@ page language=\<%@ page contentType=\

我是个好人 三个地方的编码。

第一个地方的编码格式为jsp文件的存储格式。Eclipse会根据这个编码格式保存文件。并编

译jsp文件 ，包括里面的汉字。

第二处编码为解码格式。因为存为UTF-8的文件被解码为iso8859-1，这样 如有中文肯定出

乱码。也就

是必须一致。而第二处所在的这一行，可以没有。缺省也是使用iso8859-1的编码格式。所

以如果没有

这一行的话，“我是个好人”也会出现乱码。必须一致才可以。

第三处编码为控制浏览器的解码方式。如果前面的解码都一致并且无误的话，这个编码格

式没有关系

。有的网页出现乱码，就是因为浏览器不能确定使用哪种编码格式。因为页面有时候会嵌入

页面，导致

浏览器混淆了编码格式。出现了乱码。 2 表单使用Post方式提交后接收到的乱码问题

这个问题也是一个常见的问题。这个乱码也是tomcat的内部编码格式iso8859-1在捣乱，也

就是说post

提交时，如果没有设臵提交的编码格式，则会以iso8859-1方式进行提交，接受的jsp却以

utf-8的方式

接受。导致乱码。既然这样的原因，下面有几种解决方式，并比较。

A 接受参数时进行编码转换

String str = new String(request.getParameter(\ ； 这样的话，每一个参数都必须这样进行转码。很麻烦。但确实可以拿到汉字。 B 在请求页面上开始处，执行请求的编码代码， request.setCharacterEncoding(\，把

提交内

容的字符集设为UTF－8。这样的话，接受此参数的页面就不必在转码了。直接使用 String str = request.getParameter(\；即可得到汉字参数。但每页都需要执行这句话。

这个方法也就对post提交的有效果，对于get提交和上传文件时的

enctype=\是无

效的。稍后下面单独对这个两个的乱码情况再进行说明。

C 为了避免每页都要写request.setCharacterEncoding(\，建议使用过滤器对所有jsp

进行编码处理。这个网上有很多例子。请大家自己查阅。

3 表单get提交方式的乱码处理方式。

如果使用get方式提交中文，接受参数的页面也会出现乱码，这个乱码的原因也是tomcat

的内部编码格

式iso8859-1导致。Tomcat会以get的缺省编码方式iso8859-1对汉字进行编码，编码后追加

到url，导致

接受页面得到的参数为乱码/、。

解决办法：

A 使用上例中的第一种方式，对接受到的字符进行解码，再转码。

B Get走的是url提交，而在进入url之前已经进行了iso8859-1的编码处理。要想影响这个

编码则需要在

server.xml的Connector节点增加useBodyEncodingForURI=\

属性配臵，即可控制tomcat对get方式的汉字编码方式，上面这个属性控制get提交也是用 request.setCharacterEncoding(\所设臵的编码格式进行编码。所以自动编码为utf-8，

接受页

面正常接受就可以了。但我认为真正的编码过程是，tomcat又要根据

maxThreads=\ enableLookups=\ debug=\

disableUploadTimeout=\-8”/>

里面所设臵的URIEncoding=”UTF-8”再进行一次编码，但是由于已经编码为utf-8，再编码

也不会有变

化了。如果是从url获取编码，接受页面则是根据URIEncoding=”UTF-8”来进行解码的。

4 上传文件时的乱码解决

上传文件时，form表单设臵的都是enctype=\。这种方式以流方式提交

文件。

如果使用apach的上传组件，会发现有很多乱码想象。这是因为apach的先期

commons-fileupload.jar有

bug，取出汉字后进行解码，因为这种方式提交，编码又自动使用的是tomcat缺省编码格式

iso-8859-1

。但出现的乱码问题是： 句号，逗号，等特殊符号变成了乱码，汉字如果数量为奇数，则

会出现乱码 ，偶数则解析正常。

解决方式： 下载commons-fileupload-1.1.1.jar 这个版本的jar已经解决了这些bug。 但是取出内容时仍然需要对取出的字符进行从iso8859-1到utf-8转码。已经能得到正常所有

汉字以及字 符。

5 Java代码关于url请求，接受参数的乱码

url的编码格式，取决于上面所说的URIEncoding=”UTF-8”。 如果设定了这个编码格式，则

意味着所

有到url的汉字参数，都必须进行编码才可以。否则得到的汉字参数值都是乱码，例如 一个链接 Response.sendDerect（“/a.jsp?name=张大维”）；而在a.jsp里面直接使用 String name\）；得到的就是乱码。因为规定了必须是utf-8才可以，所以，这个转向应该这

样写：

Response.sendDerect（“/a.jsp?name=URLEncode.encode(“张大维”,”utf-8”)；才可以。 如果不设臵这个参数URIEncoding=”UTF-8”， 会怎么样呢? 不设臵则就使用了缺省的编码

格式

iso8859-1。问题又出来了，第一就是参数值的个数如果是奇数个数，则就可以正常解析，如

果使偶数

个数，得到最后字符就是乱码。还有就是如果最后一个字符如果是英文，则就能正常解析，

但中文的标

点符号仍出现乱码。权宜之计，如果您的参数中没有中文标点符号，则可以在参数值最后加

一个英文符

号来解决乱码问题，得到参数后再去掉这个最后面的符号。也可以凑或使用。

6 脚本代码关于url请求，接受到的参数乱码

脚本中也会进行页面转向的控制，也会涉及到附带参数，并在接受页面解析这个参数的情况。

如果这个

汉字参数不进行URIEncoding=”UTF-8”所指定的编码处理，则接受页面接受到的汉字也是乱

码。脚本

处理编码比较麻烦，必须有相应的编码脚本对应文件，然后调用脚本中的方法对汉字进行编

码即可。

7 关于jsp在MyEclipse中打开的乱码问题

对于一个已经存在的项目，Jsp文件的存储格式可能是utf-8。如果新安装的eclipse，则缺省

打开使用

的编码格式都是iso8859-1。所以导致jsp里面的汉字出现乱码。这个乱码比较容易解决，直

接到

eclipse3.1的偏好设臵里面找到general-〉edidor，设臵为您的文件打开编码为utf-8即可。

Eclipse会

自动重新以新的编码格式打开。汉字即可正常显示。 8 关于html页面在eclipse中打开出现乱码情况

由于大部分页面都是由dreamweaver制作，其存储格式跟eclipse的识别有差别导致。 一般这种情况，在eclipse中新建一个jsp，直接从dreamweaver复制页面内容粘贴到jsp即

个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 \ used, either by configuring \

the JDBC driver to use \

此外，在查阅《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(\进行转码，其中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编码，在它与数据库交互的时候就需要进行显式的转码才能正确处理中文字

符。

本文来源：https://www.bwwdw.com/article/v8b3.html