0. 從ASCII碼說(shuō)起
學(xué)過(guò)電腦的人都聽(tīng)說(shuō)過(guò)
ASCII碼，這是一種根據(jù)英文字符表設(shè)計(jì)的字符編碼。嚴(yán)格意義上來(lái)講，標(biāo)準(zhǔn)ASCII碼只有7位（最高位為0），共128個(gè)字符，用十進(jìn)制表示是：0-127。其中0-31和127為
控制字符，而32-126為
顯示字符。國(guó)際標(biāo)準(zhǔn)化組織還發(fā)布了一些8位ASCII碼擴(kuò)展字符集，其中最流行的就是
ISO 8859-1 (ISO Latin1)。它除了兼容標(biāo)準(zhǔn)的7位ASCII字符集以外，還利用高字節(jié)位擴(kuò)充了一些西歐國(guó)家常用的字符和符號(hào)。盡管如此，由于ASCII碼屬于單字節(jié)編碼(
SBCS, or Single Byte Character Set)，所以它最多只能表示256個(gè)字符。
顯然，ASCII碼“不懂中文"。那誰(shuí)懂呢？
1. DBCS路過(guò)
記得99年我剛接觸電腦的時(shí)候，還能看到UCDOS的身影。那會(huì)兒經(jīng)常聽(tīng)老師說(shuō)一句話：“一個(gè)漢字包含兩個(gè)字節(jié)”——這其實(shí)就是
DBCS (Double Byte Character Set，雙字節(jié)字符集）使用的方法。DBCS是最常見(jiàn)的MBCS(Multi-Byte Character Set，多字節(jié)字符集)，它保留了ASCII碼的128個(gè)字符（0-127），并且對(duì)一般的非拉丁字符采用雙字節(jié)編碼。第一個(gè)字節(jié)（前導(dǎo)字節(jié)，Lead Byte）使用一個(gè)大于127的數(shù)字（即高字節(jié)位為1），和第二字節(jié)（尾隨字節(jié)，Trailing Byte）一起組成一個(gè)字符。所以，在DBCS里面，ASCII字符仍占1個(gè)字節(jié)，而象中文、日文等字符則占2個(gè)字節(jié)。
我們常使用的DBCS編碼有：
字符編碼
第一字節(jié)范圍
第二字節(jié)范圍
第一字節(jié)最高位
第二字節(jié)最高位
字符數(shù)
說(shuō)明
GB2312
(1980)
A1..F7
A1..FE
11
7445
簡(jiǎn)體字符集（基于區(qū)位碼設(shè)計(jì)，高低字節(jié)各加了$A0）
Big5
(1984, CP950)
81..FE
40..7E A1..FE
10或1
13461
繁體字符集（香港、臺(tái)灣、澳門等）
GBK 1.0
(1993, CP936)
81..FE
40..FE 80..FE
1
0或1
21886
兼容GB2312，支持Unicode 1.1中定義的CJK(簡(jiǎn)/繁體中文、日語(yǔ)和韓語(yǔ))
GB18030
(2000, CP54936)27484兼容GBK1.0，支持Unicode3.1
有單字節(jié)、雙字節(jié)和四字節(jié)三種方式
表1.1 常見(jiàn)的DBCS編碼
備注：
GB2312分為二級(jí)：一級(jí)為常用字，3755個(gè)，按照拼音排序；二級(jí)為次常用字，3008個(gè)，按照部首排序。 GBK 1.0是Microsoft對(duì)GB2312的擴(kuò)展。
說(shuō)到這里，就要引入一個(gè)很重要的概念——代碼頁(yè)(Code Page, CP)。我們常說(shuō)的代碼頁(yè)實(shí)際上是Windows為不同的字符編碼方案所分配的一個(gè)數(shù)字編號(hào)。下面列舉了一些常見(jiàn)的代碼頁(yè)：
代碼頁(yè)描述
CP932日語(yǔ) (Shift-JIS)
CP936簡(jiǎn)體中文 (GBK)
CP950繁體中文 (Big5)
CP1252Windows (ANSI) Codepage, 基于ISO-8859-1標(biāo)準(zhǔn)
CP1200UCS-2LE (Unicode little-endian)
CP1201UCS-2BE (Unicode big-endian)
CP12000UTF-32 LE
CP12000UTF-32 BE
CP54936GB18030
CP65001UTF-8 Unicode
表1.2 常見(jiàn)的Windows代碼頁(yè)
DBCS編碼總是和系統(tǒng)的代碼頁(yè)聯(lián)系在一起的。在不同的代碼頁(yè)里面，同一串?dāng)?shù)據(jù)可能會(huì)被映射成 不同的字符。比如“BA BA D7 D6 41 42 43”，在簡(jiǎn)體中文環(huán)境下（GBK，CP936），它會(huì)被映射成成“漢字ABC”；若當(dāng)前代碼頁(yè)為繁體中文 （Big5, CP950），它就變成了“犖趼ABC”；如果選擇ISO8859-1代碼頁(yè)的話，那我們會(huì)看到“ooó?ABC”——這就是我們常說(shuō)的亂碼，即沒(méi)有選擇正確的編碼。另外當(dāng)某個(gè)字符編碼在當(dāng)前代碼頁(yè)中不存在時(shí)，系統(tǒng)會(huì)用一個(gè)特殊的符號(hào)來(lái)顯示它（方框或問(wèn)號(hào)）。比如將“?2007 Google”保存為ANSI文本文件，再打開(kāi)時(shí)就變成了“?2007 Google”。
另外，不知道您發(fā)現(xiàn)了沒(méi)有，對(duì)于DBCS編碼的文本來(lái)說(shuō)，如果其中有一個(gè)字節(jié)丟失或損壞，就可能造成整個(gè)文件出現(xiàn)亂碼的情況。比如“.Net與字符編碼（理論篇）”在內(nèi)存中表示為：
“2E 4E 65 74 D3 EB D7 D6 B7 FB B1 E0 C2 EB A3 A8 C0 ED C2 DB C6 AA A3 A9”
其中D3 EB是“與”的內(nèi)碼（GBK），此時(shí)剛好前導(dǎo)字節(jié)和尾隨字節(jié)都大于7F (127)。如果這時(shí)候我們把D3改成00，保存后重新打開(kāi)。你猜會(huì)怎么樣？它已經(jīng)變得面目全非了：“.Net 胱址 嗦耄ɡ礪燮 ”。
所以說(shuō)，DBCS編碼存儲(chǔ)效率比較高，但可惜的是它包含的字符數(shù)量有限，最重要的是我們不能同時(shí)使用不同語(yǔ)言中的字符。而且從上面的例子可以看出，DBCS編碼并不是很適合網(wǎng)絡(luò)傳輸。
那我們?cè)撛趺崔k呢？
2. Unicode登場(chǎng)
字符是語(yǔ)言中最小的邏輯單位，而
Unicode所做的就是為每個(gè)字符分配一個(gè)唯一的數(shù)字(Code Point，字位)并定義一系列規(guī)則，并且與程序、平臺(tái)以及語(yǔ)言無(wú)關(guān)。使用Unicode編碼，我們就可以用一種統(tǒng)一的方式來(lái)表示和處理不同語(yǔ)言中的字符，而這在以前是不可能做到的。（比如，“漢字ABC????????????“）。Unicode編碼僅僅兼容了ISO-8859-1標(biāo)準(zhǔn)，比如U+0041表示'A'，
U+6C49來(lái)表示的（其GBK內(nèi)碼是BABA)。
ISO10646標(biāo)準(zhǔn)曾經(jīng)定義了兩種Unicode字符集方案UCS (
Universal Character Set)：分別是UCS-2和UCS-4（2 字節(jié)編碼和4字節(jié)編碼）。采用UCS-4編碼的字符有31位（最高位為0），理論上有0x80000000 (U-00000000-U-7FFFFFFF)個(gè)字位。整個(gè)編碼空間（Code Space）分成128個(gè)組，每組有256個(gè)平面，每一平面包含256行，每行又有256個(gè)字位。其中00組的00平面（即第零平面）被稱為基本多文種平面 (BMP,
Basic Multilingual Plane)。BMP共含有256*256=65536個(gè)字位，這么大的空間已經(jīng)包含了當(dāng)今世界上絕大多數(shù)常用字符（Wikipedia上有一張關(guān)于BMP如何分配的
Roadmap，有興趣的話可以看看）。UCS-2就是對(duì)BMP中的字符進(jìn)行編碼，無(wú)論英文字符還是非拉丁字符，均用2個(gè)字節(jié)表示，顯然UCS-2只是UCS-4的一個(gè)子集。
據(jù)資料顯示，現(xiàn)存的漢字已經(jīng)超過(guò)了9萬(wàn)。顯然對(duì)于某些專業(yè)領(lǐng)域來(lái)說(shuō)，BMP收錄的2萬(wàn)多漢字是遠(yuǎn)遠(yuǎn)不夠用的。2000年國(guó)家為了爭(zhēng)取主動(dòng)權(quán)，開(kāi)始對(duì)我國(guó)境內(nèi)銷售的非嵌入式軟件產(chǎn)品強(qiáng)制實(shí)行GB18030標(biāo)準(zhǔn)。該標(biāo)準(zhǔn)除了兼容GB2312和GBK以外，還收錄了CJK擴(kuò)展字符集A中的6千多漢字。它同時(shí)定義了4字節(jié)編碼，為我國(guó)少數(shù)民族及以后的擴(kuò)展保留了大量的可用編碼空間。
在這樣的環(huán)境下，Unicode組織推出了UTF-16和UTF-32編碼方案，同時(shí)取代了原有的UCS-2和UCS-4。UTF(Unicode Transformation Format)編碼格式保留了UCS-4中的前17個(gè)平面（U+000000 - U+10FFFF）作為有效編碼空間。其中UTF-16是UCS-2的擴(kuò)展：對(duì)于BMP內(nèi)的字符，它和UCS-2的編碼相同（2字節(jié)）；對(duì)于BMP以外的字符則采用一對(duì)16位字組合(surrogate pairs)的方式進(jìn)行編碼（4字節(jié)）。組合編碼的高字位（High Surrogate）在U+D800–U+DBFF，低字位（Low Surrogate）在U+DC00-U+DFFF。UTF-32則是在有效編碼空間范圍內(nèi)，對(duì)所有字符全部使用4字節(jié)編碼。
除了UTF-16和UTF-32，還有一種常用的Unicode編碼UTF-8。接下來(lái)我們分析這幾種編碼有什么區(qū)別。使用系統(tǒng)自帶的記事本和Debug工具，我們可以比較，在不同編碼下將字符串"漢字ABC"保存到Text文件后在內(nèi)存中的表示：
編碼形式編碼結(jié)果（含BOM）
UTF-8EF BB BF E6 B1 89 E8 AF AD 41 42 43
UTF-16 LEFF FE 49 6C ED 8B 41 00 42 00 43 00
UTF-16 BEFE FF 6C 49 8B ED 00 41 00 42 00 43
UTF-32 LEFF FE 00 00 49 6C 00 00 ED 8B 00 00 41 00 00 00 42 00 00 00 43 00 00 00
UTF-32 BE00 00 FE FF 00 00 6C 49 00 00 8B ED 00 00 00 41 00 00 00 42 00 00 00 43
表2.1 Unicode編碼形式
我們發(fā)現(xiàn)，在Windows的平面文件中，每種Unicode編碼都用一串字節(jié)來(lái)標(biāo)識(shí)自己。我們把這串連續(xù)的字節(jié)稱為
BOM (Byte-order Mark，字節(jié)順序標(biāo)識(shí))。它使用一個(gè)特殊字符U+FEFF (ZERO WIDTH NO-BREAK SPACE)來(lái)表示編碼形式和字節(jié)順序。
為什么會(huì)有字節(jié)順序呢？說(shuō)道這里，就要補(bǔ)一補(bǔ)基本知識(shí)了?，F(xiàn)代的計(jì)算機(jī)系統(tǒng)一般采用字節(jié)(Octet, 8 bit Byte)作為邏輯尋址單位。當(dāng)物理單位的長(zhǎng)度大于1個(gè)字節(jié)時(shí)，就要區(qū)分字節(jié)順序(Byte Order, or
Endianness)。常見(jiàn)的字節(jié)順序有兩種：Big Endian(High-byte first)和Little Endian(Low-byte first)，這就是表2.1中的BE和LE。Intel X86平臺(tái)采用Little Endian，而PowerPC處理器則采用了Big Endian。舉例來(lái)說(shuō)，整型數(shù)字$1234ABCD存儲(chǔ)的時(shí)候就會(huì)有兩種方式：
字節(jié)順序內(nèi)存數(shù)據(jù)備注
Big Endian (BE)
0xAB 0xCD 0x12 0x34此時(shí)的0xAB被稱為
most significant byte (MSB)
Little Endian (LE)
0xCD 0xAB 0x34 0x12此時(shí)的0xCD被稱為
least significant byte (LSB)
表2.2 字節(jié)順序
需要注意的是，DBCS編碼仍以字節(jié)作為基本編碼單元，因而不會(huì)有字節(jié)順序問(wèn)題，而Unicode使用16位字(WORD)來(lái)編碼，所以才會(huì)有LE和BE之分。另外從表2.1中我們可以看出UTF-8并沒(méi)有字節(jié)順序問(wèn)題，使用BOM只是為了標(biāo)識(shí)而已。
接下來(lái)我們一起看看UTF-8的編碼方法：
編碼范圍
UTF-8
U-00000000 – U-0000007F0xxxxxxx
U-00000080 – U-000007FF110xxxxx 10xxxxxx
U-00000800 – U-0000FFFF1110xxxx 10xxxxxx 10xxxxxx
U-00010000 – U-001FFFFF11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
表2.3 UTF-8 編碼方法
我們先看看“漢”字的UTF-8編碼?！皾h”字U+6C49用二進(jìn)制表示是：0110 1100 0100 1001，對(duì)應(yīng)U-00000800 – U-0000FFFF區(qū)間，將這些二進(jìn)制位放入對(duì)應(yīng)的位置后就變成了：11100110 10110001 10001001，再將其轉(zhuǎn)換成十六進(jìn)制是E6 B1 89。因此我們不難算出字符串“漢字ABC”用UTF-8編碼后變?yōu)椤癊6 B1 89 E8 AF AD 41 42 43”，這也和表2.1中的數(shù)據(jù)一致。
分析完常見(jiàn)的幾種Unicode編碼格式，我們來(lái)總結(jié)一下這幾種編碼格式所需要的字節(jié)個(gè)數(shù)以及各自的優(yōu)缺點(diǎn)。
編碼范圍
UTF-8
UTF-16
UTF-32
GB18030 *
U+000000 – U+00007F
1
2
4
1
U+000080 – U+00009F
U+0000A0 – U+0003FF
U+000400 – U+0007FF
2
2
4
2
U+000800 – U+003FFF
U+004000 – U+00FFFF
3
2
4
2
U+010000 – U+03FFFF
U+040000 – U+10FFFF
4
4
4
4
表2.4 常見(jiàn)Unicode編碼所需的字節(jié)數(shù)
備注：GB18030并不是真正意義上的Unicode編碼，僅作參考
UTF-8、UTF-16和UTF-32都可以表示有效編碼空間(U+000000-U+10FFFF)內(nèi)的所有Unicode字符。
使用UTF-8編碼時(shí)ASCII字符只占1個(gè)字節(jié)，存儲(chǔ)效率比較高，適用于拉丁字符較多的場(chǎng)合以節(jié)省空間。
對(duì)于大多數(shù)非拉丁字符（如中文和日文）來(lái)說(shuō)，UTF-16所需存儲(chǔ)空間最小，每個(gè)字符只占2個(gè)字節(jié)。
Windows NT內(nèi)核是Unicode（UTF-16），采用UTF-16編碼在調(diào)用系統(tǒng)API時(shí)無(wú)需轉(zhuǎn)換，處理速度也比較快。
采用UTF-16和UTF-32會(huì)有LE和BE之分，而UTF-8則沒(méi)有字節(jié)順序問(wèn)題，所以UTF-8適合傳輸和通信。
UTF-32采用4字節(jié)編碼，一方面處理速度比較快，但另一方面也浪費(fèi)了大量空間，影響傳輸速度，因而很少使用
