一. JSP的执行过程与编码设定概述
在JSP/Servlet中，主要有以下四种方式可以设置编码，其中前两个只能应用于JSP中，而后两个可以用于 JSP 和 Servlet 中。
pageEncoding=”UTF-8”；
contentType=”text/html;charset=UTF-8”；
request.setCharacterEncoding(“UTF-8”) ；
response.setCharacterEncoding(“UTF-8”)。
事实上，一个JSP的源文件需要经过三个阶段，两次编码，才能完成一次完整的输出，这三个阶段是：
第一阶段：转译（.jsp -> .java；pageEncoding -> UTF-8）。将jsp编译成Servlet（.java）文件，用到的指令是pageEncoding。在编译过程中，根据pageEncoding＝“XXX”的指示，找到编码的规则为“XXX”，然后服务器将JSP文件编译成.java文件时会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译成统一的UTF-8编码的JAVA源码（即.java）。
第二阶段：编译（.java -> .class；UTF-8 -> UTF-8）。从Servlet文件（.java）到Java字节码文件（.class），从UTF-8到UTF-8。在这一阶段中，不论JSP编写时候用的是什么编码方案，经过这个阶段的结果全部是UTF-8的encoding的java源码。JAVAC用UTF-8的encoding读取java源码，编译成UTF-8编码的二进制码（即.class），这是JVM对常数字串在二进制码（Java encoding）内表达的规范。这一过程是由JVM的内在规范决定的，不受外界控制。
第三阶段：编译（UTF-8 -> contentType）。从服务器到浏览器，这在一过程中用到的指令是contentType。服务器载入和执行由第二阶段生成出来JAVA二进制码，输出的结果，也就是在客户端可见到的结果，在这次输出过程中，由contentType属性中的charset来指定，将UTF8形式的二进制码以charset的编码形式来输出。如果没有人为设定，则默认的是ISO-8859-1的形式。
特别需要注意的是，pageEncoding 的默认值是 “ISO-8859-1”, contentType 的默认值是 “text/html;ISO-8859-1”。
Ps: 第一、三两个阶段的转码个人感觉联想到Sting转码更容易理解些，例如 ：new String(name.getBytes(“ISO-8859-1”), “utf-8”)。
二. pageEncoding=”UTF-8”
pageEncoding=”UTF-8” 的作用是设置JSP编译成Servlet时使用的编码。通常，在JSP内部定义的字符串（直接在JSP中定义，而不是从浏览器提交的数据）出现乱码时，很多都是由于该参数设置错误引起的。例如，你的 JSP文件中含有中文字符，而在JSP中却指定pageEncoding=”iso-8859-1”，就会导致中文字符显示异常。看下面的例子：
在其编译为Servlet后，其源码（片段）如下所示：
访问该页面，页面显示如下：
我们可以看到，由于pageEncoding被指定为”iso-8859-1”，导致其在由服务器将JSP文件编译成.java文件过程中，在使用 “iso-8859-1” 读取jsp并翻译成统一的UTF-8编码的JAVA源码时，所有的中文字符被转成乱码，并使得其呈现给用户的响应也包含乱码。特别地，该属性还有一个功能，就是在JSP中不指定contentType参数，也不使用response.setCharacterEncoding方法时，指定对服务器响应的内容进行编码。
三. contentType=”text/html;charset=UTF-8”
contentType=”text/html;charset=UTF-8” 的作用是将上述第二阶段所生成的UTF8形式的二进制码以charset的编码形式来输出到客户端，如果设置不当的话，会出现乱码。看下面的例子：
在其编译为Servlet后，其源码（片段）如下所示：
访问该页面，页面显示如下：
四. request.setCharacterEncoding(“UTF-8”)
request.setCharacterEncoding(“UTF-8”)用来指定对浏览器发送来的数据以特定的字符集进行重新编码，常用于对 POST 请求参数进行解码。
五. response.setCharacterEncoding(“UTF-8”)
response.setCharacterEncoding(“UTF-8”)的作用是：在服务器将响应返回到浏览器前，对响应使用指定字符集进行重新编码。一旦使用了该种方式，即使该响应页面指定了具体的 contentType，也将失效。看下面的例子：
在其编译为Servlet后，其源码（片段）如下所示：
访问该页面，页面显示如下：
六. 四种编码设定方式之间的相互影响以及作用的优先级
根据上文内容，我们得出以下三点：
在指定JSP编译成Servlet时使用的编码时，优先级为：pageEncoding=”UTF-8” > contentType=”text/html;charset=UTF-8”
在指定服务器对响应内容的编码时，优先级为：response.setCharacterEncoding(“UTF-8”) > contentType=”text/html;charset=UTF-8” > pageEncoding=”UTF-8”
request.setCharacterEncoding(“UTF-8”) 只用来指定对浏览器发送来的请求数据的解码方式。
七. JSP页面与JSP源文件乱码
在介绍JSP页面与JSP源文件的乱码问题前，首先我们必须对JSP页面中文乱码问题与JSP源文件中文乱码问题有一个清晰的概念，即：
JSP页面中文乱码问题是指用户在浏览器看到的服务器所返回的jsp页面中，中文字符不能正常显示；
JSP源文件中文乱码问题是指在编辑器保存JSP源文件后，中文字符不能正常显示。
因此，这是两个不同层面的问题。接下来，我们分别解决这两个问题。
1、JSP页面乱码
我们先在记事本中编写一个JSP程序，如下：
上面这个JSP程序是在页面显示几句中文而且标题也是中文，运行后在浏览器中显示如图所示：
原因在于没有在JSP中指定页面显示的编码，消除乱码的解决方案就是将上面代码中的page命令修改成如下所示即可：
再次运行中文正常显示，原理就是向页面指定编码为utf-8，那么页面就会按照此编码来显示，于是乱码消失。
2、JSP源文件乱码
1). JSP源文件乱码 与 Eclipse/MyEclipse 对JSP的默认编码设置
如果我们在Eclipse/MyEclipse中打开上面示例1的jsp源文件，由于Eclipse/MyEclipse中默认的JSP编码格式为ISO-8859-1，所以当打开由其他编辑器编辑的JSP文件时会出现乱码，如图所示：
对于这个问题，我们只需要更改一下 Eclipse/MyEclipse 中对JSP的默认编码并update就可以了，修改的地方（我的MyEclipse版本为 10）如图所示:
修改后，对于在Eclipse/MyEclipse所创建的任何一个JSP源文件，其默认编码方式均为 UTF-8，例如：
如果不做上述修改，如果我们在Eclipse/MyEclipse中编辑的JSP中存在中文字符，那么当我们保存该页面时，会弹出以下对话框：
但是，我们如果我们提前按如上步骤设置后，JSP源文件就能正常保存、编译。
2). Eclipse/MyEclipse 创建 JSP时 pageEncoding 的默认值设置
我们在编辑的JSP文件时，尤其在包含中文字符时，一定要在page编译指令中恰当地指明 pageEncoding 的值，否则在浏览器访问该JSP页面时，其中的中文就会显示为乱码。因为一旦缺省 pageEncoding 时，其值就会被默认指定为 “iso-8859-1”，该字符集不支持中文。此外，使用 Eclipse/MyEclipse 进行开发的伙伴们都知道，这两个IDE生成的JSP模板的pageEncoding的默认值是“iso-8859-1”。为方便开发，我们可以更改Eclipse/MyEclipse生成JSP模板时pageEncoding的默认值，修改的地方（我的MyEclipse版本为10）如图所示：
这样，通过以上两步的设置，当我们在 Eclipse/MyEclipse 中创建一个新的JSP文件时，该源文件在Eclipse/MyEclipse中的默认编码方式为utf-8，因此就不会导致 JSP源文件乱码；并且其 pageEncoding 的值会被自动设为“utf-8”，这就不会导致JSP页面乱码。
二. GET 请求的请求参数为中文情形
1、URL传递参数中文乱码
运行结果如下图所示：
2、表单提交中文乱码
该示例由 “收集参数的表单页” 和 “表单提交参数显示页”两部分构成。
收集参数的表单页:
表单提交参数显示页：
运行结果如下图所示：
3、GET 请求的请求参数为中文情形小结
只要我们以GET形式提交请求，无论是以表单形式提交还是以URL形式提交，如果参数中存在中文字符，那么我们必须进行相应的转码（借助String类）或者解码（借助URLDecoder类），特别地，有五点需要注意：
request.getQueryString() 所返回的原生查询字符串只适用于 GET请求 ，若对 POST请求 使用，则返回 null;
利用 URLDecoder 进行解码时，必须先对原生查询字符串解码，而后获取各请求参数。如果先获取各个请求参数，再依次解码，则仍是乱码；
使用String进行 转码时，往往都是先从 ISO-8859-1 格式的字符串中取出字节内容，然后再用页面相应的编码格式重新构造一个新的字符串，像本示例（new String(country.getBytes(“ISO-8859-1”), “utf-8”)）中的 一样。这样就可以支持中文字符的正常取值和显示；
利用 URLDecoder 进行解码时，所采用的解码字符集取决于浏览器（本文所有实验都是基于 Google Chrome 的）。对于中文环境而言，一般要么是 UTF-8，要么是 GBK ；
对于 GET请求，语句 request.setCharacterEncoding(“utf-8”); 对避免中文参数乱码起不到任何作用。
经过上面的处理，GET请求的中文参数乱码问题已经得到解决。但是如果上面的表单中的输入项不止几项，那么每个输入项都需要进行编码转换，那样就很麻烦了。这时，我们就用到了大名鼎鼎的过滤器 filter 了。
三. POST 请求的请求参数为中文情形
一般地，我们以POST形式提交请求，都是以表单形式进行并且 form 的 method 属性为 post。下面的示例对上面的示例做了一些修改，也由 “收集参数的表单页” 和 “表单提交参数显示页” 两部分构成：
收集参数的表单页:
表单提交参数显示页：
运行结果如下图所示：
根据上面运行结果，我们知道：对于POST请求，若其请求参数包含中文字符，那么我们只需在解析请求参数前加一句如下的代码即可。需要注意的是，这种方式对 Get请求起不到任何作用。此外，由于我们对请求已经重新编码，所以已经不需要使用 String类 再进行转码，否则画蛇添足。最后，对于 POST请求，request.getQueryString(); 返回的查询字符串为 null。
