Motivition
曾經有一個網友問過我這樣一個問題：
<%@page contentType="text/html; charset=UTF-8"%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
中國
</body>
</html>
這個頁面在為什麼在運行的時候“中國”會變成亂碼？
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。所以在這個環節中應用服務器都可以很好的把握，不會帶來編碼問題。
