想法 3.3 無符號 orm 微軟公司 詳解 表示 xxxxxx 全部

每一個程序員都不可避免的遇到字符編碼的問題，特別是做Web開發的程序員，“亂碼問題”一直是讓人頭疼的問題，也許您已經很少遇到“亂碼”問題，然而，對解決亂碼的方法的內在原理，您是否明白？本人作為一個程序員，在字符編碼方面同樣遇到不少問題，而且一直對各種編碼懵懵懂懂、不清不楚；在工作中也曾經遇到一個很煩人的編碼問題。這兩天在網上收集了大量編碼方面的資料，對字符編碼算是理解的比較清楚了。下面把我認為比較重要的知識點記錄下來，一方面方便以後復習；另一方面也希望給跟我一樣懵懵懂懂的人一個參考。不對或不妥之處，請批評指正。

在此之前，先了解一些有用概念：“字符集”、“字符編碼”和“內碼”。

1、字符集與字符編碼

字符是各種文字和符號的總稱，包括各個國家文字、標點符號、圖形符號、數字等。字符集是多個字符的集合，字符集種類較多，每個字符集包含的字符個數不同，常見字符集有：ASCII字符集、ISO 8859字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。計算機要準確的處理各種字符集文字，需要進行字符編碼，以便計算機能夠識別和存儲各種文字。 編碼(encoding)和字符集不同。字符集只是字符的集合，不一定適合作網絡傳送、處理，有時須經編碼(encode)後才能應用。如Unicode可依不同需要以UTF-8、UTF-16、UTF-32等方式編碼。 字符編碼就是以二進制的數字來對應字符集的字符。 因此，對字符進行編碼，是信息交流的技術基礎。 使用哪些字符。也就是說哪些漢字，字母和符號會被收入標準中。所包含“字符”的集合就叫做“字符集”。 規定每個“字符”分別用一個字節還是多個字節存儲，用哪些字節來存儲，這個規定就叫做“編碼”。 各個國家和地區在制定編碼標準的時候，“字符的集合”和“編碼”一般都是同時制定的。因此，平常我們所說的“字符集”，比如：GB2312, GBK, JIS 等，除了有“字符的集合”這層含義外，同時也包含了“編碼”的含義。 註意：Unicode字符集有多種編碼方式，如UTF-8、UTF-16等；ASCII只有一種；大多數MBCS（包括GB2312）也只有一種。

2、什麽是內碼？

2.1 維基百科的解釋 在計算機科學及相關領域當中，內碼指的是“將資訊編碼後，透過某種方式儲存在特定記憶裝置時，裝置內部的編碼形式”。在不同的系統中，會有不同的內碼。 在以往的英文系統中，內碼為ASCII。在繁體中文系統中，目前常用的內碼為大五碼（Big5）。在簡體中文系統中，內碼則為國標碼（國家標準代碼：現在強制要求使用GB18030標準；較舊計算機仍然使用GB2312）。而統一碼（Unicode）則為另一常見內碼。 2.2 百度百科的解釋 內碼是指整機系統中使用的二進制字符編碼，是溝通輸入、輸出與系統平臺之間的交換碼，通過內碼可以達到通用和高效率傳輸文本的目的。比如MS Word中所存儲和調用的就是內碼而非圖形文字。英文ASCII字符采用一個字節的內碼表示，中文字符如國標字符集中，GB2312、GB12345、GB13000皆用雙字節內碼，GB18030（27,533漢字）雙字節內碼漢字為20,902個，其余6,631個漢字用四字節內碼。

3、字符編碼分類總結

下面從計算機對多國語言支持的角度來總結字符編碼。 3.1 ASCII編碼 以下來自“維基百科”： ASCII（American Standard Code for Information Interchange，美國信息互換標準代碼）是基於拉丁字母的一套電腦編碼系統。它主要用於顯示現代英語，而其擴展版本EASCII則可以勉強顯示其他西歐語言。它是現今最通用的單字節編碼系統（但是有被UniCode追上的跡象），並等同於國際標準ISO/IEC 646。 ASCII第一次以規範標準的型態發表是在1967年，最後一次更新則是在1986年，至今為止共定義了128個字符；其中33個字符無法顯示（這是以現今操作系統為依歸，但在DOS模式下可顯示出一些諸如笑臉、撲克牌花式等8-bit符號），且這33個字符多數都已是陳廢的控制字符。控制字符的用途主要是用來操控已經處理過的文字。在33個字符之外的是95個可顯示的字符，包含用鍵盤敲下空白鍵所產生的空白字符也算1個可顯示字符（顯示為空白）。 ASCII表：見http://zh.wikipedia.org/zh-cn/ASCII ASCII缺點： ASCII的最大缺點是只能顯示26個基本拉丁字母、阿拉伯數目字和英式標點符號，因此只能用於顯示現代美國英語（而且在處理英語當中的外來詞如na?ve、café、élite等等時，所有重音符號都不得不去掉，即使這樣做會違反拼寫規則）。而EASCII雖然解決了部份西歐語言的顯示問題，但對更多其他語言依然無能為力。因此現在的蘋果電腦已經拋棄ASCII而轉用Unicode。 最早的英文DOS操作系統的系統內碼是：ASCII。計算機這時候只支持英語，其他語言不能夠在計算機存儲和顯示。 在該階段，單字節字符串使用一個字節存放一個字符（SBCS,Single Byte Character System）。如："Bob123"占6個字節。 3.2 ANSI編碼 為使計算機支持更多語言，通常使用0x800~xFF範圍的2個字節來表示1個字符。比如：漢字 ‘中‘ 在中文操作系統中，使用 [0xD6,0xD0]這兩個字節存儲。 不同的國家和地區制定了不同的標準，由此產生了GB2312,BIG5,JIS等各自的編碼標準。這些使用2個字節來代表一個字符的各種漢字延伸編碼方式，稱為 ANSI 編碼。在簡體中文系統下，ANSI 編碼代表 GB2312 編碼，在日文操作系統下，ANSI 編碼代表 JIS 編碼。 不同 ANSI 編碼之間互不兼容，當信息在國際間交流時，無法將屬於兩種語言的文字，存儲在同一段 ANSI 編碼的文本中。 中文DOS、中文/日文Windows 95/98時代系統內碼使用的是ANSI編碼（本地化） 在使用ANSI編碼支持多語言階段，每個字符使用一個字節或多個字節來表示（MBCS，Multi-Byte Character System），因此，這種方式存放的字符也被稱作多字節字符。比如，"中文123" 在中文 Windows 95 內存中為7個字節，每個漢字占2個字節，每個英文和數字字符占1個字節。 在非 Unicode 環境下，由於不同國家和地區采用的字符集不一致，很可能出現無法正常顯示所有字符的情況。微軟公司使用了代碼頁（Codepage）轉換表的技術來過渡性的部分解決這一問題，即通過指定的轉換表將非 Unicode 的字符編碼轉換為同一字符對應的系統內部使用的 Unicode 編碼。可以在“語言與區域設置”中選擇一個代碼頁作為非 Unicode 編碼所采用的默認編碼方式，如936為簡體中文GBK，950為正體中文Big5（皆指PC上使用的）。在這種情況下，一些非英語的歐洲語言編寫的軟件和文檔很可能出現亂碼。而將代碼頁設置為相應語言中文處理又會出現問題，這一情況無法避免。從根本上說，完全采用統一編碼才是解決之道，但目前尚無法做到這一點。 　　代碼頁技術現在廣泛為各種平臺所采用。UTF-7 的代碼頁是65000，UTF-8 的代碼頁是65001。 3.3 Unicode編碼 為了使國際間信息交流更加方便，國際組織制定了 UNICODE 字符集，為各種語言中的每一個字符設定了統一並且唯一的數字編號，以滿足跨語言、跨平臺進行文本轉換、處理的要求。 Unicode字符集可以簡寫為UCS（Unicode Character Set）。早期的unicodeUnicode標準有UCS-2、UCS-4的說法。UCS-2用兩個字節編碼，UCS-4用4個字節編碼。 在 UNICODE 被采用之後，計算機存放字符串時，改為存放每個字符在 UNICODE 字符集中的序號。目前計算機一般使用 2 個字節（16 位）來存放一個序號（DBCS,Double Byte Character System），因此，這種方式存放的字符也被稱作寬字節字符。比如，字符串 "中文123" 在 Windows 2000 下，內存中實際存放的是 5 個序號，一共10個字節。 Unicode字符集包含了各種語言中使用到的所有“字符”。用來給 UNICODE 字符集編碼的標準有很多種，比如：UTF-8, UTF-7, UTF-16, UnicodeLittle, UnicodeBig 等。

4、常用編碼規則

4.1 單字節字符編碼 （1）編碼標準：ISO-8859-1。 （2）說明：最簡單的編碼規則，每一個字節直接作為一個 UNICODE 字符。比如，[0xD6, 0xD0] 這兩個字節，通過 iso-8859-1 轉化為字符串時，將直接得到 [0x00D6, 0x00D0] 兩個 UNICODE 字符，即 "?D"。 反之，將 UNICODE 字符串通過 iso-8859-1 轉化為字節串時，只能正常轉化 0~255 範圍的字符。 4.2 ANSI編碼 （1）GB2312, BIG5, Shift_JIS, ISO-8859-2。 （2）把 UNICODE 字符串通過 ANSI 編碼轉化為“字節串”時，根據各自編碼的規定，一個 UNICODE 字符可能轉化成一個字節或多個字節。 反之，將字節串轉化成字符串時，也可能多個字節轉化成一個字符。比如，[0xD6, 0xD0] 這兩個字節，通過 GB2312 轉化為字符串時，將得到 [0x4E2D] 一個字符，即 ‘中‘ 字。 “ANSI 編碼”的特點： （1）這些“ANSI 編碼標準”都只能處理各自語言範圍之內的 UNICODE 字符。 （2）“UNICODE 字符”與“轉換出來的字節”之間的關系是人為規定的。 4.3 UNICODE編碼 （1）編碼標準：UTF-8, UTF-16, UnicodeBig。 （2）與“ANSI 編碼”類似的，把字符串通過 UNICODE 編碼轉化成“字節串”時，一個 UNICODE 字符可能轉化成一個字節或多個字節。 與“ANSI 編碼”不同的是： （1）這些“UNICODE 編碼”能夠處理所有的 UNICODE 字符。 （2）“UNICODE 字符”與“轉換出來的字節”之間是可以通過計算得到的。 我們實際上沒有必要去深究每一種編碼具體把某一個字符編碼成了哪幾個字節，我們只需要知道“編碼”的概念就是把“字符”轉化成“字節”就可以了。對於“UNICODE 編碼”，由於它們是可以通過計算得到的，因此，在特殊的場合，我們可以去了解某一種“UNICODE 編碼”是怎樣的規則。

5、編碼的區別

5.1 GB2312、GBK和GB18030 （1）GB2312 當中國人們得到計算機時，已經沒有可以利用的字節狀態來表示漢字，況且有6000多個常用漢字需要保存，於是想到把那些ASCII碼中127號之後的奇異符號們直接取消掉, 規定：一個小於127的字符的意義與原來相同，但兩個大於127的字符連在一起時，就表示一個漢字，前面的一個字節（稱之為高字節）從0xA1用到0xF7，後面一個字節（低字節）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裏，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 裏本來就有的數字、標點、字母都統統重新編了兩個字節長的編碼，這就是常說的"全角"字符，而原來在127號以下的那些就叫"半角"字符了。這種漢字方案叫做 "GB2312"。GB2312 是對 ASCII 的中文擴展。兼容ASCII。 （2）GBK 但是中國的漢字太多了，我們很快就就發現有許多人的人名沒有辦法在這裏打出來，不得不繼續把 GB2312 沒有用到的碼位找出來用上。後來還是不夠用，於是幹脆不再要求低字節一定是127號之後的內碼，只要第一個字節是大於127就固定表示這是一個漢字的開始，不管後面跟的是不是擴展字符集裏的內容。結果擴展之後的編碼方案被稱為 “GBK” 標準，GBK 包括了 GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。 （3）GB18030 後來少數民族也要用電腦了，於是我們再擴展，又加了幾千個新的少數民族的字，GBK 擴成了 GB18030。從此之後，中華民族的文化就可以在計算機時代中傳承了。 中國的程序員們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 "DBCS"（Double Byte Charecter Set 雙字節字符集）。在DBCS系列標準裏，最大的特點是兩字節長的漢字字符和一字節長的英文字符並存於同一套編碼方案裏，因此他們寫的程序為了支持中文處理，必須要註意字串裏的每一個字節的值，如果這個值是大於127的，那麽就認為一個雙字節字符集裏的字符出現了。在這種情況下，"一個漢字算兩個英文字符！"。然而，在Unicode環境下卻並非總是如此。 5.1 Unicode和BigEndianUnicode 這兩個指示存儲順序不同，如"A"的Unicode編碼為6500，而BigEndianUnicode編碼為0065。 5.2 UTF-7、UTF-8和UTF-16 在Unicode裏，所有的字符被一視同仁。漢字不再使用“兩個擴展ASCII”，而是使用“1個Unicode”，註意，現在的漢字是“一個字符”了，於是，拆字、統計字數這些問題也就自然而然的解決了。 但是，這個世界不是理想的，不可能在一夜之間所有的系統都使用Unicode來處理字符，所以Unicode在誕生之日，就必須考慮一個嚴峻的問題：和ASCII字符集之間的不兼容問題。 我們知道，ASCII字符是單個字節的，比如“A”的ASCII是65。而Unicode是雙字節的，比如“A”的Unicode是0065，這就造成了一個非常大的問題：以前處理ASCII的那套機制不能被用來處理Unicode了。 另一個更加嚴重的問題是，C語言使用‘\0‘作為字符串結尾，而Unicode裏恰恰有很多字符都有一個字節為0，這樣一來，C語言的字符串函數將無法正常處理Unicode，除非把世界上所有用C寫的程序以及他們所用的函數庫全部換掉。 於是，比Unicode更偉大的東東誕生了，之所以說它更偉大是因為它讓Unicode不再存在於紙上，而是真實的存在於我們大家的電腦中。那就是：UTF。 UTF= UCS Transformation Format，即UCS轉換(傳輸)格式。 它是將Unicode編碼規則和計算機的實際編碼對應起來的一個規則。現在流行的UTF有2種：UTF-8和UTF-16。 這兩種都是Unicode的編碼實現。 5.2.1 UTF-8 UCS-2編碼(16進制) UTF-8 字節流(二進制) 0000 - 007F 0xxxxxxx 0080 - 07FF 110xxxxx 10xxxxxx 0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx 例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以肯定要用3字節模板了：1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進制是：0110 110001 001001，用這個比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。 可見UTF-8是變長的，將Unicode編碼為00000000-0000007F的字符，用單個字節來表示； 00000080-000007FF的字符用兩個字節表示；00000800-0000FFFF的字符用3字節表示。因為目前為止Unicode-16規範沒有指定FFFF以上的字符，所以UTF-8最多是使用3個字節來表示一個字符。但理論上來說，UTF-8最多需要用6字節表示一個字符。 UTF-8兼容ASCII。 5.2.2 UTF-16（標準的Unicode成為UTF-16） UTF-16和上面提到的Unicode本身的編碼規範是一致的。 UTF-16以16位為單元對UCS進行編碼。對於小於0x10000的UCS碼，UTF-16編碼就等於UCS碼對應的16位無符號整數。對於不小於0x10000的UCS碼，定義了一個算法。不過由於實際使用的UCS2，或者UCS4的BMP必然小於0x10000，所以就目前而言，可以認為UTF-16和UCS-2基本相同。但UCS-2只是一個編碼方案，UTF-16卻要用於實際的傳輸，所以就不得不考慮字節序的問題。 UTF-16不兼容ASCII。 5.2.3 UTF-7 UTF-7 (7-位元 Unicode 轉換格式（Unicode Transformation Format，簡寫成 UTF）) 是一種可變長度字元編碼方式，用以將 Unicode 字元以 ASCII 編碼的字元串來呈現，可以應用在電子郵件傳輸之類的應用。 UTF-7並非Unicode標準之一。想要詳細了解的可以查閱相關資料。

6、Unicode與UTF

Unicode是內存編碼表示方案（是規範），而UTF是如何保存和傳輸Unicode的方案（是實現）。 6.1 UTF的字節序和BOM 6.1.1 字節序 UTF-8以字節為編碼單元，沒有字節序的問題。UTF-16以兩個字節為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的字節序。例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節流“594E”，那麽這是“奎”還是“乙”？ Unicode規範中推薦的標記字節順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法： 在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應該出現在實際傳輸中。UCS規範建議我們在傳輸字節流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。 這樣如果接收者收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。 UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。 6.1.2 BOM （1）BOM的來歷 為了識別 Unicode 文件，Microsoft 建議所有的 Unicode 文件應該以 ZERO WIDTH NOBREAK SPACE（U+FEFF）字符開頭。這作為一個“特征符”或“字節順序標記（byte-order mark，BOM）”來識別文件中使用的編碼和字節順序。 （2）不同的系統對BOM的支持 因為一些系統或程序不支持BOM，因此帶有BOM的Unicode文件有時會帶來一些問題。 ①JDK1.5以及之前的Reader都不能處理帶有BOM的UTF-8編碼的文件，解析這種格式的xml文件時，會拋出異常：Content is not allowed in prolog。“對於解決方法，之後我會寫篇文章專門討論該問題。” ②Linux/UNIX 並沒有使用 BOM，因為它會破壞現有的 ASCII 文件的語法約定。 ③不同的編輯工具對BOM的處理也各不相同。使用Windows自帶的記事本將文件保存為UTF-8編碼的時候，記事本會自動在文件開頭插入BOM（雖然BOM對UTF-8來說並不是必須的）。而其它很多編輯器用不用BOM是可以選擇的。UTF-8、UTF-16都是如此。 （3）BOM與XML XML解析讀取XML文檔時，W3C定義了3條規則： ①如果文檔中有BOM，就定義了文件編碼； ②如果文檔中沒有BOM，就查看XML聲明中的編碼屬性； ③如果上述兩者都沒有，就假定XML文檔采用UTF-8編碼。 6.2 決定文本的字符集與編碼 軟件通常有三種途徑來決定文本的字符集和編碼。 （1）對於Unicode文本最標準的途徑是檢測文本最開頭的幾個字節。如： 開頭字節 Charset/encoding EF BB BF　　　 UTF-8 FE FF　　　　　UTF-16/UCS-2, little endian(UTF-16LE) FF FE　　　　　UTF-16/UCS-2, big endian(UTF-16BE) FF FE 00 00　　UTF-32/UCS-4, little endian. 00 00 FE FF　　UTF-32/UCS-4, big-endia （2）采取一種比較安全的方式來決定字符集及其編碼，那就是彈出一個對話框來請示用戶。 然而MBCS文本（ANSI）沒有這些位於開頭的字符集標記，現在很多軟件保存文本為Unicode時，可以選擇是否保存這些位於開頭的字符集標記。因此，軟件不應該依賴於這種途徑。這時，軟件可以采取一種比較安全的方式來決定字符集及其編碼，那就是彈出一個對話框來請示用戶。 （3）采取自己“猜”的方法。 如果軟件不想麻煩用戶，或者它不方便向用戶請示，那它只能采取自己“猜”的方法，軟件可以根據整個文本的特征來猜測它可能屬於哪個charset，這就很可能不準了。使用記事本打開那個“聯通”文件就屬於這種情況。（把原本屬於ANSI編碼的文件當成UTF-8處理，詳細說明見：http://blog.csdn.net/omohe/archive/2007/05/29/1630186.aspx） 6.3 記事本的幾種編碼 （1）ANSI編碼 記事本默認保存的編碼格式是：ANSI，即本地操作系統默認的內碼，簡體中文一般為GB2312。這個怎麽驗證呢？用記事本保存後，使用EmEditor、EditPlus和UltraEdit之類的文本編輯器打開。推薦使用EmEditor，打開後，在又下角會顯示編碼：GB2312。 （2）Unicode編碼 用記事本另存為時，編碼選擇“Unicode”，用EmEditor打開該文件，發現編碼格式是：UTF-16LE+BOM（有簽名）。用十六進制方式查看，發現開頭兩字節為：FF FE。這就是BOM。 （3）Unicode big endian 用記事本另存為時，編碼選擇“Unicode”，用EmEditor打開該文件，發現編碼格式是：UTF-16BE+BOM（有簽名）。用十六進制方式查看，發現開頭兩字節為：FE FF。這就是BOM。 （4）UTF-8 用記事本另存為時，編碼選擇“UTF-8”，用EmEditor打開該文件，發現編碼格式是：UTF-8（有簽名）。用十六進制方式查看，發現開頭三個字節為：EF BB BF。這就是BOM。

7、幾種誤解，以及亂碼產生的原因和解決辦法

7.1 誤解一 在將“字節串”轉化成“UNICODE 字符串”時，比如在讀取文本文件時，或者通過網絡傳輸文本時，容易將“字節串”簡單地作為單字節字符串，采用每“一個字節”就是“一個字符”的方法進行轉化。 而實際上，在非英文的環境中，應該將“字節串”作為 ANSI 字符串，采用適當的編碼來得到 UNICODE 字符串，有可能“多個字節”才能得到“一個字符”。 通常，一直在英文環境下做開發的程序員們，容易有這種誤解。 7.2 誤解二 在 DOS，Windows 98 等非 UNICODE 環境下，字符串都是以 ANSI 編碼的字節形式存在的。這種以字節形式存在的字符串，必須知道是哪種編碼才能被正確地使用。這使我們形成了一個慣性思維：“字符串的編碼”。 當 UNICODE 被支持後，Java 中的 String 是以字符的“序號”來存儲的，不是以“某種編碼的字節”來存儲的，因此已經不存在“字符串的編碼”這個概念了。只有在“字符串”與“字節串”轉化時，或者，將一個“字節串”當成一個 ANSI 字符串時，才有編碼的概念。 不少的人都有這個誤解。 7.3 分析與解決 第一種誤解，往往是導致亂碼產生的原因。第二種誤解，往往導致本來容易糾正的亂碼問題變得更復雜。 在這裏，我們可以看到，其中所講的“誤解一”，即采用每“一個字節”就是“一個字符”的轉化方法，實際上也就等同於采用 iso-8859-1 進行轉化。因此，我們常常使用 bytes = string.getBytes("iso-8859-1") 來進行逆向操作，得到原始的“字節串”。然後再使用正確的 ANSI 編碼，比如 string = new String(bytes, "GB2312")，來得到正確的“UNICODE 字符串”。

8、參考與深入閱讀學習資料

8.1 《字符，字節和編碼》http://www.regexlab.com/zh/encoding.htm（強烈推介） 8.2 《關於編碼: ascii(ansi), gb-2312, unicode, utf8》http://blog.csdn.net/omohe/archive/2007/05/29/1630186.aspx 8.3 《Ansi,UTF8,Unicode,ASCII編碼的區別》http://hi.baidu.com/%D6%F0%C4%BE/blog/item/772c5944d5e77e8bb3b7dcab.html 8.4 百度百科《Unicode》http://baike.baidu.com/view/40801.htm 8.5 《Unicode與UTF-8/UTF-16之間有啥聯系或區別？》http://zhidao.baidu.com/question/52532619.html?fr=ala0

出處：http://polaris.blog.51cto.com/1146394/377468

字符編碼詳解——徹底理解掌握編碼知識，“亂碼”不復存在