pageEncoding是.jsp文件本身編碼
，contentType里面的charset是指服務器吐出的內容的編碼
，也就是客戶瀏覽器所得到的內容的編碼。
.jsp文件不像.java，.java在被編譯器讀入的時候默
認采用的是操作系統所設定的locale所對應的編碼
，比如中國大陸就是GBK，臺灣就是BIG5或者MS950
。而一般我們不管是在記事本還是在ue中寫代碼，如果沒有經過特
別轉碼的話，寫出來的都是本地編碼格式的內容。所以編譯器采用的
方法剛好可以讓虛擬機得到正確的資料。
但是jsp文件不是這樣，它沒有這個默認轉碼過程
，但是指定了pageEncoding就可以實現正確轉碼了。
舉個例子:
12
<%@ page contentType="text/html;charset
=utf-8" %>
你好嗎？
大都會打印出亂碼，因為我輸入的"你好嗎"是gbk的
，但是服務器是否正確抓到"你好嗎"不得而知。
但是如果更改為
12
<%@ page contentType="text/html;charset
=utf-8" pageEncoding="GBK"%>
你好嗎？
這樣就服務器一定會是正確抓到"你好嗎"了。
------------------------------------------------------------------------
關於 contentType 和 pageEncoding 的差異 和 中文JSP頁的設定技巧:
contentType -- 指定的是JSP頁最終 Browser(客戶端)所見到的網頁內容的編碼.
就是 Mozilla的 Character encoding, 或者是 IE6的 encoding. 例如 JSPtw Forum
用的contentType就是 Big5.
pageEncoding -- 指定JSP編寫時所用的編碼
如果你的是 WIN98, 或 ME 的NOTEPAD記事本編寫JSP, 就一定是常用的是Big5 或 gb2312, 如果是用 WIN2k
winXP的NOTEPAD時, SAVE時就可以選擇不同的編,碼, 包括 ANSI(BIG5/GB2312)或 UTF-8 或
UNIONCODE(估是 UCS 16).
因為 JSP要經過 兩次的"編碼", 第一階段會用 pageEncoding, 第二階段會用 utf-8 至utf-8,
第三階段就是由TOMCAT出來的網頁, 用的是contentType.
階段一是 JSPC的 JSP至JAVA(.java)原碼的"翻譯", 它會跟據 pageEncoding 的設定讀取JSP. 結果是
由指定的 pageEncoding(utf-8,Big5,gb2312)的JSP 翻譯成統一的utf-8 JAVA原碼(.java).
如果pageEncoding設定錯了, 或沒設定(預設 ISO8859-1), 出來的 在這個階段 就已是中文亂碼.
階段二是由 JAVAC的JAVA原碼至JAVA BYTECODE的編譯.
不論JSP的編寫時是用(utf-8,Big5,gb2312),經過階段一的結果全都是utf-8的ENCODING的JAVA原碼.
JAVAC用 utf-8的ENCODING讀取AVA原碼, 編譯成字串是 utf-8 ENCODING的二進制碼(.class). 這是
JAVA VIRTUAL MACNHINE 對常數字串在 二進制碼(JAVA BYTECODE)內表逹的規範.
階段三是TOMCAT(或其的application container)載入和執行 階段二得來的JAVA二進制碼, 輸出的結果(
也就是BROWSER(客戶端)) 見到的. 這時一早隱藏在階段一和二的參數contentType, 就發揮了功效. (見 階段一的 1
response.setContentType("text/html; charset=utf-8");
).
出來的可以是 utf-8, Big5, gb2312, 看的就是JSP 1
<%@ page session="false" pageEncoding="big5" contentType="text/html;
charset=utf-8" %>
? contentType的設定.
**還有, pageEncoding 和contentType的預設都是 ISO8859-1. 而隨便設定了其中一個,
另一個就跟著一樣了(TOMCAT4.1.27是如此). 但這不是絕對, 看的各自JSPC的處理方式.
而pageEncoding不等於contentType, 更有利亞洲區的文字 CJKV系JSP網頁的開發和展示,
(例pageEncoding=Big5 不等於 contentType=utf-8).