<%@ page contentType=text/htmlcharset=utf pageEncoding=GBK%>
jsp頁面（pageEncoding）——根據pageEncoding的設定讀取jsp——>翻譯成統一的UTF JAVA源碼（即java）——由JAVAC的JAVA源碼至java byteCode的編譯——>
編譯成UTF encoding的二進制碼（即class）——Tomcat（或其的application container）載入和執行階段二的來的JAVA二進制碼——>輸出contentType編碼給浏覽器
頁面輸入的參數用pageEncoding來編碼
頁面的默認編碼是什麼？
ntentType的默認編碼是什麼？
編碼和解碼過程各種文件時什麼編碼
responsesetContentType（text/htmlcharset=gb）是在頁面顯示時設置的字符格式requestsetCharacterEncoding（gb） 是servlet接受請求後對請求中的字符進行設置字符格式因為默認通過網絡傳輸的內容都被進行了iso編碼如果想在後處理的時候不讓中文成亂碼那就得對得到的內容進行gb編碼
JSP pageEncoding和contentType屬性
JSP要經過兩次的編碼第一階段會用pageEncoding第二階段會用utf至utf第三階段就是由Tomcat出來的網頁 用的是contentType
關於JSP頁面中的pageEncoding和contentType兩種屬性的區別
pageEncoding是jsp文件本身的編碼
contentType的charset是指服務器發送給客戶端時的內容編碼
JSP要經過兩次的編碼第一階段會用pageEncoding第二階段會用utf至utf第三階段就是由Tomcat出來的網頁用的是contentType
第一階段是jsp編譯成java它會根據pageEncoding的設定讀取jsp結果是由指定的編碼方案翻譯成統一的UTF JAVA源碼（即java）如果pageEncoding設定錯了或沒有設定出來的就是中文亂碼
第二階段是由JAVAC的JAVA源碼至java byteCode的編譯不論JSP編寫時候用的是什麼編碼方案經過這個階段的結果全部是UTF的encoding的java源碼
JAVAC用UTF的encoding讀取java源碼編譯成UTF encoding的二進制碼（即class）這是JVM對常數字串在二進制碼（java encoding）內表達的規范
第三階段是Tomcat（或其的application container）載入和執行階段二的來的JAVA二進制碼輸出的結果也就是在客戶端見到的這時隱藏在階段一和階段二的參數contentType就發揮了功效
contentType的設定
pageEncoding 和contentType的預設都是 ISO 而隨便設定了其中一個 另一個就跟著一樣了（TOMCAT是如此） 但這不是絕對的 這要看各自JSPC的處理方式 而pageEncoding不等於contentType 更有利亞洲區的文字 CJKV系JSP網頁的開發和展示 （例pageEncoding=GB 不等於 contentType=utf）
jsp文件不像javajava在被編譯器讀入的時候默認采用的是操作系統所設定的locale所對應的編碼一般我們不管是在記事本還是在ue中寫代碼如果沒有經過特別轉碼的話寫出來的都是本地編碼格式的內容所以編譯器采用的方法剛好可以讓虛擬機得到正確的資料
但是jsp文件不是這樣它沒有這個默認轉碼過程但是指定了pageEncoding就可以實現正確轉碼了
舉個例子
<%@ page contentType=text/htmlcharset=utf %>大都會打印出亂碼因為我輸入的你好嗎是gbk的但是服務器是否正確抓到你好嗎不得而知
但是如果更改為
<%@ page contentType=text/htmlcharset=utf pageEncoding=GBK%>
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26477.html
