java web开发过程中的编码问题完全解决方案

写了N多项目后，突然发现最近又碰到了中文编码不正确的问题，这在刚入java行时才会有的问题，怎么会出现在我这个熟手身上，有点不可思议。当然，先凭经验按常规来解决啦，该设置的地方都设置了，最终还是没法解决这个问题。我的应用是在一个struts2的action中要重定向到一个外部url,而这个url的参数中带有汉字，汉字作utf-8编码，当一跳转后，在外部url的servlet处接收参数，查看参数就是乱码了。
        常规解决处理方法：
        a.把所有的jsp页面的charset设置为UTF-8。
        b.添加过滤器，在filter内调用request.setCharacterEncoding("utf-8")方法将request的字符集设定为utf-8。
        c.Tomcat(或jboss)的URIEncoding默认是ISO-8859-1，需要设置为UTF-8。
以上的方法全使上，就能解决我上面的应用了。不过，在调试过程中，曾直接使用浏览器直接输入带汉字的url，还是无法解决乱码的问题。因此，上面的方法也仅能解决提交的部分场景的乱码问题。欲知如何，请看下节分解。
在实际的应用当中，主要会有以下四种使用方法：
1、表单的get提交
2、表单的post提交
3、页面链接传递中文参数
4、地址栏中参数直接输入中文提交(直接在ie或firefox中敲上中文进行访问)
在分析解决以上的几种情况前，首先我们先了解一下，一个url请求并响应的流程
浏览器 IE/FireFox ----------->Servlet容器------------------------>显示页面
       编码          使用容器的URIEncoding转码       根据页面的编码设置进行解码
1.表单get方式提交
      浏览器根据页面的charset编码方式对页面进行编码，然后提交至服务器。首先，进入对应的字符编码过滤器(如果有的话)，不过，Tomcat6.0，对于 get提交方式采用的是server.xml文件中的URIEncoding编码方式，而并不会采用过滤器中设置的编码，那么，根据我的环境设置，jsp页面都使用UTF-8的编码，Servlet容器的URIEncoding也设置为UTF-8，则servlet不用进行转码即可正确解码，获得正常的中文 字符串。那么，响应页面的中文因为页面的统一编码(UTF-8)自然也会正常显示。当然，如果我们的Tomcat的URIEncoding设置为其他，非UTF-8的编码方式时，页面的内容进入Tomcat解析时，因为Tomcat和页面的编码不统一，就需要转码。
例如，如果我们采用Tomcat默认的 ISO-8859-1，那么当我们使用request.getParameter("param1")获取表单参数值时，其实Servlet就进行了转码，转码过程为UTF-8-->ISO-58859-1(我的页面charset都是UTF-8)，java伪代码如下:

  new String(param1.getBytes("UTF-8"), "ISO-8859-1");  

new String(变量值.getBytes("UTF-8"),"ISO-8859-1");
 例如表单的username属性以字符串"编辑"提交，那么进入容器后，FormBean中的这个变量会乱码，request.getParameter(username)一样的效果，s1就是request返回的结果，下面是内存快照。

不过，即使是这样，我们依然可以使用非常规的方法，取出并显示出正常的中文，即逆向转码，例如上面的乱码，我们可以通过ISO8859-1-->UTF-8转换一次，还原出正确的中文。
综上所述，将Tomcat的URIEncoding设置为UTF-8(即和页面的编码一致即可)就能解决这类情况，get时，页面会先按页面设置的编码编码，再提交至web server，显示时会再根据显示页面的编码进行解码。

2.表单的post提交
对于这种方式的请求，request.setCharacterEncoding(一般来自于web.xml中过滤器设置的参数)方法进行编码，设置将会产生作用，struts的表单提交方式默认为post方式，因此，如果都采用UTF-8编码方式，就不会产生中文乱码问题。

3.页面链接中传递中文参数
我虚拟一个这样的场景，请求页面中有如下代码

Html代码 

<%
String username = "编辑";
%>
页面中链接传递中文
对于这种方式，我们需要先将参数使用统一的编码方式编码，将编码后的字符放入链接，这里我对参数以UTF-8方式编码，如下

Java代码 

<%
String username = java.net.URLEncoder.encode("编辑","UTF-8");
%>
那么，这样我们也不会产生中文乱码问题，因为，字符串编码的处理过程：字符串->UTF-8(提交的页面charset)->UTF-8(web server URIE)->UTF-8(显示的页面)。
4.地址栏中参数直接输入中文提交

考虑以下场景，在浏览器地址栏中直接输入"编辑"提交，对于这种方式，浏览器不会采用页面的charset方式，也不会按照filter设置的编码方式。URL中的中文进行编码后，提交至服务器(IE,FireFox都一样)，而是采用系统的GBK(估计可能和browser的语言版本或设置相关，我的机器上是编码到GBK)转码为ISO- 8859-1之后，提交至Servlet容器，那么，如果对于前三种方式我们所做的设置，此种场景下就不正常了。因为，进入容器时中文进行了GBK至ISO- 8859-1的转码，而之前我们的Servlet容器URIEncoding设置为UTF-8，当我们使用 request.getParameter("username")时，相当于又进行了这样的流程GBK-->ISO- 8859-1-->UTF-8，按照以上我们使用的测试，那么就会是乱码了。此时，如果是使用GBK-->ISO- 8859-1-->GBK的方式转换，那么就能正常取出中文汉字。

对于这种情况，我们可以采用的解决办法就是，Tomcat的URIEncoding采用默认的ISO-8859-1字符集，那么我们可以在程序中通过ISO-8859-1-->GBK这样的转码方式得到正常的中文“编辑”，但这样的结果是，我们get请求方式的中文处理解决办法，就有问题了。
综上分析所述，对于乱码问题，前三种方式是一般用户的请求方式，第四种属于非正常途径的请求方式，对于这种方式产生的问题，可能无法很好的解决(和浏览器有关server端无法控制)。测试IE6的设置会影响应用路径的编码方式，例如地址栏中请求一个中文JSP页面，如：编辑.jsp，IE默认是勾选"以UTF-8发送 URL"项的，那么按照我上面总结的处理方式，这个请求可以正常显示页面，如图：

如果取消IE的这个选项，那么浏览器会以GBK编码应用路径的中文，得到的结果如图：

按照我上面的设置，如果将Tomcat的URIEncoding设置为GBK，则也可以正常显示页面。对于FireFox3.0，则是以UTF-8编码。因此，第四种场景是和客户端相关。
因此，在项目中尽量避免第4种场景的情况出现，就基本可以解决java web开发中的乱码问题了。
本篇经由网络文字摘录整理，主要参考自：等网文。