中文编码

考虑以下场景，在浏览器地址栏中直接输入"http://localhost:8080/helloapp.do?username=编辑"提交，对于这种方式，浏览器不会采用页面的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页面，如：http://localhost:8080/helloapp/编辑.jsp，IE默认是勾选"以UTF-8发送 URL"项的，那么按照我上面总结的处理方式，这个请求可以正常显示页面，如图：

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

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