「MISC」字符編碼 - ASCII, EASCII, ANSI, EUC, GBK, Unicode, UTF-8

編程的過程中，難免會碰到一些關於編碼的問題，其中對於使用簡體中文的中國人來講最多見的就是 UTF-8 和 GBK 。
大部分的時候都可以使用語言內置的轉換函數或者一些庫來進行編碼的檢測和轉碼，可是當出現一些亂碼的時候，每每有些不知所措，不知道爲何會出現這樣的碼點，也不知如何去解決它。這主要是因爲對編碼方式的極度不瞭解。但若是知道不一樣的格式是如何編碼的，程序是如何解析的，那麼亂碼的問題便不是問題。

下面會對 ASCII, EASCII, ANSI, EUC, GB2312, GBK, UNICODE, UTF-8 和與之相關的一些術語進行解釋，相關的編碼方式進行闡述，從根本上解決讓人頭疼的編碼問題。

ASCII

ASCII - American Standard Code for Information Interchange

古老（1967）的編碼方式，也是最簡單的編碼方式，使用 7 bits 囊括了26個基本拉丁字母、阿拉伯數字、經常使用英文標點符合和彼時經常使用的控制字符，但如今大部分的ASCII控制字符都已經被廢棄使用。
簡單的編碼會讓編碼解碼變得簡單，可是缺點也顯而易見——它沒法知足其餘語言的編碼需求。

下圖是 ISO/IEC 646 定義的標準的 ASCII 7 bits 碼錶，其容許各國對除了英文字母和數字的其餘部分修改，以知足本國需求。

EASCII

EASCII - Extended American Standard Code for Information Interchange

EASCII 顧名思義，其在ASCII的基礎上拓展了1 bit，總共達到了8 bits，能夠多顯示128個字符。
EASCII 編碼方式比較混亂，在不一樣的平臺和協議上常常不相同，但咱們主要接觸到的有兩種：ISO/IEC 8859-1 (Latin-1)，Code page 437。

在這裏有必要補充說明一下什麼是代碼頁（Code page）。
代碼頁是windows上命令行中的編碼表，不一樣的代碼頁標識着不一樣的編碼方式，下面是其中一些代碼頁編號對應的編碼方式：

• 437: OEM United States

• 1252: ANSI Latin 1; Western European (Windows)

• 65001: Unicode (UTF-8)

• 936: ANSI/OEM Simplified Chinese (PRC, Singapore); Chinese Simplified (GB2312); GBK

• ...

其中代碼頁1252與 ISO/IEC 8859-1 (Latin-1)基本一致，如下兩圖分別爲代碼頁1252和代碼頁437：

Windows所有的代碼頁對應表能夠查看 https://msdn.microsoft.com/en...

ANSI

ANSI - American National Standards Institute

這個名稱的來歷，是一個很是長的故事。咱們如今說的，常常看到的通常都是Window的記事本另存爲裏面的ANSI編碼。

它確實是ANSI這個機構所發佈的 8-bit 編碼標準（雖然基本上是抄 ISO 8859）。可是微軟使用編碼標準的時候沒有注意到其實ANSI是一套標準，僅僅將它表示Latin-1。
後來逐步的，Windows的國際版本愈來愈多。如今，Windows上面的ANSI編碼表明的是操做系統本地的默認代碼頁，例如在中文版Windows10上就指的是GBK。

許多文章說 GBK、BIG-5 是屬於ANSI編碼的，其實不對。

EUC

EUC - Extended Unix Code

EUC 是一個符合 ISO 2022 標準的 8-bit 的編碼方法。
EUC 定義了4個碼集：

• CS0：ASCII 7 bits編碼標準，即 ISO 646；一個字節

• CS1: MSB(最高有效位)必須爲1，0xA0-0xFF；任意字節數

• CS2: MSB必須爲1，第一個字節必須爲0x8E，0xA0-0xFF；任意字節數

• CS3: MSB必須爲1，第一個字節必須爲0x8F，0xA0-0xFF；任意字節數

CS1，CS2，CS3規定範圍在0xA0-0xFF實際上是爲了兼容 ISO 2022

每一個碼集中都要知足以下條件：

• 碼集中每一個字符都須要使用 相同的字節數

• 碼集中每一個字符在等寬終端中都顯示相同的寬度

也就是說，我決定將某些字符用CS1中的碼來編碼，那麼這些落在CS1中的字符必須所有是一個、兩個、三個、... 、N個字節，不容許在同一個碼集的字符有些是一個字節，有些又是其餘數量的字節。

GB2312, GBK

GB - 國標

1. • 擴(展)

GB2312又稱GB0，是EUC的一種實現，它只使用了CS1，而且規定CS1爲兩個字節。
上面已經詳細的介紹了EUC，那麼GB2312的編碼方式也很是明朗了。遇到MSB爲0的，則讀取一個字節；而遇到MSB爲1的，則讀取兩個字節。

拋開具體的字節編碼，來看GB2312的設計思路：
它一共分爲81個區：

• 01-09：特殊符號

• 16-55：一級漢字（經常使用漢字），拼音排序

• 56-87：二級漢字（很是用漢字），部首/筆畫排序

其中10-15，88-94區未有編碼，每一個區（從1開始編號）有94（區號 + 0xA0）個字；因此第一個漢字的編碼就是(0xA0 + 16) + (0xA0 + 1) = 0xB0A1

關於GBK就不解釋太多，只須要知道GBK是GB2312的拓展，向後兼容。

Unicode

Unicode - 一種可以囊括全部字符的編碼標準

Unicode分爲(0-16)平面+16位編碼空間，大部分的經常使用語言的經常使用字符都落在0平面內，也就是0x0000-0xFFFF。
爲了向前兼容，Unicode的前256個字符爲上面說的ISO標準 8-bit 標準（ISO 8859-1）

0 平面也稱爲基本多文種平面(BMP)，各個平面的用途以下：

Wikipedia - Unicode字符平面映射

ʕ•̀ω•́ʔ✧ 就是這麼簡單，不比上面各個編碼如此複雜

UTF-8

UTF-8 - 8-bit Unicode Transformation Format

既然已經有了編碼標準了，接下來就要考慮的就是怎麼樣把它存到計算機裏了。
若是嚴格的按照Unicode的標準（UTF-32）來存儲的話，平面編號佔兩個字節，編碼空間佔兩個字節，那麼不論是隻須要7bits的ASCII碼抑或是能夠用兩個字節來表示的經常使用中文，就都得佔據四個字節，未免也太浪費（內存、儲存空間和帶寬資源等）了。

UTF-8是一種變長儲存的編碼實現方式，對於不一樣的字符用1~6個字節來表示。
由於是變長，因此計算機如何區分一個字符是幾個字節呢？規則以下：

• ASCII碼範圍（0x00-0x7F），使用一個字節表示

• 超過以上範圍的，第一個字節的連續前多少位是1就表示這個字符使用幾個字節，例如第一個字節爲 0b1110xxxx 就表示包括這個字節在內的，接下來三個字節表示此字符。

其實上面這張圖我認爲將後面6列放到最前面比較合適，可是擺到後面比較好看

能夠看到，上面的 x 表明的是有效儲存位，其餘的都是用來起標識做用的。那麼咱們的中文到底佔幾個字節呢？
查表可知，經常使用漢字的Unicode編碼落在基本多文種平面的0x4E00-0x9FFF（中日韓統一表意文字），即三個字節。

認真的人看到這裏確定會有一個疑問，爲何多字節字符除了第一個字節之外，後面的字節仍是要以0b10開頭呢？

讓咱們把目光放到上圖，能夠看到第一個字節沒有以0b10開頭的。若是後面的字節使用了所有的空間，程序每次定位一個位置都要從頭開始查找，由於程序並不知道當前這個字節是不是第一個字節；而若是使用0b10做爲開頭的話，程序只須要向前查找不是0b10開頭的字節，就能夠知道它是當前字符的起始字節。

BOM

BOM - Byte-order Mark

因爲UTF-16和UTF-32是定長編碼，因此在編碼單元裏面存在大端和小端儲存的問題，因此制定瞭如下規則來標識文件：

雖然UTF-8這種變長的編碼方式不存在大端小端的問題，可是仍是指定了BOM來表示這個文件是UTF-8。在實際的使用過程中儘可能不要對UTF-8添加BOM，不然不少軟件解析都會出現問題。

以後遇到文件前有兩個或者三個不知道是什麼的字節的時候就不用驚慌了。

• 爲何 UTF-8 沒有字節序，UTF-1 6和 UTF-32 有字節序？

• 大端模式和小端模式

編碼檢測

一直以來都對 notepad++ 等一干智能編輯器如何自動檢測文件編碼很是好奇，趁此機會查了下資料。

基本上全部的編碼檢測都不是徹底可靠的，都是根據字節的模式統計分析來肯定最可能的編碼，so~
其中能被最可靠的探測到的編碼就是UTF-8了，根據上文，UTF-8有大量的0b10xxxxxx以及首字節的定式編碼，因此通常來講不是很容易被檢測錯誤。

---

✧⁺⸜(●˙▾˙●)⸝⁺✧ 寫了一個月的文章完結撒花 ✧⁺⸜(●˙▾˙●)⸝⁺✧