JSP運行的編碼過程整理

pageEncoding 優先級高於 contentType，pageEncoding會按指定的編碼轉譯成統一的utf-8。

 

*.jsp（按pageEncoding） ->*servlet.java->*.class->容器load class解析執行返回結果內容

                                              -> utf-8（無論什麼編碼方式）->utf-16

上面階段jsp轉java造成的*.java是utf-8格式的文件，無論jsp指定的什麼編碼方式，java->*.class也是utf-8格式的

這個轉義到java的編碼過程是必然的

 

setContentType是瀏覽器展示給客戶端使用的編碼，setCharacterEncoding設置的setContentType的charset的內容。

瀏覽器在發送url請求時候會對url和參數進行編碼，編碼方式也是經過response.setCharacterEncoding來設置的。

jsp中使用<%@ page pageEncoding="UTF-8"%>，不指定contentType也不使用response.setCharacterEncoding,將對服務器響應的編碼。response.setContentType("text/html;charset=UTF-8");這個會影響到jsp頁面瀏覽器第1階段，解析成java階段的請求方式。

瀏覽器在接收服務器數據和發送數據到服務器時所使用的編碼是相同的，默認狀況下均爲JSP頁面的response.setCharacterEncoding參數（或者contentType和 pageEncoding參 數），咱們稱其爲瀏覽器編碼。這個是有順序優先級的。

對於服務器方面，post方式在jsp中設置request.setCharacterEncoding和response.setCharacterEncoding的編碼方式相同應該就能夠避免亂碼。

url和get方式因爲tomcat編碼方式是iso-8859-1，因此用兩種方式來處理URIEncoding=GBK（是直接將get請求和url用GBK編碼）和useBodyEncodingForURI（是在server返回客戶端時使用setCharacterEncoding來編碼請求的數據）

 

這個圖很經典的說明內存中unicode的包含大的橋樑做用，只要正確的雙向編碼就能避免亂碼問題。