轉自 Kevin Yang

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

還是得從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字符集的，也就是説，大家對於0x000x7F這個範圍的解釋基本是相同的，而對於後半部分0x800xFF的解釋卻不一定相同。甚至有時候同樣的字符在不同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），每個層面上有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-8、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小端模式。

參考鏈接：

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

Unicode 和 UTF-8 有什么区别？

轉發自知乎 盛世唐朝 https://www.zhihu.com/question/23374078

很久很久以前，有一群人，他們決定用8個可以開合的晶體管來組合成不同的狀態，以表示世界上的萬物。他們看到8個開關狀態是好的，於是他們把這稱為”字節“。再後來，他們又做了一些可以處理這些字節的機器，機器開動了，可以用字節來組合出很多狀態，狀態開始變來變去。他們看到這樣是好的，於是它們就這機器稱為”計算機“。

開始計算機只在美國用。八位的字節一共可以組合出256(2的8次方)種不同的狀態。
他們把其中的編號從0開始的32種狀態分別規定了特殊的用途，一但終端、打印機遇上約定好的這些字節被傳過來時，就要做一些約定的動作：
遇上0×10, 終端就換行；
遇上0×07, 終端就向人們嘟嘟叫；
遇上0x1b, 打印機就打印反白的字，或者終端就用彩色顯示字母。
他們看到這樣很好，於是就把這些0×20以下的字節狀態稱為”控制碼”。他們又把所有的空
格、標點符號、數字、大小寫字母分別用連續的字節狀態表示，一直編到了第127號，這樣計算機就可以用不同字節來存儲英語的文字了。大家看到這樣，都感覺很好，於是大家都把這個方案叫做 ANSI 的”Ascii”編碼（American Standard Code for Information Interchange，美國信息互換標準代碼）。當時世界上所有的計算機都用同樣的ASCII方案來保存英文文字。

後來，就像建造巴比倫塔一樣，世界各地都開始使用計算機，但是很多國家用的不是英文，他們的字母裏有許多是ASCII裏沒有的，為了可以在計算機保存他們的文字，他們決定採用 127號之後的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一個狀態255。從128 到255這一頁的字符集被稱”擴展字符集“。從此之後，貪婪的人類再沒有新的狀態可以用了，美帝國主義可能沒有想到還有第三世界國家的人們也希望可以用到計算機吧！

等中國人們得到計算機時，已經沒有可以利用的字節狀態來表示漢字，況且有6000多個常用漢字需要保存呢。但是這難不倒智慧的中國人民，我們不客氣地把那些127號之後的奇異符號們直接取消掉, 規定：一個小於127的字符的意義與原來相同，但兩個大於127的字符連在一起時，就表示一個漢字，前面的一個字節（他稱之為高字節）從0xA1用到0xF7，後面一個字節（低字節）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裏，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 裏本來就有的數字、標點、字母都統統重新編了兩個字節長的編碼，這就是常説的”全角”字符，而原來在127號以下的那些就叫”半角”字符了。中國人民看到這樣很不錯，於是就把這種漢字方案叫做 “GB2312“。GB2312 是對 ASCII 的中文擴展。

但是中國的漢字太多了，我們很快就就發現有許多人的人名沒有辦法在這裏打出來，特別是某些很會麻煩別人的國家領導人。於是我們不得不繼續把GB2312 沒有用到的碼位找出來老實不客氣地用上。後來還是不夠用，於是乾脆不再要求低字節一定是127號之後的內碼，只要第一個字節是大於127就固定表示這是一個漢字的開始，不管後面跟的是不是擴展字符集裏的內容。結果擴展之後的編碼方案被稱為GBK 標準，GBK包括了GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。 後來少數民族也要用電腦了，於是我們再擴展，又加了幾千個新的少數民族的字，GBK擴成了 GB18030。從此之後，中華民族的文化就可以在計算機時代中傳承了。 中國的程序員們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 “DBCS“（Double Byte Charecter Set 雙字節字符集）。在DBCS系列標準裏，最大的特點是兩字節長的漢字字符和一字節長的英文字符並存於同一套編碼方案裏，因此他們寫的程序為了支持中文處理，必須要注意字串裏的每一個字節的值，如果這個值是大於127的，那麼就認為一個雙字節字符集裏的字符出現了。那時候凡是受過加持，會編程的計算機僧侶們都要每天念下面這個咒語數百遍： “一個漢字算兩個英文字符！一個漢字算兩個英文字符……”

因為當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支持別人的編碼，連大陸和台灣這樣只相隔了150海里，使用着同一種語言的兄弟地區，也分別採用了不同的 DBCS 編碼方案——當時的中國人想讓電腦顯示漢字，就必須裝上一個”漢字系統”，專門用來處理漢字的顯示、輸入的問題，像是那個台灣的愚昧封建人士寫的算命程序就必須加裝另一套支持 BIG5 編碼的什麼”倚天漢字系統”才可以用，裝錯了字符系統，顯示就會亂了套！這怎麼辦？而且世界民族之林中還有那些一時用不上電腦的窮苦人民，他們的文字又怎麼辦？ 真是計算機的巴比倫塔命題啊！

正在這時，大天使加百列及時出現了——一個叫 ISO（國際標誰化組織）的國際組織決定着手解決這個問題。他們採用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符號 的編碼！他們打算叫它”Universal Multiple-Octet Coded Character Set”，簡稱 UCS, 俗稱 “unicode“。

unicode開始制訂時，計算機的存儲器容量極大地發展了，空間再也不成為問題了。於是 ISO 就直接規定必須用兩個字節，也就是16位來統一表示所有的字符，對於ASCII裏的那些”半角”字符，unicode包持其原編碼不變，只是將其長度由原來的8位擴展為16位，而其他文化和語言的字符則全部重新統一編碼。由於”半角”英文符號只需要用到低8位，所以其高8位永遠是0，因此這種大氣的方案在保存英文文本時會多浪費一倍的空間。

這時候，從舊社會裏走過來的程序員開始發現一個奇怪的現象：他們的 strlen 函數靠不住了，一個漢字不再是相當於兩個字符了，而是一個！是的，從unicode開始，無論是半角的英文字母，還是全角的漢字，它們都是統一的”一個字符“！同時，也都是統一的”兩個字節“，請注意”字符“和”字節“兩個術語的不同，”字節“是一個8位的物理存貯單元，而”字符“則是一個文化相關的符號。在unicode中，一個字符就是兩個字節。一個漢字算兩個英文字符的時代已經快過去了。

unicode同樣也不完美，這裏就有兩個的問題，一個是，如何才能區別unicode和ascii？計算機怎麼知道三個字節表示一個符號，而不是分別表示三個符號呢？第二個問題是，我們已經知道，英文字母只用一個字節表示就夠了，如果unicode統一規定，每個符號用三個或四個字節表示，那麼每個英文字母前都必然有二到三個字節是0，這對於存儲空間來説是極大的浪費，文本文件的大小會因此大出二三倍，這是難以接受的。

unicode在很長一段時間內無法推廣，直到互聯網的出現，為解決unicode如何在網絡上傳輸的問題，於是面向傳輸的眾多 UTF（UCS Transfer Format）標準出現了，顧名思義，UTF-8就是每次8個位傳輸數據，而UTF-16就是每次16個位。UTF-8就是在互聯網上使用最廣的一種unicode的實現方式，這是為傳輸而設計的編碼，並使編碼無國界，這樣就可以顯示全世界上所有文化的字符了。UTF-8最大的一個特點，就是它是一種變長的編碼方式。它可以使用1~4個字節表示一個符號，根據不同的符號而變化字節長度，當字符在ASCII碼的範圍時，就用一個字節表示，保留了ASCII字符一個字節的編碼做為它的一部分，注意的是unicode一箇中文字符佔2個字節，而UTF-8一箇中文字符佔3個字節）。從unicode到utf-8並不是直接的對應，而是要過一些算法和規則來轉換。

最後簡單總結一下：

• 中國人民通過對 ASCII 編碼的中文擴充改造，產生了 GB2312 編碼，可以表示6000多個常用漢字。
• 漢字實在是太多了，包括繁體和各種字符，於是產生了 GBK 編碼，它包括了 GB2312 中的編碼，同時擴充了很多。
• 中國是個多民族國家，各個民族幾乎都有自己獨立的語言系統，為了表示那些字符，繼續把 GBK 編碼擴充為 GB18030 編碼。
• 每個國家都像中國一樣，把自己的語言編碼，於是出現了各種各樣的編碼，如果你不安裝相應的編碼，就無法解釋相應編碼想表達的內容。
• 終於，有個叫 ISO 的組織看不下去了。他們一起創造了一種編碼 UNICODE ，這種編碼非常大，大到可以容納世界上任何一個文字和標誌。所以只要電腦上有 UNICODE 這種編碼系統，無論是全球哪種文字，只需要保存文件的時候，保存成 UNICODE 編碼就可以被其他電腦正常解釋。
• UNICODE 在網絡傳輸中，出現了兩個標準 UTF-8 和 UTF-16，分別每次傳輸 8個位和 16個位。於是就會有人產生疑問，UTF-8 既然能保存那麼多文字、符號，為什麼國內還有這麼多使用 GBK 等編碼的人？因為 UTF-8 等編碼體積比較大，佔電腦空間比較多，如果面向的使用人群絕大部分都是中國人，用 GBK 等編碼也可以。