在做
java項(xiàng)目（特別是
web項(xiàng)目）的過程中，中文亂碼一直是我們開發(fā)人員比較頭疼的問題，因?yàn)樯婕暗骄幋a，解碼，字符集，以及國際化等諸多問題，所以在著手解決的時(shí)候也缺乏相關(guān)的知識(shí)。我花了一些時(shí)間自己動(dòng)手實(shí)驗(yàn)了一把，雖然沒有洞悉編碼，解碼這些底層原理，但是解決實(shí)際問題應(yīng)該足夠了。這里主要針對(duì)java web項(xiàng)目中的文亂碼問題。
從瀏覽器采用form方式提交數(shù)據(jù)到服務(wù)器，可以分為post和get方法。
1，post方法：
在jsp頁面中的page指令中，有一個(gè)pageEncoding，這個(gè)指令表示jsp翻譯成servlet時(shí)采用的編碼，以及form提交數(shù)據(jù)的編碼格式。所以post方法提交數(shù)據(jù)的編碼格式由pageEncoding指定。那解碼方式呢？通常，我們?cè)陧撁嬖O(shè)置了pageEncoding=”utf-8”，在后臺(tái)用request.getParameter()得到的往往是亂碼，而進(jìn)一步通過new String(getBytes(“iso-8859-1”),”utf-8”)處理之后就能得到正確的數(shù)據(jù)。這是因?yàn)榉?wù)器默認(rèn)的解碼方式是iso-8859-1，所以用編碼，解碼流程解釋上面那2個(gè)動(dòng)作分別是：utf-8編碼—>iso-8859-1解碼（當(dāng)然是亂碼）； utf-8編碼—>iso-8859-1解碼—>iso-8859-1編碼—>utf-8解碼，這是個(gè)對(duì)稱的過程，所以能正確得到數(shù)據(jù)。那服務(wù)器默認(rèn)的解碼方式能改嗎？當(dāng)然可以，調(diào)用request.setCharacterEncoding()就能設(shè)置，而且只針對(duì)post方式有效，設(shè)置以后request.getParameter()直接就是正確的數(shù)據(jù)了。
2，get方法
與post方法一樣，編碼方式由pageEncoding指定，但是get方式的解碼方式與post就不一樣了。在tomcat的conf目錄下有一個(gè)
server.xml的配置文件，在里面找到Connector節(jié)點(diǎn)，有一個(gè)URIEncoding屬性，這個(gè)屬性就是指定get方式的數(shù)據(jù)解碼格式的，而且只針對(duì)get方式有效。其他處理與post一樣。
另外，通過Ajax請(qǐng)求向后臺(tái)發(fā)送的數(shù)據(jù)由于是附在URL地址后面的，所以跟get請(qǐng)求一樣。編碼由pageEncoding指定，解碼由URIEncoding指定。但是有很多開發(fā)人員樂于另外一種方式：用兩次encodeURI編碼，然后在后臺(tái)用URLDecoder.decode(str,”utf-8”)解碼。這是一個(gè)什么過程呢？我們知道，encodeURI編碼是采用的utf-8編碼，所以，這個(gè)過程為：utf-8編碼—>utf-8編碼—>iso-8859-1解碼—>utf-8解碼。這看起來不像一個(gè)對(duì)稱過程，但最后為什么能得到正確結(jié)果呢？這是因?yàn)榻?jīng)過第一次utf-8編碼之后，產(chǎn)生的已經(jīng)是非中文字符，所以，對(duì)非中文字符采再用utf-8編碼，iso-8859-1解碼不會(huì)有任何問題，這樣看來，它還是一個(gè)對(duì)稱的編碼，解碼過程，當(dāng)然能正確解析了。
當(dāng)然，我所說的這個(gè)“對(duì)稱”編碼解碼過程，也不是所有編碼都適用，例如：
gbk編碼—>utf-8解碼—>utf-8編碼—>gbk解碼，最后還是亂碼！
因?yàn)間bk編碼—>utf-8解碼產(chǎn)生了不可恢復(fù)的錯(cuò)誤，造成了信息丟失，至于為什么產(chǎn)生永久錯(cuò)誤，得從編碼的底層說起……