字符編碼的問題看似很小，經(jīng)常被技術(shù)人員忽視,，但是很容易導(dǎo)致一些莫名其妙的問題,。這里總結(jié)了一下字符編碼的一些普及性的知識，希望對大家有所幫 助,。

還是得從ASCII碼說起

說到字符編碼,，不得不說ASCII碼的簡史。計算機一開始發(fā)明的時候是用來解決數(shù)字計算的問題,，后來人們發(fā)現(xiàn)，計算機還可以做更多的事,，例如文本處 理,。但由于計算機只識“數(shù)”，因此人們必須告訴計算機哪個數(shù)字來代表哪個特定字符,，例如65代表字母‘A’,，66代表字母‘B’，以此類推,。但是 計算機之間字符-數(shù)字的對應(yīng)關(guān)系必須得一致,，否則就會造成同一段數(shù)字在不同計算機上顯 示出來的字符不一樣 。因此美國國家標準協(xié)會ANSI制定了一個標準,，規(guī)定了常用字符的集合以及每個字符對應(yīng)的編號,，這就 是ASCII字符集（Character Set），也稱ASCII碼,。

當時的計算機普遍使用8比特字節(jié)作為最小的存儲和處理單元,，加之當時用到的字符也很少，26個大小寫英文字母還有數(shù)字再加上其他常用符號，也不到 100個,，因此使用7個比特位就可以高效的存儲和處理ASCII碼,，剩下最高位1比特被用作一些通訊系統(tǒng)的奇偶校驗。

注意,，字節(jié)代表系統(tǒng)能夠處理的最小單位,，不一定是8比特。只是現(xiàn)代計算機的事實標準就是用8比特來代表一個字節(jié),。在很多技術(shù)規(guī)格文獻中,，為了避免產(chǎn) 生歧義，更傾向于使用8位組（Octet）而不是字節(jié)（Byte）這個術(shù)語來強調(diào)8個比特的二進制流,。下文中為了便于理解,，我會延用大家熟悉的“字節(jié)”這 個概念。

ASCII字符集由95個可打印字符（0x20-0x7E）和33個控制字符（0x00-0x19,，0x7F）組成,。可打印字符用于顯示在輸出設(shè)備 上,，例如熒屏或者打印紙上,，控制字符用于向計算機發(fā)出一些特殊指令，例如0x07會讓計算機發(fā)出嗶的一聲,，0x00通常用于指示字符串的結(jié)束,，0x0D和 0x0A用于指示打印機的打印針頭退到行首（回車）并移到下一行（換行）。

那時候的字符編解碼系統(tǒng)非常簡單,，就是簡單的查表過程,。例如將字符序列編碼為二進制流寫入存儲設(shè)備，只需要在ASCII字符集中依次找到字符對應(yīng)的 字節(jié),，然后直接將該字節(jié)寫入存儲設(shè)備即可,。解碼二進制流的過程也是類似。

OEM字符集的衍生

當計算機開始發(fā)展起來的時候,，人們逐漸發(fā)現(xiàn),，ASCII字符集里那可憐的128個字符已經(jīng)不能再滿足他們的需求了。人們就在想,，一個字節(jié)能夠表示的 數(shù)字（編號）有256個,，而ASCII字符只用到了0x00~0x7F，也就是占用了前128個,，后面128個數(shù)字不用白不用,，因此很多人打起了后面這 128個數(shù)字的主意?？墒菃栴}在于,，很多人同時有這樣的想法，但是大家對于0x80-0xFF這后面的128個數(shù)字分別對應(yīng)什么樣的字符，卻有各自的想 法,。這就導(dǎo)致了當時銷往世界各地的機器上出現(xiàn)了大量各式各樣的OEM字符集,。

下面這張表是IBM-PC機推出的其中一個OEM字符集，字符集的前128個字符和ASCII字符集的基本一致（為什么說基本一致呢,，是因為前32 個控制字符在某些情況下會被IBM-PC機當作可打印字符解釋）,，后面128個字符空間加入了一些歐洲國家用到的重音字符，以及一些用于畫線條畫的字符,。

事實上,，大部分OEM字符集是兼容ASCII字符集的，也就是說,，大家對于0x00~0x7F這個范圍的解釋基本是相同的,，而對于后半部分 0x80~0xFF的解釋卻不一定相同。甚至有時候同樣的字符在不同OEM字符集中對應(yīng)的字節(jié)也是不同的,。

不同的OEM字符集導(dǎo)致人們無法跨機器交流各種文檔,。例如職員甲發(fā)了一封簡歷résumés給職員乙，結(jié)果職員乙看到的卻是rsums,，因為é字符在職員甲機器上的OEM字符集中對應(yīng)的字節(jié)是0x82,，而在職員乙的機 器上，由于使用的OEM字符集不同,，對0x82字節(jié)解碼后得到的字符卻是,。

多字節(jié)字符集（MBCS）和中文字符集

上面我們提到的字符集都是基于單字節(jié)編碼，也就是說,，一個字節(jié)翻譯成一個字符,。這對于拉丁語系國家來說可能沒有什么問題，因為他們通過擴展第8個比 特,，就可以得到256個字符了,，足夠用了。但是對于亞洲國家來說,，256個字符是遠遠不夠用的,。因此這些國家的人為了用上電腦,，又要保持和ASCII字符 集的兼容,，就發(fā)明了多字節(jié)編碼方式，相應(yīng)的字符集就稱為多字節(jié)字符集,。例如中國使用的就是雙字節(jié)字符集編碼（DBCS,，Double Byte Character Set）。

對于單字節(jié)字符集來說,，代碼頁中只需要有一張碼表即可,，上面記錄著256個數(shù)字代表的字符。程序只需要做簡單的查表操作就可以完成編解碼的過程。

代碼頁是字符集編碼的具體實現(xiàn),，你可以把他理解為一張“字符-字節(jié)”映射表,，通過查表實現(xiàn)“字符-字節(jié)”的翻譯。下面會有更詳細的描述,。

而對于多字節(jié)字符集,，代碼頁中通常會有很多碼表。那么程序怎么知道該使用哪張碼表去解碼二進制流呢,？答案是,， 根據(jù)第一個字節(jié)來選擇不同的碼表進行解析 。

例如目前最常用的中文字符集GB2312,，涵蓋了所有簡體字符以及一部分其他字符,；GBK（K代表擴展的意思）則在GB2312的基礎(chǔ)上加入了對繁 體字符等其他非簡體字符（GB18030字符集不是雙字節(jié)字符集，我們在講Unicode的時候會提到）,。這兩個字符集的字符都是使用1-2個字節(jié)來表 示,。Windows系統(tǒng)采用936代碼頁來實現(xiàn)對GBK字符集的編解碼。在解析字節(jié)流的時候,，如果遇到字節(jié)的最高位是0的話,，那么就使用936代碼頁中的 第1張碼表進行解碼，這就和單字節(jié)字符集的編解碼方式一致了,。

當字節(jié)的高位是1的時候,，確切的說，當?shù)谝粋€字節(jié)位于0x81–0xFE之間時,，根據(jù)第一個字節(jié)不同找到代 碼頁中的相應(yīng)的碼表,，例如當?shù)谝粋€字節(jié)是0x81，那么對應(yīng)936中的下面這張碼表：

（關(guān)于936代碼頁中完整的碼表信息,，參見MSDN：http://msdn.microsoft.com/en-us/library/cc194913%28v=MSDN.10%29.aspx.）

按照936代碼頁的碼表,，當程序遇到連續(xù)字節(jié)流0x81 0x40的時候，就會解碼為“丂”字符,。

ANSI標準,、國家標準、ISO標準

不同ASCII衍生字符集的出現(xiàn),，讓文檔交流變得非常困難,，因此各種組織都陸續(xù)進行了標準化流程。例如美國ANSI組織制定了ANSI標準字符編碼 （注意,， 我們現(xiàn)在通常說到ANSI編碼,，通常指的是平臺的 默認編碼，例如英文操作系統(tǒng)中是ISO-8859-1,，中文系統(tǒng)是GBK ）,，ISO組織制定的各種ISO標準字符編碼,， 還有各國也會制定一些國家標準字符集，例如中國的GBK,，GB2312和GB18030,。

操作系統(tǒng)在發(fā)布的時候，通常會往機器里預(yù)裝這些標準的字符集還有平臺專用的字符集,，這樣只要你的文檔是使用標準字符集編寫的,，通用性就比較高了。例 如你用GB2312字符集編寫的文檔,，在中國大陸內(nèi)的任何機器上都能正確顯示,。同時，我們也可以在一臺機器上閱讀多個國家不同語言的文檔了,，前提是本機必 須安裝該文檔使用的字符集,。

Unicode的出現(xiàn)

雖然通過使用不同字符集，我們可以在一臺機器上查閱不同語言的文檔,，但是我們?nèi)匀粺o法解決一個問題： 在一份文檔中顯示所有字符 ,。為了解決這個問題，我們需 要一個全人類達成共識的巨大的字符集,，這就是Unicode字符集,。

Unicode字符集概述

Unicode字符集涵蓋了目前人類使用的所有字符，并為每個字符進行統(tǒng)一編號,，分配唯一的字符碼（Code Point）,。Unicode字符集將所有字符按照使用上的頻繁度劃分為17個層面（Plane），每個層面上有2¹⁶=65536 個字符碼空間,。

其中第0個層面BMP,，基本涵蓋了當今世界用到的所有字符。其他的層面要么是用來表示一些遠古時期的文字,，要么是留作擴展,。我們平常用到的 Unicode字符，一般都是位于BMP層面上的,。目前Unicode字符集中尚有大量字符空間未使用,。

編碼系統(tǒng)的變化

在Unicode出現(xiàn)之前，所有的字符集都是和具體編碼方案綁定在一起的,，都是直接將字符和最終字節(jié)流綁定死了,，例如ASCII編碼系統(tǒng)規(guī)定使用7 比特來編碼ASCII字符集；GB2312以及GBK字符集,，限定了使用最多2個字節(jié)來編碼所有字符,，并且規(guī)定了字節(jié)序,。這樣的編碼系統(tǒng)通常用簡單的查 表,，也就是通過代碼頁就可以直接將字符映射為存儲設(shè)備上的字節(jié)流了,。例如下面這個例子：

這種方式的缺點在于，字符和字節(jié)流之間耦合得太緊密了,，從而限定了字符集的擴展能力,。假設(shè)以后火星人入住地球了，要往現(xiàn)有字符集中加入火星文就變得 很難甚至不可能了,，而且很容易破壞現(xiàn)有的編碼規(guī)則,。

因此Unicode在設(shè)計上考慮到了這一點，將字符集和字符編碼方案分離開,。

也就是說,， 雖然每個字符在Unicode字符集中都 能找到唯一確定的編號（字符碼，又稱Unicode碼）,，但是決定最終字節(jié)流的卻是具體的字符編碼 ,。例如同樣是對 Unicode字符“A”進行編碼，UTF-8字符編碼得到的字節(jié)流是0x41,，而UTF-16（大端模式）得到的是0x00 0x41,。

常見的Unicode編碼

UCS-2/UTF-16

如果要我們來實現(xiàn)Unicode字符集中BMP字符的編碼方案，我們會怎么實現(xiàn),？由于BMP層面上有2¹⁶=65536個字 符碼,，因此我們只需要兩個字節(jié)就可以完全表示這所有的字符了。

舉個例子,，“中”的Unicode字符碼是0x4E2D(01001110 00101101),，那么我們可以編碼為01001110 00101101（大端）或者00101101 01001110 （小端）。

UCS-2和UTF-16對于BMP層面的字符均是使用2個字節(jié)來表示,，并且編碼得到的結(jié)果完全一致,。不同之處在于， UCS-2最初設(shè)計的時候只考慮到BMP字符,，因此使用固定2個字節(jié)長度,，也就是說，他 無法表示Unicode其他層面上的字符,，而UTF-16為了解除這個限制,，支持Unicode全字符集的編解碼，采用了變長編碼,，最少使用2個字節(jié),，如 果要編碼BMP以外的字符，則需要4個字節(jié)結(jié)對 ,，這里就不討論那么遠,，有興趣可以參考維基百科：UTF-16/UCS-2。

Windows從NT時代開始就采用了UTF-16編碼,，很多流行的編程平臺,，例如.Net,，Java，Qt還有Mac下的Cocoa等都是使用 UTF-16作為基礎(chǔ)的字符編碼,。例如代碼中的字符串,，在內(nèi)存中相應(yīng)的字節(jié)流就是用UTF-16編碼過的。

UTF-8

UTF-8應(yīng)該是目前應(yīng)用最廣泛的一種Unicode編碼方案,。由于UCS-2/UTF-16對于ASCII字符使用兩個字節(jié)進行編碼,，存儲和處理 效率相對低下，并且由于ASCII字符經(jīng)過UTF-16編碼后得到的兩個字節(jié),，高字節(jié)始終是0x00,，很多C語言的函數(shù)都將此字節(jié)視為字符串末尾從而導(dǎo)致 無法正確解析文本。因此一開始推出的時候遭到很多西方國家的抵觸,，大大影響了Unicode的推行,。后來聰明的人們發(fā)明了UTF-8編碼，解決了這個問 題,。

UTF-8編碼方案采用1-4個字節(jié)來編碼字符,，方法其實也非常簡單。

（上圖中的x代表Unicode碼的低8位,，y代表高8位）

對于ASCII字符的編碼使用單字節(jié),，和ASCII 編碼一摸一樣，這樣所有原先使用ASCII編解碼的文檔就可以直接轉(zhuǎn)到UTF-8編碼了,。對于其他字符,，則使用2-4個字節(jié)來表示，其中,，首字節(jié)前置1的 數(shù)目代表正確解析所需要的字節(jié)數(shù),，剩余字節(jié)的高2位始終是10。例如首字節(jié)是1110yyyy,，前置有3個1,，說明正確解析總共需要3個字節(jié)，需要和后面 2個以10開頭的字節(jié)結(jié)合才能正確解析得到字符 ,。

關(guān)于UTF-8的更多信息,，參考維基百科：UTF-8。

GB18030

任何能夠?qū)nicode字符映射為字節(jié)流的編碼都屬于Unicode編碼,。中國的GB18030編碼,，覆蓋了Unicode所有的字符，因此也算 是一種Unicode編碼,。只不過他的編碼方式并不像UTF-8或者UTF-16一樣,，將Unicode字符的編號通過一定的規(guī)則進行轉(zhuǎn)換，而只能通過查 表的手段進行編碼,。

關(guān)于GB18030的更多信息,，參考：GB18030,。

Unicode相關(guān)的常見問題

Unicode是兩個字節(jié)嗎？

Unicode只是定義了一個龐大的,、全球通用的字符集，并為每個字符規(guī)定了唯一確定的編號,，具體存儲為什么樣的字節(jié)流,，取決于字符編碼方案。推薦 的Unicode編碼是UTF-16和UTF-8,。

帶簽名的UTF-8指的是什么意思,？

帶簽名指的是字節(jié)流以BOM標記開始。很多軟件會“智能”的探測當前字節(jié)流使用的字符編碼,，這種探測過程出于效率考慮,，通常會提取字節(jié)流前面若干個 字節(jié)，看看是否符合某些常見字符編碼的編碼規(guī)則,。由于UTF-8和ASCII編碼對于純英文的編碼是一樣的,，無法區(qū)分開來，因此通過在字節(jié)流最前面添加 BOM標記可以告訴軟件,，當前使用的是Unicode編碼,，判別成功率就十分準確了。但是需要注意,，不是所有軟件或者程序都能正確處理BOM標記,，例如 PHP就不會檢測BOM標記，直接把它當普通字節(jié)流解析了,。因此如果你的PHP文件是采用帶BOM標記的UTF-8進行編碼的,，那么有可能會出現(xiàn)問題。

Unicode編碼和以前的字符集編碼有什么區(qū)別,？

早期字符編碼,、字符集和代碼頁等概念都是表達同一個意思。例如GB2312字符集,、GB2312編碼,，936代碼頁，實際上說的是同個東西,。但是對 于Unicode則不同,，Unicode字符集只是定義了字符的集合和唯一編號，Unicode編碼,，則是對UTF-8,、UCS-2/UTF-16等具體 編碼方案的統(tǒng)稱而已，并不是具體的編碼方案,。所以當需要用到字符編碼的時候,，你可以寫gb2312,，codepage936，utf-8,，utf-16,， 但請不要寫unicode（看過別人在網(wǎng)頁的meta標簽里頭寫charset=unicode，有感而發(fā)）,。

亂碼問題

亂碼指的是程序顯示出來的字符文本無法用任何語言去解讀,。一般情況下會包含大量?或者?。亂碼問題是所有計算機用戶或多或少會遇到的問題,。 造成亂碼的原因就是因為使用了錯誤的字符編碼去解碼字節(jié)流 ,， 因此當我們在思考任何跟文本顯示有關(guān)的問題時，請時刻保持清醒：當前使用的字符編碼是什么 ,。只有這樣,，我們才 能正確分析和處理亂碼問題。

例如最常見的網(wǎng)頁亂碼問題,。如果你是網(wǎng)站技術(shù)人員,，遇到這樣的問題，需要檢 查以下原因：

• 服務(wù)器返回的響應(yīng)頭Content-Type沒有指明字符編碼
• 網(wǎng)頁內(nèi)是否使用META HTTP-EQUIV標簽指定了字符編碼
• 網(wǎng)頁文件本身存儲時使用的字符編碼和網(wǎng)頁聲明的字符編碼是否一致  

注意,，網(wǎng)頁解析的過程如果使用的字符編碼不正確,，還可能會導(dǎo)致腳本或者樣式表出錯。具體細節(jié)可以參考我以前寫過的文章：文 檔字符集導(dǎo)致的腳本錯誤和Asp.Net 頁面的編碼問題,。

不久前看到某技術(shù)論壇有人反饋,，WinForm程序使用Clipboard類的GetData方法去訪問剪切板中的HTML內(nèi)容時會出現(xiàn)亂碼的問 題，我估計也是由于WinForm在獲取HTML文本的時候沒有用對正確的字符編碼導(dǎo)致的,。Windows剪貼板只支持UTF-8編碼,，也就是說你傳入的 文本都會被UTF-8編解碼。這樣一來,，只要兩個程序都是調(diào)用Windows剪切板API編程的話,，那么復(fù)制粘貼的過程中不會出現(xiàn)亂碼。除非一方在獲取到 剪貼板數(shù)據(jù)之后使用了錯誤的字符編碼進行解碼,，才會得到亂碼（我做了簡單的WinForm剪切板編程實驗,，發(fā)現(xiàn)GetData使用的是系統(tǒng)默認編碼，而不 是UTF-8編碼）,。

關(guān)于亂碼中出現(xiàn)?或者?,，這里需要額外提一下， 當程 序使用特定字符編碼解析字節(jié)流的時候,，一旦遇到無法解析的字節(jié)流時,，就會用?或者?來替代。因此，一旦你最終解析得到的文本包含這樣的字符,，而你又無法得 到原始字節(jié)流的時候,，說明正確的信息已經(jīng)徹底丟失了，嘗試任何字符編碼都無法從這樣的字符文本中還原出正確的信息來 ,。

必要的術(shù)語解釋

字符集（Character Set） ,，字面上的理解就是字符的集合，例如ASCII字符集,，定義了128個字 符,；GB2312定義了7445個字符。而 計算機系統(tǒng)中提 到的字符集準確來說,，指的是已編號的字符的有序集合（不一定是連續(xù)） ,。

字符碼（Code Point） 指的就是字符集中每個字符的數(shù)字編號,。例如ASCII字符集用0-127這連續(xù) 的128個數(shù)字分別表示128個字符,；GBK字符集使用區(qū)位碼的方式為每個字符編號，首先定義一個94X94的矩陣,，行稱為“區(qū)”,，列稱為“位”，然后將 所有國標漢字放入矩陣當中,，這樣每個漢字就可以用唯一的“區(qū)位”碼來標識了,。例如“中”字被放到54區(qū)第48位，因此字符碼就是5448,。而 Unicode中將字符集按照一定的類別劃分到0~16這17個層面（Planes）中,，每個層面中擁有2¹⁶=65536個字符 碼，因此Unicode總共擁有的字符碼,，也即是Unicode的字符空間總共有17*65536=1114112,。

編碼 的過程是將字符轉(zhuǎn)換成字節(jié)流。

解碼 的過程是將字節(jié)流解析為字符,。

字符編碼（Character Encoding） 是將字符集中的字符碼映射為字節(jié)流的一種具體實現(xiàn)方案,。例如 ASCII字符編碼規(guī)定使用單字節(jié)中低位的7個比特去編碼所有的字符。例如‘A’的編號是65,，用單字節(jié)表示就是0x41,，因此寫入存儲設(shè)備的時候就是 b’01000001’。GBK編碼則是將區(qū)位碼（GBK的字符碼）中的區(qū)碼和位碼的分別加上0xA0（160）的偏移（之所以要加上這樣的偏移,，主要是 為了和ASCII碼兼容）,，例如剛剛提到的“中”字，區(qū)位碼是5448,，十六進制是0x3630,，區(qū)碼和位碼分別加上0xA0的偏移之后就得到 0xD6D0，這就是“中”字的GBK編碼結(jié)果。

代碼頁（Code Page） 一種字符編碼具體形式,。早期字符相對少,，因此通常會使用類似表格的形式將字符直接 映射為字節(jié)流，然后通過查表的方式來實現(xiàn)字符的編解碼?，F(xiàn)代操作系統(tǒng)沿用了這種方式,。例如Windows使用936代碼頁、Mac系統(tǒng)使用EUC-CN代 碼頁實現(xiàn)GBK字符集的編碼,，名字雖然不一樣,，但對于同一漢字的編碼肯定是一樣的。

大小端 的說法源自《格列佛游記》,。我們知道,，雞蛋通常一端大一端小，小人國的人們對于剝蛋殼時應(yīng)從哪一端開始剝 起有著不一樣的看法,。同樣,，計算機界對于傳輸多字節(jié)字（由多個字節(jié)來共同表示一個數(shù)據(jù)類型）時，是先傳高位字節(jié)（大端）還是先傳低位字節(jié)（小端）也有著不 一樣的看法,，這就是計算機里頭大小端模式的由來了,。無論是寫文件還是網(wǎng)絡(luò)傳輸，實際上都是往流設(shè)備進行寫操作的過程,，而且這個寫操作是從流的低地址向高地 址開始寫（這很符合人的習慣）,，對于多字節(jié)字來說，如果先寫入高位字節(jié),，則稱作大端模式,。反之則稱作小端模式。也就是說,，大端模式下,，字節(jié)序和流設(shè)備的地 址順序是相反的，而小端模式則是相同的,。一般網(wǎng)絡(luò)協(xié)議都采用大端模式進行傳輸,。