乱码的解决方法新.docx

下面是处理页面（process.jsp）代码：

<%@pagecontentType="text/html;charset=gb2312"%>

<%=request.getParameter（"name"）%>

如果submit.jsp提交英文字符能正确显示，如果提交中文时就会出现乱码。

原因：

浏览器默认使用UTF

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

解决办法:

通过request.seCharacterEncoding（"gb2312"）对请求进行统一编码，就实现了中文的正常

显示。

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

<%@pagecontentType="text/html;charset=gb2312"%>

<%

request.setCharacterEncoding（"gb2312"）;

%>

<%=request.getParameter（"name"）%>

三、数据库连接出现乱码

只要涉及中文的地方全部是乱码，解决办法：

在数据库的数据库URL中加上

useUnicode=true&characterEncoding=GBK就OK了。

四、数据库的显示乱码

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

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

publicclassConvert{

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

*/

publicstaticStringISOtoGB（Stringiso）{

Stringgb;

try{

if（iso.equals（""）||iso==null）{

return"";

}

else{

iso=iso.trim（）;

gb=newString（iso.getBytes（"ISO-8859-1"）,"GB2312"）;

returngb;

}

}

catch（Exceptione）{

System.err.print（"编码转换错误：

"+e.getMessage（））;

return"";

}

}

}

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

如果你还有什么不懂之处：

我给大家推荐一个好的JSP-JAVA网站：

总结：

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

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

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

字符输出流编码设置为A,所有要输出的String的编码要转化为A的，否則会得到乱码的。

   Servelet中从request得到的String的编码和jsp中一样的，但是在servletjava文件中构造的

String是使用的系统默认的编码的。

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

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

 

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

转载：

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

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

码问题以及解决方法。

1、JSP页面乱码

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

只要在页面开始地方用下

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

 

2、数据库乱码

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

　　在数据库连接字符串中加入编码字符集

　　StringUrl="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="+.URLEncoder.encode（keywords）

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

　　keywords=newString（request.getParameter（"keywords"）.getBytes（"8859_1"））;

4、JSP页面乱码加这句 

<%@pagecontentType="text/html;charset=gb2312"language="java"import="java.sql.*"

errorPage="err.jsp"%>

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

JSP/JDBCMySQL乱码问题~~~

作者：

佚名 来源：

本站整理 发布时间：

2005-7-112:

24:

30

綠起：

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

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

Stringstr=newString（request.getParameter（"name"）.getBytes（"ISO8859-1"）,"GBK"）;

out.println（str）;

这样就可以显示中文了

MYSQL操作时的中文问题：

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

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

1.插入中文：

Stringsql2="INSERTINTOtest（name）VALUES（'"+request.getParameter（"name"）+"'）";

stmt.executeUpdate（sql2）;

不用编码就可以插入了

2.显示插入的中文：

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

Stringx=newString（（rs.getString（"title"））.getBytes（"ISO8859_1"）,"GBK"）;

out.println（x）;

3.设定存储编码：

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

Connectioncon=DriverManager.getConnection（"jdbc:

mysql:

//localhost:

3306/jsp?

useUnicode=true&characterEncoding=GBK","root",""）;

str1="中文";

Stringsql2="INSERTINTOtest（name）VALUES（'"+str1+"'）";

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

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

JSP/Servlet中的汉字编码问题

（作者：

张建芳，转自IBMDeveloperWorks中国网站　2001年04月18日15:

08）

　　网上就JSP/Servlet中DBCS字符编码问题有许多优秀的文章和讨论，本文对它们作一些整理，

并结合IBMWebSphereApplicationServer3.5（WAS）的解决方法作一些说明，希望它不是多余的。

1.问题的起源

　　每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的ASCII，中国的GB2312

-80，日本的JIS等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。

字符编码集按

长度分为SBCS（单字节字符集），DBCS（双字节字符集）两大类。

早期的软件（尤其是操作系统），

为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了LANG，

Codepage等概念。

但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版

本独立维护成本较高。

因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理

内容降低到最少。

这也就是所谓的国际化（I18N）。

各种语言信息被进一步规范为Locale信息。

处理

的底层字符集变成了几乎包含了所有字形的Unicode。

　　现在大部分具有国际化特征的软件核心字符处理都是以Unicode为基础的，在软件运行时根据当

时的Locale/Lang/Codepage设置确定相应的本地字符编码设置，并依此处理本地字符。

在处理过程中

需要实现Unicode和本地字符集的相互转换，甚或以Unicode为中间的两个不同本地字符集的相互转

换。

这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可

接受的内容。

　　Java语言内部是用Unicode表示字符的，遵守UnicodeV2.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的字位。

其所有字符都可以一对一映射到Unicode2.0，也就是说JAVA实际

上提供了GBK字符集的支持。

这是现阶段Windows和其它一些中文操作系统的缺省字符集，但并不是

所有的国际化软件都支持该字符集，感觉是他们并不完全知道GBK是怎么回事。

值得注意的是它不是

国家标准，而只是规范。

随着GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。

　　GB18030-2000（GBK2K）在GBK的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。

GBK2K从根本上解决了字位不够，字形不足的问题。

它有几个特点：

　　●它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。

　　●编码是变长的，其二字节部分与GBK兼容；四字节部分是扩充的字形、字位，其编码范围是首

字节0x81-0xfe、二字节0x30-0x39、三字节0x81-0xfe、四字节0x30-0x39。

　　●它的推广是分阶段的，首先要求实现的是能够完全映射到Unicode3.0标准的所有字形。

　　●它是国家标准，是强制性的。

　　现在还没有任何一个操作系统或软件实现了GBK2K的支持，这是现阶段和将来汉化的工作内容。

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

　　3.1常见的encoding问题的现象

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

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

’?

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

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

　　●Jsp/Servlet页面无法显示GBK汉字。

　　●Jsp/Servlet不能接收form提交的汉字。

　　●JSP/Servlet数据库读写无法获得正确的内容。

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

起的）。

解决类似的字符encoding问题，需要了解Jsp/Servlet的运行过程，检查可能出现问题的

各个点。

　　3.2JSP/Servletweb编程时的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内容发送出去。

依赖于各

JAVAAppServer的实现方式，有的将查询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位JAVAchar在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的

和servlet运行过程中得到的）是期望的内码，可以用PrintWriterōut=res.getWriter（）取代

ServletOutputStreamōut=res.getOutputStream（）,PrinterWriter将根据contentType中指定的

charset作转换（ContentType需在此之前指定！

）;也可以用OutputStreamWriter封装

ServletOutputStream类并用write（String）输出汉字字符串。

对于JSP，JAVAApplicationServer应当能够确保在这个阶段将嵌入的汉字正确传送出去。

　　d.这是URL字符encoding问题。

如果通过get/post方式从browser返回的值中包含汉字信息

，servlet将无法得到正确的值。

SUN的J2SDK中，HttpUtils.parseName在解析参数时根本没有考

虑browser的语言设置，而是将得到的值按byte方式解析。

这是网上讨论得最多的encoding问题

。

因为这是设计缺陷，只能以bin方式重新解析得到的字符串；或者以hackHttpUtils类的方式解

决。

参考文章2、3均有介绍，不过最好将其中的中文encodingGB2312、CP1381都改为GBK，否则

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

　　ServletAPI2.3提供一个新的函数HttpServeletRequest.setCharacterEncoding用于在调用

request.getParameter（“param_name”）前指定应用程序希望的encoding，这将有助于彻底解决这个

问题。

　　WebSphereApplicationServer对标准的ServletAPI2.x作了扩展，提供较好的多语言支持。

上述c,d情况，WAS都要查询Browser的语言设置，在缺省状况下zh、zh-cn等均被映射为JAVA

encodingCP1381（注意：

CP1381只是等同于GB2312的一个codepage，没有GBK支持）。

这样做我

想是因为无法确认Browser运行的操作系统是支持GB2312,还是GBK，所以取其小。

但是实际的应用

系统还是要求页面中出现GBK汉字，最著名的是朱总理名字中的“?

”（rong2，0xe946，\u9555），所

以有时还是需要将Encoding/Charset指定为GBK。

当然WAS中变更缺省的encoding没有上面说的

那么麻烦，针对a,b，参考文章5），在ApplicationServer的