Java亂碼解決方案

在做java專案（特別是web專案）的過程中，中文亂碼一直是我們開發人員比較頭疼的問題，因為涉及到編碼，解碼，字符集，以及國際化等諸多問題，所以在著手解決的時候也缺乏相關的知識。我花了一些時間自己動手實驗了一把，雖然沒有洞悉編碼，解碼這些底層原理，但是解決實際問題應該足夠了。這裡主要針對java web專案中的文亂碼問題。

從瀏覽器採用form方式提交資料到伺服器，可以分為post和get方法。

1，post方法：

在jsp頁面中的page指令中，有一個pageEncoding，這個指令表示jsp翻譯成servlet時採用的編碼，以及form提交資料的編碼格式。所以post方法提交資料的編碼格式由pageEncoding指定。那解碼方式呢？通常，我們在頁面設定了pageEncoding=”utf-8”，在後臺用request.getParameter()得到的往往是亂碼，而進一步透過new String(getBytes(“iso-8859-1”),”utf-8”)處理之後就能得到正確的資料。這是因為伺服器預設的解碼方式是iso-8859-1，所以用編碼，解碼流程解釋上面那2個動作分別是：utf-8編碼—>iso-8859-1解碼（當然是亂碼）；        utf-8編碼—>iso-8859-1解碼—>iso-8859-1編碼—>utf-8解碼，這是個對稱的過程，所以能正確得到資料。那伺服器預設的解碼方式能改嗎？當然可以，呼叫request.setCharacterEncoding()就能設定，而且只針對post方式有效，設定以後request.getParameter()直接就是正確的資料了。

2，get方法

與post方法一樣，編碼方式由pageEncoding指定，但是get方式的解碼方式與post就不一樣了。在tomcat的conf目錄下有一個server.xml的配置檔案，在裡面找到Connector節點，有一個URIEncoding屬性，這個屬性就是指定get方式的資料解碼格式的，而且只針對get方式有效。其他處理與post一樣。

 

    另外，透過Ajax請求向後臺傳送的資料由於是附在URL地址後面的，所以跟get請求一樣。編碼由pageEncoding指定，解碼由URIEncoding指定。但是有很多開發人員樂於另外一種方式：用兩次encodeURI編碼，然後在後臺用URLDecoder.decode(str,”utf-8”)解碼。這是一個什麼過程呢？我們知道，encodeURI編碼是採用的utf-8編碼，所以，這個過程為：utf-8編碼—>utf-8編碼—>iso-8859-1解碼—>utf-8解碼。這看起來不像一個對稱過程，但最後為什麼能得到正確結果呢？這是因為經過第一次utf-8編碼之後，產生的已經是非中文字元，所以，對非中文字元采再用utf-8編碼，iso-8859-1解碼不會有任何問題，這樣看來，它還是一個對稱的編碼，解碼過程，當然能正確解析了。

      

    當然，我所說的這個“對稱”編碼解碼過程，也不是所有編碼都適用，例如：

gbk編碼—>utf-8解碼—>utf-8編碼—>gbk解碼，最後還是亂碼！

因為gbk編碼—>utf-8解碼產生了不可恢復的錯誤，造成了資訊丟失，至於為什麼產生永久錯誤，得從編碼的底層說起……