各種字元編碼方式詳解及由來(ANSI,UNICODE,UTF-8,GB2312,GBK)

  轉載自： http://gjican.iteye.com/blog/1028003  

    一直對字元的各種編碼方式懵懵懂懂，什麼ANSI、UNICODE、UTF-8、GB2312、GBK、DBCS、UCS……是不是看的很暈，假如您細細的閱讀本文你一定可以清晰的了解他們。Let's go!

    很久很久以前，有一群人，他們決定用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個字元，因為一個漢字就是一個字元。