JavaJSP中文乱码问题解决心得

Java/JSP中文乱码问题解决心得

自从接触Java和JSP以来,就不断与Java的中文乱码问题打交道,现在终于得到了彻底的解决,现将我们的解决心得与大家共享。

一、Java中文问题的由来

Java的内核和class文件是基于unicode的,这使Java程序具有良好的跨平台性,但也带来了一些中文乱码问题的麻烦。原因主要有两方面,Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。

首先Java(包括JSP)源文件中很可能包含有中文,而Java和JSP源文件的保存方式是基于字节流的,如果Java和JSP编译成class文件过程中,使用的编码方式与源文件的编码不一致,就会出现乱码。基于这种乱码,建议在Java文件中尽量不要写中文(注释部分不参与编译,写中文没关系),如果必须写的话,尽量手动带参数-ecoding GBK或-ecoding gb2312编译;对于JSP,在文件头加上或基本上就能解决这类乱码问题。

本文要重点讨论的是第二类乱码,即Java程序与其他存储媒介交互时产生的乱码。很多存储媒介,如数据库,文件,流等的存储方式都是基于字节流的,Java程序与这些媒介交互时就会发生字符(char)与字节(byte)之间的转换,具体情况如下:

从页面form提交数据到java程序 byte->char

从java程序到页面显示 char?>byte

从数据库到java程序 byte?>char

从java程序到数据库 char?>byte

从文件到java程序 byte->char

从java程序到文件 char->byte

从流到java程序 byte->char

从java程序到流 char->byte

如果在以上转换过程中使用的编码方式与字节原有的编码不一致,很可能就会出现乱码。

二、解决方法

前面已经提到了Java程序与其他媒介交互时字符和字节的转换过程,如果这些转换过

程中容易产生乱码。解决这些乱码问题的关键在于确保转换时使用的编码方式与字节原有的编码方式保持一致,下面分别论述(Java或JSP自身产生的乱码请参看第一部分)。

1、JSP与页面参数之间的乱码

JSP获取页面参数时一般采用系统默认的编码方式,如果页面参数的编码类型和系统默认的编码类型不一致,很可能就会出现乱码。解决这类乱码问题的基本方法是在页面获取参数之前,强制指定request获取参数的编码方式:request.setCharacterEncoding("GBK")或request.setCharacterEncoding("gb2312")。

如果在JSP将变量输出到页面时出现了乱码,可以通过设置response.setContentType("text/html;charset=GBK")或response.setContentType("text/html;charset=gb2312")解决。

如果不想在每个文件里都写这样两句话,更简洁的办法是使用Servlet规范中的过虑器指定编码,过滤器的在web.xml中的典型配置和主要代码如下:

web.xml:

CharacterEncodingFilter

net.vschool.web.CharacterEncodingFilter

encodingGBK

CharacterEncodingFilter

/*

CharacterEncodingFilter.java:

public class CharacterEncodingFilter implements Filter

{

protected String encoding = null;

public void init(FilterConfig filterConfig) throws ServletException

{

this.encoding = filterConfig.getInitParameter("encoding");

}

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException

{

request.setCharacterEncoding(encoding);

response.setContentType("text/html;charset="+encoding);

chain.doFilter(request, response);

}

}

2、Java与数据库之间的乱码

大部分数据库都支持以unicode编码方式,所以解决Java与数据库之间的乱码问题比较明智的方式是直接使用unicode编码与数据库交互。很多数据库驱动自动支持unicode,如Microsoft的SQLServer驱动。其他大部分数据库驱动,可以在驱动的url参数中指定,如如mm的mysql驱动:jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。

3、Java与文件/流之间的乱码

Java读写文件最常用的类是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基于字节流的,常用于读写二进制文件。读写字符文件建议使用基于字符的FileReader和FileWriter,省去了字节与字符之间的转换。但这两个类的构造函数默认使用系统的编码方式,如果文件内容与系统编码方式不一致,可能会出现乱码。在这种情况下,建议使用FileReader和FileWriter的父类:InputStreamReader/OutputStreamWriter,它们也是基于字符的,但在构造函数中可以指定编码类型:InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter(OutputStream out, Charset cs)。

4、其他

上面提到的方法应该能解决大部分乱码问题,如果在其他地方还出现乱码,可能需要手动修改代码。解决Java乱码问题的关键在于在字节与字符的转换过程中,你必须知道原来字节或转换后的字节的编码方式,转换时采用的编码必须与这个编码方式保持一致。我们以前使用Resin服务器,使用smartUpload组件上传文件,上传文件同时传递的中文参数获取没有乱码问题。当在Linux中把Resin设置成服务后,上传文件同时的中文参数获取出现了乱码。这个问题困扰了我们很久,后来我们分析smartUpload组件的源文件,因为文件上传采用的是字节流的方式,里面包含的参数名称和值也是字节流的方式传递的。smartUpload

组件读取字节流后再将参数名称和值从字节流中解析出来,问题就出现在smartUpload将字节流转换成字符串时采用了系统默认的编码,而将Resin设置成服务后,系统默认的编码可能发生了改变,因此出现了乱码。后来,我们更改了smartUpload的源文件,增加了一个属性charset和setCharset(String)方法,将upload()方法中提取参数语句:

String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1 );

改成了

String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1, charset );

终于解决了这个乱码问题。

 

第二篇:中文乱码解决大全

JSP中文乱码问题综述

2010-08-10 14:25:31

中文乱码解决大全

一、Java中文问题的由来

Java的内核和class文件是基于unicode的,这使Java程序具有良好的跨平台性,但也带来了一些中文乱码问题的麻烦。原因主要有两方面,Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。

首先Java(包括JSP)源文件中很可能包含有中文,而Java和JSP源文件的保存方式是基于字节流的,如果Java和JSP编译成class文件过程中,使用的编码方式与源文件的编码不一致,就会出现乱码。基于这种乱码,建议在Java文件中尽量不要写中文(注释部分不参与编译,写中文没关系),如果必须写的话,尽量手动带参数-ecoding GBK或-ecoding gb2312编译;对于JSP,在文件头加上<%@ page contentType=text/html;charset=GBK%>或<%@ page contentType=text/html;charset=gb2312%>基本上就能解决这类乱码问题。

二、常见的解决方式

1,最基本的乱码问题。

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

<%@ page language=java pageEncoding=UTF-8%>

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

<html>

<head>

<title>中文问题</title>

<meta http-equiv=Content-Type content=text/html; charset=UTF-8>

</head>

</head>

<body>

我是个好人

</body>

</html>

三个地方的编码。

第一个地方的编码格式为jsp文件的存储格式。Ecljpse会根据这个编码格式保存文件。并编译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 进行编码处理。

如果不想在每个文件里都写这样两句话,更简洁的办法是使用Servlet规范中的过虑器指定编码,过滤器的在web.xml中的典型配置和主要代码

如下:

web.xml:

<filter>

<filter-name>CharacterEncodingFilter</filter-name>

<filter-class>net.vschool.web.CharacterEncodingFilter</filter-class>

<init-param>

<param-name>encoding</param-name>

<param-value>GBK</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CharacterEncodingFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

CharacterEncodingFilter.java:

public class CharacterEncodingFilter implements Filter

{

protected String encoding = null;

public void init(FilterConfig filterConfig) throws ServletException

{

this.encoding = filterConfig.getInitParameter(encoding);

}

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException

{

request.setCharacterEncoding(encoding);

response.setContentType(text/html;charset=+encoding);

chain.doFilter(request, response);

}

}

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 = request.getParameter(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开发过程中会遇到各种中文乱码问题,对乱码的

处理方法也有所不同!究其原因.大部分是因为编码默认采用ISO-8859-1或者是编码不一致导致的,悲剧的是默认的ISO-8859-1编码不支持中文!(唉,中国...感慨一下,不解释)所幸,UTF-8,GBK,GB2312都是支持中文的!

1. jsp页面中文乱码 这种乱码最常见也最好解决 在page指令中添加页面内容和显示方式的设置,如下两种都可以:

? <%@ page language="java" import="java.util.*" pageE

ncoding="gb2312"%>

? <%@ page language="java" import="java.util.*" Conte

ntType="text/html;charset=gb2312"%>

有人会问pageEncoding和ContentType有什么区别,简单说

contentType指定的是JSP页最终 Browser(客户端)所见到的网页内容的编码

pageEncoding指定JSP编写时所用的编码

2. 表单提交中文乱码 当用Request对象获取客户提交

的汉字代码的时候,会出现乱码

Method=”POST”

接收数据的文件中要加入<% request.setCharacterEncoding("gb2312");%>

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

new String(userName.getBytes("ISO-8859-1"), "gb2312")这句代码是转换编码格式的关键,这种转码方式还可以用在读取数据库中文乱码的转码!但要是原来的字符编码不是ISO-8859-1时这个方法就会失效,出错!

try{

byte[] tempByte = gbStr.getBytes("GB2312");

uniStr = new String(tempByte,"ISO8859_1");

}catch(Exception ex){

}

你也可以在直接的转换,首先你将获取的字符串用

ISO-8859-1进行编码,然后将这个编码存放到一个字节数组中,然后将这个数组转化成字符串对象就可以了,例如:

String str=request.getParameter(“字符串”);

Byte B[]=str.getBytes(“ISO-8859-1”);

Str=new String(B);

4. 读取cookie时出现乱码

写入cookie时先编码

Cookie nameCookie = new Cookie("name", java.net.URLEncoder.encode(strname,"GB2312"));

读取cookie时再解码

String name=java.net.URLDecoder.decode(name,"GB2312")

或者采用树上第136页的方法

写入cookie时先编码,将汉字编码转换为Unicode编码,解决汉字乱码问题

读取cookie时再解码,将Unicode编码转换为汉字编码,解决汉字乱码问题

2. 编码基本知识

最早的编码是iso8859-1,和ascii编码相似。但为了方便表示各种各样的语言,逐渐出现了很多标准编码,重要的有如下几个。

2.1. iso8859-1

属于单字节编码,最多能表示的字符范围是0-255,应用于英文系列。比如,字母'a'的编码为0x61=97。

很明显,iso8859-1编码表示的字符范围很窄,无法表示中文字符。但是,由于是单字节编码,和计算机最基础的表示单位一致,所以很多时候,仍旧使用iso8859-1编码来表示。而且在很多协议上,默认使用该编码。比如,虽然"中文"两个字不存在iso8859-1编码,以gb2312编码为例,应该是"d6d0 cec4"两个字符,使用iso8859-1编码的时候则将它拆开为4个字节来表示:"d6 d0 ce c4"(事实上,在进行存储的时候,也是以字节为单位处理的)。而如果是UTF编码,则是6个字节"e4 b8 ad e6 96 87"。很明显,这种表示方法还需要以另一种编码为基础。

2.2. GB2312/GBK

这就是汉子的国标码,专门用来表示汉字,是双字节编码,而英文字母和iso8859-1一致(兼容iso8859-1编码)。其中gbk编码能够用来同时表示繁体字和简体字,而gb2312只能表示简体字,gbk是兼容gb2312编码的。

2.3. unicode

这是最统一的编码,可以用来表示所有语言的字符,而且是定长双字节(也有四字节的)编码,包括英文字母在内。所以可以说它是不兼容iso8859-1编码的,也不兼容任何编码。不过,相对于iso8859-1编码来说,uniocode编码只是在前面增加了一个0字节,比如字母'a'为"00 61"。

需要说明的是,定长编码便于计算机处理(注意GB2312/GBK不是定长编码),而unicode又可以用来表示所有字符,所以在很多软件内部是使用unicode编码来处理的,比如java。

2.4. UTF

考虑到unicode编码不兼容iso8859-1编码,而且容易占用更

多的空间:因为对于英文字母,unicode也需要两个字节来表示。所以unicode不便于传输和存储。因此而产生了utf编码,utf编码兼容iso8859-1编码,同时也可以用来表示所有语言的字符,不过,utf编码是不定长编码,每一个字符的长度从1-6个字节不等。另外,utf编码自带简单的校验功能。一般来讲,英文字母都是用一个字节表示,而汉字使用三个字节。

注意,虽然说utf是为了使用更少的空间而使用的,但那只是相对于unicode编码来说,如果已经知道是汉字,则使用GB2312/GBK无疑是最节省的。不过另一方面,值得说明的是,虽然utf编码对汉字使用3个字节,但即使对于汉字网页,utf编码也会比unicode编码节省,因为网页中包含了很多的英文字符。

相关推荐