ASCII(American
Standard Code for Information Interchange)
?
美國信息交換標準代碼，這是計算機上最早使用的通用的編碼方案。那個時候計算機還只是拉丁文字的專利，根本沒有想到現在計算機的發展勢頭，如果想到了，可能一開始就會使用
unicode
了。當時絕大部分專家都認為，要用計算機，必須熟練掌握英文。這種編碼占用
7
個
Bit
，在計算機中占用一個字節，
8
位，最高位沒用，通訊的時候有時用作奇偶校驗位。因此
ASCII
編碼的取值范圍實際上是：
0x00-0x7f,
只能表示
128
個字符。后來發現
128
個不太夠用，做了擴展，叫做
ASCII
擴展編碼，用足八位，取值范圍變成：
0x00-0xff,
能表示
256
個字符。其實這種擴展意義不大，因為
256
個字符表示一些非拉丁文字遠遠不夠，但是表示拉丁文字，又用不完。所以擴展的意義還是為了下面的
ANSI
編碼服務。
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
編碼的問題。
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 ,
只要有字庫，任何文字都能同時顯示，也可以到任何語言的平臺上的去運行，不再有亂碼的困惑！其實現在絕大部分軟件已經是這么做的了！
??
另外也不要被很多名詞屬于所迷惑，其實這些只是標準的問題，根本沒有什么新的東西，更沒有什么復雜的東西。
?
摘自
http://blog.csdn.net/softman11/archive/2011/01/08/6124345.aspx
?