電腦各種編碼來曆及區別

GB2312：

一個小於127的字元的意義與原來相同，但兩個大於127的字元連在一起時，就表示一個漢字，
這樣我們就可以組合出大約7000多個簡體漢字了。
在這些編碼裡，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，
連在 ASCII 裡本來就有的數字、標點、字母都統統重新編了兩個位元組長的編碼，這就是常說的"全形"字元，
而原來在127號以下的那些就叫"半形"字元了。
一個漢字算兩個英文字元！一個漢字算兩個英文字元……

GBK:

不再要求低位元組一定是127號之後的內碼，只要第一個位元組是大於127就固定表示這是一個漢字的開始，
不管後面跟的是不是擴充字元集裡的內容。
結果擴充之後的編碼方案被稱為 GBK 標準，
GBK 包括了 GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。

GB18030:

又加了幾千個新的少數民族的字，GBK 擴成了 GB18030。

中國的程式員們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 "DBCS"（Double Byte Charecter Set 雙位元組字元集）。
在DBCS系列標準裡，
最大的特點是兩位元組長的漢字字元和一位元組長的英文字元並存於同一套編碼方案裡，
因此他們寫的程式為了支援中文處理，必須要注意字串裡的每一個位元組的值，
如果這個值是大於127的，那麼就認為一個雙位元組字元集裡的字元出現了。

每個國家都搞出自己的一套編碼，為了全世界的使用統一，於是有了。。。

ISO （國際標誰化組織）的國際組織決定著手解決這個問題。
他們打算叫它"Universal Multiple-Octet Coded Character Set"，簡稱 UCS, 俗稱 "UNICODE"。

UNICODE:
ISO 就直接規定必須用兩個位元組，也就是16位來統一表示所有的字元，
對於ascii裡的那些“半形”字元，UNICODE 包持其原編碼不變，只是將其長度由原來的8位擴充為16位，
而其他文化和語言的字元則全部重新統一編碼。
由於"半形"英文符號只需要用到低8位，所以其高 8位永遠是0，
因此這種大氣的方案在儲存英文文本時會多浪費一倍的空間。

他們的strlen函數靠不住了，一個漢字不再是相當於兩個字元了，而是一個！
是的，從 UNICODE 開始，無論是半形的英文字母，還是全形的漢字，
它們都是統一的"一個字元"！同時，也都是統一的"兩個位元組"，
“位元組”是一個8位的物理存貯單元，而“字元”則是一個文化相關的符號。
在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時並不是直接的對應，而是要過一些演算法和規則來轉換。

從網上引來一段從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的編碼。

當一個軟體開啟一個文本時，它要做的第一件事是決定這個文本究竟是使用哪種字元集的哪種編碼儲存的。軟體一般採用三種方式來決定文本的字元集和編碼：
檢測檔案頭標識，提示使用者選擇，根據一定的規則猜測
最標準的途徑是檢測文本最開頭的幾個位元組，開頭位元組 Charset/encoding,如下表：
EF BB BF UTF-8
FE FF UTF-16/UCS-2, little endian
FF FE UTF-16/UCS-2, big endian
FF FE 00 00 UTF-32/UCS-4, little endian.
00 00 FE FF UTF-32/UCS-4, big-endian.

ANSI字元集：ASCII字元集，以及由此派生併兼容的字元集，
如：GB2312，正式的名稱為MBCS（Multi-Byte Chactacter System，多位元組字元系統），
通常也稱為ANSI字元集。

big endian和little endian
big endian和little endian是CPU處理多位元組數的不同方式。
例如“漢”字的Unicode編碼是6C49。那麼寫到檔案裡時，
究竟是將6C寫在前面，還是將49寫在前面？
如果將6C寫在前面，就是big endian。
還是將49寫在前面，就是little endian。

從ASCII、GB2312、GBK到GB18030，這些編碼方法是向下相容的，
即同一個字元在這些方案中總是有相同的編碼，後面的標準支援更多的字元。

UTF-8就是以8位為單元對UCS進行編碼。

UTF-16以16位為單元對UCS進行編碼。
對於小於0x10000的UCS碼，UTF-16編碼就等於UCS碼對應的16位不帶正負號的整數。
對於不小於 0x10000的UCS碼，定義了一個演算法。
不過由於實際使用的UCS2，或者UCS4的BMP必然小於0x10000，
所以就目前而言，可以認為UTF -16和UCS-2基本相同。
但UCS-2隻是一個編碼方案，UTF-16卻要用於實際的傳輸，
所以就不得不考慮位元組序的問題。

我很早前就發現Unicode、Unicode big endian和UTF-8編碼的txt檔案的開頭會多出幾個位元組，
分別是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。
但這些標記是基於什麼標準呢？

即讀取檔案時，
若為unicode時，前兩個位元組可以不用讀取。註：固定是兩個位元組一個字。
若為utf-8時，前三個位元組可以不用讀取。
若為ansi時，前面沒有多餘位元組，可從檔案頭直接讀取。