JSP乱码解决大全

 

一、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>

<body>
<%
out.print("JSP的中文处理");
%>
</body>
</html>

二、表单提交中文时出现乱码
下面是一个提交页面(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>

<body>
<%=request.getParameter("name")%>
</body>
</html>

三、数据库连接出现乱码
只要涉及中文的地方全部是乱码，解决办法：在数据库的数据库URL中加上
useUnicode=true&characterEncoding=GBK 就OK了。

四、数据库的显示乱码
在mysql4.1.0中,varchar类型，text类型就会出现中文乱码，对于varchar类型把它设为binary属性就

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

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
作者简介

posted on 2008-03-19 15:51 白露 阅读(245) 评论(0)  编辑  收藏 所属分类: J2EE技术


只有注册用户登录后才能发表评论。
网站导航:
 
<2025年7月>
日一二三四五六
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

导航

统计

留言簿(1)

文章分类

文章档案

搜索

最新评论