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

（GB2312,GBK,UTF-8,UTF-16都可以表示中文）參考文獻(xiàn)：https://第四頁，共21頁。幾種編碼格式的比較

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

網(wǎng)絡(luò)I/O第六頁，共21頁。

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

第八頁，共21頁。URL的幾個組成部分

第九頁，共21頁。GET

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

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

在JSP標(biāo)準(zhǔn)的語法中，如果pageEncoding屬性存在，那么JSP頁面的字符編碼方式就由pageEncoding決定，否則就由contentType屬性中的charset決定，如果charset也不存在，JSP頁面的字符編碼方式就采用默認(rèn)的ISO-8859-1。第十三頁，共21頁。常見問題分析

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

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