轉載：http://www.cnblogs.com/KevinYang/archive/2010/06/18/1760597.html
字符編碼的問題看似很小，經常被技術人員忽視，但是很容易導致一些莫名其妙的問題。這裏總結了一下字符編碼的一些普及性的知識，希望對大家有所幫助。
還是得從ASCII 碼說起
說到字符編碼，不得不說ASCII 碼的簡史。計算機一開始發明的時候是用來解決數字計算的問題，後來人們發現，計算機還可以做更多的事，例如文本處 理。但由於計算機只識“ 數” ，因此人們必須告訴計算機哪個數字來代表哪個特定字符，例如65 代表字母‘A’ ，66 代表字母‘B’ ，以此類推。但是計算機之間字符- 數字的對應關係必須得一致，否則就會造成同一段數字在不同計算機上顯示出來的字符不一樣 。因此美國國家標準協會ANSI 制定了一個標準，規定了常用字符的集合以及每個字符對應的編號，這就是ASCII 字符集（Character Set ），也稱ASCII 碼。
當時的計算機普遍使用8 比特字節作爲最小的存儲和處理單元，加之當時用到的字符也很少，26 個大小寫英文字母還有數字再加上其他常用符號，也不到100 個，因此使用7 個比特位就可以高效的存儲和處理ASCII 碼，剩下最高位1 比特被用作一些通訊系統的奇偶校驗。
注意，字節代表系統能夠處理的最小單位，不一定是8 比特。只是現代計算機的事實標準就是用8 比特來代表一個字節。在很多技術規格文獻中，爲了避免產 生歧義，更傾向於使用8 位組（Octet ）而不是字節（Byte ）這個術語來強調8 個比特的二進制流。下文中爲了便於理解，我會延用大家熟悉的“ 字節” 這 個概念。
ASCII 字符集由95 個可打印字符（0x20-0x7E ）和33 個控制字符（0x00-0x19 ，0x7F ）組成。可打印字符用於顯示在輸出設備 上，例如熒屏或者打印紙上，控制字符用於向計算機發出一些特殊指令，例如0x07 會讓計算機發出嗶的一聲，0x00 通常用於指示字符串的結束，0x0D 和 0x0A 用於指示打印機的打印針頭退到行首（回車）並移到下一行（換行）。
那時候的字符編解碼系統非常簡單，就是簡單的查表過程。例如將字符序列編碼爲二進制流寫入存儲設備，只需要在ASCII 字符集中依次找到字符對應的字節，然後直接將該字節寫入存儲設備即可。解碼二進制流的過程也是類似。
OEM 字符集的衍生
當計算機開始發展起來的時候，人們逐漸發現，ASCII 字符集裏那可憐的128 個字符已經不能再滿足他們的需求了。人們就在想，一個字節能夠表示的 數字（編號）有256 個，而ASCII 字符只用到了0x00~0x7F ，也就是佔用了前128 個，後面128 個數字不用白不用，因此很多人打起了後面這 128 個數字的主意。可是問題在於，很多人同時有這樣的想法，但是大家對於0x80-0xFF 這後面的128 個數字分別對應什麼樣的字符，卻有各自的想 法。這就導致了當時銷往世界各地的機器上出現了大量各式各樣的OEM 字符集。
下面這張表是IBM-PC 機推出的其中一個OEM 字符集，字符集的前128 個字符和ASCII 字符集的基本一致（爲什麼說基本一致呢，是因爲前32 個控制字符在某些情況下會被IBM-PC 機當作可打印字符解釋），後面128 個字符空間加入了一些歐洲國家用到的重音字符，以及一些用於畫線條畫的字符。
事實上，大部分OEM 字符集是兼容ASCII 字符集的，也就是說，大家對於0x00~0x7F 這個範圍的解釋基本是相同的，而對於後半部分0x80~0xFF 的解釋卻不一定相同。甚至有時候同樣的字符在不同OEM 字符集中對應的字節也是不同的。
不同的OEM 字符集導致人們無法跨機器交流各種文檔。例如職員甲發了一封簡歷résumés 給職員乙，結果職員乙看到的卻是r sum s ，因爲é 字符在職員甲機器上的OEM 字符集中對應的字節是0x82 ，而在職員乙的機器上，由於使用的OEM 字符集不同，對0x82 字節解碼後得到的字符卻是 。
多字節字符集（MBCS ）和中文字符集
上面我們提到的字符集都是基於單字節編碼，也就是說，一個字節翻譯成一個字符。這對於拉丁語系國家來說可能沒有什麼問題，因爲他們通過擴展第8 個比 特，就可以得到256 個字符了，足夠用了。但是對於亞洲國家來說，256 個字符是遠遠不夠用的。因此這些國家的人爲了用上電腦，又要保持和ASCII 字符 集的兼容，就發明了多字節編碼方式，相應的字符集就稱爲多字節字符集。例如中國使用的就是雙字節字符集編碼（DBCS ，Double Byte Character Set ）。
對於單字節字符集來說，代碼頁中只需要有一張碼錶即可，上面記錄着256 個數字代表的字符。程序只需要做簡單的查表操作就可以完成編解碼的過程。
代碼頁是字符集編碼的具體實現，你可以把他理解爲一張“ 字符- 字節” 映射表，通過查表實現“ 字符- 字節” 的翻譯。下面會有更詳細的描述。
而對於多字節字符集，代碼頁中通常會有很多碼錶。那麼程序怎麼知道該使用哪張碼錶去解碼二進制流呢？答案是，根據第一個字節來選擇不同的碼錶進行解析 。
例如目前最常用的中文字符集GB2312 ，涵蓋了所有簡體字符以及一部分其他字符；GBK （K 代表擴展的意思）則在GB2312 的基礎上加入了對繁 體字符等其他非簡體字符（GB18030 字符集不是雙字節字符集，我們在講Unicode 的時候會提到）。這兩個字符集的字符都是使用1-2 個字節來表 示。Windows 系統採用936 代碼頁來實現對GBK 字符集的編解碼。在解析字節流的時候，如果遇到字節的最高位是0 的話，那麼就使用936 代碼頁中的 第1 張碼錶進行解碼，這就和單字節字符集的編解碼方式一致了。
當字節的高位是1 的時候，確切的說，當第一個字節位於0x81–0xFE 之間時，根據第一個字節不同找到代碼頁中的相應的碼錶，例如當第一個字節是0x81 ，那麼對應936 中的下面這張碼錶：
（關於936 代碼頁中完整的碼錶信息，參見MSDN ：http://msdn.microsoft.com/en-us/library/cc194913%28v=MSDN.10%29.aspx . ）
按照936 代碼頁的碼錶，當程序遇到連續字節流0x81 0x40 的時候，就會解碼爲“ 丂” 字符。
ANSI 標準、國家標準、ISO 標準
不同ASCII 衍生字符集的出現，讓文檔交流變得非常困難，因此各種組織都陸續進行了標準化流程。例如美國ANSI 組織制定了ANSI 標準字符編碼（注意，我們現在通常說到ANSI 編碼，通常指的是平臺的默認編碼，例如英文操作系統中是ISO-8859-1 ，中文系統是GBK ），ISO 組織制定的各種ISO 標準字符編碼，還有各國也會制定一些國家標準字符集，例如中國的GBK ，GB2312 和GB18030 。
操作系統在發佈的時候，通常會往機器裏預裝這些標準的字符集還有平臺專用的字符集，這樣只要你的文檔是使用標準字符集編寫的，通用性就比較高了。例 如你用GB2312 字符集編寫的文檔，在中國大陸內的任何機器上都能正確顯示。同時，我們也可以在一臺機器上閱讀多個國家不同語言的文檔了，前提是本機必 須安裝該文檔使用的字符集。
Unicode 的出現
雖然通過使用不同字符集，我們可以在一臺機器上查閱不同語言的文檔，但是我們仍然無法解決一個問題：在一份文檔中顯示所有字符 。爲了解決這個問題，我們需要一個全人類達成共識的巨大的字符集，這就是Unicode 字符集。
Unicode 字符集概述
Unicode 字符集涵蓋了目前人類使用的所有字符，併爲每個字符進行統一編號，分配唯一的字符碼（Code Point ）。Unicode 字符集將所有字符按照使用上的頻繁度劃分爲17 個層面（Plane ），每個層面上有216 =65536 個字符碼空間。
其中第0 個層面BMP ，基本涵蓋了當今世界用到的所有字符。其他的層面要麼是用來表示一些遠古時期的文字，要麼是留作擴展。我們平常用到的Unicode 字符，一般都是位於BMP 層面上的。目前Unicode 字符集中尚有大量字符空間未使用。
編碼系統的變化
在Unicode 出現之前，所有的字符集都是和具體編碼方案綁定在一起的，都是直接將字符和最終字節流綁定死了，例如ASCII 編碼系統規定使用7 比特來編碼ASCII 字符集；GB2312 以及GBK 字符集，限定了使用最多2 個字節來編碼所有字符，並且規定了字節序。這樣的編碼系統通常用簡單的查 表，也就是通過代碼頁就可以直接將字符映射爲存儲設備上的字節流了。例如下面這個例子：
這種方式的缺點在於，字符和字節流之間耦合得太緊密了，從而限定了字符集的擴展能力。假設以後火星人入住地球了，要往現有字符集中加入火星文就變得很難甚至不可能了，而且很容易破壞現有的編碼規則。
因此Unicode 在設計上考慮到了這一點，將字符集和字符編碼方案分離開。
也就是說，雖然每個字符在Unicode 字符集中都能找到唯一確定的編號（字符碼，又稱Unicode 碼），但是決定最終字節流的卻是具體的字符編碼 。例如同樣是對Unicode 字符“A” 進行編碼，UTF-8 字符編碼得到的字節流是0x41 ，而UTF-16 （大端模式）得到的是0x00 0x41 。
常見的Unicode 編碼
UCS-2/UTF-16
如果要我們來實現Unicode 字符集中BMP 字符的編碼方案，我們會怎麼實現？由於BMP 層面上有216 =65536 個字符碼，因此我們只需要兩個字節就可以完全表示這所有的字符了。
舉個例子，“ 中” 的Unicode 字符碼是0x4E2D(01001110 00101101) ，那麼我們可以編碼爲01001110 00101101 （大端）或者00101101 01001110 （小端）。
UCS-2 和UTF-16 對於BMP 層面的字符均是使用2 個字節來表示，並且編碼得到的結果完全一致。不同之處在於，UCS- 2 最初設計的時候只考慮到BMP 字符，因此使用固定2 個字節長度，也就是說，他無法表示Unicode 其他層面上的字符，而UTF-16 爲了解除這個限 制，支持Unicode 全字符集的編解碼，採用了變長編碼，最少使用2 個字節，如果要編碼BMP 以外的字符，則需要4 個字節結對 ，這裏就不討論那麼遠，有興趣可以參考維基百科：UTF-16/UCS-2 。
Windows 從NT 時代開始就採用了UTF-16 編碼，很多流行的編程平臺，例如.Net ，Java ，Qt 還有Mac 下的Cocoa 等都是使用UTF-16 作爲基礎的字符編碼。例如代碼中的字符串，在內存中相應的字節流就是用UTF-16 編碼過的。
UTF-8
UTF-8 應該是目前應用最廣泛的一種Unicode 編碼方案。由於UCS-2/UTF-16 對於ASCII 字符使用兩個字節進行編碼，存儲和處理 效率相對低下，並且由於ASCII 字符經過UTF-16 編碼後得到的兩個字節，高字節始終是0x00 ，很多C 語言的函數都將此字節視爲字符串末尾從而導致 無法正確解析文本。因此一開始推出的時候遭到很多西方國家的抵觸，大大影響了Unicode 的推行。後來聰明的人們發明了UTF-8 編碼，解決了這個問 題。
UTF-8 編碼方案採用1-4 個字節來編碼字符，方法其實也非常簡單。
（上圖中的x 代表Unicode 碼的低8 位，y 代表高8 位）
對於ASCII 字符的編碼使用單字節，和ASCII 編碼一摸一樣， 這樣所有原先使用ASCII 編解碼的文檔就可以直接轉到UTF-8 編碼了。對於其他字符，則使用2-4 個字節來表示，其中，首字節前置1 的數目代表正確解 析所需要的字節數，剩餘字節的高2 位始終是10 。例如首字節是1110yyyy ，前置有3 個1 ，說明正確解析總共需要3 個字節，需要和後面2 個以10 開頭 的字節結合才能正確解析得到字符 。
關於UTF-8 的更多信息，參考維基百科：UTF-8 。
GB18030
任何能夠將Unicode 字符映射爲字節流的編碼都屬於Unicode 編碼。中國的GB18030 編碼，覆蓋了Unicode 所有的字符，因此也算 是一種Unicode 編碼。只不過他的編碼方式並不像UTF-8 或者UTF-16 一樣，將Unicode 字符的編號通過一定的規則進行轉換，而只能通過查 表的手段進行編碼。
關於GB18030 的更多信息，參考：GB18030 。
Unicode 相關的常見問題
Unicode 是兩個字節嗎？
Unicode 只是定義了一個龐大的、全球通用的字符集，併爲每個字符規定了唯一確定的編號，具體存儲爲什麼樣的字節流，取決於字符編碼方案。推薦的Unicode 編碼是UTF-16 和UTF-8 。
帶簽名的UTF-8 指的是什麼意思？
帶簽名指的是字節流以BOM 標記開始。很多軟件會“ 智能” 的探測當前字節流使用的字符編碼，這種探測過程出於效率考慮，通常會提取字節流前面若干個 字節，看看是否符合某些常見字符編碼的編碼規則。由於UTF-8 和ASCII 編碼對於純英文的編碼是一樣的，無法區分開來，因此通過在字節流最前面添加 BOM 標記可以告訴軟件，當前使用的是Unicode 編碼，判別成功率就十分準確了。但是需要注意，不是所有軟件或者程序都能正確處理BOM 標記，例如 PHP 就不會檢測BOM 標記，直接把它當普通字節流解析了。因此如果你的PHP 文件是採用帶BOM 標記的UTF-8 進行編碼的，那麼有可能會出現問題。
Unicode 編碼和以前的字符集編碼有什麼區別？
早期字符編碼、字符集和代碼頁等概念都是表達同一個意思。例如GB2312 字符集、GB2312 編碼，936 代碼頁，實際上說的是同個東西。但是對 於Unicode 則不同，Unicode 字符集只是定義了字符的集合和唯一編號，Unicode 編碼，則是對UTF-8 、UCS-2/UTF-16 等具體 編碼方案的統稱而已，並不是具體的編碼方案。所以當需要用到字符編碼的時候，你可以寫gb2312 ，codepage936 ，utf-8 ，utf-16 ， 但請不要寫unicode （看過別人在網頁的meta 標籤裏頭寫charset=unicode ，有感而發）。