首先,我們先了解一下JSP的編碼規則,從中可以理解到contentType和pageEncoding的作用域.
contentType的charset是指服務器發送給客戶端時的內容編碼.而pageEncoding是jsp文件本身的編碼.
JSP要經過兩次的“編碼”,第一階段會用pageEncoding,第二階段會用utf-8至utf-8,第三階段就是由Tomcat出來的網頁, 用的是contentType。
第一階段是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)。
從此我們可以看出, pageEncoding影響的是JSP編繹成.java文件(即servlet文件)階段,此時如果pageEncoding設定錯了,用一般的編繹器編繹出來的.java文件中就會出現中文亂碼. 而用eclipse的話會提示你編碼錯誤..
而contentType影響的是最后一個階段,即由Tomcat(或其的application container)載入和執行階段二的來的JAVA二進制碼(也就是.class文件)的階段,我們在客戶端看到的結果就是此階段產生的, 這時的編碼就是根據contentType來設定. 光從客戶端來說,pageEncoding 和contentType設置的不一樣,例pageEncoding=GB2312,contentType的charset=UTF-8,此時客戶端顯示的JSP頁面都能夠正常顯示中文亂碼.
但是更重要的是與服務器的交互... 當從一個JSP頁面發送請求至服務器端時, header中會發送什么數據呢?
header中發送的編碼設定是由contentType指定的.. 此時如果contentType指定的編碼與服務器的編碼不一致時,在服務器端就會產生中文亂碼!
在開發J2EE WEB應用時最好使用過濾器來杜絕中文亂碼的問題. 附過濾器源碼:





































在web.xml中添加以下代碼:












