今天在测试一GET接口时，在浏览器输入拼接的中文参数后台乱码了，我的页面所有格式均设成UTF-8
格式，在后台过滤器中用request.setCharacterEncoding("utf-8")方法将request的字符集设定为utf-8，到网上仔细找下资料，原因在于TOMCAT 编码未设置原因，可以再server.xml配置文件中加上URIEncoding="UTF-8" 。这个以前也碰到过，不总结就会忘，所以今天有找了相关的资料总结一下javaweb乱码的原因。
1.浏览器拼中文参数乱码（即get方式提交）
浏览器根据页面的charset编码方式对页面进行编码，然后提交至服务器，Tomcat对于get提交方式采用
的是server.xml文件中的URIEncoding编码方式转码，而并不会采用过滤器中设置的编码转码，是如果浏览器中的编码方式和tomcat中配置的编码方式不同就会乱码，tomcat 中默认的编码方式是ISO-8859-1，所以今天才遇到这样的乱码。如果是其他系统需要调用你的接口，如果两个系统编码方式不同，在请求参数时，应将中文参数按接口系统的编码进行编码，才行。
所以今天遇到的乱码问题 我通过new String(变量值.getBytes("ISO-8859-1"),"UTF-8"); 转码能获取正
确变量值。
但像对于我现在用的 jersey框架，不是通过request.getParameter的方式获取而是采用@QueryParam
和@FormParam参数注解的方式获取就不会乱码。
2.POST方式提交
POST方式一般在后台过滤其中配置了编码格式，保持前后台一致就不会乱码。如果是外放接口，对方
编码不一样，需要将中文进行后台编码格式进行编码，才不会乱码。
3.页面链接中传递中文
保持页面（pageEncoding="你的编码"）和tomcat编码方式相同即可。或者在页面中参数按tomcat编码
进行编码（URLEncoder.encode(参数值, input_charset) ）后在传至后台。另一个解决办法是使用js的encodeURI或者encodeURIComponent方法，进行编码两次，后台再用你指定的编码解码一次，即可，因为第一次编码，你的参数内容便不带有多字节字符了，成了纯粹的 Ascii 字符串。(这里把编第一次的结果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不带有多字节字符的)。再编一次后，提交，接收时容器自动解一次 （容器自动解的这一次，不管是按 GBK 还是 UTF-8 还是 ISO-8859-1 都好，都能够正确的得到 [STR_ENC1]）。再在程序中实现一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的参数的原值。（http://bbs.csdn.net/topics/330072196）
4.包含中文名的页面
如：测试.jsp 这个我确实很少用过，不过看网上资料如果浏览器的charset编码方式和tomcat编码一致
就不会乱码，建议还是少用这种方式
很多东西自己理解也不是很深刻，如果有错误地方欢迎指正。