編碼簡介
常見的一些字符編碼方式無非有:Unicode、ASCII、GBK、GB2312、UTF-8。下面先對常見的這一些字符編碼方式作下說明:
1.ASCII碼
這是美國在19世紀60年代的時候爲了建立英文字符和二進制的關係時制定的編碼規範,它能表示128個字符,其中包括英文字符、阿拉伯數字、西文字符以及32個控制字符。它用一個字節來表示具體的字符,但它只用後7位來表示字符(2^7=128),最前面的一位統一規定爲0。
2.擴展的ASCII碼
原本的ASCII碼對於英文語言的國家是夠用了,但是歐洲國家的一些語言會有拼音,這時7個字節就不夠用了。因此一些歐洲國家就決定,利用字節中閒置的最高位編入新的符號。比如,法語中的é的編碼爲130(二進制10000010)。這樣一來,這些歐洲國家使 用的編碼體系,可以表示最多256個符號。但這時問題也出現了:不同的國家有不同的字母,因此,哪怕它們都使用256個符號的編碼方式,代表的字母卻不一樣。比如,130在法語編碼 中代表了é,在希伯來語編碼中卻代表了字母Gimel (ג),在俄語編碼中又會代表另一個符號。但是不管怎樣,所有這些編碼方式中,0—127表示的符號是一樣的,不一樣的只是128—255的這一段。這個問題就直接促使了Unicode編碼的產生。
3.Unicode符號集
正如上一節所說,世界上存在着多種編碼方式,同一個二進制數字可以被解釋成不同的符號。因此,要想打開一個文本文件,就必須知道它的編碼方式,否則用錯誤的編碼方式解讀,就會出現亂碼。爲什麼電子郵件常常出現亂碼?就是因爲發信人和收信人使用的編碼方式不一樣。而Unicode就是這樣一種編碼:它包含了世界上所有的符號,並且每一個符號都是獨一無二的。比如,U+0639表示阿拉伯字母Ain,U+0041表示英語的大寫字母A,U+4E25表示漢字“嚴”。具體的符號對應表,可以查詢unicode.org,或者專門的漢字對應表 。很多人都說Unicode編碼,但其實Unicode是一個符號集(世界上所有符號的符號集),而不是一種新的編碼方式。
但是正因爲Unicode包含了所有的字符,而有些國家的字符用一個字節便可以表示,而有些國家的字符要用多個字節才能表示出來。即產生了兩個問題:第一,如果有兩個字節的數據,那計算機怎麼知道這兩個字節是表示一個漢字呢?還是表示兩個英文字母呢?第二,因爲不同字符需要的存儲長度不一樣,那麼如果Unicode規定用2個字節存儲字符,那麼英文字符存儲時前面1個字節都是0,這就大大浪費了存儲空間。
上面兩個問題造成的結果是:1)出現了unicode的多種存儲方式,也就是說有許多種不同的二進制格式,可以用來表示unicode。2)unicode在很長一段時間內無法推廣,直到互聯網的出現。
4.UTF-8
互聯網的普及,強烈要求出現一種統一的編碼方式。UTF-8就是在互聯網上使用最廣的一種unicode的實現方式。其他實現方式還包括UTF-16和UTF-32,不過在互聯網上基本不用。重複一遍,這裏的關係是,UTF-8是Unicode的實現方式之一。
UTF-8最大的一個特點,就是它是一種變長的編碼方式。它可以使用1~4個字節表示一個符號,根據不同的符號而變化字節長度。
UTF-8的編碼規則很簡單,只有兩條:
1)對於單字節的符號,字節的第一位設爲0,後面7位爲這個符號的unicode碼。因此對於英語字母,UTF-8編碼和ASCII碼是相同的。
2)對於n字節的符號(n>1),第一個字節的前n位都設爲1,第n+1位設爲0,後面字節的前兩位一律設爲10。剩下的沒有提及的二進制位,全部爲這個符號的unicode碼。
5.GBK/GB2312/GB18030
GBK和GB2312都是針對簡體字的編碼,只是GB2312只支持六千多個漢字的編碼,而GBK支持1萬多個漢字編碼。而GB18030是用於繁體字的編碼。漢字存儲時都使用兩個字節來儲存。
總的來說:
ASCII編碼:用來表示英文,它使用1個字節表示,其中第一位規定爲0,其他7位存儲數據,一共可以表示128個字符。
拓展ASCII編碼:用於表示更多的歐洲文字,用8個位存儲數據,一共可以表示256個字符
GBK/GB2312/GB18030:表示漢字。GBK/GB2312表示簡體中文,GB18030表示繁體中文。
Unicode編碼:包含世界上所有的字符,是一個字符集。
UTF-8:是Unicode字符的實現方式之一,它使用1-4個字符表示一個符號,根據不同的符號而變化字節長度。
*如果你想了解更多關於編碼的信息,推薦閱讀:字符編碼方式 (空閒時請再繼續研讀一下這篇文章)
*相關閱讀:判定文件編碼或文本流編碼的方式(Java實現)
常見編碼的具體介紹
1. ASCII碼
我們知道,在計算機內部,所有的信息最終都表示爲一個二進制的字符串。每一個二進制位(bit)有0和1兩種狀態,因此八個二進制位就可以組合出256種狀態,這被稱爲一個字節(byte)。也就是說,一個字節一共可以用來表示256種不同的狀態,每一個狀態對應一個符號,就是256個符號,從0000000到11111111。
上個世紀60年代,美國製定了一套字符編碼,對英語字符與二進制位之間的關係,做了統一規定。這被稱爲ASCII碼,一直沿用至今。
ASCII碼一共規定了128個字符的編碼,比如空格"SPACE"是32(二進制00100000),大寫的字母A是65(二進制01000001)。這128個符號(包括32個不能打印出來的控制符號),只佔用了一個字節的後面7位,最前面的1位統一規定爲0。
2、非ASCII編碼
英語用128個符號編碼就夠了,但是用來表示其他語言,128個符號是不夠的。比如,在法語中,字母上方有注音符號,它就無法用ASCII碼錶示。於是,一些歐洲國家就決定,利用字節中閒置的最高位編入新的符號。比如,法語中的é的編碼爲130(二進制10000010)。這樣一來,這些歐洲國家使用的編碼體系,可以表示最多256個符號。
但是,這裏又出現了新的問題。不同的國家有不同的字母,因此,哪怕它們都使用256個符號的編碼方式,代表的字母卻不一樣。比如,130在法語編碼中代表了é,在希伯來語編碼中卻代表了字母Gimel (ג),在俄語編碼中又會代表另一個符號。但是不管怎樣,所有這些編碼方式中,0--127表示的符號是一樣的,不一樣的只是128--255的這一段。
至於亞洲國家的文字,使用的符號就更多了,漢字就多達10萬左右。一個字節只能表示256種符號,肯定是不夠的,就必須使用多個字節表達一個符號。比如,簡體中文常見的編碼方式是GB2312,使用兩個字節表示一個漢字,所以理論上最多可以表示256x256=65536個符號。
中文編碼的問題需要專文討論,這篇筆記不涉及。這裏只指出,雖然都是用多個字節表示一個符號,但是GB類的漢字編碼與後文的Unicode和UTF-8是毫無關係的。
3.Unicode
正如上一節所說,世界上存在着多種編碼方式,同一個二進制數字可以被解釋成不同的符號。因此,要想打開一個文本文件,就必須知道它的編碼方式,否則用錯誤的編碼方式解讀,就會出現亂碼。爲什麼電子郵件常常出現亂碼?就是因爲發信人和收信人使用的編碼方式不一樣。
可以想象,如果有一種編碼,將世界上所有的符號都納入其中。每一個符號都給予一個獨一無二的編碼,那麼亂碼問題就會消失。這就是Unicode,就像它的名字都表示的,這是一種所有符號的編碼。
Unicode當然是一個很大的集合,現在的規模可以容納100多萬個符號。每個符號的編碼都不一樣,比如,U+0639表示阿拉伯字母Ain,U+0041表示英語的大寫字母A,U+4E25表示漢字"嚴"。具體的符號對應表,可以查詢unicode.org,或者專門的漢字對應表。
4. Unicode的問題
需要注意的是,Unicode只是一個符號集,它只規定了符號的二進制代碼,卻沒有規定這個二進制代碼應該如何存儲。
比如,漢字"嚴"的unicode是十六進制數4E25,轉換成二進制數足足有15位(100111000100101),也就是說這個符號的表示至少需要2個字節。表示其他更大的符號,可能需要3個字節或者4個字節,甚至更多。
這裏就有兩個嚴重的問題,第一個問題是,如何才能區別Unicode和ASCII?計算機怎麼知道三個字節表示一個符號,而不是分別表示三個符號呢?第二個問題是,我們已經知道,英文字母只用一個字節表示就夠了,如果Unicode統一規定,每個符號用三個或四個字節表示,那麼每個英文字母前都必然有二到三個字節是0,這對於存儲來說是極大的浪費,文本文件的大小會因此大出二三倍,這是無法接受的。
它們造成的結果是:1)出現了Unicode的多種存儲方式,也就是說有許多種不同的二進制格式,可以用來表示Unicode。2)Unicode在很長一段時間內無法推廣,直到互聯網的出現。
5.UTF-8
互聯網的普及,強烈要求出現一種統一的編碼方式。UTF-8就是在互聯網上使用最廣的一種Unicode的實現方式。其他實現方式還包括UTF-16(字符用兩個字節或四個字節表示)和UTF-32(字符用四個字節表示),不過在互聯網上基本不用。重複一遍,這裏的關係是,UTF-8是Unicode的實現方式之一。
UTF-8最大的一個特點,就是它是一種變長的編碼方式。它可以使用1~4個字節表示一個符號,根據不同的符號而變化字節長度。
UTF-8的編碼規則很簡單,只有二條:
1)對於單字節的符號,字節的第一位設爲0,後面7位爲這個符號的unicode碼。因此對於英語字母,UTF-8編碼和ASCII碼是相同的。
2)對於n字節的符號(n>1),第一個字節的前n位都設爲1,第n+1位設爲0,後面字節的前兩位一律設爲10。剩下的沒有提及的二進制位,全部爲這個符號的unicode碼。
下表總結了編碼規則,字母x表示可用編碼的位。
Unicode符號範圍 | UTF-8編碼方式
(十六進制) | (二進制)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
跟據上表,解讀UTF-8編碼非常簡單。如果一個字節的第一位是0,則這個字節單獨就是一個字符;如果第一位是1,則連續有多少個1,就表示當前字符佔用多少個字節。
下面,還是以漢字"嚴"爲例,演示如何實現UTF-8編碼。
已知"嚴"的unicode是4E25(100111000100101),根據上表,可以發現4E25處在第三行的範圍內(0000 0800-0000 FFFF),因此"嚴"的UTF-8編碼需要三個字節,即格式是"1110xxxx 10xxxxxx 10xxxxxx"。然後,從"嚴"的最後一個二進制位開始,依次從後向前填入格式中的x,多出的位補0。這樣就得到了,"嚴"的UTF-8編碼是"11100100 10111000 10100101",轉換成十六進制就是E4B8A5。
6. Unicode與UTF-8之間的轉換
通過上一節的例子,可以看到"嚴"的Unicode碼是4E25,UTF-8編碼是E4B8A5,兩者是不一樣的。它們之間的轉換可以通過程序實現。
在Windows平臺下,有一個最簡單的轉化方法,就是使用內置的記事本小程序Notepad.exe。打開文件後,點擊"文件"菜單中的"另存爲"命令,會跳出一個對話框,在最底部有一個"編碼"的下拉條。
裏面有四個選項:ANSI,Unicode,Unicode big endian 和 UTF-8。
1)ANSI是默認的編碼方式。對於英文文件是ASCII編碼,對於簡體中文文件是GB2312編碼(只針對Windows簡體中文版,如果是繁體中文版會採用Big5碼)。
2)Unicode編碼指的是UCS-2編碼方式,即直接用兩個字節存入字符的Unicode碼。這個選項用的little endian格式。
3)Unicode big endian編碼與上一個選項相對應。我在下一節會解釋little endian和big endian的涵義。
4)UTF-8編碼,也就是上一節談到的編碼方法。
選擇完"編碼方式"後,點擊"保存"按鈕,文件的編碼方式就立刻轉換好了。
7. Little endian和Big endian
上一節已經提到,Unicode碼可以採用UCS-2格式直接存儲。以漢字"嚴"爲例,Unicode碼是4E25,需要用兩個字節存儲,一個字節是4E,另一個字節是25。存儲的時候,4E在前,25在後,就是Big endian方式;25在前,4E在後,就是Little endian方式。
這兩個古怪的名稱來自英國作家斯威夫特的《格列佛遊記》。在該書中,小人國裏爆發了內戰,戰爭起因是人們爭論,吃雞蛋時究竟是從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開。爲了這件事情,前後爆發了六次戰爭,一個皇帝送了命,另一個皇帝丟了王位。
因此,第一個字節在前,就是"大頭方式"(Big endian),第二個字節在前就是"小頭方式"(Little endian)。
那麼很自然的,就會出現一個問題:計算機怎麼知道某一個文件到底採用哪一種方式編碼?
Unicode規範中定義,每一個文件的最前面分別加入一個表示編碼順序的字符,這個字符的名字叫做"零寬度非換行空格"(ZERO WIDTH NO-BREAK SPACE),用FEFF表示。這正好是兩個字節,而且FF比FE大1。
如果一個文本文件的頭兩個字節是FE FF,就表示該文件採用大頭方式;如果頭兩個字節是FF FE,就表示該文件採用小頭方式。
8. 實例
下面,舉一個實例。
打開"記事本"程序Notepad.exe,新建一個文本文件,內容就是一個"嚴"字,依次採用ANSI,Unicode,Unicode big endian 和 UTF-8編碼方式保存。
然後,用文本編輯軟件UltraEdit中的"十六進制功能",觀察該文件的內部編碼方式。
1)ANSI:文件的編碼就是兩個字節"D1 CF",這正是"嚴"的GB2312編碼,這也暗示GB2312是採用大頭方式存儲的。
2)Unicode:編碼是四個字節"FF FE 25 4E",其中"FF FE"表明是小頭方式存儲,真正的編碼是4E25。
3)Unicode big endian:編碼是四個字節"FE FF 4E 25",其中"FE FF"表明是大頭方式存儲。
4)UTF-8:編碼是六個字節"EF BB BF E4 B8 A5",前三個字節"EF BB BF"表示這是UTF-8編碼,後三個"E4B8A5"就是"嚴"的具體編碼,它的存儲順序與編碼順序是一致的。
9. 延伸閱讀
* The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets(關於字符集的最基本知識)
* RFC3629:UTF-8, a transformation format of ISO 10646(如果實現UTF-8的規定)
判斷文件編碼
在程序中,文本文件經常用來存儲標準的ASCII碼文本,比如英文、加減乘除等號這些運算符號。文本文件也可能用於存儲一些其他非ASCII字符,如基於GBK的簡體中文,基於GIG5的繁體中文等等。在存儲這些字符時需要正確指定文件的編碼格式;而在讀取這些文本文件時,有時候就需要自動判定文件的編碼格式。
按照給定的字符集存儲文本文件時,在文件的最開頭的三個字節中就有可能存儲着編碼信息,所以,基本的原理就是隻要讀出文件前三個字節,判定這些字節的值,就可以得知其編碼的格式。其實,如果項目運行的平臺就是中文操作系統,如果這些文本文件在項目內產生,即開發人員可以控制文本的編碼格式,只要判定兩種常見的編碼就可以了:GBK和UTF-8。由於中文Windows默認的編碼是GBK,所以一般只要判定UTF-8編碼格式。
對於UTF-8編碼格式的文本文件,其前3個字節的值就是-17、-69、-65,所以,判定是否是UTF-8編碼格式的代碼片段如下:
- java.io.File f=new java.io.File("待判定的文本文件名");
- try{
- java.io.InputStream ios=new java.io.FileInputStream(f);
- byte[] b=new byte[3];
- ios.read(b);
- ios.close();
- if(b[0]==-17&&b[1]==-69&&b[2]==-65)
- System.out.println(f.getName()+"編碼爲UTF-8");
- else System.out.println(f.getName()+"可能是GBK");
- }catch(Exception e){
- e.printStackTrace();
- }
上述代碼只是簡單判定了是否是UTF-8格式編碼的文本文件,如果項目對要判定的文本文件編碼不可控(比如用戶上傳的一些HTML、XML等文本),可以採用一個現成的開源項目:cpdetector,它所在的網址是:http://cpdetector.sourceforge.net/。它的類庫很小,只有500K左右,利用該類庫判定文本文件的代碼如下:
- /*------------------------------------------------------------------------
- detector是探測器,它把探測任務交給具體的探測實現類的實例完成。
- cpDetector內置了一些常用的探測實現類,這些探測實現類的實例可以通過add方法
- 加進來,如ParsingDetector、 JChardetFacade、ASCIIDetector、UnicodeDetector。
- detector按照“誰最先返回非空的探測結果,就以該結果爲準”的原則返回探測到的
- 字符集編碼。
- --------------------------------------------------------------------------*/
- cpdetector.io.CodepageDetectorProxy detector =
- cpdetector.io.CodepageDetectorProxy.getInstance();
- /*-------------------------------------------------------------------------
- ParsingDetector可用於檢查HTML、XML等文件或字符流的編碼,構造方法中的參數用於
- 指示是否顯示探測過程的詳細信息,爲false不顯示。
- ---------------------------------------------------------------------------*/
- detector.add(new cpdetector.io.ParsingDetector(false));
- /*--------------------------------------------------------------------------
- JChardetFacade封裝了由Mozilla組織提供的JChardet,它可以完成大多數文件的編碼
- 測定。所以,一般有了這個探測器就可滿足大多數項目的要求,如果你還不放心,可以
- 再多加幾個探測器,比如下面的ASCIIDetector、UnicodeDetector等。
- ---------------------------------------------------------------------------*/
- detector.add(cpdetector.io.JChardetFacade.getInstance());
- //ASCIIDetector用於ASCII編碼測定
- detector.add(cpdetector.io.ASCIIDetector.getInstance());
- //UnicodeDetector用於Unicode家族編碼的測定
- detector.add(cpdetector.io.UnicodeDetector.getInstance());
- java.nio.charset.Charset charset = null;
- File f=new File("待測的文本文件名");
- try {
- charset = detector.detectCodepage(f.toURL());
- } catch (Exception ex) {ex.printStackTrace();}
- if(charset!=null){
- System.out.println(f.getName()+"編碼是:"+charset.name());
- }else
- System.out.println(f.getName()+"未知");
上面代碼中的detector不僅可以用於探測文件的編碼,也可以探測任意輸入的文本流的編碼,方法是調用其重載形式:
- charset=detector.detectCodepage(待測的文本輸入流,測量該流所需的讀入字節數);
上面的字節數由程序員指定,字節數越多,判定越準確,當然時間也花得越長。要注意,字節數的指定不能超過文本流的最大長度。
判定文件編碼的具體應用舉例:
屬性文件(.properties)是Java程序中的常用文本存儲方式,象STRUTS框架就是利用屬性文件存儲程序中的字符串資源。它的內容如下所示:
- #註釋語句
- 屬性名=屬性值
讀入屬性文件的一般方法是:
- FileInputStream ios=new FileInputStream("屬性文件名");
- Properties prop=new Properties();
- prop.load(ios);
- ios.close();
利用java.io.Properties的load方法讀入屬性文件雖然方便,但如果屬性文件中有中文,在讀入之後就會發現出現亂碼現象。發生這個原因是load方法使用字節流讀入文本,在讀入後需要將字節流編碼成爲字符串,而它使用的編碼是“iso-8859-1”,這個字符集是ASCII碼字符集,不支持中文編碼,所以這時需要使用顯式的轉碼:
- String value=prop.getProperty("屬性名");
- String encValue=new String(value.getBytes("iso-8859-1"),"屬性文件的實際編碼");
在上面的代碼中,屬性文件的實際編碼就可以利用上面的方法獲得。當然,象這種屬性文件是項目內部的,我們可以控制屬性文件的編碼格式,比如約定採用Windows內定的GBK,就直接利用"gbk"來轉碼,如果約定採用UTF-8,也可以是使用"UTF-8"直接轉碼。如果想靈活一些,做到自動探測編碼,就可利用上面介紹的方法測定屬性文件的編碼,從而方便開發人員的工作。