Tomcat处理编码的流程
Tomcat是如何处理query/post的编码问题的？
首先我们看看get方式时，tomcat如何获取querystring。
比如我们的url是：http://abc.com/?keywords=%C6%A1%BE%C6??? (其中%C6%A1%BE%C6是啤酒的GBK的URLEncode编码)
当请求来到服务器的tomcat(也可以说是Servlet)这一层面时，我们可以通过request获取这个keywords。获取的方式有两种：
(1) 直接使用getParameter("keywords")得到keywords参数
(2) 先使用getQueryString()，再手动解析出keywords参数
我们看看这两种方式。
(1) getParameter("keywords")
这里涉及 config/server.xml中URIEncode的配置项，假设我没对tomcat作任何URIEncoding的配置，它默认使用ISO-8859-1的编码。
?????? 当访问http://localhost/?keywords=%C6%A1%BE%C6后，我们试图打印出getParameter("keywords")的值，你猜看到什么？乱码！
我们试图质问tomcat：“为什么是乱码？！如果我输入的keywords是“啤酒”这样的字符，得到乱码我可以接受，但是我输入的可是“%C6%A1%BE%C6”这样一串ISO-8859-1编码的字符啊！
有人猜测，那是浏览器在搞鬼，浏览器发送的不是“%C6%A1%BE%C6”这样的可见字符的，而是发送“啤酒”这个非ascii字符(当然，我们应该理解本质上传送的“啤酒”肯定是“啤酒”的某某编码格式的字节码，这个编码可以是常见的GBK或UTF-8)。
但是，其实不是浏览器搞鬼，浏览器发送的就是“%C6%A1%BE%C6”，你可以通过打印request.getQueryString();看到，它输出“keywords=%C6%A1%BE%C6”。
那到底是怎么回事呢？
源于tomcat对表单提交的参数(包括Get方式和Post方式)有个UDecode类的处理过程。什么是UDecode类的处理过程，详细你可以看tomcat源码的UDecode类，这里用简单的一句话概括UDecode类做的事情：修改request中的parameter(包括get方式的url参数的value和post方式的application/x-www-form-urlencoded的参数的value)的字节, 将每1个“%HH”(占3个字节)变成“0xHH”(占1个字节)，且将加号"+"(占1个字节)变成空格“ ”(占1个字节)。下面的图直观的描述了这个UDecode过程：
