Java字符編碼原理

1、Java 字符編碼原理Java 開發(fā)中,常常會遇到亂碼的問題,一旦遇到這種問題,常常比較煩惱,大家都不愿意承認是自己的代碼有問題。其 實編碼問題并沒有那么神秘,那么不可捉摸,搞清 Java 的編碼本質(zhì)過程就真相大白了。先看個圖:其實,編碼問題存在兩個方面:JVM 之內(nèi)和 JVM 之外。1、 Java 文件編譯后形成 class這里 Java 文件的編碼可能有多種多樣, 但 Java 編譯器會自動將這些編碼按照 Java 文件的編碼格式正確讀取后產(chǎn)生 class 文件,這里的 class 文件編碼是 Unicode 編碼(具體說是 UTF-16編碼。因此,在 Java 代碼中定義一個字符串:St

2、ring s="漢字 "不管在編譯前 java 文件使用何種編碼,在編譯后成 class 后,他們都是一樣的 -Unicode 編碼表示。1 / 3 2、 JVM 中的編碼JVM 加載 class 文件讀取時候使用 Unicode 編碼方式正確讀取 class 文件, 那么原來定義的 String s="漢字 " 在內(nèi)存中 的表現(xiàn)形式是 Unicode 編碼。當調(diào)用 String.getBytes(的時候, 其實已經(jīng)為亂碼買下了禍根。 因為此方法使用平臺默認的字符集來獲取字符串對應的 字節(jié)數(shù)組。在 WindowsXP 中文版中,使用的默認編碼是 GBK

3、,不信運行下:public class Test public static void main(String args System.out.println(" 當前 JRE :" + System.getProperty("java.version" ;System.out.println(" 當前 JVM 的默認字符集:" + Charset.defaultCharset(;當前 JRE :1.8.0_16當前 JVM 的默認字符集:GBK當不同的系統(tǒng)、數(shù)據(jù)庫經(jīng)過多次編碼后,如果對其中的原理不理解,就容易導致亂碼。因此,在一個系

4、統(tǒng)中,有必要對 字符串的編碼做一個統(tǒng)一,這個統(tǒng)一模糊點說,就是對外統(tǒng)一。比如方法字符串參數(shù), IO 流,在中文系統(tǒng)中,可以統(tǒng)一使用 GBK 、 GB13080、 UTF-8、 UTF-16等等都可以,只是要選擇有些更大字符集,以保證任何可能用到的字符都可以正常顯示, 避免亂碼的問題。(假設對所有的文件都用 ASCII 碼那么就無法實現(xiàn)雙向轉(zhuǎn)換了。要特別注意的是, UTF-8并非能容納了所有的中文字符集編碼,因此,在特殊情況下, UTF-8轉(zhuǎn) GB18030可能會出現(xiàn) 亂碼, 然而一群傻 B 常常在做中文系統(tǒng)喜歡用 UTF-8編碼而不說不出個所以然出來! 最傻 B 的是, 一個系統(tǒng)多個人做, 源

5、代 碼文件有的人用 GBK 編碼,有人用 UTF-8,還有人用 GB18030。 FK ,都是中國人,也不是外包項目,用什么 UTF-8啊, 神經(jīng)!源代碼統(tǒng)統(tǒng)都用 GBK18030就 OK 了,免得 ANT 腳本編譯時候提示不可認的字符編碼。因此,對于中文系統(tǒng)來說,最好選擇 GBK 或 GB18030編碼(其實 GBK 是 GB18030的子集,以便最大限度的避免 亂碼現(xiàn)象。3、內(nèi)存中字符串的編碼內(nèi)存中的字符串不僅僅局限于從 class 代碼中直接加載而來的字符串,還有一些字符串是從文本文件中讀取的,還有的 是通過數(shù)據(jù)庫讀取的,還有可能是從字節(jié)數(shù)組構(gòu)建的,然而他們基本上都不是 Unicode 編碼的,原因很簡單,存儲優(yōu)化。2 / 3因此就需要處理各種各樣的編碼問題, 在處理之前, 必須明確 “源” 的編碼, 然后用指定的編碼方式正確讀取到內(nèi)存中。 如果是一個方法的參數(shù),實際上必須明確該字符串參數(shù)的編碼,因為這個參數(shù)可能是另外一個日文系統(tǒng)傳遞過來的。當明確 了字符串編碼時候,就可以按照要求正確處理字符串,以避免亂碼。在對字符串進行解碼編碼的時候,應該調(diào)用下面的方法:getBytes(String charsetNameString(byte b