???? ?遇到乱码，是最令人不爽的事情。一下是收集并整理的一些解决问题的有效办法。
??? ? 在看正文之前，先要强调一下：对于GET和POST的乱码问题处理是不同的。?
???? ?首先看看，为什么会有乱码产生。从而能够更好的避免乱码，以及解决乱码问题。
????? 在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个环节必须把握：开发和编译代码时指定字符集为ISO8859_1。运行操作系统的默认编码必须是ISO8859_1，如Linux。在JSP头部声明。
（2）如果统一指定为GBK中文字符集，上述3个环节同样需要做到，不同的是只能运行在默认编码为GBK的操作系统，如中文Windows。统一编码为ISO8859_1和GBK虽然带来编制代码的方便，但是各自只能在相应的操作系统上运行。但是也破坏了Java跨平台运行的优越性，只在一定范围内行得通。例如，为了使得GBK编码在linux上运行，设置Linux编码为GBK。
那么有没有一种除了应用系统以外不需要进行任何附加设置的中文编码根本解决方案呢？
将Java/J2EE系统的统一编码定义为UTF-8。UTF-8编码是一种兼容所有语言的编码方式，惟一比较麻烦的就是要找到应用系统的所有出入口，然后使用UTF-8去“结扎”它。一个J2EE应用系统需要做下列几步工作：
开发和编译代码时指定字符集为UTF-8。JBuilder和Eclipse都可以在项目属性中设置。使用过滤器，如果所有请求都经过一个Servlet控制分配器，那么使用Servlet的filter执行语句，将所有来自浏览器的请求（request）转换为UTF-8，因为浏览器发过来的请求包根据浏览器所在的操作系统编码，可能是各种形式编码。关键一句：request.setCharacterEncoding("UTF-8")。网上有此filter的源码，Jdon框架源码中com.jdon.util.SetCharacterEncodingFilter需要配置web.xml 激活该Filter。
在JSP头部声明：
在Jsp的html代码中，声明UTF-8:
设定数据库连接方式是UTF-8。例如连接MYSQL时配置URL如下：
jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8
一般数据库都可以通过管理设置设定UTF-8
其他和外界交互时能够设定编码时就设定UTF-8，例如读取文件，操作XML等。
一、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"%>基本上就能解决这类乱码问题。
本文要重点讨论的是第二类乱码，即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: <filter> ? <filter-name>SetCharacterEncodingFilter</filter-name> ? <filter-class>filter.SetCharacterEncodingFilter</filter-class> ? <init-param> ?? <param-name>encoding</param-name> ?? <param-value>GBK</param-value> ? </init-param> </filter> <filter-mapping> ? <filter-name>SetCharacterEncodingFilter</filter-name> ? <url-pattern>/*</url-pattern> </filter-mapping>?
?SetCharacterEncodingFilter.java
package action;
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 SetCharacterEncodingFilter implements Filter {
// 编码的字符串
protected String encoding = null;
// 过滤器的配置
protected FilterConfig filterConfig = null;
// 是否忽略客户端的编码
protected boolean ignore = true;
// 销毁过滤器
public void destroy() {
this.encoding = null;
this.filterConfig = null;
}
// 过滤方法
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
// 如果使用过滤器，忽略客户端的编码，那么使用通过过滤器设定编码
if (ignore || (request.getCharacterEncoding() == null)) {
String encoding = selectEncoding(request);
if (encoding != null)
request.setCharacterEncoding(encoding);
}
// 传送给下一个过滤器
chain.doFilter(request, response);
}
// 初始化过滤器
public void init(FilterConfig filterConfig) throws ServletException {
this.filterConfig = filterConfig;
this.encoding = filterConfig.getInitParameter("encoding");
String value = filterConfig.getInitParameter("ignore");
if (value == null)
this.ignore = true;
else if (value.equalsIgnoreCase("true"))
this.ignore = true;
else if (value.equalsIgnoreCase("yes"))
this.ignore = true;
else
this.ignore = false;
}
// 返回过滤器设定的编码
protected String selectEncoding(ServletRequest request) {
return (this.encoding);
}
}
?
?
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)。
?
三、避免乱码的一些注意点
1.尽量使用统一的编码，如果你是重头开发一个系统，特别是Java开发的，推荐从页面到数据库再到配置文件都使用UTF-8进行编码，安全第一。
2.SetCharacterEncodingFilter的使用，这个东西不是万能的，但是没有它就会很麻烦，如果是基于Servlet开发的东西，能用的就给它用上，省心。不过有一个注意的地方，这个Filter只是对POST请求有效，GET一律忽略，不信你可以debug一下，看看它怎么做的，至于为什么不过滤get请求，好象是它对GET请求是无能为力的。
3.就如上面所说，GET请求有问题，尽量使用POST请求，这个也是Web开发的一个基本要领：
Web Health Warning:Put All Destructive Actions Behind a POST method(from Agile Web Development with Rails)
有点扯远了，不过少用GET，是会有回报滴。
4.JavaScript和Ajax乱码的避免，注意JavaScript默认是ISO8859的编码，避免JS/AJAX乱码和GET一样，不要在URL里面使用中文，实在避免不了，就只能在生成链接的时候转码，绝对不能想当然的认为SetCharacterEncodingFilter会帮你做什么事情。
?
四、乱码发生的情况和应对措施
最古老的解决方案是使用String的字节码转换，这种方案问题是不方便，我们需要破坏对象封装性，进行字节码转换。
还有一种方式是对J2EE容器进行编码设置，如果J2EE应用系统脱离该容器，则会发生乱码，而且指定容器配置不符合J2EE应用和容器分离的原则。
1.开发环境乱码
????? 由于Java默认使用UTF-8编码，而且网上很多人都建议Struts开发的时候应尽量选用UTF-8做为默认编码，而非GBK。IDE使 用Eclipse，在第一次使用Eclipse的时候应将default text editor改为UTF-8编码，免得日后后悔再改就惨了
2.POST请求的过滤
????? 这个是最基本的了，每个Servlet系统基本都会用到这个东西。不过只对POST请求有效，这个挺关键的。使用SetCharacterEncodingFilter（具体代码前面有），这个很基础的一套过滤器，将所有来自页面的POST请求全部过滤为UTF-8编码。
3. JSP ,HTML页面乱码
???? 将JSP页面全部改为charset=UTF-8，这样可以保证与后台交互的时候都是UTF-8编码，一般应用做了以上工作就基本可以应付了。
4.资源文件中汉字转化UTF-8字符问题
????? 国际化问题，在使用资源文件的时候，由于中文在properties文件中无法被程序所识别，需要将其进行转码，我在资源文件下面制作了一个很简单的 bat文件，每次修改资源文件的时候都是在一个临时文件中修改，然后执行这个bat文件，将其转化并保存为所需要的资源文件，这个动作挺烦的，也有项目组 成员使用一些插件，但是那些东西都是直接写UTF-8码的，有时候反倒不方便，不过以后任务量巨大的时候可能会考虑使用。Bat文件内容：:set path=%path%;%JAVA_HOME%/bin/,native2ascii -encoding UTF-8 ApplicationResources_bk.txt > ApplicationResources_zh.properties
???? PS:上面的方法好老了，实际操作起来相当麻烦，现在基本都是使用Eclipse插件，Eclipse3.1时使用PropertyEditor，但是这 个项目看上去好像停摆了，到Eclipse3.2时改用了ResourseBundle，相当的强劲的一个插件，推荐使用。
5. GET请求乱码
????? 如果在本项目中采用了get方式提交请求并附加参数，结果导致编码乱码，原因是Tomcat默认请求编码是ISO8859，需要在Tomcat的配置文件 server.xml添加一个参数，URIEncoding=”UTF-8”,这样请求中附件的参数就会以UTF-8来进行编码。方法是找到 server.xml 中的
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
??? enableLookups="false" redirectPort="8443" URIEncoding='GBK' />标记，粗体字是我添加的。
记住修改了tomcat的配置后要重启tomcat
6.Ajax请求乱码
??? 使用Ajax，JS也是默认使用ISO8859编码，所以在进行请求时遇到中文参数需要进行编码，如：var url = "GetSelectListAction.do?queryData=subTrade" + "&queryId=" + encodeURI(obj.value) + "&r=" + Math.random();??
??? 这里有两个地方需要注意：第一个地方是encodeURI()，方法，可以将参数进行转码，默认是转化为UTF-8，如果需要转为其他码制，需要在方法中添加第二个参数。
???? 第二个地方是Math.random()，由于Ajax有缓存机制，在接受请求的时候第一时间先判断该请求的地址是否被访问过，如果被访问过则 直接使用缓存中的内容返回，这个东西很讨厌，客户在访问过一次出错后以后每次出现的都是这个错误，所以在请求中给其增加一个时间戳，只要可以随机生成一个 不同的字串就可以，保证Ajax每次都去访问服务器。
?用ajax来get一个页面时，responseText里面的中文一般都会乱码，这是因为xmlHttp在处理返回responseText的时候，是把resposeBody按UTF-8编码进行解码形成的，如果服务器送出的确实是UTF-8的数据流的时候汉字会正确显示，而送出了GBK编码流的时候就乱了。解决的办法就是在送出的流里面加一个HEADER，指明送出的是什么编码流，这样XMLHTTP就不会乱搞了。
JSP:?? response.setHeader("Charset","GB2312");
但是切记：如果是使用了session_start();
那么一定要如下的格式进行编写：
header("Content-type: text/html;charset=GB2312");
session_start();不然，session就不会产生效果！！
而在POST传递时这种方法就没有效果，则可以使用先在javascript中把中文进行两次encodeURL转换，在服务端用urldecode换会后用iconv()进行把utf-8转换成gb2312。（默认传过去就是utf-8编码，如果你的网页本身就是utf-8编码格式，则不需要进行iconv转换）
ajax产生乱码的原因整理如下：
a、xtmlhttp 返回的数据默认的字符编码是utf-8，如果客户端页面是gb2312或者其它编码数据就会产生乱码
b、post方法提交数据默认的字符编码是utf-8，如果服务器端是gb2312或其他编码数据就会产生乱码.
解决办法有：
a、若客户端是gb2312编码，则在服务器指定输出流编码
b、服务器端和客户端都使用utf-8编码
7. GET方法的另一个乱码问题
????? 在项目即将交工的时候突然又出现乱码问题，发现对于超长的汉字做为参数传递仍然会出现乱码问题，解决方法是采用java.net.URLEncoder的 Encode方法强制转码，缺点是会使JSP页面代码相当的长，但是目前还没有其他好的解决办法，我想最好的办法就是不用中文做为参数传递 ：P，写法如：<a href="TestAction.do?name=<%= java.net.URLEncoder.encode("你好","UTF-8")%>
8.数据库乱码其实也很讨厌的，一般来说驱动问题比较常见，所以一旦碰到比较难缠的乱码可以先考虑下换换驱动。也有如MySQL这种，直接连接的时候就需要显示进行编码转化的，这个就要不同情况区别对待了。
Java乱码是因为Java和JSP源文件的保存方式是基于字节流的，如果Java和JSP编译成class文件过程中，使用的编码方式与源文件的编码不一致，就会出现乱码。在这里，总结一下java乱码的一些常见情况:
1.Javascript传参乱码：
在浏览器端对要传递的中文参数进行编码处理.代码如下:
xmlhttp.open("POST",url,true); //请求参数初始化
xmlhttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded"); //因为请求方式为POST,所以这里要设置请求头.(如果请求方式为GET,此句代码可以省略)
xmlhttp.send("name="+encodeURI(encodeURI("星期日"))); //向服务器端发送参数
在服务器端代码:
页面jsp保证是utf-8编码
<%@ page contentType="text/html; charset=utf-8"%>
接受中文参数
PrintWriter out = response.getWriter(); //得到response的输出流对象
String name1 = request.getParameter("name"); //得到KEY为"name"的请求参数
String name = URLDecoder.decode(name1,"utf-8"); //对得到的参数进行解码
out.print(name); //向浏览器端发送数据
?
2.JSP与页面参数之间的乱码
?????? JSP获取页面参数时一般采用系统默认的编码方式，如果页面参数的编码类型和系统默认的编码类型不一致，很可能就会出现乱码。解决这类乱码问题的基本方法是在页面获取参数之前，强制指定request获取参数的编码方式：request.setCharacterEncoding("UTF-8") 。
??? 如果在JSP将变量输出到页面时出现了乱码，可以通过设置response.setContentType("text/html;charset=UTF-8")。
JSP页面乱码通常只要在页面开始地方用上面代码指定字符集编码即可。如果还不行，那么请用下面这句话来转换 str=new String(str.getBytes("ISO-8859-1"),"页面编码方式");
3.热链接传参乱码
在传参的jsp对中文进行编码：href="new.jsp?name=java.net.URLEncoder.encode("链接")";
在接受的jsp对中文进行转码：String str = URLDecoder.decode(request.getParameter("name "), "utf-8");
4.Java与数据库之间的乱码
大部分数据库都支持以unicode编码方式，所以解决Java与数据库之间的乱码问题比较明智的方式是直接使用unicode编码与数据库交互。很多数据库驱动自动支持unicode，如Microsoft的SQLServer驱动。其他大部分数据库驱动，可以在驱动的url参数中指定，如mysql驱动：jdbc:mysql://localhost/MYAPPS?useUnicode=true&characterEncoding=GBK。
5.Java与文件/流之间的乱码
Java读写文件最常用的类是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基于字节流的，常用于读写二进制文件。读写字符文件建议使用基于字符的FileReader和FileWriter，省去了字节与字符之间的转换。但这两个类的构造函数默认使用系统的编码方式，如果文件内容与系统编码方式不一致，可能会出现乱码。在这种情况下，建议使用FileReader和FileWriter的父类：InputStreamReader/OutputStreamWriter，它们也是基于字符的，但在构造函数中可以指定编码类型：InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter(OutputStream out, Charset cs)。
关于三者之间的中文乱码问题，各大论坛都讨论过不少了，但是很多都是给矛了针对某种转换的解决办法，有的搞了几年开发，对这个问
题的原理，三者之间的转换关系，还是比较模糊的，包括我自己. 于是今天下决心砌底地把这个web应用中最常见的问题搞明白，请各位达人指点一下。
??? 根据以往的经验，这种中文乱码问题，都是由于jsp,java,数据库三者之前的编码不同造成的，jsp的编码是在
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" import="java.util.*"%>中设定的，java文件中的字符串编码，众所周知是unicode的，而数据表的字符编码，也是可以设定的。
好了，我先开了个头了，现在我想通过几个例子来让大家讨论有个焦点。
程序的流程是这样的，我们先从java文件中读到数据库中的中文字符，然后，在jsp页面上，用<jsp:useBean />标签来取出字符，并out.println()显示出来。
例1 如果jsp的CHARSET=utf8，数据库的字符编码也是GBK的，三者之间的编码转换的过程是怎样的？
例2 如果jsp的charset=UTF-8, 数据库的字符编码是GBK呢？
例3 如果jsp的charset=UTF-8,数据库中的字符编码也是UTF-8的呢？
其实，最重要的是原理跟过程，希望大家把自己知道的都说出来，能让别人或自己在此贴中学习到一些之前忽略了的东西就够了。?
??
区分：jsp页头的，charset和pageEncoding这两者的作用分别是什么呢？
JSP要经过两次的“编码”，第一阶段会用pageEncoding，第二阶段会用utf-8至utf-8，第三阶段就是由Tomcat出来的网页， 用的是contentType
第一阶段是jsp编译成.java，它会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译成统一的UTF-8 JAVA源码（即.java），如果pageEncoding设定错了，或没有设定，出来的就是中文乱码。
第二阶段是由JAVAC的JAVA源码至java byteCode的编译，不论JSP编写时候用的是什么编码方案，经过这个阶段的结果全部是UTF-8的encoding的java源码。
JAVAC用UTF-8的encoding读取java源码，编译成UTF-8 encoding的二进制码（即.class），这是JVM对常数字串在二进制码（java encoding）内表达的规范。
第三阶段是Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码，输出的结果，也就是在客户端见到的，这时隐藏在阶段一和阶段二的参数contentType就发挥了功效。不通版本的tomcat的设置可能不通