原諒轉自：
該文章介紹的不錯，值得收藏。
最近有一些朋友常問我一些亂碼的問題，和他們交流過程中，發現這個編碼的相關知識還真是雜亂不堪，不少人對一些
知識理解似乎也有些偏差，網上百度,google的內容，也有不少以訛傳訛，根本就是錯誤的（例如說 unicode編碼是兩
個字節），各種軟件讓你選擇編碼的時候，常常是很長的一個選單，讓用戶不知道該如何選。基于這樣的問題，我就寫
下我的理解吧，一方面幫助一些需要幫助的人糾正認識，一方面作為自己以后備查的資料。
1.ASCII(American Standard Code for Information Interchange)
美國信息交換標準代碼，這是計算機上最早使用的通用的編碼方案。那個時候計算機還只是拉丁文字的專利，根本沒
有想到現在計算機的發展勢頭，如果想到了，可能一開始就會使用unicode了。當時絕大部分專家都認為，要用計算機
，必須熟練掌握英文。這種編碼占用7個Bit，在計算機中占用一個字節，8位，最高位沒用，通訊的時候有時用作奇偶
校驗位。因此ASCII編碼的取值范圍實際上是：0x00-0x7f,只能表示128個字符。后來發現128個不太夠用，做了擴展，
叫做ASCII擴展編碼，用足八位，取值范圍變成：0x00-0xff,能表示256個字符。其實這種擴展意義不大，因為256個字
符表示一些非拉丁文字遠遠不夠，但是表示拉丁文字，又用不完。所以擴展的意義還是為了下面的ANSI編碼服務。
2.ANSI（American National Standard Institite ）
美國國家標準協會，也就是說，每個國家（非拉丁語系國家）自己制定自己的文字的編碼規則，并得到了ANSI認可，
符合ANSI的標準，全世界在表示對應國家文字的時候都通用這種編碼就叫ANSI編碼。換句話說，中國的ANSI編碼和在日
本的ANSI的意思是不一樣的，因為都代表自己國家的文字編碼標準。比如中國的ANSI對應就是GB2312標準，日本就是
JIT標準，香港，臺灣對應的是BIG5標準等等。當然這個問題也比較復雜，微軟從95開始，用就是自己搞的一個標準GBK
。GB2312里面只有6763個漢字，682個符號，所以確實有時候不是很夠用。GBK一直能和GB2312相互混淆并且相安無事的
一個重要原因是GBK全面兼容GB2312，所以沒有出現任何沖突，你用GB2312編碼的文件通過GBK去解釋一定能獲得相同的
顯示效果，換句話說：GBK對GB2312就是，你有的，我也有，你沒得的，我還有！
好了，ANSI的標準是什么呢，首先是ASCII的代碼你不能用！也就是說ASCII碼在任何ANSI中應該都是相同的。其他的，
你們自己擴展。所以呢，中國人就把ASCII碼變成8位，0x7f之前我不動你的，我從0xa0開始編，0xa0到0xff才95個碼位
，對于中國字那簡直是杯水車薪，因此，就用兩個字節吧，因此編碼范圍就從0xA1A1 - 0xFEFE，這個范圍可以表示
23901個漢字。基本夠用了吧，GB2312才7000多個呢！GBK更猛，編碼范圍是從0x8140 - 0xFEFE,可以表示3萬多個漢字
。可以看出，這兩種方案，都能保證漢字頭一個字節在0x7f以上，從而和ASCII不會發生沖突。能夠實現英文和漢字同
時顯示。
BIG5，香港和臺灣用的比較多，繁體，范圍： 0xA140 - 0xF9FE, 0xA1A1 - 0xF9FE，每個字由兩個字節組成，其第一
字節編碼范圍為0xA1~0xF9，第二字節編碼范圍為0x40-0x7E與0xA1-0xFE，總計收入13868個字 (包括5401個常用字、
7652 個次常用字、7個擴充字、以及808個各式符號)。
那么到底ANSI是多少位呢？這個不一定！比如在GB2312和GBK，BIG5中，是兩位！但是其他標準或者其他語言如果不夠
用，就完全可能不止兩位！
例如：GB18030:
GB18030-2000(GBK2K)在GBK的基礎上進一步擴展了漢字，增加了藏、蒙等少數民族的字形。GBK2K從根本上解決了字位
不夠，字形不足的問題。它有幾個特點：它并沒有確定所有的字形，只是規定了編碼范圍，留待以后擴充。
編碼是變長的，其二字節部分與GBK兼容；四字節部分是擴充的字形、字位，其編碼范圍是首字節0x81-0xfe、二字節
0x30-0x39、三字節0x81-0xfe、四字節0x30-0x39。它的推廣是分階段的，首先要求實現的是能夠完全映射到
Unicode3.0標準的所有字形。它是國家標準，是強制性的。
搞懂了ANSI的含義，我們發現ANSI有個致命的缺陷，就是每個標準是各自為陣的，不保證能兼容。換句話說，要同時顯
示中文和日本文或者阿拉伯文，就完全可能會出現一個編碼兩個字符集里面都有對應，不知道該顯示哪一個的問題，也
就是編碼重疊的問題。顯然這樣的方案不好，所以Unicode才會出現！
3.MBCS（Multi-Byte Chactacter System（Set)）
多字節字符系統或者字符集，基于ANSI編碼的原理上，對一個字符的表示實際上無法確定他需要占用幾個字節的，只
能從編碼本身來區分和解釋。因此計算機在存儲的時候，就是采用多字節存儲的形式。也就是你需要幾個字節我給你放
幾個字節，比如A我給你放一個字節，比如"中“，我就給你放兩個字節，這樣的字符表示形式就是MBCS。
在基于GBK的windows中，不會超過2個字節，所以windows這種表示形式有叫做DBCS（Double-Byte Chactacter System
），其實算是MBCS的一個特例。
C語言默認存放字符串就是用的MBCS格式。從原理上來說，這樣是非常經濟的一種方式。
4.CodePage
代碼頁，最早來自IBM，后來被微軟，oracle ,SAP等廣泛采用。因為ANSI編碼每個國家都不統一，不兼容，可能導致沖
突，所以一個系統在處理文字的時候，必須要告訴計算機你的ANSI是哪個國家和地區的標準，這種國家和標準的代號（
其實就是字符編碼格式的代號），微軟稱為Codepage代碼頁，其實這個代碼頁和字符集編碼的意思是一樣的。告訴你代
碼頁，本質就是告訴了你編碼格式。
但是不同廠家的代碼頁可能是完全不同，哪怕是同樣的編碼，比如， UTF-8字符編碼 在IBM對應的代碼頁是1208，在微
軟對應的是65001,在德國的SAP公司對應的是 4110 。所以啊，其實本來就是一個東西，大家各自為政，搞那么多新名
詞，實在沒必要！所以標準還是很重要的！！！
比如GBK的在微軟的代碼頁是936，告訴你代碼頁是936其實和告訴你我編碼格式是GBK效果完全相同。那么處理文本的時
候就不會有問題，不會去考慮某個代碼是顯示的韓文還是中文，同樣，日文和韓文的代碼頁就和中文不同，這樣就可以
避免編碼沖突導致計算機不知如何處理的問題。當然用這個也可以很容易的切換語言版本。
但是這都是治標不治本的方法，還是無法解決同時顯示多種語言的問題，所以最后還是都用unicode吧，永遠不會有沖
突了。
5.Unicode(Universal Code)
這是一個編碼方案，說白了就是一張包含全世界所有文字的一個編碼表，不管你用的上，用不上，不管是現在用的，
還是以前用過的，只要這個世界上存在的文字符號，統統給你一個唯一的編碼，這樣就不可能有任何沖突了。不管你要
同時顯示任何文字，都沒有問題。
因此在這樣的方案下，Unicode出現了。Unicode編碼范圍是：0-0x10FFFF，可以容納1114112個字符，100多萬啊。全
世界的字符根本用不完了，Unicode 5.0版本中，才用了238605個碼位。所以足夠了。
因此從碼位范圍看，嚴格的unicode需要3個字節來存儲。但是考慮到理解性和計算機處理的方便性，理論上還是用4個
字節來描述。
Unicode采用的漢字相關編碼用的是《CJK統一漢字編碼字符集》— 國家標準 GB13000.1 是完全等同于國際標準《
通用多八位編碼字符集 (UCS)》 ISO 10646.1。《GB13000.1》中最重要的也經常被采用的是其雙字節形式的基本多文
種平面。在這65536個碼位的空間中，定義了幾乎所有國家或地區的語言文字和符號。其中從0x4E00到 0x9FA5 的連續
區域包含了 20902 個來自中國（包括臺灣）、日本、韓國的漢字，稱為 CJK (Chinese Japanese Korean) 漢字。CJK
是《GB2312-80》、《BIG5》等字符集的超集。
CJK包含了中國，日本，韓國，越南，香港，也就是CJKVH。這個在UNICODE的Charset chart中可以明顯看到。
unicode的相關標準可以從unicode.org上面獲得，目前已經進行到了6.0版本。
下面這段描述來自百度百科：
Unicode字符集可以簡寫為UCS（Unicode Character Set）。早期的 unicodeUnicode標準有UCS-2、UCS-4的說法。
UCS-2用兩個字節編碼，UCS-4用4個字節編碼。UCS-4根據最高位為0的最高字節分成2^7=128個group。每個group再根據
次高字節分為256個平面（plane）。每個平面根據第3個字節分為256行 （row），每行有256個碼位（cell）。group 0
的平面0被稱作BMP（Basic Multilingual Plane）。將UCS-4的BMP去掉前面的兩個零字節就得到了UCS-2。 每個平
面有2^16=65536個碼位。Unicode計劃使用了17個平面，一共有17*65536=1114112個碼位。在Unicode 5.0.0版本中，已
定義的碼位只有238605個，分布在平面0、平面1、平面2、平面14、平面15、平面16。其中平面15和平面16上只是定義
了兩個各占65534個碼位的專用區（Private Use Area），分別是0xF0000-0xFFFFD和0x100000-0x10FFFD。所謂專用區
，就是保留給大家放自定義字符的區域，可以簡寫為PUA。 平面0也有一個專用區：0xE000-0xF8FF，有6400個碼位
。平面0的0xD800-0xDFFF，共2048個碼位，是一個被稱作代理區（Surrogate）的特殊區域。代理區的目的用兩個UTF-
16字符表示BMP以外的字符。在介紹UTF-16編碼時會介紹。 如前所述在Unicode 5.0.0版本中，238605-65534*2-
6400-2408=99089。余下的99089個已定義碼位分布在平面0、平面1、平面2和平面14上，它們對應著Unicode目前定義的
99089個字符，其中包括71226個漢字。平面0、平面1、平面2和平面14上分別定義了52080、3419、43253和337個字符。
平面2的43253個字符都是漢字。平面0上定義了27973個漢字。
6.Unicode的實現方案
Unicode其實只是一張巨大的編碼表。要在計算機里面實現，也出現了幾種不同的方案。也就是說如何表示unicode
編碼的問題。
（1）UTF-8（UCS Transformation Format 8bit)
這個方案的意思以8位為單位來標識文字，注意并不是說一個文字用8位標識。他其實是一種MBCS方案，可變字節的
。到底需要幾個字節表示一個符號，這個要根據這個符號的unicode編碼來決定，最多4個字節。
編碼規則如下：
Unicode編碼(16進制) ║ UTF-8 字節流(二進制)
000000 - 00007F ║ 0xxxxxxx
000080 - 0007FF ║ 110xxxxx 10xxxxxx
000800 - 00FFFF ║ 1110xxxx 10xxxxxx 10xxxxxx
010000 - 10FFFF ║ 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
UTF-8的特點是對不同范圍的字符使用不同長度的編碼。對于0x00-0x7F之間的字符，UTF-8編碼與ASCII編碼完全相同。
UTF-8編碼的最大長度是4個字節。從上表可以看出，4字節模板有21個x，即可以容納21位二進制數字。Unicode的最大
碼位0x10FFFF也只有21位。
例1：“漢”字的Unicode編碼是0x6C49。0x6C49在0x0800-0xFFFF之間，使用用3字節模板了：1110xxxx 10xxxxxx
10xxxxxx。將0x6C49寫成二進制是：0110 1100 0100 1001， 用這個比特流依次代替模板中的x，得到：11100110
10110001 10001001，即E6 B1 89。
例2：Unicode編碼0x20C30在0x010000-0x10FFFF之間，使用用4字節模板了：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx。
將0x20C30寫成21位二進制數字（不足21位就在前面補0）：0 0010 0000 1100 0011 0000，用這個比特流依次代替模板
中的x，得到：11110000 10100000 10110000 10110000，即F0 A0 B0 B0。
（2）UTF-16
UTF-16編碼以16位無符號整數為單位。注意是16位為一個單位，不表示一個字符就只有16位。現在機器上的unicode編
碼一般指的就是UTF-16。絕大部分2個字節就夠了，但是不能絕對的說所有字符都是2個字節。這個要看字符的unicode
編碼處于什么范圍而定，有可能是2個字節，也可能是4個字節。這點請注意！
下面算法解釋來自百度百科。
我們把Unicode unicode編碼記作U。編碼規則如下：
如果U<0x10000，U的UTF-16編碼就是U對應的16位無符號整數（為書寫簡便，下文將16位無符號整數記作WORD）。
如果U≥0x10000，我們先計算U'=U-0x10000，然后將U'寫成二進制形式：yyyy yyyy yyxx xxxx xxxx，U的UTF-16
編碼（二進制）就是：110110yyyyyyyyyy 110111xxxxxxxxxx。為什么U'可以被寫成20個二進制位？Unicode的最大碼位
是0x10ffff，減去0x10000后，U'的最大值是0xfffff，所以肯定可以用20個二進制位表示。
例如：Unicode編碼0x20C30，減去0x10000后，得到0x10C30，寫成二進制是：0001 0000 1100 0011 0000。用前10
位依次替代模板中的y，用后10位依次替代模板中的x，就得到：1101100001000011 1101110000110000，即0xD843
0xDC30。
按照上述規則，Unicode編碼0x10000-0x10FFFF的UTF-16編碼有兩個WORD，第一個WORD的高6位是110110，第二個
WORD的高6位是110111。可見，第一個WORD的取值范圍（二進制）是11011000 00000000到11011011 11111111，即
0xD800-0xDBFF。第二個WORD的取值范圍（二進制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。
為了將一個WORD的UTF-16編碼與兩個WORD的UTF-16編碼區分開來，Unicode編碼的設計者將0xD800-0xDFFF保留下來
，并稱為代理區（Surrogate）：
D800－DB7F ║ High Surrogates ║ 高位替代
DB80－DBFF ║ High Private Use Surrogates ║ 高位專用替代
DC00－DFFF ║ Low Surrogates ║ 低位替代
高位替代就是指這個范圍的碼位是兩個WORD的UTF-16編碼的第一個WORD。低位替代就是指這個范圍的碼位是兩個
WORD的UTF-16編碼的第二個WORD。那么，高位專用替代是什么意思？我們來解答這個問題，順便看看怎么由UTF-16編碼
推導Unicode編碼。
如果一個字符的UTF-16編碼的第一個WORD在0xDB80到0xDBFF之間，那么它的Unicode編碼在什么范圍內？我們知道第
二個WORD的取值范圍是0xDC00-0xDFFF，所以這個字符的UTF-16編碼范圍應該是0xDB80 0xDC00到0xDBFF 0xDFFF。我們
將這個范圍寫成二進制： 1101101110000000 11011100 00000000 - 1101101111111111 1101111111111111 按
照編碼的相反步驟，取出高低WORD的后10位，并拼在一起，得到 1110 0000 0000 0000 0000 - 1111 1111 1111
1111 1111
即0xe0000-0xfffff，按照編碼的相反步驟再加上0x10000，得到0xf0000-0x10ffff。這就是UTF-16編碼的第一個WORD在
0xdb80到0xdbff之間的Unicode編碼范圍，即平面15和平面16。因為Unicode標準將平面15和平面16都作為專用區，所以
0xDB80到0xDBFF之間的保留碼位被稱作高位專用替代。
（3）UTF-32
這個就簡單了，和Unicode碼表基本一一對應，固定四個字節。
為什么不采用UTF-32呢，因為unicode定義的范圍太大了，其實99%的人使用的字符編碼不會超過2個字節，所以如同統
一用4個字節，簡單倒是簡單了，但是數據冗余確實太大了，不好，所以16位是最好的。就算遇到超過16位能表示的字
符，我們也可以通過上面講到的代理技術，采用32位標識，這樣的方案是最好的。所以現在絕大部分機器實現unicode
還是采用的utf-16的方案。當然也有UTF-8的方案。比如windows用的就是UTF16方案，不少linux用的就是utf8方案。
7. 編碼存儲差異
這里就要引出兩個名詞：
LE（little endian):小字節字節序，意思就是一個單元在計算機中的存放時按照低位在前（低地址），高位在后（高
地址）的模式存放。
BE（big endian):大字節字節序，和LE相反，是高位在前，低位在后。
比如一個unicode編碼為：0x006C49，如果是LE，那么在文件中的存放順序應該是：49 6c 00
如果是BE ,那么順序應該是：00 6c 49
8.編碼格式的檢測
到底采用什么編碼，如果能檢測就好了。專家們也是這么想的，所以專家給每種格式和字節序規定了一些特殊的編碼，
這些編碼在unicode 中是沒有使用的，所以不用擔心會沖突。
這個叫做BOM（Byte Order Mark）頭。意思是字節序標志頭。通過它基本能確定編碼格式和字節序。
UTF編碼 ║ Byte Order Mark
UTF-8 ║ EF BB BF
UTF-16LE ║ FF FE
UTF-16BE ║ FE FF
UTF-32LE ║ FF FE 00 00
UTF-32BE ║ 00 00 FE FF
所以通過檢測文件前面的BOM頭，基本能確定編碼格式和字節序。
但是這個BOM頭只是建議添加，不是強制的，所以不少軟件和系統沒有添加這個BOM頭（所以有些軟件格式中有帶BOM頭
和NoBOM頭的選擇），這個時候要檢測什么格式，就比較麻煩了
當然可以檢測，但是不能保證100%準確，只能通過編碼范圍從概率上來檢查，雖然準確度還是比較高，但是不能保證
100%。所以，時常看到檢測錯誤的軟件，也不奇怪了。
總結：
終于寫完了，其實這些問題都是不統一導致的，屬于歷史問題，所以才會有這些困惑，這里也呼吁所有的軟件 開發
人員自覺的采用Unicode標準進行文字處理，我相信在不久的將來，這些困擾都不會存在了，因為所有軟件都是unicode
d ,只要有字庫，任何文字都能同時顯示，也可以到任何語言的平臺上的去運行，不再有亂碼的困惑！
其實現在絕大部分軟件已經是這么做的了！
另外也不要被很多名詞屬于所迷惑，其實這些只是標準的問題，根本沒有什么新的東西，更沒有什么復雜的東西。