UTF-8

UTF-8建議所有電子郵件程式都能夠使用UTF-8展示和建立郵件， W3C建議UTF-8作為XML檔案和HTML檔案的預設編碼方式。網際網路工程工作小組建議所有電子郵件軟體都支援UTF-8編碼。歷史.1992年初，為建立良好的位元組串編碼系統以供多位元組字元集使用，開始了一個正式的研究。ISO/IEC 10646的初稿中有一個非必須的附錄，名為UTF。當中包含了一個供32位元的字元使用的位元組串編碼系統。這個編碼方式的效能並不令人滿意，但它提出了將0-127的範圍保留給ASCII以相容舊系統的概念。1992年7月，X/Open委員會XoJIG開始尋求一個較佳的編碼系統。Unix系統實驗室的Dave Prosser為此提出了一個編碼系統的建議。它具備可更快速實作的特性，並引入一項新的改進。其中，7位元的ASCII符號只代表原來的意思，所有多位元組序列則會包含第8位元的符號，也就是所謂的最高有效位元。1992年8月，這個建議由IBMX/Open的代表流傳到一些感興趣的團體。與此同時，貝爾實驗室九號計畫作業系統工作小組的肯·湯普遜對這編碼系統作出重大的修改，讓編碼可以自我同步，使得不必從字串的開首讀取，也能找出字元間的分界。1992年9月2日，肯·湯普遜和羅勃·派克一起在美國新澤西州一架餐車的餐桌墊上描繪出此設計的要點。接下來的日子，Pike及湯普遜將它實現，並將這編碼系統完全應用在九號計畫當中，及後他將有關成果回饋X/Open。1993年1月25-29日的在聖地牙哥舉行的USENIX會議首次正式介紹UTF-8。自1996年起，微軟的CAB規格在UTF-8標準正式落實前就明確容許在任何地方使用UTF-8編碼系統。但有關的編碼器實際上從來沒有實作這方面的規格。結構.UTF-8使用一至六個位元組為每個字元編碼：對上述提及的第四種字元而言，UTF-8使用四至六個位元組來編碼似乎太耗費資源了。但UTF-8對所有常用的字元都可以用三個位元組表示，而且它的另一種選擇，UTF-16編碼，對前述的第四種字元同樣需要四個位元組來編碼，所以要決定UTF-8或UTF-16哪種編碼比較有效率，還要視所使用的字元的分佈範圍而定。不過，如果使用一些傳統的壓縮系統，比如DEFLATE，則這些不同編碼系統間的的差異就變得微不足道了。若顧及傳統壓縮演算法在壓縮較短文字上的效果不大，可以考慮使用Unicode標準壓縮格式。描述.目前有好幾份關於UTF-8詳細規格的檔案，但這些檔案在定義上有些許的不同：它們取代了以下那些被淘汰的定義：事實上，所有定義的基本原理都是相同的，它們之間最主要的不同是支援的字元範圍及無效輸入的處理方法。Unicode字元的位元被分割為數個部分，並分配到UTF-8的位元組串中較低的位元的位置。在U+0080的以下字元都使用內含其字元的單位元組編碼。這些編碼正好對應7位元的ASCII字元。在其他情況，有可能需要多達4個字元組來表示一個字元。這些多位元組的最高有效位元會設定成1，以防止與7位元的ASCII字元混淆，並保持標準的位元組主導字串運作順利。Note 1 Unicode在範圍D800-DFFF中不存在任何字元，基本多文種平面中約定了這個範圍用於UTF-16擴充套件標識輔助平面。當然，任何編碼都是可以被轉換到這個範圍，但在unicode中他們並不代表任何合法的值。例如，希伯來語字母aleph的Unicode程式碼是U+05D0，按照以下方法改成UTF-8：所以開始的128個字元只需一位元組，接下來的1920個字元需要雙位元組編碼，包括帶附加符號的拉丁字母，希臘字母，西裡爾字母，科普特語字母，亞美尼亞語字母，希伯來文字母和阿拉伯字母的字元。基本多文種平面中其餘的字元使用三個位元組，剩餘字元使用四個位元組。根據這種方式可以處理更大數量的字元。原來的規範允許長達6位元組的序列，可以覆蓋到31位元。儘管如此，2003年11月UTF-8被RFC 3629重新規範，〉; zh-hk:》，它由肯·湯普遜於1992年建立，現在已經標準化為RFC 3629。UTF-8就是以8位為單元對UCS進行編碼，而UTF-8不使用大尾序和小尾序的形式，每個使用UTF-8儲存的字元，除了第一個位元組外，其餘位元組的頭兩個位元都是以"10"開始，使文書處理器能夠較快地找出每個字元的開始位置。但為了與以前的ASCII碼相容，因此UTF-8選擇了使用可變長度位元組來儲存Unicode：ASCII字母繼續使用1位元組儲存，重音文字、希臘字母或西里爾字母等使用2位元組來儲存，而常用的漢字就要使用3位元組。輔助平面字元則使用4位元組。在UTF-8+BOM格式檔案的開首，很多時都放置一個U+FEFF字元，以顯示這個文字檔案是以UTF-8編碼。UTF-8編碼的優點.總體來說，在Unicode字串中不可能由碼點數量決定顯示它所需要的長度，或者顯示字串之後在文字緩衝區中游標應該放置的位置；組合字元、變寬字型、不可列印字元和從右至左的文字都是其歸因。所以儘管在UTF-8字串中字元數量與碼點數量的關係比UTF-32更為複雜，在實際中很少會遇到有不同的情形。更詳細的說，UTF-8編碼具有以下幾點優點：UTF-8 編碼的缺點.編寫不良的解析器.如果一個 UTF-8 解析器寫得很差，那麼它接收到一些偽 UTF-8 時會將其轉換成看似正確實則錯誤的 Unicode 輸出。處理八位表示的校驗例程可能遺漏一些資訊。不利於正則表示式檢索.正則表示式可以進行很多高階的英文模糊檢索。例如，[a-h]表示 a 到 h 間所有字母。同樣 GBK 編碼的中文也可以這樣利用正則表示式，比如在只知道一個字的讀音而不知道怎麼寫的情況下，也可用正則表示式檢索，因為 GBK 編碼是按讀音排序的。但是 Unicode 漢字不是按讀音排序的，所以不利於用正則表示式檢索。雖然正則表示式檢索並未考慮中文的多音字，但是由於中文的多音字數量不多，不少多音字還是同音不同調型別的多音字，所以大多數情況下正則表示式檢索是還可以接受的。不過 Unicode 漢字按部首排序，因此在只知道一個字的部首而不知道如何發音的情況下，UTF-8 可用正則表示式檢索而 GBK 不行。其他.UTF-8 的 ASCII 字元-{只}-佔用一個位元組，比較節省空間，但是更多字元的 UTF-8 編碼佔用的空間就要多出1/2，特別是中文、日文和韓文這樣的方塊文字，它們大多需要三個位元組。UTF-8的衍生物.Windows.雖然不是標準，但許多Windows程式在UTF-8編碼的檔案的開首加入一段位元組串codice_4。這是位元組順序記號codice_5的UTF-8編碼結果。對於沒有預期要處理UTF-8的文字編輯器和瀏覽器會顯示成ISO-8859-1字串codice_6。Posix系統.Posix系統明確不建議使用位元組序掩碼codice_4。因為很多文字檔案期望以 “#!”。2002年9月釋出的Red Hat Linux 8.0才開始正式把大多數區域設定的預設編碼設為UTF-8。此前是各種語言的但位元組編碼為主。2004年9月SuSE Linux 9.1開始，預設編碼遷移為UTF-8。字串處理時，使用UTF-8或locale依賴的多位元組編碼情形，比使用C語言wchar_t的寬字元固定寬度編碼，要慢1至2個數量級。Java.在通常用法下，Java程式語言在透過和讀取和寫入串的時候支援標準UTF-8。但是，Java也支援一種非標準的變體UTF-8，供物件的序列化，Java本地介面和在class檔案中的嵌入常數時使用的。變種UTF-8.標準和變種的UTF-8有兩個不同點。第一，空字元使用雙位元組的0xc0 0x80，而不是單位元組的0x00。這保證了在已編碼字串中沒有嵌入空位元組。因為C語言等語言程式中，單位元組空字元是用來標誌字串結尾的。當已編碼字串放到這樣的語言中處理，一個嵌入的空字元將把字串一刀兩斷。第二個不同點是基本多文種平面之外字元的編碼的方法。在標準UTF-8中，這些字元使用4位元組形式編碼，而在修正的UTF-8中，這些字元和UTF-16一樣首先表示為代理對，然後再像CESU-8那樣按照代理對分別編碼。這樣修正的原因更是微妙。Java中的字元為16位長，因此一些Unicode字元需要兩個Java字元來表示。語言的這個性質蓋過了Unicode的增補平面的要求。儘管如此，為了要保持良好的向後相容、要改變也不容易了。這個修正的編碼系統保證了一個已編碼字串可以一次編為一個UTF-16碼，而不是一次一個Unicode碼點。不幸的是，這也意味著UTF-8中需要4位元組的字元在變種UTF-8中變成需要6位元組。因為變種UTF-8並不是UTF-8，所以使用者在交換資訊和使用網際網路的時候需要特別注意不要誤把變種UTF-8當成UTF-8資料。Mac OS X.Mac OS X作業系統使用正式分解萬國碼，在檔案系統中使用UTF-8編碼進行檔案命名，這做法通常被稱為UTF-8-MAC。正式分解萬國碼中，預組合字元是被禁止使用的，必須以組合字元取代。這種方法使分類變得非常簡單，但是會搞混那些使用預組合字元為標準、組合字元用來顯示特殊字元的軟體。Mac系統的這種NFD資料是萬國碼規範化的一種格式。而其他系統，包括Windows和Linux，使用萬國碼規範的NFC形式，也是W3C標準使用的形式。所以通常NFD資料必須轉換成NFC才能被其他平臺或者網路使用。蘋果開發者專區有關於此問題的討論：Apple Q&amp;A 1173 。MySQL.MySQL字元編碼集中有兩套UTF-8編碼實現：“utf8”和“utf8mb4”，其中“utf8”是一個字最多佔據3位元組空間的編碼實現；而“utf8mb4”則是一個字最多佔據4位元組空間的編碼實現，也就是UTF-8的完整實現。這是由於MySQL在4.1版本開始支援UTF-8編碼。直到2010年在5.5版本推出“utf8mb4”來代替、“utf8”重新命名為“utf8mb3”並調整“utf8”為“utf8mb3”的別名，並不建議使用舊“utf8”編碼，以此修正遺留問題。由統一碼聯盟出版的書.