JAVAWeb中的中文編碼問題

JavaWeb中的中文編碼問題

--學習筆記你將了解到：在java中經常遇到的幾種編碼格式的區(qū)別；在java中經常需要編碼的場景；出現中文問題的原因分析；開發(fā)JavaWeb程序時可能存在編碼問題的幾個地方；一個Http請求怎么控制編碼格式；如何避免出現中文編碼問題。為什么要編碼？比較通俗的講解就是：只要不是說英語的國家，要使用計算機就必須經過編碼，這是現狀。如果可以把計算機中存儲信息的最小單位改成漢字，這樣我們就不存在編碼問題了。字節(jié)字符如何“翻譯”常見的編碼格式有ASCII,ISO-8859-1,GB2312,GBK,UTF-8,UTF-16

（GB2312,GBK,UTF-8,UTF-16都可以表示中文）參考文獻：https:///question/23374078幾種編碼格式的比較

GB2312與GBK編碼規(guī)則類似，但是GBK范圍更大，它能處理所有漢字字符，所以GB2312與GBK比較應該選擇GBK。UTF-8編碼與GBK和GB2312不同，不用查碼表，所以在編碼效率上UTF-8的效率會更好，所以在存儲中文字符時UTF-8編碼比較理想。相對來說UTF-16編碼效率最高，字符到字節(jié)相互轉換更簡單，進行字符串操作也更好。如Java的內存編碼就是采用UTF-16編碼。但是它不適合在網絡之間傳輸，因為網絡傳輸容易損壞字節(jié)流，一旦字節(jié)流損壞將很難恢復。UTF-8在編碼效率上和編碼安全性上做了平衡，是理想的中文編碼方式。Java中需要編碼的場景磁盤I/O

網絡I/O

JavaWeb中可能會存在編碼轉換用戶從瀏覽器端發(fā)起一個HTTP請求，需要存在編碼的地方是URL、Cookie、Parameter。服務器端接受到HTTP請求后要解析HTTP協(xié)議，其中URI、Cookie和POST表單參數需要解碼；服務器端可能還需要讀取數據庫中的數據，本地或網絡中其它地方的文本文件，這些數據都可能存在編碼問題。一次HTTP請求的編碼示例

URL的幾個組成部分

GET

和POST兩種方式GET方式HTTP請求的QueryString與POST方式HTTP請求的表單參數都是作為Parameters保存，都是通過request.getParameter獲取參數值。對它們的解碼是在request.getParameter方法第一次被調用時進行的。Get對Header中的項進行解碼也是在調用request.getHeader是進行的，如果請求的Header項沒有解碼則調用MessageBytes的toString方法，這個方法將從byte到char的轉化使用的默認編碼也是ISO-8859-1，而我們也不能設置Header的其它解碼格式，所以如果你設置Header中有非ASCII字符解碼肯定會有亂碼。解決辦法：使用org.apache.catalina.util.URLEncoder編碼然后再添加到Header中(或js帶的編碼fun)，服務器接收以后按照相應的字符集解碼就好了。PostPOST表單參數傳遞方式與QueryString不同，它是通過HTTP的BODY傳遞到服務端的。當我們在頁面上點擊submit按鈕時瀏覽器首先將根據ContentType的Charset編碼格式對表單填的參數進行編碼然后提交到服務器端，在服務器端同樣也是用ContentType中字符集進行解碼。所以通過POST表單提交的參數一般不會出現問題，而且這個字符集編碼是我們自己設置的，可以通過request.setCharacterEncoding(charset)來設置。JSP設置編碼格式：

<%@pagecontentType="text/html;charset=UTF-8"%>

在JSP標準的語法中，如果pageEncoding屬性存在，那么JSP頁面的字符編碼方式就由pageEncoding決定，否則就由contentType屬性中的charset決定，如果charset也不存在，JSP頁面的字符編碼方式就采用默認的ISO-8859-1。常見問題分析

中文變成了看不懂的字符例如，字符串“淘！我喜歡！”變成了“ì?￡??ò?2??￡?”編碼過程如下圖所示字符串在解碼時所用的字符集與編碼字符集不一致導致漢字變成了看不懂的亂碼，而且是一個漢字字符變成兩個亂碼字符。一個漢字變成一個問號例如，字符串“淘！我喜歡！”變成了“？？？？？？”編碼過程如下圖所示將中文和中文符號經過不支持中文的ISO-8859-1編碼后，所有字符變成了“？”，這是因為用ISO-8859-1進行編解碼時遇到不在碼值范圍內的字符時統(tǒng)一用3f表示，這也就是通常所說的“黑洞”，所有ISO-8859-1不認識的字符都變成了“？”。一個漢字變成兩個問號例如，字符串“淘！我喜歡！”變成了“？？？？？？？？？？？？”編碼過程如下圖所示

這種情況比較復雜，中文經過多次編碼，但是其中有一次編碼或者解碼不對仍然會出現中文字符變成“？”現象，出現這種情況要仔細查看中間的編碼環(huán)節(jié)，找出出現編碼錯誤的地方。一種不正常的正確編碼還有一種情況是在我們通過request.getParameter獲取參數值時，當我們直接調用Stringvalue=request.getParameter(name);會出現亂碼，但是如果用下面的方式Stringvalue=String(request.getParameter(name).getBytes("ISO-8859-1"),"GBK");解析時取得的value會是正確的漢字字符，這種情況是怎么造成的呢？看下如所示：這種情況是這樣的，ISO-8859-1字符集的編碼范圍是0000-00FF，正好和一個字節(jié)的編碼范圍相對應。這種特性保證了使用ISO-8859-1進行編碼和解碼可以保持編碼數值“不變”。雖然中文字符在經過網絡傳輸時，被錯誤地“拆”成了兩個歐洲字符，但由于輸出時也是用ISO-8859-1，結果被“拆”開的中文字的兩半又被合并在一起，從而又剛好組成了一個正確的漢字。雖然最終能取得正確的漢字，但是還是不建議用這種不正常的方式取得參數值，因為這中間增加了一次額外的編碼與解碼，這種情況出現亂碼時因為Tomcat的配置文件中useBodyEncodingForURI配置項沒有設置為”true”，從而造成第一次解析式用ISO-8859-1來解析才造成亂碼的。CharacterEncodingFilter-org.springframework.web.filter.CharacterEncodingFilter

常用編碼工具Jsscape