（4）UTF-8

從前述內容可以看出：無論是UCS-2/4還是UTF-16/32，一個字符都需要多個字節來編碼，這對那些英語國家來說多浪費帶寬?。。ㄓ绕湓诰W速本來就不快的那個年代......），而且我們注意到UTF-16最少2字節和UTF-32不變4字節，這肯定是不兼容ASCII碼的，由此，UTF-8產生了。

在UTF-8編碼中，ASCII碼中的字符還是ASCII碼的值，只需要一個字節表示，其余的字符需要2字節、3字節或4字節來表示。

UTF-8的編碼規則：

• 對于ASCII碼中的符號，使用單字節編碼，其編碼值與ASCII值相同。其中ASCII值的范圍為0~0x7F，所有編碼的二進制值中第一位為0（這個正好可以用來區分單字節編碼和多字節編碼）。

• 其它字符用多個字節來編碼（假設用N個字節），多字節編碼需滿足：第一個字節的前N位都為1，第N+1位為0，后面N-1 個字節的前兩位都為10，這N個字節中其余位全部用來存儲Unicode中的碼位值。

現如今UTF-8 是互聯網上使用最廣的一種 Unicode 的實現方式，是其他兩種無可比擬的。

（5）UTF的字節序和BOM

字節序就要先補充一點知識：

碼元（code unit）：是能用于處理或交換編碼文本的最小比特組合。它代表某種編碼中最小的可用來識別一個合法字符的最小字節數序列。

• UTF-8使用變長的字節序列來表示字符；某個字符(對應一個碼點)可能使用1-4個字節才能表示；在UTF-8中一個字符最小可能一個字節，所以我們規定1個字節就是一個碼元；

• UTF-16使用也變長字節序列來表示字符；某個字符(對應一個碼點)可能使用2個或者4個字符來表示；因為2個字節序列是最小的能夠識別一個碼點的單位，同理我們規定2個字節就是一個碼元；

• UTF-32使用定長的4個字節表示一個字符；一個字符(對應一個碼點)使用4個字符來表示，這樣4個字節就是一個碼元。

簡單來說，就是“碼點”經過映射后得到的二進制串的轉換格式單位稱之為“碼元”。“碼點”就是一串二進制數，“碼元”就是切分這個二進制數的方法。這些編碼每次處理一個碼元，你可以把它理解為UTF-8每次讀碼點的8位，UTF-16每次讀碼點的16位，UTF-32每次讀碼點的32位,。當然這也是為什么叫這些叫Unicode轉換格式的原因。處理的是同一個字符集，但是處理方式不同。

三

字節序

UTF-8一次一個UTF-8碼元，即處理一個字節，沒有字節序的問題。UTF-16一次處理一個UTF-16碼元，對應兩個字節，UTF-32一次一個UTF-32碼元，對應處理四個字節，所以這就要考慮到一個字節序問題。

以UTF-16w為例，在解釋一個UTF-16編碼文本前，首先要弄清楚每個編碼單元的字節序。例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。

如果我們收到UTF-16字節流“594E”，那么這是“奎”還是“乙”？這就考慮大小端問題，所以UTF-16編碼包括三種：UTF-16BE（Big Endian），UTF-16LE（Little Endian）、UTF-16（類似的名稱UCS-2BE和UCS-2LE用于顯示UCS-2的版本。）

UTF-16BE和UTF-16LE好理解，直接指定了字節序（大小端），但是UTF-16怎么處理呢？

Unicode規范中推薦的標記字節順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：

在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAKSPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸字節流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。這樣如果接收者收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little-Endian的。

同樣的類比，UTF-32也是這樣的。有UTF-32BE、UTF-32LE、UTF-32。前面UTF-32BE和UTF-32LE直接指定了字節序（大小端），后面的UTF-32也是靠BOM。

UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。字符"ZERO WIDTH NO-BREAKSPACE"的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。

Windows就是使用BOM來標記文本文件的編碼方式的。它就建議所有的 Unicode 文件應該以 ZERO WIDTH NOBREAK SPACE（U+FEFF）字符開頭。這作為一個“特征符”或“字節順序標記（byte-ordermark，BOM）”來識別文件中使用的編碼和字節順序。所以用Windows自帶的記事本將文件保存為UTF-8編碼的時候，記事本會自動在文件開頭插入BOM（雖然BOM對UTF-8來說并不是必須的）。

但也有一些系統或程序不支持BOM，因此帶有BOM的Unicode文件有時會帶來一些問題。比如JDK1.5以及之前的Reader都不能處理帶有BOM的UTF-8編碼的文件，解析這種格式的xml文件時，會拋出異常：Content is not allowed inprolog。

Linux/UNIX 并沒有使用 BOM，因為它會破壞現有的 ASCII 文件的語法約定。所以一般我們不建議用Windows自帶的記事本編輯UTF-8文件就是這樣。

四

總結

1、簡單地說：Unicode和UCS是字符集，不屬于編碼UTF-8、UTF-16、UTF-32等是針對Unicode字符集的編碼，UCS-2和UCS-4是針對UCS字符集的編碼（只是我們習慣把Unicode字符集編碼簡稱為Unicode編碼，把UCS字符集編碼稱為UCS編碼）。

Unicode沿用UCS字符集，在UCS-2和UCS-4基礎上提出的UTF-16、UTF-32。并發展了UTF-8，發展到現在，就密不可分了，大家基于UCS就把Uniocde維護好就行，發布標準大家統一。以往的UCS-2和UCS-4概念就默認作廢了這樣一個關系，整個他們的發展長話短說就是這樣，懂了嗎。

2、UTF-8、UTF-16、UTF-32、UCS-2、UCS-4對比：

由于歷史方面的原因，你還會在不少地方看到把Unicode稱為一種編碼的情況，那是因為早期的2字節編碼最初稱為“ Unicode”，但現在稱為“ UCS-2”，這種情況下的 Unicode 通常就是 UTF-16 或者是更早的 UCS-2 編碼，只是被一直搞混了，在某些老軟件上尤為常見。比如下面editplus里面文件編碼設置。

以前的Windows電腦上的記事本（左邊）顯示的是Unicode，不過現在好像改了變成了UTF-16。

不過由于各種原因，必須承認，在不同的語境下，“Unicode”這個詞有著不同的含義。

它可能指：

（1）Unicode 標準

（2）Unicode 字符集

（3）Unicode 的抽象編碼（編號），也即碼點、碼位（code point）

（4）Unicode 的一個具體編碼實現，通常即為變長的 UTF-16（16 或 32 位），又或者是更早期的定長 16 位的 UCS-2

所以像我一般有時候非要區分的話都是直接說全，Unicode 標準，Unicode 字符集，Unicode編碼等等。

五

ANSI編碼

為使計算機支持更多語言，通常使用0x800~xFF范圍的2個字節來表示1個字符。比如：漢字‘中’ 在中文操作系統中，使用 [0xD6,0xD0]這兩個字節存儲。

不同的國家和地區制定了不同的標準，由此產生了 GB2312、GBK、GB18030、Big5、Shift_JIS 等各自的編碼標準。這些使用多個字節來代表一個字符的各種語言延伸編碼方式，稱為 ANSI 編碼。

在簡體中文Windows操作系統中，ANSI 編碼代表 GBK 編碼；在繁體中文Windows操作系統中，ANSI編碼代表Big5；在日文Windows操作系統中，ANSI 編碼代表 Shift_JIS 編碼。

不同 ANSI 編碼之間互不兼容，當信息在國際間交流時，無法將屬于兩種語言的文字，存儲在同一段 ANSI 編碼的文本中。

在使用ANSI編碼支持多語言階段，每個字符使用一個字節或多個字節來表示（MBCS，Multi-Byte Character System），因此，這種方式存放的字符也被稱作多字節字符。比如，“中文123” 在中文 Windows 95 內存中為7個字節，每個漢字占2個字節，每個英文和數字字符占1個字節。

在非 Unicode 環境下，由于不同國家和地區采用的字符集不一致，很可能出現無法正常顯示所有字符的情況。微軟公司使用了代碼頁（Codepage）轉換表的技術來過渡性的部分解決這一問題，即通過指定的轉換表將非Unicode 的字符編碼轉換為同一字符對應的系統內部使用的Unicode 編碼。

可以在“語言與區域設置”中選擇一個代碼頁作為非 Unicode 編碼所采用的默認編碼方式，如936為簡體中文GBK，950為正體中文Big5（皆指PC上使用的）。在這種情況下，一些非英語的歐洲語言編寫的軟件和文檔很可能出現亂碼。而將代碼頁設置為相應語言中文處理又會出現問題，這一情況無法避免。

從根本上說，完全采用統一編碼才是解決之道，雖然現在Unicode有了，但由于歷史遺留，老軟件等等原因，所以系統統一用某種編碼格式的Unicode目前尚無法做到這一點。

代碼頁技術現在廣泛為各種平臺所采用。UTF-7 的代碼頁是65000，UTF-8的代碼頁是65001。簡體中文上使用的代碼頁為936，GBK編碼。

以前中文DOS、中文/日文Windows95/98時代系統內碼使用的是ANSI編碼（本地化，根據不同地區設置不同的系統內碼Windows版本），現在win7，win10等等系統的內碼都是用的Unicode。

不過微軟為了以前的程序兼容性，比如在某些情況下，比如你的程序需要和不支持Unicode的程序交互時，可能還是會需要用到code page，提供代碼頁服務（就好比微軟不能說：“老子支持unicode了，以后不支持Unicode的程序都給我滾粗?！敝荒芫镏ü勺屵@些老掉牙的程序仍然可以運行，于是只好給他們提供一個“非Unicode默認字符集”） ?？梢栽赾md下輸入chcp查看code page。

• WindowsAPI 的Wide Char 表達是 UTF-16: Unicode (Windows), L"" 表示是轉換為 wide char。

• Cocoa的NSString 和 Core Foundation 的CFString 內部表達都是 UTF-16，所以其實 OSX 和 iOS 內部處理都用的是 UTF-16。

• JavaString 的內部表達是 UTF-16，所以大量跨平臺程序和 Android 程序其實內部也在用 UTF-16。

• 大部分的操作系統和 UI framework 的內部字符串表達（內碼）都是UTF-16，不過Linux系統內使用的內碼是UTF-8。

六

Tip：內碼和外碼

在計算機科學及相關領域當中，內碼指的是“將信息編碼后，透過某種方式存儲在特定記憶設備時，設備內部的編碼形式”。在不同的系統中，會有不同的內碼。

在以往的英文系統中，內碼為ASCII。在繁體中文系統中，當前常用的內碼為大五碼。在簡體中文系統中，內碼則為國標碼。

為了軟件開發方便，如國際化與本地化，現在許多系統會使用Unicode做為內碼，常見的操作系統Windows、Mac OS X、Linux皆如此。許多編程語言也采用Unicode為內碼，如Java、Python3。

外碼：除了內碼，皆是外碼。要注意的是，源代碼編譯產生的目標代碼文件（如果Java可執行文件或class文件）中的編碼方式屬于外碼。