在Jsp頁面中合理的設置pageEncoding、contentType屬性，能夠解決日常遇見的頁面亂碼問題，下面就pageEncoding和contentType兩種屬性的分別，進行簡單闡述一下：
1、pageEncoding是JSP文件默認的編碼屬性。
2、contentType中charset是指遠程服務器端發送給本地客戶端時的內容編碼格式。
在頁面傳輸過程中Jsp要經過三次兩種形式的編碼：
第一次編碼會用pageEncoding；
第二次編碼會用utf-8至utf-8；
第三次編碼就是由TOMCAT解釋輸出的網頁，用contentType的charset編碼。
第一次編碼是Jsp編譯成.java文件時，會根據pageEncoding的設定讀取Jsp文件，結果是根據指定的編碼方案翻譯成統一的UTF-8格式的JAVA源碼（即所謂的.java），如果pageEncoding設定錯了，或是沒有設定，出來的就是中文亂碼。
第二次編碼是由Javac的JAVA源碼到Java byteCode的編譯，不管JSP編寫時候用的是什麼編碼方案，經過這個階段的處理，結果全部是UTF-8的encoding的java源碼了。
JAVAC用UTF-8的encoding讀取java源碼數據，編譯成UTF-8 encoding的二進制碼（即.class）形式，這是就JVM對常數字串在二進制碼（java encoding）內表達的規範。
第三次編碼是Tomcat（或其的application container）載入和執行階段二的來的JAVA二進制碼，輸出的結果，也就是在客戶端見到的，這時隱藏在第一次編碼和第二次編碼的參數contentType就發揮了作用了。
contentType的常規設定：
pageEncoding和contentType的預設都是ISO8859-1，只要設定了其中一個, 另一個也就變成一樣的了，(TOMCAT4.1.27是如此)。 但這不是一定絕對的, 這要看各自JSPC的處理方式， 然而pageEncoding不等於contentType, 更有利亞洲區的文字 CJKV系JSP網頁的開發和展示, 比如：pageEncoding=GB2312並不等於contentType=utf-8。
然而Jsp文件不像.java，.java在被編譯器讀入的時候默認採用的是操作系統所設定的locale所對應的編碼，比如中國大陸就是GBK，臺灣就是BIG5或者MS950。而一般我們不管是在記事本還是在ue中寫代碼，如果沒有經過特別轉碼的話，寫出來的都是本地編碼格式的內容。所以編譯器採用的方法剛好可以讓虛擬機得到正確的資料。
可是Jsp文件並不是這樣的編碼，沒有默認轉碼過程，主要我們指了pageEncoding就可以實現正確轉碼了。
下面是個簡單的示例:
<%@ page contentType="text/html;charset=utf-8" %>
基本上絕大多數會打印出亂碼，因爲輸入的“學習Java”是gbk的，但是服務器是否正確抓到“學習Java”還是未知的。。
試着把上面代碼改成：
<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>
傳輸到服務器後，服務器才能正確抓到“學習Java”，且也不會出現亂碼。