一、request.setCharacterEncoding（）：是設置從request中取得的值或從數據庫中取出的值。
指定后可以通過getParameter()則直接獲得正確的字符串，如果不指定，則默認使用iso8859-1編碼。值得注意的是在執行setCharacterEncoding()之前，不能執行任何getParameter()。而且，該指定只對POST方法有效，對GET方法無效。分析原因，應該是在執行第一個getParameter()的時候，Java將會按照編碼分析所有的提交內容，而后續的getParameter()不再進行分析，所以setCharacterEncoding()無效。而對於GET方法提交表單是，提交的內容在URL中，一開始就已經按照編碼分析提交內容，setCharacterEncoding()自然就無效。
get需在Tomcat的server.xml中的:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"
URIEncoding="GBK" />
)加入URIEncoding="GBK",解決get請求亂碼問題
客戶端編碼后，用該方法告知服務端，解碼時使用相同的編碼格式，否則會出現亂碼。客戶端一般編碼()設置
<meta http-equiv="Content-Type" content="text/html; charset=gbk"> （post提交的form表單參數采用meta編碼方式）
二、response.setContentType("text/html;charset=gb2312")是設置頁面中為中文編碼。（get中的QueryString參數用response中的contentType編碼，如果沒有采用meta編碼）
前者是設置動態文字（參數，數據庫），后者設置頁面靜態文字
response.setContentType指定 HTTP 響應的編碼,同時指定了瀏覽器顯示的編碼.
response.setCharacterEncoding設置HTTP 響應的編碼,如果之前使用response.setContentType設置了編碼格式,則使用response.setCharacterEncoding指定的編碼格式覆蓋之前的設置.與response.setContentType相同的是,調用此方法,必須在getWriter執行之前或者response被提交之前.
該方法是指定服務端編碼格式，並告知客戶端解碼時的編碼碼格式，這樣兩者保持一致，才不會出現亂碼。
三、post表單和get queryString編碼設置
實踐證明queryString只配置URIEncoding就可以，如果是pathInfo就需要配置useBodyEncodingForURI。關於queryString的編碼有如下闡述：（引自http://blog.csdn.net/sfdev/article/details/3841719）
對於Get方式的URL請求有兩種情況，其一：用戶直接在瀏覽器地址欄中輸入URL，此時瀏覽器沒有編碼可參考，直接用瀏覽器的默認編碼進行解析並提交到服務端；其二：在form表單內提交，只是form屬性method為GET，此時瀏覽器會參考目前html中對編碼的相關設置進行解析，比如content-type或meta中的charset。
以下就重點講講第二種方式的提交：
GET方式form submit：瀏覽器會對URL進行URL encoding，然后發送給服務器。
- 對於中文IE,如果在高級選項中選中總以UTF-8發送(默認方式)，則PathInfo在URL Encoding時按照UTF-8編碼；QueryString按照GBK編碼。
此時提交是：GET /example/%E4%B8%AD%E5%9B%BD?name=%D6%D0%B9%FA - 對於中文IE,如果在高級選項中取消總以UTF-8發送，則PathInfo和QueryString在URL encoding時按照GBK編碼。
此時提交是：GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA - 對於中文firefox、Chrome，因為沒有類似IE中的這種設置選項，所以這兩種瀏覽器中對pathInfo的編碼規則沒有做特殊處理，MS是和queryString采取同樣的編碼規則；在本例中的假設情況下：pathInfo和queryString在URL encoding時都按照GBK編碼。
此時提交是：GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
很顯然，不同的瀏覽器以及同一瀏覽器的不同設置，會影響最終URL中PathInfo的編碼，該編碼可能不會由我們應用來控制；對於queryString，則是可以由我們的應用來完全控制的，對於上面的事例：中文的IE和FIREFOX都是采用GBK編碼queryString。
若調整下上例中的假設條件，設置Html內content-type或meta中的charset=UTF-8；
此時在IE中queryString會按照UTF-8進行編碼，即name=%E4%B8%AD%E5%9B%BD；
但是在非IE（Firefox、Chrome）中，此時提交時URL中會以中文直接提交，即name=中文；此時服務端的web服務器上肯定要進行相應的編碼配置，否則肯定會出現亂碼；
若設置Html內content-type或meta中的charset=ISO-5899-1；
此時在IE、Firefox、Chrome中queryString都被用ISO-5899-1編碼了，即name= %26%2320013%3B%26%2322269%3B；
