jsp涉及到的編碼的流程
JSP要經過3次的“編碼”，第1階段會用 pageEncoding，第2階段會用utf-8至utf-8，第3階段就是由Tomcat出來的網頁， 用的是contentType.
第1階段, 是jsp編譯成.java，它會根據pageEncoding的設定讀取jsp，結果是由指定的編碼方案翻譯成統一的UTF-8 JAVA源碼（即.java).
第2階段, 是由JAVAC的JAVA源碼至java byteCode的編譯，不論JSP編寫時候用的是什么編碼方案，經過這個階段的結果全部是UTF-8的編碼的java代碼.
第3階段, 是Tomcat（或其的application container）載入和執行階段二的來的JAVA二進制碼，輸出的結果，也就是在客戶端見到的，這時隱藏在階段一和階段二的參數contentType就發揮了功效.
JSP 中 pageEncoding 和contentType中charset 的區別
pageEncoding="UTF-8"
contentType="text/html;charset=UTF-8"
前面說過,pageEncoding="UTF-8"的作用是JSP編譯成Servlet時使用的編碼。通常，在JSP內部定義的字符串（直接在JSP中定義，而不是從瀏覽器提交的數據）出現亂碼時，很多都是由於該參數設置錯誤引起的。例如，你的 JSP文件是以GBK為編碼保存的，而在JSP中卻指定pageEncoding="UTF-8"，就會引起JSP內部定義的字符串出現亂碼。 另外，該參數還有一個功能，就是在JSP中不指定contentType參數，也不使用response.setCharacterEncoding方法時，將對服務器響應的編碼。
contentType="text/html;charset=UTF-8"的作用是指定對服務器響應進行重新編碼的編碼。在不使用response.setCharacterEncoding方法時，用該參數指定對服務器的響應進行重新編碼的編碼。
常用編碼
- url的組成: scheme://ip:port/contextPath/servletPath/pathInfo?queryString
例如,在 http://192.168.1.101:8080/ReceiveAndroid/ServletForPostMethod/pathInfo?name=莉莉&pwd=abc 中,
-
- contextPath:/ReceiveAndroid
- servletPath:/ServletForPostMethod
- getScheme:http
- uri:/ReceiveAndroid/ServletForPostMethod
- url:http://192.168.1.101:8080/ReceiveAndroid/ServletForPostMethod/pathInfo?name=莉莉&pwd=abc
- protocol:HTTP/1.1
2.請求
-
- request.getRequestURI: //內容為 contextPath/servletPath/pathinfo, 是瀏覽器提交過來的原始數據,沒有被Servlet服務器decode過.
- request.setCharacterEncoding: 僅適用於post提交的request body部分,而不適用於get提交的query string編碼.
3.響應
-
- ContentType: html頭部ContentType("text/html; charset=utf-8") [不是meta'中的ContentType]: 的作用是指定對服務器響應進行重新編碼的編碼,是針對.class文件輸出的結果,即我們在瀏覽器客戶端看到的(使用的編碼).
- response.setCharacterEncoding: 官方的文檔說使用 response.setCharacterEncoding 是服務器在將數據發送到瀏覽器前，使用的編碼,方法會重寫 response.setContentType 中的charset,但並不表示setCharacterEncoding可以替換setContentType.當客戶端為瀏覽器的時候,setContentType設置編碼可以替換setCharacterEncoding,怎么說,當沒有設置setContentType,僅設置setCharacterEncoding的時候,在非瀏覽器的客戶端,可以得到正常,但是對於瀏覽器的客戶端,還是會出現亂碼.這是因為,服務器端響應的編碼並不等價於瀏覽器顯示給客戶端使用的編碼,這更進一步說明了setContentType是瀏覽器展現給客戶端使用的編碼.
瀏覽器是如何對接收和發送的數據進行編碼
response.setCharacterEncoding("UTF- 8"): 前面說過,是服務器在將數據發送到瀏覽器前，使用的編碼.同時，瀏覽器也是 根據這個參數來對其接收到的數據進行重新編碼（或者稱為解碼）。所以在無論你在 JSP中設置response.setCharacterEncoding("UTF-8")或者 response.setCharacterEncoding("GBK")，瀏覽器均能正確顯示中文（前提是你發送到瀏覽器的數據編碼是正確的，比如正 確設置了pageEncoding參數等）。讀者可以做個實驗，在JSP中設置response.setCharacterEncoding("UTF- 8")，在IE中顯示該頁面時，在IE的菜單中選擇"查看(V)"à"編碼(D)"中可以查看到是" Unicode（UTF-8）"，而在在JSP中設置response.setCharacterEncoding("GBK")，在IE中顯示該頁面 時，在IE的菜單中選擇"查看(V)"à"編碼(D)"中可以查看到是"簡體中文（GB2312）"[在html中可以通過'meta'中設置'content'的'charset',可以達到同樣的效果]。
瀏覽器在發送數據時，對URL和參數會進行URL編碼，對參數中的中文，瀏覽器也是使response.setCharacterEncoding 參數來進行URL編碼的。以百度和 GOOGLE為例，如果你在百度中搜索"漢字"，百度會將其編碼為"%BA%BA%D7%D6"。而在GOOGLE中搜索"漢字"，GOOGLE會將其編 碼為"%E6%B1%89%E5%AD%97"，這是因為百度的response.setCharacterEncoding參數為GBK，而 GOOGLE的的response.setCharacterEncoding參數為UTF-8。
瀏覽器在接收服務器數據和發送數據到服務器時所使用的編碼是相同的，默認情況下均為JSP頁面的response.setCharacterEncoding參數（或者contentType和 pageEncoding參 數），我們稱其為瀏覽器編碼。當然，在IE中可以修改瀏覽器編碼（在IE的菜單中選擇"查看(V)"à"編碼(D)"中修 改），但通常情況下，修改該參數會使原本正確的頁面中出現亂碼。一個有趣的例子是，在IE中瀏覽GOOGLE的主頁時，將瀏覽器編碼修改為"簡體中文 （GB2312）"，此時，頁面上的中文會變成亂碼，不理它，在文本框中輸入"漢字"，提交，GOOGLE會將其編碼為"%BA%BA%D7%D6"，可 見，瀏覽器在對中文進行URL編碼時，使用的就是瀏覽器編碼。
弄清了瀏覽器是在接收和發送數據時，是如何對數據進行編碼的了，我們再來看看服務器是在接收和發送數據時，是如何對數據進行編碼的。
對於發送數據，服務器按照response.setCharacterEncoding—contentType—pageEncoding的優先順序，對要發送的數據進行編碼。
對於接收數據，要分三種情況。一種是瀏覽器直接用URL提交的數據，另外兩種是用表單的GET和POST方式提交的數據。
因為各種WEB服務器對這三種方式的處理也不相同，所以我們以Tomcat5.0為例。
無論使用那種方式提交，如果參數中包含中文，瀏覽器都會使用當前瀏覽器編碼對其進行URL編碼。
對於表單中POST方式提交的數據，只要在接收數據的JSP中正確request.setCharacterEncoding參數，即將對客戶端請求進行重 新編碼的編碼設置成瀏覽器編碼，就可以保證得到的參數編碼正確。有些讀者可能會問，那如何得到瀏覽器編碼呢？上面我們提過了，在默認請情況下，瀏覽器編碼 就是你在響應該請求的JSP頁面中response.setCharacterEncoding設置的值。所以對於POST表單提交的數據，在獲得數據的 JSP頁面中request.setCharacterEncoding要和生成提交該表單的JSP頁面的 response.setCharacterEncoding設置成相同的值。
對於URL提交的數據和表單中GET方式提交的數據，在接收數據的JSP中設置request.setCharacterEncoding參數是不行的，因為在Tomcat5.0中，默認情況下使用 iso-8859-1對URL提交的數據和表單中GET方式提交的數據進行重新編碼（解碼），而不使用該參數對URL提交的數據和表單中GET方式提交的數據進行 重新編碼（解碼）。要解決該問題，應該在Tomcat的配置文件的Connector標簽中設置useBodyEncodingForURI或者 URIEncoding屬 性，其中useBodyEncodingForURI參數表示是否用request.setCharacterEncoding 參數對URL提交的數據和表單中GET方式提交的數據進行重新編碼，在默認情況下，該參數為false（Tomcat4.0中該參數默認為 true）；URIEncoding參數指定對所有GET方式請求（包括URL提交的數據和表單中GET方式提交的數據）進行統一的重新編碼（解碼）的編 碼。URIEncoding和useBodyEncodingForURI區別是，URIEncoding是對所有GET方式的請求的數據進行統一的重新 編碼（解碼），而useBodyEncodingForURI則是根據響應該請求的頁面的request.setCharacterEncoding參數 對數據進行的重新編碼（解碼），不同的頁面可以有不同的重新編碼（解碼）的編碼。所以對於URL提交的數據和表單中GET方式提交的數據，可以修改 URIEncoding參數為瀏覽器編碼或者修改useBodyEncodingForURI為true，並且在獲得數據的JSP頁面中 request.setCharacterEncoding參數設置成瀏覽器編碼。
下面總結下，以Tomcat5.0為WEB服務器時，如何防止中文亂碼。
1、對於同一個應用，最好統一編碼，推薦為UTF-8，當然GBK也可以。
2、正確設置JSP的pageEncoding參數
3、在所有的JSP/Servlet中設置contentType="text/html;charset=UTF-8"或response.setCharacterEncoding("UTF-8")，從而間接實現對瀏覽器編碼的設置。
4、 對於請求，可以使用過濾器或者在每個JSP/Servlet中 設置request.setCharacterEncoding("UTF-8")。同時， 要修改Tomcat的默認配置，推薦將useBodyEncodingForURI參數設置為true，也可以將URIEncoding參數設置為 UTF-8（有可能影響其他應用，所以不推薦）。
ref:http://www.cnblogs.com/loulijun/archive/2012/03/28/2421568.html