JSP中“charset”與“pageEncoding”的區別

        在設置JSP頁面源代碼字符編碼的時候，如果有pageEncoding這一項，則采取這一項的值，如果沒有，采取charset的值，如果都沒有，采取iso8859-1。這個跟頁面中文亂碼有直接關系比如你使用默認編碼:<%@ page contentType="text/html;charset=ISO-8859-1"%>，而你在頁面中輸出了中文，那麼中文就會因為編碼錯誤而亂碼。解決辦法是改成GB2312 或者 UTF-8 或者 GBK 

我們新建JSP頁面時，第一行語句：<%@ page contentType="text/html;charset=GB2312"%>的作用是：

設置文檔類型, text/html代表是文本類型的html文件;charset=GB2312  字符集編碼是GB2312。

然而有些頁面第一行語句：<%@ page contentType="text/html;charset=GB2312" pageEncoding="GB2312"%>
“charset”與“pageEncoding”到底有什麼區別？
charset:字符編碼
pageEncoding:頁面編碼

• pageEncoding是設置的JSP頁面源代碼的字符編碼格式，如果該項的值是utf-8，則JSP源代碼裡不能寫漢字了，如果你用的是eclipse等工具的話，保存時他會提示有一個錯誤，改成gbk就沒事了，就是這個道理
• charset是請求服務器以後返回過來的內容的字符編碼，即使pageEncoding設置了gbk，保存，運行程序，查看頁面時會發現剛才寫的漢字不能正常顯示，把charset改成gbk，正常

JSP要經過兩次的“編碼”，第一階段會用pageEncoding，第二階段會用utf-8至utf-8，第三階段就是由Tomcat返回來的網頁，用的是charset。 

第一階段是jsp編譯成.java，它會根據pageEncoding的設定讀取jsp，結果是由指定的編碼方案翻譯成統一的UTF-8 JAVA源碼（即.java），如果pageEncoding設定錯了，或沒有設定，出來的就是中文亂碼。

第二階段是由JAVAC的JAVA源碼至java byteCode的編譯，不論JSP編寫時候用的是什麼編碼方案，經過這個階段的結果全部是UTF-8的encoding的java源碼。 

第三階段是Tomcat（或其的application container）載入和執行階段，輸出的結果，也就是在客戶端見到的，這時隱藏在階段一和階段二的參數contentType就發揮了功效。

注意：在設置JSP頁面源代碼字符編碼的時候，如果有pageEncoding這一項，則采取這一項的值，如果沒有，采取charset的值，如果都沒有，采取iso8859-1。pageEncoding 和contentType的預設都是 ISO8859-1. 而隨便設定了其中一個, 另一個就跟著一樣了(TOMCAT4.1.27是如此). 但這不是絕對的, 這要看各自JSP容器的處理方式.

如：在Tomcat中如果在jsp中設定了pageEncoding，則contentType也跟著設定成相同的編碼了,但是在resion中就不是，resin中還會用默認的，這點通過查看編譯後的類servlet java文件就可以看到這一點，而問題恰恰就出在這裡，所以，在jsp中，如果是在resin下最好還是明確的單獨設定這2個屬性。

總結：通常我們在JSP頁面設定<%@ page contentType="text/html;charset=GB2312"%>即可。