由習翔宇發表在天碼營

1 ASCII碼

說到字元編碼，不得不說ASCII碼的簡史。計算機一開始發明的時候是用來解決數字計算的問題，後來人們發現，計算機還可以做更多的事，例如文本處理。但由於計算機只識「數」，因此人們必須告訴計算機哪個數字來代表哪個特定字元，例如65代表字母『A』，66代表字母『B』，以此類推。但是計算機之間字元-數字的對應關係必須得一致，否則就會造成同一段數字在不同計算機上顯示出來的字元不一樣。因此美國國家標準協會ANSI制定了一個標準，規定了常用字元的集合以及每個字元對應的編號，這就是ASCII字符集（Character Set），也稱ASCII碼。

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

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

那時候的字元編解碼系統非常簡單，就是簡單的查表過程。例如將字元序列編碼為二進位流寫入存儲設備，只需要在ASCII字符集中依次找到字元對應的位元組，然後直接將該位元組寫入存儲設備即可。解碼二進位流的過程也是類似。

2 OEM字符集

當計算機開始發展起來的時候，人們逐漸發現，ASCII字符集里那可憐的128個字元已經不能再滿足他們的需求了。人們就在想，一個位元組能夠表示的數字（編號）有256個，而ASCII字元只用到了0x00~0x7F，也就是佔用了前128個，後面128個數字不用白不用，因此很多人打起了後面這128個數字的主意。可是問題在於，很多人同時有這樣的想法，但是大家對於0x80-0xFF這後面的128個數字分別對應什麼樣的字元，卻有各自的想法。這就導致了當時銷往世界各地的機器上出現了大量各式各樣的OEM字符集。

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

3 多位元組字符集MBSC(Multiple Byte Charset Set)

上面我們提到的字符集都是基於單位元組編碼，也就是說，一個位元組翻譯成一個字元。這對於拉丁語系國家來說可能沒有什麼問題，因為他們通過擴展第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中的下面這張碼錶

4 ANSI標準、國家標準、ISO標準

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

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

5 unicode

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

Unicode字符集涵蓋了目前人類使用的所有字元，並為每個字元進行統一編號，分配唯一的字元碼（Code Point）。Unicode字符集將所有字元按照使用上的頻繁度劃分為17個層面（Plane），每個層面上有216=65536個字元碼空間。

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

5.1 編碼系統的變化

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

這種方式的缺點在於，字元和位元組流之間耦合得太緊密了，從而限定了字符集的擴展能力。假設以後火星人入住地球了，要往現有字符集中加入火星文就變得很難甚至不可能了，而且很容易破壞現有的編碼規則。

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

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

5.2 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開頭的位元組結合才能正確解析得到字元。

5.3 GB18030

任何能夠將Unicode字元映射為位元組流的編碼都屬於Unicode編碼。中國的GB18030編碼，覆蓋了Unicode所有的字元，因此也算是一種Unicode編碼。只不過他的編碼方式並不像UTF-8或者UTF-16一樣，將Unicode字元的編號通過一定的規則進行轉換，而只能通過查表的手段進行編碼。

5.4 容易混淆的概念

5.4.1 unicode 是兩個位元組嗎？

Unicode只是定義了一個龐大的、全球通用的字符集，並為每個字元規定了唯一確定的編號，具體存儲為什麼樣的位元組流，取決於字元編碼方案。推薦的Unicode編碼是UTF-16和UTF-8。

5.4.2 Unicode編碼和以前的字符集編碼有什麼區別？

早期字元編碼、字符集和代碼頁等概念都是表達同一個意思。例如GB2312字符集、GB2312編碼，936代碼頁，實際上說的是同個東西。但是對於Unicode則不同，Unicode字符集只是定義了字元的集合和唯一編號，Unicode編碼，則是對UTF-8、UCS-2/UTF-16等具體編碼方案的統稱而已，並不是具體的編碼方案。所以當需要用到字元編碼的時候，你可以寫gb2312，codepage936，utf-8，utf-16，但請不要寫unicode

6 必要的術語解釋

6.1 字符集(Character Set)

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

6.2 字元碼

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

6.3 字元編碼

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

6.4 代碼頁

一種字元編碼具體形式。早期字元相對少，因此通常會使用類似表格的形式將字元直接映射為位元組流，然後通過查表的方式來實現字元的編解碼。現代操作系統沿用了這種方式。例如Windows使用936代碼頁、Mac系統使用EUC-CN代碼頁實現GBK字符集的編碼，名字雖然不一樣，但對於同一漢字的編碼肯定是一樣的。

6.5 大小端

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

歡迎關注天碼營微信公眾號： TMY-EDU

小編重點推薦：

Spring MVC實戰入門訓練

Spring Data JPA實戰入門訓練

Java Web實戰訓練

Node.js全棧開發

更多精彩內容請訪問天碼營網站
推薦閱讀：