談談Unicode編碼 - 十年磨一劍

我很早前就發現Unicode、Unicode big endian和UTF-8編碼的txt文件的開頭會多出幾個字元，分別是FF、FE（Unicode）,FE、FF（Unicode big endian） ... 十年磨一劍 跳到主文 邁向中鳥階段-EmbeddedArmLinux嵌入式系統開發與學習，歡迎各位同好的交流。

部落格全站分類：數位生活 相簿 部落格 留言 名片 May13Wed200917:20 談談Unicode編碼 會放這篇文章上來，主要也是因為最近作研究時有用到Unicode，需要它的編碼表，偶然間看到這篇文章覺得還不錯，雖然是舊文了，但裡面的一些知識，還是能讓人對於字元編碼有更多的了解。

－－簡要解釋UCS、UTF、BMP、BOM等名詞　　作者：fmddlmyy　　這是一篇程序員寫給程序員的趣味讀物。

所謂趣味是指可以比較輕鬆地瞭解一些原來不清楚的概念，增進知識，類似於打RPG遊戲的昇級。

整理這篇文章的動機是兩個問題：問題一：　　使用Windows記事本的「另存為」，可以在GBK、Unicode、Unicodebigendian和UTF-8這幾種編碼方式間相互轉換。

同樣是txt文件，Windows是怎樣識別編碼方式的呢？　　我很早前就發現Unicode、Unicodebigendian和UTF-8編碼的txt文件的開頭會多出幾個字元，分別是FF、FE（Unicode）,FE、FF（Unicodebigendian）,EF、BB、BF（UTF-8）。

但這些標記是關於什麼標準呢？問題二：　　最近在網上看到一個ConvertUTF.c，實現了UTF-32、UTF-16和UTF-8這三種編碼方式的相互轉換。

對於Unicode(UCS2)、GBK、UTF-8這些編碼方式，我原來就瞭解。

但這個程序讓我有些糊塗，想不起來UTF-16和UCS2有什麼關係。

　　查了查相關資料，總算將這些問題弄清楚了，順帶也瞭解了一些Unicode的細節。

作者寫成一篇文章，送給有過類似疑問的朋友。

本文在寫作時盡量做到通俗易懂，但要求讀者知道什麼是字元，什麼是十六進制。

0、bigendian和littleendian　　bigendian和littleendian是CPU處理多字元數的不同方式。

例如「漢」字的Unicode編碼是6C49。

那麼寫到文件裡時，究竟是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是bigendian。

如果將49寫在前面，就是littleendian。

　　「endian」這個詞出自《格列佛遊記》。

小人國的內戰就源於吃雞蛋時是究竟從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開，由此曾發生過六次叛亂，一個皇帝送了命，另一個丟了王位。

　　我們一般將endian翻譯成「字元序」，將bigendian和littleendian稱作「大尾」和「小尾」。

1、字串編碼、內碼，順帶介紹漢字編碼　　字串必須編碼後才能被電腦處理。

電腦使用的預設編碼方式就是電腦的內碼。

早期的電腦使用7位的ASCII編碼，為了處理漢字，程序員設計了用於簡體中文的GB2312和用於繁體中文的big5。

　　GB2312(1980年)一共收錄了744灌水限制符，包括6763個漢字和682個其它符號。

漢字區的內碼範圍高字元從B0-F7，低字元從A1-FE，佔用的碼位是72*94=6768。

其中有5個空位是D7FA-D7FE。

　　GB2312支持的漢字太少。

1995年的漢字增強規範GBK1.0收錄了21886個符號，它分為漢字區和圖形符號區。

漢字區包括21003個字串。

2000年的GB18030是取代GBK1.0的正式國家標準。

該標準收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文字。

現在的PC平台必須支持GB18030，對嵌入式產品暫不作要求。

所以手機、MP3一般只支持GB2312。

　　從ASCII、GB2312、GBK到GB18030，這些編碼方法是向下相容的，即同一個字串在這些方案中總是有相同的編碼，後面的標準支持更多的字串。

在這些編碼中，英文和中文可以統一地處理。

區分中文編碼的方法是高字元的最高位不為0。

按照程序員的稱呼，GB2312、GBK到GB18030都屬於雙字元字串集(DBCS)。

　　有的中文Windows的預設內碼還是GBK，可以通過GB18030昇級包昇級到GB18030。

不過GB18030相對GBK增加的字串，普通人是很難用到的，通常我們還是用GBK指代中文Windows內碼。

這裡還有一些細節： １GB2312的原文還是區位碼，從區位碼到內碼，需要在高字元和低字元上分別加上A0。

２在DBCS中，GB內碼的儲存於格式始終是bigendian，即高位在前。

３GB2312的兩個字元的最高位都是1。

但符合這個條件的碼位只有128*128=16384個。

所以GBK和GB18030的低字元最高位都可能不是1。

不過這不影響DBCS字串流的解析：在讀取DBCS字串流時，只要遇到高位為1的字元，就可以將下兩個字元作為一個雙字元編碼，而不用管低字元的高位是什麼。

2、Unicode、UCS和UTF　　前面提到從ASCII、GB2312、GBK到GB18030的編碼方法是向下相容的。

而Unicode只與ASCII相容（更準確地說，是與ISO-8859-1相容），與GB碼不相容。

例如「漢」字的Unicode編碼是6C49，而GB碼是BABA。

　　Unicode也是一種字串編碼方法，不過它是由國際組織設計，可以容納全世界所有語言文字的編碼方案。

Unicode的學名是"UniversalMultiple-OctetCodedCharacterSet"，簡稱為UCS。

UCS可以看作是"UnicodeCharacterSet"的縮寫。

　　根據維基百科全書(http://zh.wikipedia.org/wiki/)的記載：歷史上存在兩個試圖獨立設計Unicode的組織，即國際標準化組織（ISO）和一個軟體製造商的協會（unicode.org）。

ISO開發了ISO10646項目，Unicode協會開發了Unicode項目。

　　在1991年前後，雙方都認識到世界不需要兩個不相容的字串集。

於是它們開始合併雙方的工作成果，並為創立一個單一編碼表而協同工作。

從Unicode2.0開始，Unicode項目採用了與ISO10646-1相同的字庫和字碼。

　　目前兩個項目仍都存在，並獨立地公佈各自的標準。

Unicode協會現在的最新版本是2005年的Unicode4.1.0。

ISO的最新標準是ISO10646-3:2003。

　　UCS只是規定如何編碼，並沒有規定如何傳輸、儲存這個編碼。

例如「漢」字的UCS編碼是6C49，我可以用4個ascii數位來傳輸、儲存這個編碼；也可以用utf-8編碼:3個連續的字元E6B189來表示它。

關鍵在於通信雙方都要認可。

UTF-8、UTF-7、UTF-16都是被廣泛接受的方案。

UTF-8的一個特別的好處是它與ISO-8859-1完全相容。

UTF是「UCSTransformationFormat」的縮寫。

　　IETF的RFC2781和RFC3629以RFC的一貫風格，清晰、明快又不失嚴謹地描述了UTF-16和UTF-8的編碼方法。

我總是記不得IETF是InternetEngineeringTaskForce的縮寫。

但IETF負責維護的RFC是Internet上一切規範的基礎。

2.1、內碼和codepage　　目前Windows的內核已經採用Unicode編碼，這樣在內核上可以支持全世界所有的語言文字。

但是由於現有的大量程序和文件都採用了某種特定語言的編碼，例如GBK，Windows不可能不支持現有的編碼，而全部改用Unicode。

　　Windows使用程式碼頁(codepage)來適應各個國家和地區。

codepage可以被理解為前面提到的內碼。

GBK對應的codepage是CP936。

　　微軟也為GB18030定義了codepage：CP54936。

但是由於GB18030有一部分4字元編碼，而Windows的程式碼頁只支持單字元和雙字元編碼，所以這個codepage是無法真正使用的。

3、UCS-2、UCS-4、BMP　　UCS有兩種格式：UCS-2和UCS-4。

顧名思義，UCS-2就是用兩個字元編碼，UCS-4就是用4個字元（實際上只用了31位，最高位必須為0）編碼。

下面讓我們做一些簡單的數學遊戲：　　UCS-2有2^16=65536個碼位，UCS-4有2^31=2147483648個碼位。

　　UCS-4根據最高位為0的最高字元分成2^7=128個group。

每個group再根據次高字元分為256個plane。

每個plane根據第3個字元分為256行(rows)，每行包含256個cells。

當然同一行的cells只是最後一個字元不同，其餘都相同。

　　group0的plane0被稱作BasicMultilingualPlane,即BMP。

或者說UCS-4中，高兩個字元為0的碼位被稱作BMP。

　　將UCS-4的BMP去掉前面的兩個零字元就得到了UCS-2。

在UCS-2的兩個字元前加上兩個零字元，就得到了UCS-4的BMP。

而目前的UCS-4規範中還沒有任何字串被分配在BMP之外。

4、UTF編碼　　UTF-8就是以8位為單元對UCS進行編碼。

從UCS-2到UTF-8的編碼方式如下：　　　　　UCS-2編碼(16進制)　　　　　　UTF-8字元流(二進制)　　　　　0000-007F　　　　　　　　　0xxxxxxx　　　　　0080-07FF　　　　　　　　　110xxxxx10xxxxxx　　　　　0800-FFFF　　　　　　　　　1110xxxx10xxxxxx10xxxxxx　　例如「漢」字的Unicode編碼是6C49。

6C49在0800-FFFF之間，所以肯定要用3字元範本了：1110xxxx10xxxxxx10xxxxxx。

將6C49寫成二進制是：0110110001001001，用這個比特流依次替代範本中的x，得到：111001101011000110001001，即E6B189。

　　讀者可以用記事本測試一下我們的編碼是否正確。

需要注意，UltraEdit在開啟utf-8編碼的文本文件時會自動轉換為UTF-16，可能產生混淆。

你可以在設定中關掉這個選項。

更好的工具是HexWorkshop。

　　UTF-16以16位為單元對UCS進行編碼。

對於小於0x10000的UCS碼，UTF-16編碼就等於UCS碼對應的16位無符號整數。

對於不小於0x10000的UCS碼，定義了一個算法。

不過由於實際使用的UCS2，或者UCS4的BMP必然小於0x10000，所以就目前而言，可以認為UTF-16和UCS-2基本相同。

但UCS-2只是一個編碼方案，UTF-16卻要用於實際的傳輸，所以就不得不考慮字元序的問題。

5、UTF的字元序和BOM　　UTF-8以字元為編碼單元，沒有字元序的問題。

UTF-16以兩個字元為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的字元序。

例如「奎」的Unicode編碼是594E，「乙」的Unicode編碼是4E59。

如果我們收到UTF-16字元流「594E」，那麼這是「奎」還是「乙」？　　Unicode規範中推薦的標記字元順序的方法是BOM。

BOM不是「BillOfMaterial」的BOM表，而是ByteOrderMark。

BOM是一個有點小聰明的想法：　　在UCS編碼中有一個叫做"ZEROWIDTHNO-BREAKSPACE"的字串，它的編碼是FEFF。

而FFFE在UCS中是不存在的字串，所以不應該出現在實際傳輸中。

UCS規範建議我們在傳輸字元流前，先傳輸字串"ZEROWIDTHNO-BREAKSPACE"。

　　這樣如果接收者收到FEFF，就表明這個字元流是Big-Endian的；如果收到FFFE，就表明這個字元流是Little-Endian的。

因此字串"ZEROWIDTHNO-BREAKSPACE"又被稱作BOM。

　　UTF-8不需要BOM來表明字元順序，但可以用BOM來表明編碼方式。

字串"ZEROWIDTHNO-BREAKSPACE"的UTF-8編碼是EFBBBF（讀者可以用我們前面介紹的編碼方法驗證一下）。

所以如果接收者收到以EFBBBF開頭的字元流，就知道這是UTF-8編碼了。

　　Windows就是使用BOM來標記文本文件的編碼方式的。

6、進一步的參考資料　　本文主要參考的資料是"ShortoverviewofISO-IEC10646andUnicode"。

　　我還找了兩篇看上去不錯的資料，不過因為我開始的疑問都找到了答案，所以就沒有看：　　"UnderstandingUnicodeAgeneralintroductiontotheUnicodeStandard"　　"CharactersetencodingbasicsUnderstandingcharactersetencodingsandlegacyencodings"　　我寫過UTF-8、UCS-2、GBK相互轉換的軟體包，包括使用WindowsAPI和不使用WindowsAPI的版本。

以後有時間的話，我會整理一下放到我的個人主頁上(http://fmddlmyy.home4u.china.com)。

附錄1再說說區位碼、GB2312、內碼和程式碼頁　　有的朋友對文章中這句話還有疑問：　　「GB2312的原文還是區位碼，從區位碼到內碼，需要在高字元和低字元上分別加上A0。

」　　我再詳細解釋一下：　　「GB2312的原文」是指國家1980年的一個標準《中華人民共和國國家標準訊息交換用漢字編碼字串集基本集GB2312-80》。

這個標準用兩個數來編碼漢字和中文符號。

第一個數稱為「區」，第二個數稱為「位」。

所以也稱為區位碼。

1-9區是中文符號，16-55區是一級漢字，56-87區是二級漢字。

現在Windows也還有區位輸入法，例如輸入1601得到「啊」。

　　內碼是指操作系統內部的字串編碼。

早期操作系統的內碼是與語言相關的.現在的Windows在內部統一使用Unicode，然後用程式碼頁適應各種語言,「內碼」的概念就比較模糊了。

微軟一般將預設程式碼頁指定的編碼說成是內碼，在特殊的場合也會說自己的內碼是Unicode，例如在GB18030問題的處理上。

　　所謂程式碼頁(codepage)就是針對一種語言文字的字串編碼。

例如GBK的codepage是CP936，BIG5的codepage是CP950，GB2312的codepage是CP20936。

　　Windows中有預設程式碼頁的概念，即預設用什麼編碼來解釋字串。

例如Windows的記事本開啟了一個文本文件，裡面的內容是字元流：BA、BA、D7、D6。

Windows應該去怎麼解釋它呢？　　是按照Unicode編碼解釋、還是按照GBK解釋、還是按照BIG5解釋，還是按照ISO8859-1去解釋？如果按GBK去解釋，就會得到「漢字」兩個字。

按照其它編碼解釋，可能找不到對應的字串，也可能找到錯誤的字串。

所謂「錯誤」是指與文本作者的本意不符，這時就產生了亂碼。

　　答案是Windows按照現用的預設程式碼頁去解釋文本文件裡的字元流。

預設程式碼頁可以通過控制台的區域選項設定。

記事本的另存為中有一項ANSI，其實就是按照預設程式碼頁的編碼方法儲存。

　　Windows的內碼是Unicode，它在技術上可以同時支持多個程式碼頁。

只要文件能說明自己使用什麼編碼，用戶又安裝了對應的程式碼頁，Windows就能正確顯示，例如在HTML文件中就可以指定charset。

　　有的HTML文件作者，特別是英文作者，認為世界上所有人都使用英文，在文件中不指定charset。

如果他使用了0x80-0xff之間的字串，中文Windows又按照預設的GBK去解釋，就會出現亂碼。

這時只要在這個html文件中加上指定charset的語句，例如：如果原作者使用的程式碼頁和ISO8859-1相容，就不會出現亂碼了。

　　再說區位碼，啊的區位碼是1601，寫成16進制是0x10,0x01。

這和電腦廣泛使用的ASCII編碼衝突。

為了相容00-7f的ASCII編碼，我們在區位碼的高、低字元上分別加上A0。

這樣「啊」的編碼就成為B0A1。

我們將加過兩個A0的編碼也稱為GB2312編碼，雖然GB2312的原文根本沒提到這一點。

中日韓漢字Unicode編碼表http://khiav.myweb.hinet.net/html/unicode.htm網頁式的Unicode轉換器-但顯示的編碼為十進制http://tool.webmasterhome.cn/unicode.asp 資料來源：http://forum.slime.com.tw/thread169880.html 全站熱搜 創作者介紹 flykof 十年磨一劍 flykof發表在痞客邦留言(1)人氣() E-mail轉寄 全站分類：藝文評論上一篇：MySQL安裝設定 下一篇：ASCII字元表 ▲top 留言列表 發表留言 站方公告 [公告]2022/09/02相簿、部落格功能維護公告[公告]2022/08/22、08/23應用市集部分功能維護公告[公告]痞客邦APP全新服務上線-美食優惠券 熱門文章 文章分類 網頁設計(2) CGI(1)Javascript(1) 資訊(2) RFID(1)Embedded(1) 網際網路(2) PPP(1)網際網路(3) Error(1) error(4) C/C++(2) C/C++(4)原創Function(1) Linux(3) LinuxDeviceDrivers(11)linux(10)ubuntu(3) Embedded(4) S3C2410(5)WinCE-s3c2410(2)cortex-m3(1)菜鳥的嵌入式系統(4) QT(1) QT(12) SQL(2)未分類文章(10) 最新文章 最新留言 文章精選 文章精選 2012四月(1) 2012三月(8) 2011十一月(3) 2011十月(1) 2010四月(3) 2010三月(2) 2010二月(2) 2010一月(1) 2009十二月(2) 2009十一月(2) 2009十月(1) 2009九月(6) 2009八月(2) 2009七月(5) 2009六月(4) 2009五月(10) 2009四月(10) 2009三月(14) 所有文章列表 文章搜尋 新聞交換(RSS) 誰來我家 參觀人氣 本日人氣： 累積人氣： QRCode POWEREDBY (登入) 回到頁首 回到主文 免費註冊 客服中心 痞客邦首頁 ©2003-2022PIXNET 關閉視窗