這樣我們再刷新頁面會出現中文亂碼

      但是這種亂碼卻可以通過改變瀏覽器的編碼方式來解決，在瀏覽器空白處右鍵-->編碼，選擇Unicode(UTF-8)即可。

      那我們現在再來改一下，我們將pageEncoding改為utf-8；即：

<%@ page contentType="text/html" pageEncoding="utf-8"%>

      這樣很明顯，JSP在編碼的時候將采用utf-8；默認的charset也是utf-8 ，這個時候刷新，頁面中又出現了亂碼。

     在此基礎上，我們改變charset=gbk再來看一下效果，此時瀏覽器的編碼為utf-8：

修改瀏覽器編碼為GBK：

       可以看到，當pageEncoding編碼為UTF-8時無論如何，用戶訪問JSP頁面的時候，內容都是中文亂碼。

       為什么會這樣，pageEncoding和contentType中的charset區別到底在哪里？

       網上搜索了一下，我認為下面的這個解釋說的挺好，挺詳細的。

       事實上，jsp需要經過兩次“編碼”，第一階段會用pageEncoding，第二階段會用utf-8的.java文件至utf-8的.class文件，第三階段就是由Tomcat傳回瀏覽器的網頁， 用的是contentType。ContentType 屬性指定響應的 HTTP 內容類型。如果未指定 ContentType，默認為 text/HTML。

第一階段：將jsp編譯成Servlet（.java）文件。用到的指令是pageEncoding，根據pageEncoding＝“XXX”的指示，找到編碼的規則為“XXX”，服務器在將JSP文件編譯成.java文件時會根據pageEncoding的設定讀取jsp，結果是由指定的編碼方案翻譯成統一的UTF-8編碼的JAVA源碼（即.java）。

第二階段：從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的內在規范決定的，不受外界控制。

第三階段：從服務器到瀏覽器，這在一過程中用到的指令是contentType。服務器載入和執行由第二階段生成出來JAVA二進制碼，輸出的結果，也就是在客戶端可見到的結果，在這次輸出過程中，由contentType屬性中的charset來指定，將UTF8形式的二進制碼以charset的編碼形式來輸出。如果沒有人為設定，則默認的是ISO-8859-1的形式。

       可以簡單認為是，pageEncoding是jsp文件本身的編碼；contentType的charset是指服務器發送給客戶端時的內容編碼。例如：pageEncoding="GBK"。這句話的意思是，告訴JVM 這個jsp本身采用的"GBK"編碼,在JSP編譯成Servlet傳給JVM的時候，就用“GBK”的編碼方式將Jsp網頁源文件翻譯成統一的UTF-8形式的Java字節碼（如果不加設定，則JVM默認的用ISO-8859-1這種編碼方式）。contentType里的charset=gbk，指的是此網頁文件輸出到瀏覽器的輸出方式為gbk（如果不加設定，則默認為pageEncoding所設定的編碼類型），理解了以上的過程，相信大家都對上述的各種亂碼情況都有了更深入的理解，知其然而知其所以然了。

（參考文章：http://www.cnblogs.com/kevin-yuan/archive/2011/12/31/2308479.html）