關於字符編碼，你所須要知道的（ASCII,Unicode,Utf-8,GB2312…）

在生活中，純數字沒有意義，如110能夠是分數，能夠是電話號碼，也能夠是money，數字只有在具體語境中才有意義。計算機只能存儲0和1，它的意義就靠編碼方式來肯定，一樣的數字在不一樣的編碼方式的解釋下意義不一樣。

 

 

字符編碼的問題看似很小，常常被技術人員忽視，可是很容易致使一些莫名其妙的問題。這裏總結了一下字符編碼的一些普及性的知識，但願對你們有所幫助。

仍是得從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給職員乙，結果職員乙看到的倒是rsums，由於é字符在職員甲機器上的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），每一個層面上有2¹⁶=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層面上有2¹⁶=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-八、UCS-2/UTF-16等具體 編碼方案的統稱而已，並非具體的編碼方案。因此當須要用到字符編碼的時候，你能夠寫gb2312，codepage936，utf-8，utf-16， 但請不要寫unicode（看過別人在網頁的meta標籤裏頭寫charset=unicode，有感而發）。

亂碼問題

亂碼指的是程序顯示出來的字符文本沒法用任何語言去解讀。通常狀況下會包含大量或者?。亂碼問題是全部計算機用戶或多或少會遇到的問題。形成亂碼的緣由就是由於使用了錯誤的字符編碼去解碼字節流，所以當咱們在思考任何跟文本顯示有關的問題時，請時刻保持清醒：當前使用的字符編碼是什麼。只有這樣，咱們才能正確分析和處理亂碼問題。

例如最多見的網頁亂碼問題。若是你是網站技術人員，遇到這樣的問題，須要檢查如下緣由：

• 服務器返回的響應頭Content-Type沒有指明字符編碼
• 網頁內是否使用META HTTP-EQUIV標籤指定了字符編碼
• 網頁文件自己存儲時使用的字符編碼和網頁聲明的字符編碼是否一致

注意，網頁解析的過程若是使用的字符編碼不正確，還可能會致使腳本或者樣式表出錯。具體細節能夠參考我之前寫過的文章：文檔字符集致使的腳本錯誤和Asp.Net頁面的編碼問題。

不久前看到某技術論壇有人反饋，WinForm程序使用Clipboard類的GetData方法去訪問剪切板中的HTML內容時會出現亂碼的問 題，我估計也是因爲WinForm在獲取HTML文本的時候沒有用對正確的字符編碼致使的。Windows剪貼板只支持UTF-8編碼，也就是說你傳入的 文本都會被UTF-8編解碼。這樣一來，只要兩個程序都是調用Windows剪切板API編程的話，那麼複製粘貼的過程當中不會出現亂碼。除非一方在獲取到 剪貼板數據以後使用了錯誤的字符編碼進行解碼，纔會獲得亂碼（我作了簡單的WinForm剪切板編程實驗，發現GetData使用的是系統默認編碼，而不 是UTF-8編碼）。

關於亂碼中出現?或者?，這裏須要額外提一下，當程序使用特定字符編碼解析字節流的時候，一旦遇到沒法解析的字節流時，就會用或者?來替代。所以，一旦你最終解析獲得的文本包含這樣的字符，而你又沒法獲得原始字節流的時候，說明正確的信息已經完全丟失了，嘗試任何字符編碼都沒法從這樣的字符文本中還原出正確的信息來。

必要的術語解釋

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

字符碼（Code Point）指的就是字符集中每一個字符的數字編號。例如ASCII字符集用0-127這連續 的128個數字分別表示128個字符；GBK字符集使用區位碼的方式爲每一個字符編號，首先定義一個94X94的矩陣，行稱爲「區」，列稱爲「位」，而後將 全部國標漢字放入矩陣當中，這樣每一個漢字就能夠用惟一的「區位」碼來標識了。例如「中」字被放到54區第48位，所以字符碼就是5448。而 Unicode中將字符集按照必定的類別劃分到0~16這17個層面（Planes）中，每一個層面中擁有2¹⁶=65536個字符碼，所以Unicode總共擁有的字符碼，也便是Unicode的字符空間總共有17*65536=1114112。

 

編碼的過程是將字符轉換成字節流。

解碼的過程是將字節流解析爲字符。

字符編碼（Character Encoding）是將字符集中的字符碼映射爲字節流的一種具體實現方案。例如 ASCII字符編碼規定使用單字節中低位的7個比特去編碼全部的字符。例如‘A’的編號是65，用單字節表示就是0x41，所以寫入存儲設備的時候就是 b’01000001’。GBK編碼則是將區位碼（GBK的字符碼）中的區碼和位碼的分別加上0xA0（160）的偏移（之因此要加上這樣的偏移，主要是 爲了和ASCII碼兼容），例如剛剛提到的「中」字，區位碼是5448，十六進制是0x3630，區碼和位碼分別加上0xA0的偏移以後就獲得 0xD6D0，這就是「中」字的GBK編碼結果。

代碼頁（Code Page）一種字符編碼具體形式。早期字符相對少，所以一般會使用相似表格的形式將字符直接 映射爲字節流，而後經過查表的方式來實現字符的編解碼。現代操做系統沿用了這種方式。例如Windows使用936代碼頁、Mac系統使用EUC-CN代 碼頁實現GBK字符集的編碼，名字雖然不同，但對於同一漢字的編碼確定是同樣的。

大小端的說法源自《格列佛遊記》。咱們知道，雞蛋一般一端大一端小，小人國的人們對於剝蛋殼時應從哪一端開始剝 起有着不同的見解。一樣，計算機界對於傳輸多字節字（由多個字節來共同表示一個數據類型）時，是先傳高位字節（大端）仍是先傳低位字節（小端）也有着不 同樣的見解，這就是計算機裏頭大小端模式的由來了。不管是寫文件仍是網絡傳輸，實際上都是往流設備進行寫操做的過程，並且這個寫操做是從流的低地址向高地 址開始寫（這很符合人的習慣），對於多字節字來講，若是先寫入高位字節，則稱做大端模式。反之則稱做小端模式。也就是說，大端模式下，字節序和流設備的地 址順序是相反的，而小端模式則是相同的。通常網絡協議都採用大端模式進行傳輸，windows操做系統採用Utf-16小端模式。

——Kevin Yang

參考連接：

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• http://developers.sun.com/dev/gadc/technicalpublications/articles/gb18030.html
• http://en.wikipedia.org/wiki/Universal_Character_Set
• http://en.wikipedia.org/wiki/Code_page

 

轉自：http://www.imkevinyang.com/2010/06/%E5%85%B3%E4%BA%8E%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81%EF%BC%8C%E4%BD%A0%E6%89%80%E9%9C%80%E8%A6%81%E7%9F%A5%E9%81%93%E7%9A%84.html