JAVAWeb中的中文編碼問(wèn)題

JavaWeb中的中文編碼問(wèn)題

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

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

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

網(wǎng)絡(luò)I/O

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

URL的幾個(gè)組成部分

GET

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

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

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

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

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

常用編碼工具Jsscape