請求參數亂碼問題

問題描述: 在通過request對象獲取請求參數時, 如果參數中有中文數據, 在獲取時就會出現亂碼, 其原因是由於瀏覽器發送參數時(編碼時)使用的碼錶和服務器在結束數據時(解碼時)使用的碼錶不一致造成的!
(1)瀏覽器發送數據時使用的碼錶: 瀏覽器在發送數據時使用的碼錶取決於打開頁面時使用的碼錶, 即瀏覽器使用什麼編碼打開頁面, 就會使用相同的編碼來發送數據. 這裏使用的是utf-8這個碼錶!
(2)服務器接收數據時使用的碼錶: 服務器在接收數據時默認使用iso8859-1來接收請求參數
解決方案:讓編碼時使用的碼錶和解碼時使用的碼錶保持一致即可!!!

一、通過手動編解碼來解決亂碼!!
(1)根據獲取到的亂碼字符串, 反向編碼得回正確的二進制數據

(2)將二進制數組查詢utf-8碼錶轉成字符串, 得回正確的數據

二、如果發送請求的方式是POST提交, 還可以通過request提供的方法來解決亂碼:
request.setCharacterEncoding(“utf-8”); 這行代碼是通知服務器使用utf-8來接收請求實體內容中的數據.
由於POST提交的參數剛好在請求實體內容中, 所以這行代碼可以解決POST提交時產生亂碼問題.

但是由於GET提交的參數在請求行中的請求資源路徑後面拼接着, 不在請求實體內容中, 所有這行代碼對GET提交產生的亂碼不會起作用!

三、通過在tomcat中的server.xml文件中找出如下代碼，照樣修改可以解決get請求的亂碼

四、在數據庫配置屬性文件的連接路徑後面加上編碼定義語句如下所示，可以解決post請求亂碼
jdbcUrl=jdbc:mysql:///jtsys?useUnicode=true&characterEncoding=utf-8

響應參數亂碼問題

字節流發送亂碼產生原因
（1）服務端在發送數據，數據使用的編碼是GBK(字符串轉成二進制數組調用的是getBytes()，這個方法如果不指定，將會使用默認的平臺碼GBK)
（2）瀏覽器自己有默認的編碼(比如谷歌)，如果不指定，默認使用utf-8來接收數據. 發送數據和接收數據使用的碼錶不一致造成亂碼。
字符流亂碼產生的原因:
（1）服務器端使用字符流發送數據，底層需要將字符轉成字節，這時需要使用一個碼錶，如果不指定，服務器默認使用iso8859-1編碼，而這個編碼中沒有中文漢字，所以必然會出現亂碼!
（2）無論客戶端使用什麼編碼，接收到的數據都是亂碼!
3、解決的方案:
（1）字節流發送
第一步: 通知服務端使用utf-8來發送數據
第二步: 通知瀏覽器也使用utf-8來接收數據

等價於：

（2）字符流發送
第一步: 通知服務端使用utf-8來發送數據

第二步: 通知瀏覽器也使用utf-8來接收數據

4、總結: 其實在解決字符流發送中文亂碼問題的過程中，
response.setCharacterEncoding(“utf-8”);
– 這行代碼可以省略不寫，原因是因爲
response.setContentType(“text/html;charset=utf-8”);
– 這行代碼有兩個作用，既會通知服務器用utf-8來發送數據，也會通知瀏覽器使用utf-8來接收數據!