Unicode,ANSI,UTF-8的故事

好久好久之前，有一羣人，他們決定用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系列的編碼方式，在這種編碼下，"聯通"的內碼是：
 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個字符，由於一個漢字就是一個字符。