UNICODE 萬國碼淺談

MarchFun

■ UTF-8 轉換格式
在現有的軟體和訊息科技執行過程中，通常每位元中僅有 7 位元具備交換字元資料的功能。若要使用此類系統中的 Unicode 字元資料，則需要將個別萬國碼字元值及替換對組，轉換為代表相同訊息的一或多位元序列，但是仍受限於特定的數值範圍內。
為了配合使用者的需要，進而發展出二種變換格式。配合個別所需制定的傳送通道透明方式規則，這二種傳送格式繼而取代原有的單一方法。這就是所謂的通用字元集變換格式 (Universal Character Set Transformation format-UTF)，特別是 UTF-7 和 UTF-8。

UTF-8 一詞為 8 位元格式 UCS Transformation format (通用字元集變換格式) 的縮寫。若要在 8 位元 UNVIX 環境中使用萬國碼字元資料，X/Open 開發並公佈了所謂檔案系統通用字元集變換安全格式 (File System Safe UTF)-FSS-UFT，也稱作 UTF-2 的傳送格式。此後 UTF 已公認為 ISO/IEC 10646 的附加標準，並重新命名為 UTF-8，即通用字元集變換格式 8 位元格式。

UTF-8 的重要特性包括:

‧從 U+OOO0 至 U+007E 範圍內的萬國碼字元 (ASCII指令表)，變換為 UTF-8 位元 00 至 7E (ASCII值)
‧ASCII 值不會另外出現在 UTF-8 的變換過程中，因此適用於歷史檔案系統和符合 ASCII 位元語法的其他系統。
‧萬國碼本文之間的轉換程序十分簡單且效率極高。
‧第一個位元代表多位元序列之後的位元數量，可作為語法分析的有效參考值。
‧可以有效地自位元流中的任意位置尋找字元起始點，至少需反向搜尋 4 位元，便能容易地辨識出起始位元。例如 c 語言 isInitialByte=((byte & OxCO)!=0x80)
‧UTF-8 中即包含編碼使用的位元數。

■ UTF-7 轉換格式
UTF-7 一詞為 7 位元格式 UCS Transformation format (通用字元集變換格式) 的縮寫。許多現有的字元傳送媒介僅支援個別位元中的 7 位元特殊資料，只有內部整數值 0．‥127 的子集可以透明方式進行交換。但是 C0 (0．‥31)、DEL (127) 和其他數值卻無法在本媒介中，使用透明方式進行交換。此類媒介包括網際網路經常使用的一般郵件傳送媒介，特別是使用簡單信件傳輸協定 (Simple Mail Transport Protocol-SMTP) 的媒介。

為了發揮傳送媒介的功能，特別是開發多媒體網際網路郵件擴充協定 (Multimedia Internet Mail Extensions-MIME) 的標準規格，因此使用此傳輸格式，支援此環境之萬國碼 (UCS-2) 字元資料的有效交換功能。這類格式稱為 UTF-7。UTF-7 可應用於網際網路工作群組 (Internet NetworkWorking Group) RFC-1642，也可透過 unicode.org 全球訊息網網頁 (World Wide Web Page)，以及 unicode.org FTP 檔案資料庫的電子格式使用。

字元組 UTF-7 可確保網際網路郵件傳送的安全性，使用 MIME 協定的內容傳送編碼方式 (但不得違反行列長度和斷行的規定)。此外也可接受 7 位元 script 的編碼和標題 Q 編碼二種方式。MIME協定字元組識別符號為 UNICODE-1-1-UTF-7。

■ UTF-16
UTF-16 一詞即為 UCS Transformation format (通用字元集變換格式的縮寫)，意指 00 群組
的字面。

UTF-16 為 ISO/IEC 編碼，使用方式與萬國碼標準規格相同。在 UTF-16 中，UCS-2 編碼值與原值相同，字面 1...1610 的 ISO/IEC 10646 非 BMP 編碼值，使用特殊編碼對組表示。
UTF-16 定義 00 群組字面 1 至 16 與 UCS-4 編碼位置，以及特殊編碼對組之間的轉換程序，並與預留空間 D.28 部分萬國碼編準編碼中定義的轉換程序完全相同。

與萬國碼標準規格相同，所有預留空間編碼對組中的第一個元件，必須是在 D800 至 BFF18
範圍內的 UCS-2 編碼值。這兩個範圍即是所謂的上半部預留空間及下半部預留空間，聯合組成新定義 BMP 的 S (特殊) 區域。兩個範圍共提供 102410 個數值，此機制總共顯示出 10242 (=l,048,576) 個編碼值。這些編碼值取自於字面 UCS-4 中 0 群組的 1...1610 字面，也就是在 UCS-4 編碼 OOO01OOO0．‥OOlOFFFF16 的範圍內。

UTF-I6 並不支援顯示所有的 UCS-4 編碼空間，但範圍限制在 BMP 中和緊接於後的 16 個字面內。由於 ISOJTC1/SC2/WG2 規定，字面 1...14 應先填寫預先指定的字元。因此上述的範圍限制相當合理。此外其他的字面如字面 15 (OOOFOOOO...OOOFFFFF16) 和字面 16 (00100000...OOOFFFFF16)，則會保留為專用區域。其他的 UCS-4 專用編碼值 (群組 60 至 7F 以及 00 群組中的 E0 至 FF 字面)，無法使用 UTF-I6 執行。由於以此類編碼值編碼的資料無法在萬國碼操作程序中進行交換，特別建議您勿使用此類專用編碼值，可以字面 15 和 16 替代。

交換 ISO/IEC 10646 位於字面 1...16 中，內含非 BMP 編碼值資料的應用程式，應使用 UTF-l6 為預設的編碼形式。以萬國碼應用程式交換資料，必須使用 UCS-2 形式；若資料中包含非 BMP 編碼字元，則應先轉換成 UTF-16。