JSP页面编码问题研究

Motivition
曾经有一个网友问过我这样一个问题：
<%@page contentType="text/html; charset=UTF-8"%>





中国


这个页面在为什么在运行的时候“中国”会变成乱码？
Analysis
      Key Step
对于上面问题的分析需要从整个JSP页面请求的生命周期来看，一般的都需要经历下面几个阶段：
1。应用服务器根据JSP页面生成一个Java文件
2。应用服务器调用java.exe将Java文件编译成一个Servlet对应的class文件
3。用户的浏览器请求JSP对应的Servlet，Web容器起一个线程执行Servlet，将数据返回给客户端浏览器
4。用户的IE根据返回的数据，将结果显示给用户。
      Key Step Analysis
为了更好的了解编码问题，我们暂时先从上面的四个环节一步步来分析，根据分析的结果，来得到最终的解决办法。
1． 在应用服务器根据JSP页面生成Java文件阶段。
应用服务器会将整个JSP页面的代码读取出来，然后写到一个新的JAVA文件中，在读文件和写文件的时候都牵涉到一个编码问题，这个编码问题应用服务器是如何解决的呢？我研究Tomcat应用服务器的源代码，发现Tomcat中有一个pageEncoding参数非常重要，在ParserController会从JSP文件中读出这个参数（如果没有读到，就从第一行的contentType中读取charset），然后保存起来，如果没有读取到这个参数，会从JspConfig中读出一个默认的PageEncoding参数,如果这两个参数都没有的设置，系统会默认成ISO8859-1的编码来读取原来的JSP文件。
   从上面的分析出，我们已经基本了解了应用服务器读取JSP文件的编码方式，由于Java底层都是基于Unicode编码来存储字符的，所以在写文件的时候，都输出成Unicode编码的形式。
2。在JDK将Java文件编译成Class文件的时候
可以利用-encoding参数指定源文件的编码，这在手动编译的时候非常重要，因为这决定了Java虚拟机读取Java文件时采用的编码方式，但是在Web应用中这个环节我们可以忽略，因为应用服务器可以很好的解决这个编码。以Tomcat为例，由于生成的java文件是固定的UTF-8编码，所以Tomcat也固定的采用UTF-8编码来读取，通过浏览AbstractCatalinaTask可以看到reader = new InputStreamReader(hconn.getInputStream(), CHARSET);其中的CHARSET=utf-8。所以在这个环节中应用服务器都可以很好的把握，不会带来编码问题。