jsp乱码解决大全

来源：互联网发布：外国域名注册网站编辑：程序博客网时间：2024/04/28 17:56

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

一、JSP页面显示乱码

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

三、数据库连接

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

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

一、JSP页面显示乱码
下面的显示页面(display.jsp)就出现乱码：
<html>
<head>
<title>JSP的中文处理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<%
out.print("JSP的中文处理");
%>
</body>
</html>
对不同的WEB服务器和不同的JDK版本，处理结果就不一样。原因：服务器使用的编码方式不同和浏览器

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

行加上：<%@ page contentType="text/html; charset=gb2312"%>，就可以消除乱码了。完整页面如下

：
<%@ page contentType="text/html; charset=gb2312"%>
<html>
<head>
<title>JSP的中文处理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

二、表单提交中文时出现乱码
下面是一个提交页面(submit.jsp)，代码如下：
<html>
<head>
<title>JSP的中文处理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<form name="form1" method="post" action="process.jsp">
<div align="center">
<input type="text" name="name">
<input type="submit" name="Submit" value="Submit">
</div>
</form>
</body>
</html>
下面是处理页面(process.jsp)代码：
<%@ page contentType="text/html; charset=gb2312"%>
<html>
<head>
<title>JSP的中文处理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<%=request.getParameter("name")%>
</body>
</html>
如果submit.jsp提交英文字符能正确显示，如果提交中文时就会出现乱码。原因：浏览器默认使用UTF

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

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

显示。修改后的process.jsp代码如下：
<%@ page contentType="text/html; charset=gb2312"%>
<%
request.seCharacterEncoding("gb2312");
%>
<html>
<head>
<title>JSP的中文处理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

三、数据库连接出现乱码
只要涉及中文的地方全部是乱码，解决办法：在数据库的数据库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("") || iso == null){
return "";
}
else{
iso = iso.trim();
gb = new String(iso.getBytes("ISO-8859-1"),"GB2312");
return gb;
}
}
catch(Exception e){
System.err.print("编码转换错误："+e.getMessage());
return "";
}
}
}
把它编译成class，就可以调用Convert类的静态方法ISOtoGB()来转换编码。

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

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

总结：

1. 在jsp中<%@ page contentType="text/html; charset=A" %>如果指定了，那么在改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="text/html; charset=A" %>沒有指定，那么相当于指定了<%@

page contentType="text/html; charset=ISO-8859-1" %>

3． Servelte中如果执行了像 response.setContentType("text/html;charset=A");説明将response的

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

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

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

//////////////////////////////////////////////////////////////////////////////////////////
转载：JSP中文乱码问题解决方法小结
　　在使用JSP的过程中，最使人头疼的一个问题就是中文乱码问题，以下是我在软件开发中遇到的乱

码问题以及解决方法。

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

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

2、数据库乱码
　　这种乱码会使你插入数据库的中文变成乱码，或者读出显示时也是乱码，解决方法如下：
　　在数据库连接字符串中加入编码字符集
　　String Url="jdbc:mysql://localhost/digitgulf?

user=root&password=root&useUnicode=true&characterEncoding=GB2312";
　　并在页面中使用如下代码：
　　response.setContentType("text/html;charset=gb2312");
　　request.setCharacterEncoding("gb2312");

3、中文作为参数传递乱码
　　当我们把一段中文字符作为参数传递个另一页面时，也会出现乱码情况，解决方法如下：
　　在参数传递时对参数编码，比如
　　RearshRes.jsp?keywords=" + java.net.URLEncoder.encode(keywords)
　　然后在接收参数页面使用如下语句接收
　　keywords=new String(request.getParameter("keywords").getBytes("8859_1"));

4、JSP页面乱码加这句
<%@ page contentType="text/html; charset=gb2312" language="java" import="java.sql.*"

errorPage="err.jsp" %>
/////////////////////////////////////////////////////////////////////////////////////////
JSP/JDBC MySQL乱码问题~~~
作者：佚名来源：本站整理发布时间：2005-7-1 12:24:30
綠起：
JSP的request 默认为ISO8859_1，所以在处理中文的时候，
要显示中文的话，必须转成GBK的，如下
String str=new String(request.getParameter("name").getBytes("ISO8859-1"),"GBK");
out.println(str);
这样就可以显示中文了

MYSQL操作时的中文问题：
这个要看MySQL的默认编码了，一般不调整的话为latin1其实和ISO8859_1一样，所以操作的时候要处理

和他一致，不然就会乱码的

1.插入中文：
String sql2="INSERT INTO test (name) VALUES('"+request.getParameter("name")+"')";
stmt.executeUpdate(sql2);
不用编码就可以插入了

2.显示插入的中文：
因为存入的是latin，所以显示的时候就要GBK一下
String x=new String((rs.getString("title")).getBytes("ISO8859_1"),"GBK");
out.println(x);

3.设定存储编码：
当然在MySQL为latin1编码时，也可以存的时候用GBK了
Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/jsp?

useUnicode=true&characterEncoding=GBK","root","");
str1="中文";
String sql2="INSERT INTO test (name) VALUES('"+str1+"')";
这样也可以很成功的插入了，呵呵
////////////////////////////////////////////////////////////////////////////////////////
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="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 应当能够确保在这个阶段将嵌入的汉字正确传送出去。

　　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，/u9555)，所

以有时还是需要将 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="java" pageEncoding="UTF-8"%>

<%@ page contentType="text/html;charset=iso8859-1"%>

<html>

<head>

</head>

<body>

我是个好人

</body>

</html>

三个地方的编码。

第一个地方的编码格式为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("something").getBytes("ISO-8859-1"),"utf-8")

；这样的话，每一个参数都必须这样进行转码。很麻烦。但确实可以拿到汉字。

B 在请求页面上开始处，执行请求的编码代码， request.setCharacterEncoding("UTF-8")，把提交内

容的字符集设为UTF－8。这样的话，接受此参数的页面就不必在转码了。直接使用

String str = request.getParameter("something")；即可得到汉字参数。但每页都需要执行这句话。

这个方法也就对post提交的有效果，对于get提交和上传文件时的enctype="multipart/form-data"是无

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

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

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

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

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

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

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

解决办法：

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

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

server.xml的Connector节点增加useBodyEncodingForURI="true"

属性配置，即可控制tomcat对get方式的汉字编码方式，上面这个属性控制get提交也是用

request.setCharacterEncoding("UTF-8")所设置的编码格式进行编码。所以自动编码为utf-8，接受页

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

<Connector port="8080"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

debug="0" connectionTimeout="20000" useBodyEncodingForURI="true"

disableUploadTimeout="true" URIEncoding=”UTF-8”/>

里面所设置的URIEncoding=”UTF-8”再进行一次编码，但是由于已经编码为utf-8，再编码也不会有变

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

4 上传文件时的乱码解决

上传文件时，form表单设置的都是enctype="multipart/form-data"。这种方式以流方式提交文件。

如果使用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即可。
//////////////////////////////////////////////////////////////////////////////////////////
jsp中文乱码问题的解决办法 jsp中java中文编码问题的个人经验|终于看到一个完全解决的方案
四月 5th, 2006
====================http://www.glgg.net/blog===================zsjnju@hotmail.com=========

=======
开发java应用出现乱码是很常见的，毕竟现在unicode的使用还不是很广泛，在使用gb2312（包含了gbk

简体，big5繁体）的系统中要正确实现

中文的display和数据库的存储是最基本的要求。

========================http://www.glgg.net/blog=======================================
1，首先developer要明确自己为什么会遇到乱码，遇到什么样的乱码（无意义的符号还是一串问号或者

其它什么东西）。
新手遇到一堆很乱的字符时通常不知所措，最直接的反映就是打开google搜索”java中文”（这个字符

串在搜索引擎上的查询频率非常高），

然后一个一个的去看别人的解决方法。这样做没有错，但是很难达到目的，原因下面会提到。
总之，出现乱码的原因是非常多的，解决的方法也完全不一样，要解决问题必须先分析自己的”上下文

环境”。

========================http://www.glgg.net/blog=====================================
2，具体说来，需要哪些信息才能确定项目中的乱码的根源。
a，开发者所用的操作系统
b，j2ee容器的名称，版本
c，数据库的名称，版本（精确版本）以及jdbc驱动的版本
d，出现乱码的source code（比如是system out 出来的，还是jsp页面中的，如果是jsp中的，那么头

部声明的情况也很重要）

=========================http://www.glgg.net/blog========================================
3，如何初步分析乱码出现的原因。
有了上述的信息，基本上就可以发帖求助了，相信放到javaworld等论坛上，很快就会有高手给你提出

有效的解决方案的。
当然不能总靠发帖求助，也要试试自行解决问题。如何下手呢？
a，分析一下你的”乱码”到底是什么编码。这个其实不难，比如
System.out.println(testString);
这一段出现了乱码，那么不妨用穷举法猜测一下它的实际编码格式。
System.out.println(new String(testString.getBytes(”ISO-8859-1〃),”gb2312〃));
System.out.println(new String(testString.getBytes(”UTF8〃),”gb2312〃));
System.out.println(new String(testString.getBytes(”GB2312〃),”gb2312〃));
System.out.println(new String(testString.getBytes(”GBK”),”gb2312〃));
System.out.println(new String(testString.getBytes(”BIG5〃),”gb2312〃));
等等，上述代码的意思是用制定的编码格式去读取testString这个”乱码”，并转换成gb2312（此处仅

以中文为例）
然后你看哪一个转换出来的结果是ok的，那就。。。

b，如果用上面的步骤能得到正确的中文，说明你的数据肯定是在的，只不过是界面中没有正确显示而

已。那么第二步就该纠正你的view部分了

，通常需要检查的是jsp中是否选择了正确的页面编码。

在此要声明被很多人误解的一点，那就是<%@ page contentType=”text/html; charset=GB2312〃 %>

指令和<META http-equiv=Content-Type

content=”text/html; charset=gb2312〃>两者的不同。通常网上的很多文章在提到中文问题时都是说

数据库中选择unicode或者gb2312存储，同

时在jsp中用page指令声明编码就可以解决。但是我觉得这种说法很不负责任，害的我费了N多时间为本

来并不存在的乱码而郁闷。实际上page

的作用是在jsp被编译成为html的过程中提供编码方式让java来”读取”表达式当中的String（有点类

似于上面的第三个语句的作用），而meta

的作用是众所周知的为IE浏览器提供编码选择，是用来”显示”最后的数据的。但是没有看到有人提醒

这一点，我一直把page当成meta在用，

导致本来是iso-8859的数据，被page指令读成gb2312，于是乱码，所以又加了编码转化的函数把所有的

string数据都从iso8859转到gb2312（为

什么这么转，当时也没考虑这么多，因为这么做可以正常显示了，所以就这么改了，呵呵当时实在没有

时间慢慢排查问题了）。

===========================http://www.glgg.net/blog=======================================

===
4，数据库选择什么样的编码比较好。
目前流行的DB主要有sql server，mysql，oracle，DB2等，其中mysql作为免费DB中的老大，性能和功

能是得到公认的，安装配置比较方便，相

应的driver也比较完善，性价比是绝对的OK。所以就以mysql为例。

我个人建议采用mysql的默认编码来存储，也就是iso-8859-1（在mysql的选项中对应于latin-1）。理

由主要有这么几个，一是iso-8859-1对中

文的支持不错；二是跟java中的默认编码一致，至少在很多地方免除了转换编码的麻烦；三是默认的比

较稳定，兼容性也更好，因为多编码的

支持是由具体的DB产品提供的，别说跟其它的DB会不兼容，即使自身的不同版本也可能出现兼容性的问

题。

例如mysql 4.0以前的产品中，很多中文的解决方案是利用connection中的characterEncoding字段来制

定编码，比如gb2312什么的，这样是ok

的，因为原数据都是ISO8859_1编码，jdbc驱动会采用url里面指定的character set来进行编码，

resultSet.getString(*)取出的就是编码后的

字符串。这样就直接拿到gb2312的数据了。

但是mysql 4.1的推出给很多dbadmin带来了不小的麻烦，因为mysql4.1支持column level的character

set，每个table,column都可以指定编码

，不指定就是ISO8895_1，因此jdbc取出数据后会根据column的character set来进行编码，而不再是用

一个全局的参数来取所有的数据了。

这从另一个方面也说明了乱码问题的产生实在是很复杂的事情，原因太多了。我也只是针对自己遇

////////////////////////////////////////////////////////////////////////////////////////
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编码，在它与数据库交互的时候就需要进行显式的转码才能正确处理中文字符。

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

0 0