关于处理Java web中中文乱码的问题.doc

河北师范大学附属民族学院 学生毕业论文（设计）题目 关于Java Web 技术开发中中文乱码问题 的深入讨论 作者姓名 张天龙 系 别 数信系 专 业 计算机应用技术 班 级 08专1班 指导教师 段继光 完成日期 2011 年 5 月 30 日 河北师范大学附属民族学院教务处编制关于 Java Web技术开发中中文乱码问题的深入探讨数信系08专1班 张天龙 08221035 指导老师：段继光摘要：在利用Servalete/Jsp 技术开发 Web应用程序的时候，不可避免的会遇到中文乱码问题。如：页面编码不一致；表单get提交时产生乱码问题；表单使用post方式时产生的乱码问题等。本文首先详细分析这些中文乱码问题产生的原因，并以图例清晰具体的展现出来，最后在此基础上提出详细合理的解决方案。关键字：Java Web技术开发 中文乱码 字符集1 引言为了能在计算机中表示不同语言中字符，每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的ASCII，中国GB2312和GBK，日本的JIS等。Java语言内部用Unicode来表示字符，Unicode被称为统一的字符编码标准集，它为几乎每种语言中的字符设定了唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。这也使得Java具有良好的可移植性，符合其国际化的思想。然而在实际应用中，由于应用程序的运行环境不同，和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的中文乱码问题时时困扰着程序员和用户。2. 中文乱码产生的原因Java中文问题一直困扰着很多初学者，如果了解了Java系统的中文问题原理，我们就可以对中文问题能够采取根本的解决之道。 最古老的解决方案是使用String的字节码转换，这种方案问题是不方便，我们需要破坏对象封装性，进行字节码转换。 还有一种方式是对J2EE容器进行编码设置，如果J2EE应用系统脱离该容器，则会发生乱码，而且指定容器配置不符合J2EE应用和容器分离的原则。 在Java内部运算中，涉及到的所有字符串都会被转化为UTF-8编码来进行运算。那么，在被Java转化之前，字符串是什么样的字符集？ Java总是根据操作系统的默认编码字符集来决定字符串的初始编码，而且Java系统的输入和输出的都是采取操作系统的默认编码。 因此，如果能统一Java系统的输入、输出和操作系统3者的编码字符集合，将能够使Java系统正确处理和显示汉字。这是处理Java系统汉字的一个原则， 但是在实际项目中，能够正确抓住和控制住Java系统的输入和输出部分是比较难的。J2EE中，由于涉及到外部浏览器和数据库等，所以中文问题乱码显得非常突出。 J2EE应用程序是运行在J2EE容器中。在这个系统中，输入途径有很多种：一种是通过页面表单打包成请求 （request）发往服务器的；第二种是通过数据库读入；还有第3种输入比较复杂，JSP在第一次运行时总是被编译成Servlet，JSP中常常包含 中文字符，那么编译使用javac时，Java将根据默认的操作系统编码作为初始编码。除非特别指定，如在Jbuilder/eclipse中可以指定默 认的字符集。 输出途径也有几种：第一种是JSP页面的输出。由于JSP页面已经被编译成Servlet，那么在输出时，也将根据操作系统的默认编码来选择输出编码，除非指定输出编码方式；还有输出途径是数据库，将字符串输出到数据库。 由此看来，一个J2EE系统的输入输出是非常复杂，而且是动态变化的，而Java是跨平台运行的，在实际编译和运行中，都可能涉及到不同的操作系统，如果任由Java自由根据操作系统来决定输入输出的编码字符集，这将不可控制地出现乱码。 正是由于Java的跨平台特性，使得字符集问题必须由具体系统来统一解决，所以在一个Java应用系统中，解决中文乱码的根本办法是明确指定整个应用系统统一字符集。 指定统一字符集时，到底是指定ISO8859_1 、GBK还是UTF-8呢？ （1）如统一指定为ISO8859_1，因为目前大多数软件都是西方人编制的，他们默认的字符集就是ISO8859_1，包括操作系统Linux和数据库MySQL等。这样，如果指定Jive统一编码为ISO8859_1，那么就有下面3个环节必须把握： A 开发和编译代码时指定字符集为ISO8859_1。 B 运行操作系统的默认编码必须是ISO8859_1，如Linux。 C 在JSP头部声明：。 （2）如果统一指定为GBK中文字符集，上述3个环节同样需要做到，不同的是只能运行在默认编码为GBK的操作系统，如中文Windows。 统一编码为ISO8859_1和GBK虽然带来编制代码的方便，但是各自只能在相应的操作系统上运行。但是也破坏了Java跨平台运行的优越性，只在一定范围内行得通。例如，为了使得GBK编码在linux上运行，设置Linux编码为GBK。 那么有没有一种除了应用系统以外不需要进行任何附加设置的中文编码根本解决方案呢？ 将Java/J2EE系统的统一编码定义为UTF-8。UTF-8编码是一种兼容所有语言的编码方式，惟一比较麻烦的就是要找到应用系统的所有出入口，然后使用UTF-8去“结扎”它。 一个J2EE应用系统需要做下列几步工作： A 开发和编译代码时指定字符集为UTF-8。JBuilder和Eclipse都可以在项目属性中设置。 B 使用过滤器，如果所有请求都经过一个Servlet控制分配器，那么使用Servlet的filter执行语句，将所有来自浏览器的请求（request）转换为UTF-8，因为浏览器发过来的请求包根据浏览器所在的操作系统编码，可能是各种形式编码。关键一句： request.setCharacterEncoding(UTF-8)。 网上有此filter的源码，Jdon框架源码中com.jdon.util.SetCharacterEncodingFilter ，需要配置web.xml 激活该Filter。 C 在JSP头部声明：。 D 在Jsp的html代码中，声明UTF-8: E 设定数据库连接方式是UTF-8。例如连接MYSQL时配置URL如下： jdbc:mysql:/localhost:3306/test?useUnicode=true&characterEncoding=UTF-8 一般数据库都可以通过管理设置设定UTF-8 F 其他和外界交互时能够设定编码时就设定UTF-8，例如读取文件，操作XML等。在Web应用中，通常都包括了浏览器、Web服务器、Web应用程序和数据库等部分。若不指定编码格式，浏览器会根据本地系统默认的字符集（如：GB2312）提交数据，而Web容器默认采用的是ISO-8859-1的编码方式解析Post数据，另外JDBC驱动程序多数也采用ISO-8859-1的编码方式，因此，在Web应用程序运行过程中，输入的中文字符往往需要在不同的字符集之间来回转换，这就导致了中文乱码问题的频繁出现。浏览器发送GB2312编码的中文数据。Web容器内部按照ISO-8859-1向Unicode编码。在应用程序中调用请求对象的getParameter方法得到请求的参数值Unicode向编码的字符向GB2312转换，导致浏览器最终显示乱码。输出时指定字符集为GB2312图 1在Web请求过程中，中文字符编码的转换过程图1描述了在Web应用的请求相应过程中，发生的字符编码转换过程，其中浏览器是IE6.0，Web容器是tomcat5.5因此，对于中文问题的处理，应该在图1的、的位置明确指定使用同一的支持中文的字符编码集。3. 中文乱码问题的解决方案通过对中文乱码产生原因的分析，结合容易产生该问题的具体场景，提出以下的解决方案。3.1 最基本的乱码问题。这个乱码问题是最简单的乱码问题。一般新人会出现。就是页面编码不一致导致的乱码。中文问题我是个好人三个地方的编码。第一个地方的编码格式为jsp文件的存储格式。Ecljpse等编辑jsp的环境会根据这个编码格式保存并编译jsp文件，编辑时要将编辑jsp的环境设置成这样的编码格式载入。第二处编码为解码格式，即浏览器按照什么格式显示网页。缺省是使用iso8859-1的编码格式。因为iso8859-1不含中文字符，这样如有中文肯定出现乱码。也就是要换成GB2312或UTF-8。此句必须，若不设置有时浏览器不知道用什么编码方式显示网页。当此句设置的和第一句相同时，可以省略第一句。第三处编码为html控制浏览器的解码方式。如果前面的两处都无误的话，这个编码格式没有关系。有的网页出现乱码，就是因为浏览器不能确定使用哪种编码格式。因为页面有时候会嵌入页面，导致浏览器混淆了编码格式。出现了乱码。3.2表单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又要根据里面所设置的URIEncoding=”UTF-8”再进行一次编码，但是由于已经编码为utf-8，再编码也不会有变化了。如果是从url获取编码，接受页面则是根据URIEncoding=”UTF-8”来进行解码的。3.3表单使用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)，把提交内容的字符集设为UTF8。这样的话，直接使用String str = request.getParameter(something)；即可得到汉字参数。但每页都需要执行这句话。这个方法也就对post提交的有效 果，对于get提交和上传文件时的enctype=multipart/form-data是无效的。稍后下面单独对这个两个的乱码情况再进行说明。C， 为了避免每页都要写request.setCharacterEncoding(UTF-8)，建议使用过滤器对所有jsp进行编码处理。如：在web.xml里面加 char mon.CharacterFilter char /* CharacterFilter类package mon;import java.io.IOException;import javax.servlet.Filter;import javax.servlet.FilterChain;import javax.servlet.FilterConfig;import javax.servlet.ServletException;import javax.servlet.ServletRequest;import javax.servlet.ServletResponse;public class CharacterFilter implements Filter public void destroy() public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException System.out.println(filter.); request.setCharacterEncoding(UTF-8); chain.doFilter(request, response); public void init(FilterConfig filterConfig) throws ServletExcepti