舊文重發：漫談字符集和編碼

本文寫於好久好久之前，最初發在live space上，後來空間關了，我也就沒再找地方重發。今天有網友找來問，想作轉發，因此我作了一點點微小的整理工做，重貼一次原文。
－－－－－－－－－－－－－－－－－－－－－－－－－－
　　
　　快下班了，愛問問題的小朋友Nico又問了一個問題：
　　「sqlserver裏面有char和nchar，那個n聽說是指unicode的數據，這個是什麼意思。」
　　並非全部簡單的問題都很容易回答，就像這個問題同樣。因而我答應專門寫一篇BLOG來從頭講講編碼的故事。那麼就讓咱們找個草堆坐下，先抽口煙，看看夜晚天空上的銀河，而後想想要從哪裏開始講起。嗯，也許這樣開始比較好……
　　
　　
　　好久好久之前，有一羣人，他們決定用8個能夠開合的晶體管來組合成不一樣的狀態，以表示世界上的萬物。他們看到8個開關狀態是好的，因而他們把這稱爲「字節」。
　　再後來，他們又作了一些能夠處理這些字節的機器，機器開動了，能夠用字節來組合出不少狀態，狀態開始變來變去。他們看到這樣是好的，因而它們就這機器稱爲「計算機」。
　　
　　開始計算機只在美國用。八位的字節一共有256種不一樣的狀態。
　　他們把其中的編號從0開始的32種狀態分別規定了特殊的用途，一但終端、打印機趕上這些字節被傳過來時，就要作一些約定的動做。因而打印機會打印反白的字了（0x1b…），會換行(0x10)了，終端會嘟嘟(0x07)叫了，有色彩(0x1b…)了。他們看到這樣很好，因而就把這些0x20如下的字節狀態稱爲「控制碼」。
　　他們又把全部的空格、標點符號、數字、大小寫字母分別用連續的字節狀態表示，一直編到了第127號，這樣計算機就能夠用不一樣字節來存儲英語的文字了。你們看到這樣，都感受很好，因而你們都把這個方案叫作ANSI的「Ascii」編碼（American Standard Code for Information Interchange，美國信息互換標準代碼），全部的計算機都用一樣的ASCII方案來保存英文文字。
　　後來，就像建造巴比倫塔同樣，世界各地的都開始使用計算機，可是不少國家用的不是英文，他們的字母裏有許可能是ASCII裏沒有的，爲了能夠在計算機保存他們的文字，他們決定採用127號以後的空位來表示這些新的字母、符號，還加入了不少畫表格時須要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一個狀態255。從128到255這一頁的字符集被稱「擴展字符集」。今後以後，貪LAN的人類再沒有新的狀態能夠用了，美帝國主義可能沒有想到還有第三世界國家的人們也但願能夠用到計算機吧！
　　等中國人們獲得計算機時，已經沒有能夠利用的字節狀態來表示漢字，何況有6000多個經常使用漢字須要保存呢。可是這難不倒智慧的中國人民，咱們直接不客氣地把那些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的，那麼就認爲一個雙字節字符集裏的字符出現了。那時候凡是受過加持，會編程的人都要天天念下面這個咒語數百遍：
　　「一個漢字算兩個英文字符！一個漢字算兩個英文字符……」
　　
　　可是世界民族之林中，還有很很多用不上電腦的少數民族，他們的文字怎麼辦？並且各個國家都像中國這樣搞出一套本身的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支持別人的編碼。當時的中國人想讓電腦顯示漢字，就必須裝上一個「漢字系統」，專門用來處理漢字的顯示、輸入的問題，可是那個臺灣的愚昧封建人士寫的算命程序就必須加裝另外一套支持BIG5編碼的什麼「倚天漢字系統」才能夠用。
　　真是計算機的巴比倫塔命題啊！
　　正在這時，國際標誰化組織ISO及時出現了，他們決定廢了全部的地區性編碼方案，從新搞一個包括了地球上全部文化、全部字母和符號的編碼來，還打算叫它「Universal Multiple-Octet Coded Character Set」，簡稱UCS, 俗稱「UNICODE」。
　　UNICODE開始制訂時，計算機的存儲器容量極大地發展了，空間不再成爲問題了。因而ISO就沒有考慮與ANSI兼容的問題，而直接規定必須用兩個字節，也就是16位來統一表示全部的字符，因爲「半角」英文符號只須要用到低８位，因此其高位永遠是０，所以這種大氣的方案在保存英文文本時會多浪費一倍的空間。
　　這時候，從舊社會裏走過來的程序員開始發現一個奇怪的現象：他們的strlen函數靠不住了，一個漢字再也不是至關於兩個字符了，而是一個！是的，從UNICODE開始，不管是半角的英文字母，仍是全角的漢字，它們都是統一的「一個字符！」同時，也都是統一的「兩個字節」，請注意「字符」和「字節」兩個術語的不一樣。UNICODE的一個字符就是兩個字節。一個漢字算兩個英文字符的時代已經快過去了。
　　多種字符集存在時，那些作多語言軟件的公司趕上了很大麻煩，他們在區域化軟件時不得不也加持那個雙字節字符集咒語，還要到處當心不要搞錯。UNICODE對於他們來講是一個很好的一攬子解決方案，因而從Windows NT開始，MS趁機把它們的操做系統改了一遍，把全部的核心代碼都改爲了兼容UNICODE的版本，從這時開始，WINDOWS系統終於無須要加裝各類本土語言系統，就能夠顯示全世界上全部文化的字符了。
　　可是，UNICODE在制訂時沒有考慮與任何一種現有的編碼方案保持兼容，這使得GBK與UNICODE在漢字的內碼編排上徹底是不同的，沒有一種簡單的算術方法能夠把文本內容從一個編碼轉換到另外一種編碼，這種轉換必須經過查表來進行。
　　如前所述，UNICODE是用兩個字節來表示爲一個字符，他總共能夠組合出65535不一樣的字符，這大概已經能夠覆蓋世界上全部文化的符號。若是還不夠也沒有關係，ISO已經準備了UCS-4方案，說簡單了就是四個字節來表示一個字符，這樣咱們就能夠組合出21億個不一樣的字符出來（最高位有其餘用途），這大概能夠用到銀河聯邦成立那一天吧！
　　
　　UNICODE來到時，一塊兒到來的還有計算機網絡的興起，UNICODE如何在網絡上傳輸也是一個必須考慮的問題，因而面向傳輸的衆多UTF（UCS Transfer Format）標準出現了，顧名思義，UTF8就是每次8個位傳輸數據，而UTF16就是每次16個位，只不過爲了傳輸時的可靠性，從UNICODE到UTF時並非直接的對應，而是要過一些算法和規則來轉換。
　　受到過網絡編程加持的計算機僧侶們都知道，在網絡裏傳遞信息時有一個很重要的問題，就是對於數據高低位的解讀方式，一些計算機是採用低位先發送的方法，例如咱們的INTEL架構，而另外一些是採用高位先發送的方式，在網絡中交換數據時，爲了覈對雙方對於高低位的認識是不是一致的，採用了一種很簡便的方法，就是在文本流的開始時向對方發送一個標誌符——若是以後的文本是高位在位，那就發送「FEFF」，反之，則發送「FFFE」。不信你能夠用二進制方式打開一個UNICODE或是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系列的編碼方式，在這種編碼下，「聯想」的內碼是：
　　c1 1100 0001
　　aa 1010 1010
　　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的方式解讀之，這時亂碼又不出現了。
　　
　　好了，終於能夠回答NICO的問題了，在數據庫裏，有n前綴的字串類型就是UNICODE類型，這種類型中，固定用兩個字節來表示一個字符，不管這個字符是漢字仍是英文字母，或是別的什麼。
　　若是你要測試「abc漢字」這個串的長度，在沒有n前綴的數據類型裏，這個字串是7個字符的長度，由於一個漢字至關於兩個字符。而在有n前綴的數據類型裏，一樣的測試串長度的函數將會告訴你是5個字符，由於一個漢字就是一個字符。
　　
　　但願這篇文章正是NICO想要的.