Java Web中的中文编码问题分析
一、為什么需要編碼
? ? 在計算機中存儲信息的最小單位是1個字節(jié)，即8bit，所以能標識的最大字符范圍是0~255，而人類自然語言中例如漢語、日語要表示的符號太多，無法單純用一個字節(jié)來完全表示，為了解決這個矛盾必須要有一個新的人類可識別的數(shù)據(jù)存儲結(jié)構(gòu)字符，而從char到byte必須編碼。
?
二、常見的編碼格式
1 - ASCII碼
? ? 總共128個，使用一個字節(jié)的低7位表示，0~31是控制字符如換行、回車、刪除等，32~126是打印字符，可以通過鍵盤輸入并且能夠顯示出來
?
2 - ISO-8859-1
? ? ISO組織在ASCII碼的基礎(chǔ)上利用了單個字節(jié)的所有位定制了一系列標準擴展了ASCII編碼，ISO-8859-1仍然是單字節(jié)編碼，總共可以表示256個字符
?
3 - GB2312
? ? GB2312全稱是《信息技術(shù)中文編碼字符集》，它采用了雙字節(jié)編碼，總的編碼范圍是A1~F7，其中A1~A9是符號區(qū)，總共包含682個符號；B0~F7是漢字區(qū)，包含6763個漢字。
?
4 - GBK
? ? GBK全稱是《漢字內(nèi)碼擴展規(guī)范》是國家技術(shù)監(jiān)督局位windows 95制定的新的內(nèi)碼規(guī)范，它的出現(xiàn)是為了擴展GB2312，并加入更多的漢字，它的編碼范圍是8140~FEFE，總共有23940個碼位可以表示21003個漢字，它的編碼與GB2312兼容，也就是說采用GB2312編碼的漢字均可以通過GBK去解碼，并且不會有亂碼。
5 - UTF-16
? ? UTF-16定義了Unicode字符在計算機中的存取方法，UTF-16使用兩個字節(jié)表示Unicode的轉(zhuǎn)化格式，這是一個定長的表示方法，無論什么字符UTF-16都用兩個字節(jié)表示，2個字節(jié)就是16位，所以稱之為UTF-16，UTF-16表示字符非常方便，每兩個字節(jié)表示一個字符，在字符串操作的時候大大簡化了操作，這個也是Java以UTF-16作為內(nèi)存的字符存儲格式的一個很重要的原因。
Unitcode使用UTF-16編碼規(guī)則如下：
? ? UTF-16編碼以16位無符號整數(shù)為單位，我們
????
?
6 - UTF-8
? ? UTF-16統(tǒng)一采用兩個字節(jié)表示一個字符，雖然在表示上非常簡單方便，但是也有其缺點，有很大一部分字符使用一個字節(jié)就可以表示的現(xiàn)在需要兩個字節(jié)表示，存儲空間增大了一倍，在現(xiàn)在網(wǎng)絡(luò)帶寬還非常有限的今天，這樣做無疑會增大網(wǎng)絡(luò)傳輸?shù)牧髁?#xff0c;而且也沒什么必要，而UTF-8采用的是一種變長的技術(shù)，每種編碼區(qū)域都會有不同的字節(jié)長度，不同類型的字符可以有1~6個字節(jié)組成。
UTF-8有以下編碼規(guī)則
? ? 1.如果是1個字節(jié)，最高為（第8位）為0，則表示這是1個ASCII字符（00~7F）。可見，所有ASCII編碼已經(jīng)是UTF-8了。
? ? 2.如果是1個字節(jié)，以11開頭，則連續(xù)的1的個數(shù)暗示這個字符的字節(jié)數(shù)，例如：110xxxxx代表它是雙字節(jié)UTF-8字符的首字節(jié)。
? ? 3.如果是1個字節(jié)，以10開始，表示它不是首字節(jié)，則需要向前查找才能得到當前字符的首字節(jié)。
?
三、在Java中需要編碼的場景
1 - 在IO操作中存在的編碼
? ? 我們知道在涉及編碼的地方一般都在從字符到字節(jié)或者是從字節(jié)到字符的轉(zhuǎn)化過程中，而需要這種轉(zhuǎn)化的場景主要是I/O，而這個IO主要包括磁盤IO和網(wǎng)絡(luò)IO。
? ? 在Java中負責在IO過程中處理字節(jié)到字符轉(zhuǎn)換的是InputStreamReader，它繼承自Reader，在類創(chuàng)建時關(guān)聯(lián)了一個字節(jié)輸入流InputStream對象，對具體字節(jié)到字符的轉(zhuǎn)換它主要委托給內(nèi)部的StreamDecode去做，StreamDecoder在解碼過程中需要基于指定的Charset獲取對應(yīng)的CharsetDecoder將字節(jié)流為字符，如果沒有指定將使用操作系統(tǒng)默認的編碼方式，在中文環(huán)境中通常時GBK。相反在java中關(guān)聯(lián)字符到字節(jié)轉(zhuǎn)換的橋梁是OutputStreamWriter，他繼承自Writer，在類創(chuàng)建時關(guān)聯(lián)了字節(jié)輸出流OutputStream對象，對具體字符到字節(jié)的轉(zhuǎn)換它主要委托給內(nèi)部的StreamEncoder，StreamEncoder獲取對應(yīng)Charset的CharsetEncoder編碼器將字符編碼位字節(jié)，如果沒有指定字符集Charset通常采用本地操作系統(tǒng)默認的字符集進行編碼。
????在我們的應(yīng)用程序中涉及I/O操作時，只要注意指定統(tǒng)一的編解碼Charset字符集，一般不會出現(xiàn)亂碼問題。
????對有些應(yīng)用程序如果不注意指定字符編碼，則在中文環(huán)境中會使用操作系統(tǒng)默認編碼。如果編解碼都在中文環(huán)境中，通常也沒有問題，但還是不推薦使用操作系統(tǒng)的默認編碼，因為這樣會使你的應(yīng)用程序的編碼格式和運行環(huán)境綁定起來，在跨環(huán)境時很可能出現(xiàn)亂碼問題。
?
2 - 在內(nèi)存操作中的編碼
????在Java開發(fā)中除I/O涉及編碼外，最常用的應(yīng)該就是在內(nèi)存中進行從字符到字節(jié)的數(shù)據(jù)類型轉(zhuǎn)換，在Java中用String表示字符串，所以String類就提供了轉(zhuǎn)換到字節(jié)的方法，也支持將字節(jié)轉(zhuǎn)換為字符串的構(gòu)造函數(shù)。
String s = "這是一段中文字符串"; byte[] b = s.getBytes("UTF-8"); String str = new String(b,"UTF-8");? ? 在程序中這三行代碼一共經(jīng)歷了以下過程：
1）UTF-16輸入流到Unicode的解碼（在JVM中發(fā)生）
2）Unicode到UTF-8編碼的輸出流
3）UTF-8輸入流到Unicode的解碼
4）Unicode到UTF-16的編碼（在JVM中發(fā)生）
思考下代碼最終執(zhí)行結(jié)果字節(jié)數(shù)組a與b是否相同，結(jié)合Java默認的編碼方式以及JVM內(nèi)部默認采用存儲漢字的編碼方式，分析這一過程
byte[] a = new byte[]{(byte) 0xc6, (byte) 0xd0}; String s = new String(a); byte[] b = s.getBytes();Charset提供encode與decode，分別對應(yīng)char[]到byte[]的編碼和byte[]到char[]的解碼。
String s = "這是一段中文字符串"; Charset charset = Charset.forName("UTF-8"); ByteBuffer byteBuffer = charset.encode(s); CharBuffer charBuffer = charset.decode(byteBuffer);?
四、在Java中如何進行編碼和解碼
? ? Java中涉及編碼的類圖如下：
?
下圖是String.getBytes(String charsetName)對應(yīng)的時序圖
?
?
? ? 由圖可知，String.getBytes(String charsetName)編碼基本流程如下：
1）根據(jù)charsetName找到Charset類，然后根據(jù)這個字符集編碼生成CharsetEncoder，這個類是所有字符編碼的父類，針對不同的字符編碼集在charset中定義了獲取對應(yīng)CharsetEncoder的方法；
2）基于獲取到的編碼器CharsetEncoder對當前字符串進行編碼
?
1 - 按照ISO-8859-1編碼方式編碼
字符串“I am 君山”用ISO-8859-1編碼時，編碼結(jié)果如圖：
?
????可以看出，7個 char 字符經(jīng)過 ISO-8859-1 編碼轉(zhuǎn)變成7個 byte 數(shù)組，ISO-8859-1 是單字節(jié)編碼，中文“君山”被轉(zhuǎn)化成值是 3f 的 byte。3f 也就是“？”字符，所以經(jīng)常會出現(xiàn)中文變成“？”，很可能就是錯誤的使用了 ISO-8859-1 這個編碼導(dǎo)致的。中文字符經(jīng)過 ISO-8859-1 編碼會丟失信息，通常我們稱之為“黑洞”，它會把不認識的字符吸收掉。由于現(xiàn)在大部分基礎(chǔ)的 Java 框架或系統(tǒng)默認的字符集編碼都是 ISO-8859-1，所以很容易出現(xiàn)亂碼問題。
?
2 - 按照GB2312編碼
字符串“I am 君山”用GB2312編碼時，編碼結(jié)果如圖：
GB2312 對應(yīng)的 Charset 是 sun.nio.cs.ext.EUC_CN，而對應(yīng)的 CharsetEncoder是 sun.nio.cs.ext.DoubleByte.Encoder，我們進入該類encodeLoop方法的源碼：
protected CoderResult encodeLoop(CharBuffer var1, ByteBuffer var2) {return var1.hasArray() && var2.hasArray() ? this.encodeArrayLoop(var1, var2) : this.encodeBufferLoop(var1, var2);}? ? 這里只是簡單的做了基本要素的判空繼續(xù)進入encodeArrayLoop方法
protected CoderResult encodeArrayLoop(CharBuffer var1, ByteBuffer var2) {char[] var3 = var1.array();int var4 = var1.arrayOffset() + var1.position();int var5 = var1.arrayOffset() + var1.limit();byte[] var6 = var2.array();int var7 = var2.arrayOffset() + var2.position();int var8 = var2.arrayOffset() + var2.limit();try {while(true) {if (var4 < var5) {char var15 = var3[var4];int var10 = this.encodeChar(var15);CoderResult var11;if (var10 != 65533) {//若大于255則證明是雙字節(jié)字符，雙字節(jié)字符高8位作為第1個字節(jié)存儲，低8位作為第2個字節(jié)存//儲,if (var10 > 255) {if (var8 - var7 < 2) {var11 = CoderResult.OVERFLOW;return var11;}var6[var7++] = (byte)(var10 >> 8);var6[var7++] = (byte)var10;} else {//否則是單個字節(jié)字符，直接編碼作為單個字節(jié)存儲if (var8 - var7 < 1) {var11 = CoderResult.OVERFLOW;return var11;}var6[var7++] = (byte)var10;}++var4;continue;}......}? ? 這個方法代碼挺長，我們略過非核心內(nèi)容可以看到真正進行字符編碼的地方是在圖中注釋處的代碼，我們看到他調(diào)用了本類的encoderChar方法繼續(xù)進入該方法進行后續(xù)分析：
public int encodeChar(char var1) {return this.c2b[this.c2bIndex[var1 >> 8] + (var1 & 255)];}? ? 到這里，Java中GB2312的大致編碼流程就很清晰了，GB2312 字符集有一個 char 到 byte 的碼表，通過這個碼表獲取每個字符對應(yīng)的碼位值var10，再通過對這個碼位值進行判斷，如果大于255，則基于高位編址法取它的高8位作為第一個字節(jié)存放，低8位作為第2個字節(jié)，由此可見GB2312的編解碼其實是基于碼表進行的。
?
3 - 按照GBK進行編碼
字符串“I am 君山”用GBK編碼時，編碼結(jié)果如圖：
????你可能已經(jīng)發(fā)現(xiàn)，上圖與 GB2312 編碼的結(jié)果是一樣的，沒錯，GBK 與 GB2312 編碼結(jié)果是一樣的，由此可以得出 GBK 編碼是兼容 GB2312 編碼的，它們的編碼算法也是一樣的。不同的是它們的碼表長度不一樣，GBK 包含的漢字字符更多。所以只要是經(jīng)過 GB2312 編碼的漢字都可以用 GBK 進行解碼，反過來則不然。
?
4 - 按照UTF-16編碼
字符串“I am 君山”用UTF-16編碼時，編碼結(jié)果如圖
????用 UTF-16 編碼將 char 數(shù)組放大了一倍，單字節(jié)范圍內(nèi)的字符，在高位補 0 變成兩個字節(jié)，中文字符也變成兩個字節(jié)。從 UTF-16 編碼規(guī)則來看，僅僅將字符的高位和地位進行拆分變成兩個字節(jié)。特點是編碼效率非常高，規(guī)則很簡單，由于不同處理器對 2 字節(jié)處理方式不同，Big-endian（高位字節(jié)在前，低位字節(jié)在后）或 Little-endian（低位字節(jié)在前，高位字節(jié)在后）編碼，所以在對一串字符串進行編碼是需要指明到底是 Big-endian 還是 Little-endian，所以前面有兩個字節(jié)用來保存 BYTE_ORDER_MARK 值，UTF-16 是用定長 16 位（2 字節(jié)）來表示的 UCS-2 或 Unicode 轉(zhuǎn)換格式，通過代理對來訪問 BMP 之外的字符編碼。
?
5 - 按照UTF-8進行編碼
????字符串“I am 君山”用UTF-8編碼時，編碼結(jié)果如圖：
????UTF-16 雖然編碼效率很高，但是對單字節(jié)范圍內(nèi)字符也放大了一倍，這無形也浪費了存儲空間，另外 UTF-16 采用順序編碼，不能對單個字符的編碼值進行校驗，如果中間的一個字符碼值損壞，后面的所有碼值都將受影響。而 UTF-8 這些問題都不存在，UTF-8 對單字節(jié)范圍內(nèi)字符仍然用一個字節(jié)表示，對漢字采用三個字節(jié)表示。UTF-8 編碼與 GBK 和 GB2312 不同，不用查碼表，所以在編碼效率上 UTF-8 的效率會更好，所以在存儲中文字符時 UTF-8 編碼比較理想。
6 -?對幾種編碼格式的比較
??? 1）對于中文字符，GB2312與GBK編碼規(guī)則類似，但是GBK范圍更大，它能處理所有漢字字符，所以將GB2312與GBK進行比較，應(yīng)該選擇GBK。
? ? 2）UTF-16與UTF-8都是處理Unicode編碼，它們的編碼規(guī)則不太相同，相對來說，UTF-16的編碼效率較高，從字符到到字節(jié)的相互轉(zhuǎn)換更簡單，進行字符串操作也更好。它適合在本地磁盤和內(nèi)存之間使用，可以進行字符和字節(jié)之間的快速切換，如Java的內(nèi)存編碼就采用UTF-16編碼。但是它不合適在網(wǎng)絡(luò)之間傳輸，因為網(wǎng)絡(luò)傳輸容易損壞字節(jié)流，一旦字節(jié)流損壞將很難恢復(fù)，所以相比較而言UTF-8更適合網(wǎng)絡(luò)傳輸。
? ? 3）UTF-8對ASCII字符采用單字節(jié)存儲，另外單個字符損壞也不會影響后面的其他字符，在編碼效率上介于GBK和UTF-16之間，所以UTF-8在編碼效率上和編碼安全上做了平衡，是理想的中文編碼方式。
?
五、在Java Web中涉及的編解碼
????前面已經(jīng)提到了I/O操作會引起編碼，而大部分I/O引起的亂碼都是網(wǎng)絡(luò)I/O，因為現(xiàn)在幾乎所有的應(yīng)用程序都涉及網(wǎng)絡(luò)操作，而數(shù)據(jù)經(jīng)過網(wǎng)絡(luò)傳輸時是以字節(jié)為單位的，所以所有的數(shù)據(jù)都必須能夠被序列化為字節(jié)。在Java中數(shù)據(jù)要被序列化，必須繼承Serializable接口。
????用戶從瀏覽器發(fā)起一個HTTP請求，存在編碼的地方是URL、Cookie、Parameter。服務(wù)器端接收到HTTP請求后要解析HTTP，其中URL、Cookie和Post表單參數(shù)需要解碼，服務(wù)器端可能還需要讀取數(shù)據(jù)庫中的數(shù)據(jù)——本地或網(wǎng)絡(luò)中其他地方的文本文件，這些數(shù)據(jù)都可能存在編碼問題。當Servlet處理完所有請求的數(shù)據(jù)后，需要將這些數(shù)據(jù)再編碼，通過Socket發(fā)送到用戶請求的瀏覽器里，再經(jīng)過瀏覽器解碼成文本。這個過程如圖：?
1 - URL的編碼解碼
? ? 瀏覽器編碼URL是將非ASCII字符按照某種編碼格式編碼成16進制數(shù)字后將每個16進制數(shù)字表示的字節(jié)前加上%。
? ? 用戶提交一個URL，在這個URL中可能存在中文，因此需要編碼，如圖為用戶提交的一個URL：
?
? ? 以Tomcat作為ServletEngine為例，把他們分別對應(yīng)到配置文件中，Port對應(yīng)在Tomcat->Server.xml的<Connector port="8080" />中配置，而ContextPath在context.xml的<context path="/examples">中配置，ServletPath在Web應(yīng)用的web.xml的<url-pattern>中配置，PathInfo是我們請求的具體的Servlet，QueryString是要傳遞的參數(shù)
? ? 注意這里是在瀏覽器里直接輸入URL，所以是通過Get方法請求的，如果通過Post方法請求QueryString將通過表單方式提交到服務(wù)器端
<servlet-mapping><servlet-name>junshangExample</servlet-name><url-pattern>/servlets/servlet/*</url-pattern> </servlet-mapping>????當我們在瀏覽器直接輸入這個URL時，在瀏覽器端和服務(wù)器端會如何編碼和解析這個URL呢
? ? 1）瀏覽器端編碼?
? ? 我們在fireFox瀏覽器上測試可以發(fā)現(xiàn)瀏覽器對PathInfo呵呵QueryString采用的編碼方式是不一樣的，在Chrome中PathInfo是采用UTF-8編碼，而QueryString則是GBK，不同瀏覽器對與PathInfo的編碼方式可能還不一樣，這就為服務(wù)端的解析帶來了困難。
? ? 2）服務(wù)器端解析
? ? 對于URL的URI部分進行解碼的字符集是在connector的<Connector URIEncoding="UTF-8" />中定義的，如果沒有定義，那么默認將會采用默認的編碼ISO-8859-1進行解析（ISO-8859-1不包含中文）。所以有中文URL的時候最好把URIEncoding設(shè)置成UTF-8編碼。
? ? 對于QueryString的解析過程：以Get方式HTTP請求的QueryString與以POST方式的HTTP請求的表單參數(shù)都是作為Parameters保存的，都是通過request.getParameter獲取參數(shù)值。對他們的解碼是在request.getParameter方法第一次被調(diào)用的時進行的。
? ? QueryString的編碼字符集要么是Header中ContentType定義的Charset，要么是默認的ISO-8859-1，要使用ContentType中定義的編碼，就要將connector的<Connector URIEncoding="UTF-8" useBodyEncodingForURI="True" />中的useBodyEncodingForURI設(shè)置為True。這個配置項容易使人產(chǎn)生混淆，他并不是對整個URI都采用BodyEncoding進行解碼，而僅僅是對QueryString使用BodyEncoding解碼這一點需要特別注意。
? ? 從上面URL編碼和解碼過程來看，比較復(fù)雜而且編碼和解碼不是在我們應(yīng)用程序中能完全控制的，在我們的應(yīng)用程序中，應(yīng)該盡量避免在URL中使用非ASCII字符，不然可能會遇到亂碼問題。當我們的服務(wù)器端最好設(shè)置<Connector />中的URIEncoding和useBodyEncodingForURI這兩個參數(shù)
2 - HTTP Header的編碼解碼
? ? 當客戶端發(fā)起一個HTTP請求的時候，除了URL之外還可能會在Header中傳遞其他的參數(shù)，例如Cookie、redirectPath等，這些用戶設(shè)置的值可能也會存在編碼的問題。Tomcat對于他們是怎么解碼的呢？
? ? 對于Header中的項進行解碼也是在調(diào)用request.getHeader時進行的。如果請求的Header項沒有解碼則調(diào)用MessageBytes的toString方法，這個方法對于從byte到char的轉(zhuǎn)化使用的默認編碼也是ISO-8859-1而我們也不能設(shè)置Header的其他編碼格式，所以如果你設(shè)置的Header中有非ASCII字符，解碼中肯定會有亂碼。
? ? 我們在添加Header時，如果一定要傳非ASCII字符，可以先將這些字符使用org.apache.catalina.util.URLEncoder編碼，再添加到Header中，這樣在瀏覽器到服務(wù)器的傳遞過程中就不會丟失信息了，我們要訪問這些項時在按照相應(yīng)的字符集解碼即可
?
3 - POST表單的編解碼
? ? POST表單提交的參數(shù)的解碼是在第一次調(diào)用request.getParameter時發(fā)生的，POST表單的參數(shù)傳遞方式與QueryString不同，它是通過HTTP的BODY傳遞到服務(wù)端的。
? ? 當我們在頁面上單擊提交按鈕時，瀏覽器首先將根據(jù)ContentType的Charset編碼格式對表單中填入的參數(shù)進行編碼，然后提交到服務(wù)器端，在服務(wù)器端同樣也是采用ContentType中的字符集進行解碼的，這個字符集我們也可以在服務(wù)端通過request.setCharacterEncoding(Charset)來進行設(shè)置。
????另外針對multipart/for-data類型的參數(shù)，也就是上傳的文件編碼，同樣也是使用ContentType定義的字符集編碼。注意，上傳文件是用字節(jié)流的方式傳遞到服務(wù)器的本地臨時目錄，這個過程并沒有涉及字符編碼，而真正的編碼是將文件內(nèi)容添加到Parameters中時，如果不能使用這種編碼方式則會使用默認編碼ISO-8859-1來編碼。
?
4 - HTTP Body的編碼與解碼
? ? 當用戶請求的資源已經(jīng)成功獲取后，這些內(nèi)容將會通過Response返回給客戶端瀏覽器。這個過程要先經(jīng)過編碼，再到瀏覽器進行解碼。編碼字符集可以通過response.setCharacterEncoding來設(shè)置，它將會覆蓋request.setCharacterEncoding的值，并且通過Header的Content-Type返回客戶端，瀏覽器接收到返回的Socket流時將通過Content-Type的charset來解碼
? ? 如果返回的HTTP Header中的Content-Type沒有設(shè)置charset，那么瀏覽器將根據(jù)HTML的<meta HTTP-equiv="Content-Type" content="text/html; charset=GBK" />中指定的charset來解碼。如果沒有定義，那么瀏覽器將使用默認的編碼來解碼。
? ? 訪問數(shù)據(jù)庫都是通過客戶端JDBC驅(qū)動來完成的，使用JDBC來存取數(shù)據(jù)時要和數(shù)據(jù)的內(nèi)置編碼保持一致，可以通過設(shè)置JDBC URL來指定，如MySQL：url=”jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK”
?
六、在JS中涉及的編碼解碼
?
1 - 外部引入JS文件
在一個單獨的JS文件中包含中文字符串輸入的情況，例如：
<html> <head> <script src="static/javascript/script.js" charset="gbk"></script>如果引入一個script.js腳本，這個腳本中含有如下代碼：
docuemnt.write("這是一段中文");這時如果script沒有設(shè)置charset，瀏覽器就會以當前這個頁面默認的字符集解析這個JS文件。如果外部的JS文件的編碼格式與當前頁面的編碼格式一致，那么就可以不設(shè)置這個charset。但是如果script.js文件與當前頁面的編碼格式不一致，如script.js是UTF-8編碼而頁面時GBK編碼，上面代碼中的中文輸入就會變成亂碼。
?
2 - JS的URL編碼
? ? 通過JS發(fā)起異步調(diào)用的URL默認的編碼也是受瀏覽器的影響，如果使用原始Ajax的http_request.open('GET',url,true)調(diào)用，URL的默認編碼在IE是操作系統(tǒng)的默認編碼而在Firefox下則是UTF-8編碼，另外不同的JS框架可能對于URL的編碼處理也不一樣。
? ? 處理JS的URL編碼問題：
1）encodeURI()與decodeURI()
JS用來對URL編碼的函數(shù)，他可以將整個URL中的字符（一些特殊字符除外）進行UTF-8編碼，在每個碼值前加上"%"。
2）encodeURIComponent()和decodeURIComponent()
? ? encodeURIComponent()這個函數(shù)比encodeURI()編碼更為徹底。通常用于將一個URL當做一個參數(shù)放在另一個URL中
3）Java與JS的編碼解碼問題。在Java端處理URL編碼解碼的有兩個類，分別是java.net.URLDecoder和java.net.URLEncoder。這兩個類可以將所有“%”加UTF-8碼值使用UTF-8解碼，從而得到原始的字符。Java端的URLEncode和URLDecoder與前端JS對應(yīng)的是encodeURIComponent和decodeURIComponent。
????注意：前端用encodeURIComponent編碼后，到服務(wù)端用URLDecoder解碼可能會出現(xiàn)亂碼，這一定是兩個字符編碼類型不一致導(dǎo)致的。JS編碼默認的是UTF-8編碼，而服務(wù)器中文解碼一段都是GBK或者GB2312，所以用encodeURIComponent編碼后是UTF-8，而java用GBK去解碼顯然不對。
????解決的辦法是用encodeURIComponent兩次編碼，如encodeURIComponent(encodeURIComponent(str))。這樣在Java端通過request.getParamter()用GBK解碼后取得的就是UTF-8編碼的字符串，如果Java端需要使用這個字符串，則再用UTF-8解碼一次；如果是將這個結(jié)果直接通過JS輸出到前端，那么這個UTF-8字符串可以直接在前端正常顯示。
?
七、常見問題的分析
? ? 基于前面的了解的Java web編碼解碼知識之后我們知道出現(xiàn)亂碼問題唯一的原因就是在編碼解碼過程中采用的字符集不一致導(dǎo)致的，因為在一次操作中經(jīng)常涉及多次編碼和解碼，因此出現(xiàn)亂碼問題的時候也給我們排查帶來的難度，下面分析幾種常見的情景：
1 - 中文變成看不懂的字符
? ? 例如，字符串“淘！我喜歡！”變成了“ì ? ￡ ?? ò ?2?? ￡ ?”編碼過程如下圖所示?
????字符串在解碼時所用的字符集與編碼字符集不一致導(dǎo)致漢字變成了看不懂的亂碼，而且是一個漢字字符變成兩個亂碼字符。這種情景在開發(fā)中經(jīng)常發(fā)生，例如在瀏覽器中輸入一個帶有中文字符串參數(shù)的URL一些瀏覽器默認對QueryString采用的是GBK編碼方式，但是由于在web中間件例如tomcat沒有做相關(guān)配置，在服務(wù)端讀取請求參數(shù)時也沒有指定編碼方式，于是默認使用ISO-8859-1進行解碼導(dǎo)致亂碼。這種出現(xiàn)亂碼且亂碼字符串長度是原編碼前字符串的兩倍的原因可能是采用2字節(jié)編碼例如GBK、UTF-16等然后使用單字節(jié)進行解碼例如ISO-8859-1導(dǎo)致的
?
2 - 一個漢字變成一個問號
例如，字符串“淘！我喜歡！”變成了“？？？？？？”編碼過程如下圖所示?
?
????將中文和中文符號經(jīng)過不支持中文的 ISO-8859-1 編碼后，所有字符變成了“？”，這是因為用 ISO-8859-1 進行編解碼時遇到不在碼值范圍內(nèi)的字符時統(tǒng)一用 3f 表示，這也就是通常所說的“黑洞”，所有 ISO-8859-1 不認識的字符都變成了“？”。
?
3 -?一個漢字變成兩個問號
例如，字符串“淘！我喜歡！”變成了“？？？？？？？？？？？？”編碼過程如下圖所示?
?
????這種情況比較復(fù)雜，中文經(jīng)過多次編碼，但是其中有一次編碼或者解碼不對仍然會出現(xiàn)中文字符變成“？”現(xiàn)象，出現(xiàn)這種情況要仔細查看中間的編碼環(huán)節(jié)，找出出現(xiàn)編碼錯誤的地方。
?
4 - 一種不正常的正確編碼解碼
還有一種情況是在我們通過 request.getParameter 獲取參數(shù)值時，當我們直接調(diào)用下面代碼會出現(xiàn)亂碼
String value = request.getParameter(name);但是如果用下面的方式解析時取得的 value 會是正確的漢字字符
String value = new String(request.getParameter(name).getBytes("ISO-8859-1"), "GBK");這種情況是怎么造成的呢？看下圖：?
????這種情況是這樣的，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 來解析才造成亂碼的。
?
八、Java Web編碼解碼問題總結(jié)
????要解決中文編碼問題，首先要搞清楚哪些地方會引起字符到字節(jié)的編碼以及字節(jié)到字符的解碼，最常見的地方就是存儲數(shù)據(jù)到磁盤或者數(shù)據(jù)要經(jīng)過網(wǎng)絡(luò)傳輸。其次應(yīng)針對這些地方搞清楚操作這些數(shù)據(jù)的框架或系統(tǒng)是如何控制編碼的。最后正確設(shè)置編碼格式，避免使用軟件默認的或者操作系統(tǒng)平臺默認的編碼格式。
總結(jié)
以上是生活随笔為你收集整理的Java Web中的中文编码问题分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 机器学习流行算法一览
- 下一篇： Java 中的位移运算符