乱码问题

前言



一、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>
 
display.jsp


对不同的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>

pagecode.jsp

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

下面是一个提交页面(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>
submit.jsp


下面是处理页面(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>
process.jsp


如果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>

process.jsp

三、数据库连接出现乱码

只要涉及中文的地方全部是乱码,解决办法:在数据库的数据库URL中加上useUnicode=true&characterEncoding=GBK 就OK了。

在数据库连接字符串中加入编码字符集 
  String Url="jdbc:mysql://localhost/digitgulf?
user=root&password=root&useUnicode=true&characterEncoding=GB2312"; 
  并在页面中使用如下代码: 
  response.setContentType("text/html;charset=gb2312"); 
  request.setCharacterEncoding("gb2312"); 
或者使用:
然后在接收参数页面使用如下语句接收   keywords=new String(request.getParameter("keywords").getBytes("8859_1")); 

四、数据库的显示乱码

在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 "" ;
}
}
}
Convert.java

示例1:
String x=new String((rs.getString("title")).getBytes("ISO8859_1"),"GBK");

实例二:设定存储编码
当然在MySQL为latin1编码时,也可以存的时候用GBK了
Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/jsp?useUnicode=true&characterEncoding=GBK","root",""); 

根源

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内容发送出去。依赖于各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运行过程中得到的)是期望的内码,可以用PrintWriterout=res.getWriter()取代ServletOutputStreamout=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方式重新解析得到的字符串;或者以hackHttpUtils类的方式解决。不过最好将其中的中文 encoding GB2312、 CP1381 都改为 GBK,否则遇到 GBK 汉字时,还是会有问题。 


   ServletAPI2.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 没有上面说的那么麻烦 ),在 Application Server 的命令行参数中指定-Dfile.encoding=GBK即可;针对d,在ApplicationServer的命令行参数中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK,那么c情况下可以不再指定charset。 


 数据库读写时的 encoding 问题 



  JSP/Servlet 编程中经常出现 encoding 问题的另一个地方是读写数据库中的数据。流行的关系数据库系统都支持数据库 encoding,也就是说 在创建数据库时可以指定它自己的字符集设置,数据库的数据以指定的编码形式存储。当应用程序访问数据时,在入口和出口处都会有 encoding 转换。对于中文数据,应当保证数据的完整性。GB2312,GBK,UTF-8 等都是可选的数据库 encoding;如果选择 ISO8859-1(8-bitSBCS),那么应用程序在写数据之前须将16Bit的一个汉字或Unicode拆分成两个8-bit的字符,读数据之后则需将两个字节合并起来,同时还有判别其中的 SBCS 字符。没有充分利用数据库 encoding 的作用,反而增加了编程的复杂度,ISO8859-1不是推荐的数据
库 encoding。JSP/Servlet编程时,可以先用数据库管理系统提供的功能检查其中的中文数据是否正确。 


  然后应当注意的是读出来的数据的 encoding,JAVA 程序中一般得到的是 Unicode。写数据时则相反。 


   定位问题时常用的技巧 



  定位中文encoding问题通常采用最笨的也是最有效的办法——在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字符串的内码,你可以发现什么时候中文字符被转换成Unicode,什么时候Unicode被转回中文内码,什么时候一个中文字成了两个Unicode字符,什么时候中文字符串被转成了一串问号,什么时候中文字符串的高位被截掉了…… 


  取用合适的样本字符串也有助于区分问题的类型。如:”aa啊aa?aa”等中英相间、GB、GBK特征字符均有的字符串。一般来说,英文字符无论怎么转换或处理,都不会失真(如果遇到了,可以尝试着增加连续的英文字母长度)。 


表单使用Post方式提交后接收到的乱码问题

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


String str = new String(request.getParameter("something").getBytes("ISO-8859-1"),"utf-8");这样的话,每一个参数都必须这样进行转码。很麻烦。但确实可以拿到汉字。


B 在请求页面上开始处,执行请求的编码代码
request.setCharacterEncoding("UTF-8"),把提交内容的字符集设为UTF-8。这样的话,接受此参数的页面就不必在转码了。
注:这个方法也就对post提交的有效果,对于get提交和上传文件时的enctype="multipart/form-data"是无效的

C 为了避免每页都要写request.setCharacterEncoding("UTF-8"),建议使用过滤器对所有jsp进行编码处理。


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


这个乱码的原因也是tomcat的内部编码格式iso8859-1导致。Tomcat会以get的缺省编码方式iso8859-1对汉字进行编码,编码后追加到url,导致接受页面得到的参数为乱码

解决办法:

A。String str = new String(request.getParameter("something").getBytes("ISO-8859-1"),"utf-8");
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”来进行解码的。

 上传文件时的乱码解决

上传文件时,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转码。已经能得到正常所有汉字以及字符。


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



脚本中也会进行页面转向的控制,也会涉及到附带参数,并在接受页面解析这个参数的情况。如果这个汉字参数不进行URIEncoding=”UTF-8”所指定的编码处理,则接受页面接受到的汉字也是乱码。脚本处理编码比较麻烦,必须有相应的编码脚本对应文件,然后调用脚本中的方法对汉字进行编码即可。


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



对于一个已经存在的项目,Jsp文件的存储格式可能是utf-8。如果新安装的eclipse,则缺省打开使用的编码格式都是iso8859-1。所以导致jsp里面的汉字出现乱码。这个乱码比较容易解决,直接到eclipse3.1的偏好设置里面找到general-〉edidor,设置为您的文件打开编码为utf-8即可。Eclipse会自动重新以新的编码格式打开。汉字即可正常显示。


 关于html页面在eclipse中打开出现乱码情况

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



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。问题又出来了,第一就是参数值的个数如果是奇数个数,则就可以正常解析,如果使偶数个数,得到最后字符就是乱码。还有就是如果最后一个字符如果是英文,则就能正常解析,但中文的标点符号仍出现乱码。权宜之计,如果您的参数中没有中文标点符号,则可以在参数值最后加一个英文符号来解决乱码问题,得到参数后再去掉这个最后面的符号。也可以凑或使用。

总结

三个地方的编码


第一个地方的编码格式为jsp文件的存储格式。Eclipse会根据这个编码格式保存文件。并编译jsp文件,包括里面的汉字。


第二处编码为解码格式。因为存为UTF-8的文件被解码为iso8859-1,这样如有中文肯定出乱码。也就是必须一致。缺省也是使用iso8859-1的编码格式。
   第三处编码为控制浏览器的解码方式。如果前面的解码都一致并且无误的话,这个编码格式没有关系。有的网页出现乱码,就是因为浏览器不能确定使用哪种编码格式
因为页面有时候会嵌入页面,导致浏览器混淆了编码格式。出现了乱码。

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中一样的,但是在servletjava文件中构造的String是使用的系统默认的编码的。在servelt中从外部得到的String是使用原来的编码的,比如从编码为B的数据库得到的数据是编码为B的,不是A,也不是系统默认的编码。


具体说来,需要哪些信息才能确定项目中的乱码的根源。

a,开发者所用的操作系统
b,j2ee容器的名称,版本
c,数据库的名称,版本(精确版本)以及jdbc驱动的版本
d,出现乱码的source code(比如是system out 出来的,还是jsp页面中的,如果是jsp中的,那么头部声明的情况也很重要)


如何初步分析乱码出现的原因。

有了上述的信息,基本上就可以发帖求助了,相信放到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-Typecontent=”text/html; charset=gb2312〃>两者的不同。通常网上的很多文章在提到中文问题时都是说数据库中选择unicode或者gb2312存储,同
时在jsp中用page指令声明编码就可以解决。但是我觉得这种说法很不负责任,害的我费了N多时间为本
来并不存在的乱码而郁闷。 实际上page的作用是在jsp被编译成为html的过程中提供编码方式让java来”读取”表达式当中的String,而meta
的作用是众所周知的为IE浏览器提供编码选择,是用来”显示”最后的数据的


数据库选择什么样的编码比较好。

目前流行的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的characterset,每个table,column都可以指定编码,不指定就是ISO8895_1,因此jdbc取出数据后会根据column的character set来进行编码,而不再是用一个全局的参数来取所有的数据了。


这从另一个方面也说明了乱码问题的产生实在是很复杂的事情,原因太多了。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值