字符集與編碼

很久很久以前,有一羣人,他們決定用8個可以開合的晶體管來組合成不同的狀態,以表示世界上的萬物。他們看到8個開關狀態是好的,於是他們把這稱爲"字節"。

 再後來,他們又做了一些可以處理這些字節的機器,機器開動了,可以用字節來組合出很多狀態,狀態開始變來變去。他們看到這樣是好的,於是它們就這機器稱爲"計算機"。

 開始,計算機只在美國用。八位的字節一共可以組合出256(2的8次方)種不同的狀態。

 他們把其中的編號從0開始的32種狀態分別規定了特殊的用途,一旦終端、打印機遇上約定好的這些字節被傳過來時,就要做一些約定的動作。遇上 00x10, 終端就換行,遇上0x07, 終端就向人們嘟嘟叫,例如遇上0x1b, 打印機就打印反白的字,或者終端就用彩色顯示字母。他們看到這樣很好,於是就把這些0x20以下的字節狀態稱爲"控制碼"。

 他們又把所有的空格、標點符號、數字、大小寫字母分別用連續的字節狀態表示,一直編到了第127號,這樣計算機就可以用不同字節來存儲英語的文字了。大家看到這樣,都感覺很好,於是大家都把這個方案叫做 ANSI 的"ASCII"編碼(American Standard Code for Information Interchange,美國信息互換標準代碼)。當時世界上所有的計算機都用同樣的ASCII方案來保存英文文字。

 後來,就像建造巴比倫塔一樣,世界各地的都開始使用計算機,但是很多國家用的不是英文,他們的字母裏有許多是ASCII裏沒有的,爲了可以在計算機保存他們的文字,他們決定採用127號之後的空位來表示這些新的字母、符號,還加入了很多畫表格時需要用到的橫線、豎線、交叉等形狀,一直把序號編到了最後一個狀態255。從128到255這一頁的字符集被稱"擴展字符集"。從此之後,貪婪的人類再沒有新的狀態可以用了,美帝國主義可能沒有想到還有第三世界國家的人們也希望可以用到計算機吧!

 等中國人們得到計算機時,已經沒有可以利用的字節狀態來表示漢字,況且有6000多個常用漢字需要保存呢。但是這難不倒智慧的中國人民,我們不客氣地把那些127號之後的奇異符號們直接取消掉, 規定:一個小於127的字符的意義與原來相同,但兩個大於127的字符連在一起時,就表示一個漢字,前面的一個字節(他稱之爲高字節)從0xA1用到 0xF7,後面一個字節(低字節)從0xA1到0xFE,這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裏,我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了,連在 ASCII 裏本來就有的數字、標點、字母都統統重新編了兩個字節長的編碼,這就是常說的"全角"字符,而原來在127號以下的那些就叫"半角"字符了。

 中國人民看到這樣很不錯,於是就把這種漢字方案叫做 "GB2312"。GB2312 是對 ASCII 的中文擴展。

 但是中國的漢字太多了,我們很快就發現有許多人的人名沒有辦法在這裏打出來,特別是某些很會麻煩別人的國家領導人。於是我們不得不繼續把 GB2312 沒有用到的碼位找出來老實不客氣地用上。

 後來還是不夠用,於是乾脆不再要求低字節一定是127號之後的內碼,只要第一個字節是大於127就固定表示這是一個漢字的開始,不管後面跟的是不是擴展字符集裏的內容。結果擴展之後的編碼方案被稱爲 GBK 標準,GBK 包括了 GB2312 的所有內容,同時又增加了近20000個新的漢字(包括繁體字)和符號。

 後來少數民族也要用電腦了,於是我們再擴展,又加了幾千個新的少數民族的字,GBK 擴成了 GB18030。從此之後,中華民族的文化就可以在計算機時代中傳承了。

 中國的程序員們看到這一系列漢字編碼的標準是好的,於是通稱他們叫做 "DBCS"(Double Byte Charecter Set 雙字節字符集)。在DBCS系列標準裏,最大的特點是兩字節長的漢字字符和一字節長的英文字符並存於同一套編碼方案裏,因此他們寫的程序爲了支持中文處理,必須要注意字串裏的每一個字節的值,如果這個值是大於127的,那麼就認爲是一個雙字節字符集裏的字符出現了。那時候凡是會編程的計算機僧侶們都要每天念下面這個咒語數百遍:

 "一個漢字算兩個英文字符!一個漢字算兩個英文字符......"

 因爲當時各個國家都像中國這樣搞出一套自己的編碼標準,結果互相之間誰也不懂誰的編碼,誰也不支持別人的編碼,連大陸和臺灣這樣只相隔了150海里,使用着同一種語言的兄弟地區,也分別採用了不同的 DBCS 編碼方案。當時的中國人想讓電腦顯示漢字,就必須裝上一個"漢字系統",專門用來處理漢字的顯示、輸入的問題,但是那個臺灣的愚昧封建人士寫的算命程序就必須加裝另一套支持 BIG5 編碼的什麼"倚天漢字系統"纔可以用,裝錯了字符系統,顯示就會亂了套!這怎麼辦?而且世界民族之林中還有那些一時用不上電腦的窮苦人民,他們的文字又怎麼辦?

 真是計算機的巴比倫塔命題啊!

 正在這時,大天使加百列及時出現了:一個叫 ISO (國際標誰化組織)的國際組織決定着手解決這個問題。他們採用的方法很簡單:廢了所有的地區性編碼方案,重新搞一個包括了地球上所有文化、所有字母和符號的編碼!他們打算叫它"Universal Multiple-Octet Coded Character Set",簡稱 UCS, 俗稱 "UNICODE"。

 UNICODE 開始制訂時,計算機的存儲器容量極大地發展了,空間再也不成爲問題了。於是 ISO 就直接規定必須用兩個字節,也就是16位來統一表示所有的字符,對於ASCII裏的那些"半角"字符,UNICODE 包持其原編碼不變,只是將其長度由原來的8位擴展爲16位,而其他文化和語言的字符則全部重新統一編碼。由於"半角"英文符號只需要用到低8位,所以其高 8位永遠是0,因此這種大氣的方案在保存英文文本時會多浪費一倍的空間。

 這時候,從舊社會裏走過來的程序員開始發現一個奇怪的現象:他們的strlen函數靠不住了,一個漢字不再是相當於兩個字符了,而是一個!是的,從 UNICODE 開始,無論是半角的英文字母,還是全角的漢字,它們都是統一的"一個字符"!同時,也都是統一的"兩個字節"。請注意"字符"和"字節"兩個術語的不同,"字節"是一個8位的物理存貯單元,而"字符"則是一個文化相關的符號。在UNICODE 中,一個字符就是兩個字節。一個漢字算兩個英文字符的時代已經快過去了。

 從前多種字符集存在時,那些做多語言軟件的公司遇上過很大麻煩,他們爲了在不同的國家銷售同一套軟件,就不得不在區域化軟件時也加持那個雙字節字符集咒語,不僅要處處小心不要搞錯,還要把軟件中的文字在不同的字符集中轉來轉去。UNICODE 對於他們來說是一個很好的一攬子解決方案,於是從 Windows NT 開始,MS 趁機把它們的操作系統改了一遍,把所有的核心代碼都改成了用 UNICODE 方式工作的版本,從這時開始,WINDOWS 系統終於無需加裝各種本土語言系統,就可以顯示全世界上所有文化的字符了。

 但是,UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持兼容,這使得 GBK 與UNICODE 在漢字的內碼編排上完全是不一樣的,沒有一種簡單的算術方法可以把文本內容從UNICODE編碼和另一種編碼進行轉換,這種轉換必須通過查表來進行。

 如前所述,UNICODE 是用兩個字節來表示爲一個字符,他總共可以組合出65535不同的字符,這大概已經可以覆蓋世界上所有文化的符號。如果還不夠也沒有關係,ISO已經準備了UCS-4方案,說簡單了就是四個字節來表示一個字符,這樣我們就可以組合出21億個不同的字符出來(最高位有其他用途),這大概可以用到銀河聯邦成立那一天吧!

 UNICODE 來到時,一起到來的還有計算機網絡的興起,UNICODE 如何在網絡上傳輸也是一個必須考慮的問題,於是面向傳輸的衆多 UTF(UCS Transfer Format)標準出現了,顧名思義,UTF8就是每次8個位傳輸數據,而UTF16就是每次16個位,只不過爲了傳輸時的可靠性,從UNICODE到 UTF時並不是直接的對應,而是要經過一些算法和規則來轉換。

 受到過網絡編程加持的計算機僧侶們都知道,在網絡裏傳遞信息時有一個很重要的問題,就是對於數據高低位的解讀方式,一些計算機是採用低位先發送的方法,例如我們PC機採用的 INTEL 架構,而另一些是採用高位先發送的方式,在網絡中交換數據時,爲了覈對雙方對於高低位的認識是否是一致的,採用了一種很簡便的方法,就是在文本流的開始時向對方發送一個標誌符。如果之後的文本是高位在先,那就發送"FEFF",反之,則發送"FFFE"。不信你可以用二進制方式打開一個UTF-X格式的文件,看看開頭兩個字節是不是這兩個字節?

 講到這裏,我們再順便說說一個很著名的奇怪現象:當你在 windows 的記事本里新建一個文件,輸入"聯通"兩個字之後,保存,關閉,然後再次打開,你會發現這兩個字已經消失了,代之的是幾個亂碼!呵呵,有人說這就是聯通之所以拼不過移動的原因。

 其實這是因爲GB2312編碼與UTF8編碼產生了編碼衝撞的原因。

 從網上引來一段從UNICODE到UTF8的轉換規則:

Unicode

UTF-8

0000 - 007F

0xxxxxxx

0080 - 07FF

110xxxxx 10xxxxxx

0800 - FFFF

1110xxxx 10xxxxxx 10xxxxxx

 例如:"漢"字的Unicode編碼是6C49。 6C49在0800-FFFF之間,所以要用3字節模板:1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進制是:0110 1100 0100 1001,將這個比特流按照三字節模板的分段方法分爲0110 110001 001001,依次代替模板中的x,得到:1110-0110 10-110001 10-001001,即E6 B1 89,這就是其UTF8的編碼。

 而當你新建一個文本文件時,記事本的編碼默認是ANSI, 如果你在ANSI的編碼輸入漢字,那麼它實際就是GB系列(簡體中文系列)的編碼方式,在這種編碼下,"聯通"的內碼是:

 “聯”字的內碼是:c1aa

c1 (1100 0001)

aa (1010 1010)

 “通”字的內碼是:cda8

cd (1100 1101)

a8 (1010 1000)

 注意到了嗎?第一二個字節、第三四個字節的起始部分的都是"110"和"10",正好與UTF8規則裏的兩字節模板是一致的,於是再次打開記事本時,記事本就誤認爲這是一個UTF8編碼的文件,讓我們把第一個字節的110和第二個字節的10去掉,我們就得到了"00001 101010",再把各位對齊,補上前導的0,就得到了"0000 0000 0110 1010",不好意思,這是UNICODE的006A,也就是小寫的字母"j",而之後的兩字節用UTF8解碼之後是0368,這個字符什麼也不是。這就是隻有"聯通"兩個字的文件沒有辦法在記事本里正常顯示的原因。

 而如果你在"聯通"之後多輸入幾個字,其他的字的編碼不見得又恰好是110和10開始的字節,這樣再次打開時,記事本就不會堅持這是一個utf8編碼的文件,而會用ANSI的方式解讀之,這時亂碼又不出現了。


寫程序的人基本上都會遇到亂碼的問題,之前自己對字符集、編碼等問題也是一知半解,大概明白什麼意思,但卻說不清楚。由於公司需要做多語言,於是研究了一下,終於把字符集和編碼等問題弄明白了。

 ascii、GB2312、GBK、unicode、utf-8、utf-16、ucs2、ucs4......,對於很多人來說這些東西都是比較模糊的(以前的我也是),字符集編碼問題不理解透徹,很難說清楚他們之間的關係。下面就從頭開始把這些概念整理一下,希望對大家有幫助,自己也總結一下。

 計算機只認識0和1,因此世界上的任何符號在計算機中都必須轉換成0和1來表示,所謂字符集就是一個字符對應到數字編碼的對應表。於是最先有了ascii 碼,它是用一個字節(8位)來表示字符。ascii的第一個bit永遠是0,因此ascii碼最多能表示128個字符(2的7次方)。英語大小寫字母共 52個字母,加上數字和一些控制符號(如回車、tab等),128也夠用了。

 

        但隨着計算機的普及,除了英語以外的其他語言(如中文)使用ascii碼就不行了。於是每個國家都爲自己的語言定義了一套字符集,以中文爲例,有了 gb2312、big5等字符集。gb2312中收錄了7000多個常用的簡體中文字符,而big5爲臺灣用的繁體中文。gb2312和big5等字符集都是用兩個字節來保存的,因爲一個字節只能表示128個字符。新的字符集出來,程序問題也相應的出來了,以前的程序處理字符都是1個1個字節的處理字符,而新的字符集要求兩個兩個的處理字符,那我們的程序到底是該一個一個字節讀取還是兩個兩個字節的讀取呢?很快人們發現ascii碼都是以0開頭,那麼新的字符集都用1開頭問題就解決了。程序讀到以0開頭的字節就一個字節一個字節的讀字符,遇到1開頭的字節就兩個兩個字節的開始讀。因此gb2312、 big5等字符集和ascii是兼容的。

 

        gb2312只收錄了7000多個字符,並沒有收錄所有的中文字符,因此在1995年和2000年,我國先後推出了gbk1.0和gb18030。 gb18030收錄了所有的中文字符,包括少數民族的文字。到此我們有了一箇中文字符集的發展線路:ascii -> gb2312 -> gbk1.0 -> gb18030 他們是由小到大的,並且是向下兼容的。到此中文的問題解決了,似乎一切都OK了。

 

        但世界上如此多的國家,每個國家都有一套自己的字符集,這樣太亂了,於是老大哥ISO開始推出統一全世界字符的字符集了——unicode(也稱 UCS)。unicode佔用4個字節,總共可以收錄2147483648個字符,這足以涵蓋地球上所有用到的字符了。但一個字符4個字節相當的浪費資源,特別是在網絡傳輸時。於是unicode推出了2個標準,分別是UCS-2和UCS-4。

 

        USC-2用2個字節保存字符,其包含了西歐和亞洲絕大多數國家的字符,常用unicode採用USC-2。USC-4用4個字節保存字符,這種基本上很少用到,因爲太浪費資源。

 

        UTF-8、UTF-16是unicode的編碼格式,這裏需要搞清楚字符集和編碼格式的區別。字符集是一個字符和數字的對應表,表示每一個字符對應的數字,而編碼是指這些字符對應的數字在計算機中如何保存。比如,字符“中”對應的unicode碼爲4E2D,但在計算機中保存時不一定就是4E2D。(注意,此處寫的是不一定)

 

        先說簡單的UTF-16,UTF-16用固定兩個字節對unicode進行編碼,因此UTF-16編碼就等於unicode碼。例如,字符“中”對應 UTF-16編碼爲4E2D。這中間又必須考慮字節序的問題,因爲不同的平臺對於字節序的處理方式不一樣,有的是高位在前低位在後,而有的正好相反。因此,字符“中”的UTF-16有兩種編碼方式,分別是4E2D和2D4E。那程序如何知道是哪種呢?於是有了BOM( Bill Of Material),簡單點說就是在文件最前面加一個標記(佔2個字節,其實也是一個unicode字符)來表示高位在前還是低位在前。如果文件最前面是 FEFF則表示高位在前,又叫Big-Endian,如果是FFFE則表示低位在前,又叫Little-Endian。

 

        UTF-8比較麻煩一點,他是編碼是變長的,也就是說不是使用固定的兩個字節來進行編碼。對於0-127的字符采用0XXXXXXX的形式保存(1個字節),128-2047採用110XXXXX 10XXXXXX的形式保存(兩個字節),2048-65535採用1110XXXX 10XXXXXX 10XXXXXX(三個字節)的形式保存。舉例來說,字符“中”對應的unicode碼爲4E2D(0100111000101101)也就是 20013,在2048-65535之間,因此“中”的UTF-8編碼爲11100100 10 111000 10101101。對於UTF-8編碼來說,程序讀到0開頭的字節表示只需要讀一個字節,遇到110開頭的表示需要讀取兩個字節,而讀到1110開頭的表示要讀取三個字節。因此對於有大量英文字符的文檔而言,使用UTF-8編碼可以節約大量磁盤空間。UTF-8是不需要BOM的,因爲它是單個字節處理的,但也可以爲UTF-8文件加上BOM。爲UTF-8加上BOM後,在文件頭會多出3個字節,爲 EF BB BF,它就是FEFF對應的UTF-8編碼。

 

        OK,總結一下吧,ascii、gb2312、gbk、big5、unicode都稱爲字符集,而UTF-8、UTF-16叫做編碼方式(其實 gb2312也有其編碼方式,此文暫不討論)。一般情況下,儘量使用UTF-8編碼方式,因爲它即通用又能很好的節約空間。

 

        我們可以做一些實驗檢驗一下上文所述內容,下面是我檢驗的結果,大家可以對照一下:

文本內容 文本格式 佔用空間大小
a ascii 1字節
a unicode 4字節 (FFFE + a字母)
a unicode big endian 4字節 (FEFF + a字母)
a utf-8 1字節
a utf-8+ 4字節 (EFBBBF + a字母)
ascii 2字節
unicode 4字節
unicode big endian 4字節
utf-8 3字節
utf-8+ 6字節
 

轉自:

http://www.cnblogs.com/xugang/archive/2010/05/08/1730451.html

http://www.cnblogs.com/xugang/archive/2010/04/07/1706232.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章