編碼問題詳解

搞清經常使用編碼特性是解決字符集編碼問題的基礎。字符集編碼的識別與轉換、分析各類亂碼產生的緣由、編程操做各類編碼字符串（例如字符數計算、截斷處理）等都須要弄清楚編碼的特性。

瞭解一種字符集編碼主要是要了解該編碼的編碼範圍，編碼對應的字符集（都包含哪些字符），和其餘字符集編碼之間的關係等。

ASCII

ASCII碼是7位編碼，編碼範圍是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯數字和標點符號等字符。其中0x00-0x20和0x7F共33個控制字符。

只支持ASCII碼的系統會忽略每一個字節的最高位，只認爲低7位是有效位。HZ字符編碼就是早期爲了在只支持7位ASCII系統中傳輸中文而設計的編碼。早期不少郵件系統也只支持ASCII編碼，爲了傳輸中文郵件必須使用BASE64或者其餘編碼方式。

GB2312

GB2312是基於區位碼設計的，區位碼把編碼表分爲94個區，每一個區對應94個位，每一個字符的區號和位號組合起來就是該漢字的區位碼。區位碼通常 用10進制數來表示，如1601就表示16區1位，對應的字符是「啊」。在區位碼的區號和位號上分別加上0xA0就獲得了GB2312編碼。

區位碼中01-09區是符號、數字區，16-87區是漢字區，10-15和88-94是未定義的空白區。它將收錄的漢字分紅兩級：第一級是經常使用漢字 計3755個，置於16-55區，按漢語拼音字母/筆形順序排列；第二級漢字是次經常使用漢字計3008個，置於56-87區，按部首/筆畫順序排列。一級漢 字是按照拼音排序的，這個就能夠獲得某個拼音在一級漢字區位中的範圍，不少根據漢字能夠獲得拼音的程序就是根據這個原理編寫的。

GB2312字符集中除經常使用簡體漢字字符外還包括希臘字母、日文平假名及片假名字母、俄語西裏爾字母等字符，未收錄繁體中文漢字和一些生僻字。能夠用繁體漢字測試某些系統是否是隻支持GB2312編碼。

GB2312的編碼範圍是0xA1A1-0x7E7E，去掉未定義的區域以後能夠理解爲實際編碼範圍是0xA1A1-0xF7FE。

EUC-CN能夠理解爲GB2312的別名，和GB2312徹底相同。

區位碼更應該認爲是字符集的定義，定義了所收錄的字符和字符位置，而GB2312及EUC-CN是實際計算機環境中支持這 種字符集的編碼。HZ和ISO-2022-CN是對應區位碼字符集的另外兩種編碼，都是用7位編碼空間來支持漢字。區位碼和GB2312編碼的關係有點像 Unicode和UTF-8。

GBK

GBK編碼是GB2312編碼的超集，向下徹底兼容GB2312，同時GBK收錄了Unicode基本多文種平面中的全部CJK漢字。同 GB2312同樣，GBK也支持希臘字母、日文假名字母、俄語字母等字符，但不支持韓語中的表音字符（非漢字字符）。GBK還收錄了GB2312不包含的 漢字部首符號、豎排標點符號等字符。

GBK的總體編碼範圍是爲0x8140-0xFEFE，不包括低字節是0×7F的組合。高字節範圍是0×81-0xFE，低字節範圍是0x40-7E和0x80-0xFE。

低字節是0x40-0x7E的GBK字符有必定特殊性，由於這些字符佔用了ASCII碼的位置，這樣會給一些系統帶來麻煩。

有些系統中用0x40-0x7E中的字符（如「|」）作特殊符號，在定位這些符號時又沒有判斷這些符號是否是屬於某個 GBK字符的低字節，這樣就會形成錯誤判斷。在支持GB2312的環境下就不存在這個問題。須要注意的是支持GBK的環境中小於0x80的某個字節未必就 是ASCII符號；另外就是最好選用小於0×40的ASCII符號作一些特殊符號，這樣就能夠快速定位，且不用擔憂是某個漢字的另外一半。Big5編碼中也存在相應問題。

CP936和GBK的有些許差異，絕大多數狀況下能夠把CP936看成GBK的別名。

GB18030

GB18030編碼向下兼容GBK和GB2312，兼容的含義是不只字符兼容，並且相同字符的編碼也相同。GB18030收錄了全部Unicode3.1中的字符，包括中國少數民族字符，GBK不支持的韓文字符等等，也能夠說是世界大多民族的文字符號都被收錄在內。

GBK和GB2312都是雙字節等寬編碼，若是算上和ASCII兼容所支持的單字節，也能夠理解爲是單字節和雙字節混合的變長編碼。GB18030編碼是變長編碼，有單字節、雙字節和四字節三種方式。

GB18030的單字節編碼範圍是0x00-0x7F，徹底等同與ASCII；雙字節編碼的範圍和GBK相同，高字節是0x81-0xFE，低字節 的編碼範圍是0x40-0x7E和0x80-FE；四字節編碼中第1、三字節的編碼範圍是0x81-0xFE，2、四字節是0x30-0x39。

Windows中CP936代碼頁使用0x80來表示歐元符號，而在GB18030編碼中沒有使用0x80編碼位，用其餘位置來表示歐元符號。這能夠理解爲是GB18030向下兼容性上的一點小問題；也能夠理解爲0x80是CP936對GBK的擴展，而GB18030只是和GBK兼容良好。

BIG5

Big5是雙字節編碼，高字節編碼範圍是0x81-0xFE，低字節編碼範圍是0x40-0x7E和0xA1-0xFE。和GBK相比，少了低字節是0x80-0xA0的組合。0x8140-0xA0FE是保留區域，用於用戶造字區。

Big5收錄的漢字只包括繁體漢字，不包括簡體漢字，一些生僻的漢字也沒有收錄。GBK收錄的日文假名字符、俄文字符Big5也沒有收錄。由於Big5當中收錄的字符有限，所以有不少在Big5基礎上擴展的編碼，如倚天中文系統。Windows系統上使用的代碼頁CP950也能夠理解爲是對Big5的擴展，在Big5的基礎上增長了7個漢字和一些符號。Big5編碼對應的字符集是GBK字符集的子集，也就是說Big5收錄的字符是GBK收錄字符的一部分，但相同字符的編碼不一樣。

由於Big5也佔用了ASCII的編碼空間（低字節所使用的0x40-0x7E），因此Big5編碼在一些環境下存在和GBK編碼相同的問題，即低字節範圍爲0x40-0x7E的字符有可能會被誤處理，尤爲是低字節是0x5C（"/"）和0x7C（"|"）的字符。能夠參考GBK一節相應說明。

儘管有些區別，大多數狀況下能夠把CP950看成Big5的別名。

ISO-8859-1

ISO-8859-1編碼是單字節編碼，向下兼容ASCII，其編碼範圍是0x00-0xFF，0x00-0x7F之間徹底和ASCII一致，0x80-0x9F之間是控制字符，0xA0-0xFF之間是文字符號。

ISO-8859-1收錄的字符除ASCII收錄的字符外，還包括西歐語言、希臘語、泰語、阿拉伯語、希伯來語對應的文字符號。歐元符號出現的比較晚，沒有被收錄在ISO-8859-1當中。

由於ISO-8859-1編碼範圍使用了單字節內的全部空間，在支持ISO-8859-1的系統中傳輸和存儲其餘任何編碼的字節流都不會被拋棄。換言之，把其餘任何編碼的字節流看成ISO-8859-1編碼看待都沒有問題。這是個很重要的特性，MySQL數據庫默認編碼是Latin1就是利用了這個特性。ASCII編碼是一個7位的容器，ISO-8859-1編碼是一個8位的容器。

Latin1是ISO-8859-1的別名，有些環境下寫做Latin-1。

UCS-2和UTF-16

Unicode組織和ISO組織都試圖定義一個超大字符集，目的是要涵蓋全部語言使用的字符以及其餘學科使用的一些特殊符號，這個字符集就是通用字符集（UCS，Universal Character Set）。這兩個組織通過協調，雖然在各自發展，但定義的字符位置是徹底一致的。ISO相應的標準是ISO 10646。Unicode和ISO 10646都在不斷的發展過程當中，因此會有不一樣的版本號來標明不一樣的發展階段，每一個Unicode版本號都能找到相對應的ISO 10646版本號。

ISO 10646標準定義了一個31位的字符集。前兩個字節的位置（0x0000-0xFFFD）被稱爲基本多語言面（Basic Multilingual Plane, BMP） ，超出兩個字節的範圍稱做輔助語言面。BMP基本包括了全部語言中絕大多數字符，因此只要支持BMP就能夠支持絕大多數場合下的應用。Unicode 3.0對應的字符集在BMP範圍內。

UCS字符集爲每一個字符分配了一個位置，一般用「U」再加上某個字符在UCS中位置的16進制數做爲這個字符的UCS表示，例如「U+0041」表示字符「A」。UCS字符U+0000到U+00FF與ISO-8859-1徹底一致。

UCS-二、UTF-16是UCS字符集（或者說是Unicode字符集）實際應用中的具體編碼方式。UCS-2是兩個字節的等寬編碼，由於只是使用了兩個字節的編碼空間，因此只能對BMP中的字符作編碼。UTF-16是變長編碼，用兩個字節對BMP內的字符編碼，用4個字節對超出BMP範圍的輔助平面內的字符做編碼。

UCS-2不一樣於GBK和Big5，它是真正的等寬編碼，每一個字符都使用兩個字節，這個特性在字符串截斷和字符數計算時很是方便。

UTF-16是UCS-2的超集，UTF-16編碼的兩字節編碼方式徹底和UCS-2相同，也就是說在BMP的框架內UCS-2徹底等同與UTF-16。實際狀況當中經常把UCS-16看成UCS-2的別名。

UCS-2和UTF-16在存儲和傳輸時會使用兩種不一樣的字節序，分別是big endian和little endian（大尾和小尾）。例如「啊」（U+554A）用big endian表示就是0x554A，用little endian表示就是0x4A55。UCS-2和UTF-16默認的字節序是big endian方式。在傳輸過程當中爲了說明字節序須要在字節流前加上BOM（Byte order Mark），0xFEFF表示是big endian，0xFFFE表示是little endian。UCS-2BE、UCS-2LE是實際應用中使用的編碼名稱，對應着big endian和little endian，UTF-16BE、UTF-16LE也是如此。由於默認是BE字節序，因此能夠把UCS-2當作是UCS-2BE的別名。

在UCS編碼中有一個叫作「ZERO WIDTH NO-BREAK SPACE」的字符，它的編碼是U+FEFF，是個沒有實際意義的字符。UCS規範建議咱們在傳輸字節流前，先傳輸字符「ZERO WIDTH NO-BREAK SPACE」，若是傳輸的ZERO WIDTH NO-BREAK SPACE是0xFEFF就說明是big endian，反之就是little endian。

UCS-2和UTF-16也能夠理解爲和ASCII以及ISO-8859-1兼容，在ASCII編碼或者ISO-8859-1編碼的每一個字節前加上0x00，就獲得相應字符的UCS-2編碼。

UCS-2和UTF-16中會使用0x00做爲某個字符編碼的一部分，某些系統會把0x00看成字符串結束的標誌，在處理UCS-2或UTF-16編碼時會出現問題。

UTF-8

UTF-8是UCS字符集的另外一種編碼方式，UTF-16的每一個單元是兩個字節（16位），而UTF-8的每一個單元是一個字節（8位）。UTF-16中用一個或兩個雙字節表示一個字符，UTF-8中用一個或幾個單字節表示一個字符。

能夠認爲UTF-8編碼是根據必定規律從UCS-2轉換獲得的，從UCS-2到UTF-8之間有如下轉換關係：

UCS-2 UTF-8 
U+0000 - U+007F 0xxxxxxx 
U+0080 - U+07FF 110xxxxx 10xxxxxx 
U+0800 - U+FFFF 1110xxxx 10xxxxxx 10xxxxxx 


例如「啊」字的UCS-2編碼是0x554A，對應的二進制是0101 0101 0100 1010，轉成UTF-8編碼以後的二進制是1110 0101 10 010101 10 001010，對應的十六進制是0xE5958A。

UCS-4也是一種UCS字符集的編碼方式，是使用4個字節的等寬編碼，能夠用UCS-4來表示BMP以外的輔助面字符。UCS-2中每兩個字節前再加上0x0000就獲得了BMP字符的UCS-4編碼。從UCS-4到UTF-8也存在轉換關係，根據這種轉換關係，UTF-8最多可使用六個字節來編碼UCS-4。

根據UTF-8的生成規律和UCS字符集的特性，能夠看到UTF-8具備的特性：

UTF-8徹底和ASCII兼容，也就是說ASCII對應的字符在UTF-8中和ASCII編碼徹底一致。範圍在0x00-0x7F以內的字符必定是ASCII字符，不多是其餘字符的一部分。GBK和Big5都存在的缺陷在UTF-8中是不存在的。 
大於U+007F的UCS字符，在UTF-8編碼中至少是兩個字節。 
UTF-8中的每一個字符編碼的首字節總在0x00-0xFD之間（不考慮UCS-4支持的狀況，首字節在0x00-0xEF之間）。根據首字節就能夠判斷以後連續幾個字節。 
非首字節的其餘字節都在0x80-0xBF之間；0xFE和0xFF在UTF-8中沒有被用到。 
GBK編碼中的漢字字符都在UCS-2中的範圍都在U+0800 - U+FFFF之間，因此每一個GBK編碼中的漢字字符的UTF-8編碼都是3個字節。但GBK中包含的其餘字符的UTF-8編碼就不必定是3個字節了，如GBK中的俄文字符。 
在UTF-8的編碼的傳輸過程當中即便丟掉一個字節，根據編碼規律也很容易定位丟掉的位置，不會影響到其餘字符。在其餘雙字節編碼中，一旦損失一個字節，就會影響到此字節以後的全部字符。從這點能夠看出UTF-8編碼很是適合做爲傳輸編碼