本頁使用了標題或全文手工轉換

UTF-8

維基百科,自由的百科全書
前往: 導覽搜尋

UTF-88-bit Unicode Transformation Format)是一種針對Unicode的可變長度字元編碼,也是一種字首碼。它可以用來表示Unicode標準中的任何字元,且其編碼中的第一個位元組仍與ASCII相容,這使得原來處理ASCII字元的軟體無須或只須做少部份修改,即可繼續使用。因此,它逐漸成為電子郵件網頁及其他儲存或傳送文字的應用中,優先採用的編碼。

UTF-8使用一至六個位元組為每個字元編碼(儘管如此,2003年11月UTF-8被RFC 3629重新規範,只能使用原來Unicode定義的區域,U+0000到U+10FFFF,也就是說最多四個位元組):

  1. 128個US-ASCII字元只需一個位元組編碼(Unicode範圍由U+0000至U+007F)。
  2. 帶有附加符號拉丁文希臘文西里爾字母亞美尼亞語希伯來文阿拉伯文敘利亞文它拿字母則需要兩個位元組編碼(Unicode範圍由U+0080至U+07FF)。
  3. 其他基本多文種平面(BMP)中的字元(這包含了大部分常用字,如大部分的漢字)使用三個位元組編碼(Unicode範圍由U+0800至U+FFFF)。
  4. 其他極少使用的Unicode 輔助平面的字元使用四至六位元組編碼(Unicode範圍由U+10000至U+1FFFFF使用四位元組,Unicode範圍由U+200000至U+3FFFFFF使用五位元組,Unicode範圍由U+4000000至U+7FFFFFFF使用六位元組)。

對上述提及的第四種字元而言,UTF-8使用四至六個位元組來編碼似乎太耗費資源了。但UTF-8對所有常用的字元都可以用三個位元組表示,而且它的另一種選擇,UTF-16編碼,對前述的第四種字元同樣需要四個位元組來編碼,所以要決定UTF-8或UTF-16哪種編碼比較有效率,還要視所使用的字元的分布範圍而定。不過,如果使用一些傳統的壓縮系統,比如DEFLATE,則這些不同編碼系統間的的差異就變得微不足道了。若顧及傳統壓縮演算法在壓縮較短文字上的效果不大,可以考慮使用Unicode標準壓縮格式(SCSU)。

網際網路工程工作小組(IETF)要求所有網際網路協議都必須支援UTF-8編碼[1]網際網路郵件聯盟(IMC)建議所有電子郵件軟體都支援UTF-8編碼。[1]

歷史[編輯]

1992年初,為建立良好的位元組串編碼系統以供多位元組字元集使用,開始了一個正式的研究。ISO/IEC 10646的初稿中有一個非必須的附錄,名為UTF。當中包含了一個供32位元字元使用的位元組串編碼系統。這個編碼方式的效能並不令人滿意,但它提出了將0-127的範圍保留給ASCII以相容舊系統的概念。

1992年7月,X/Open委員會XoJIG開始尋求一個較佳的編碼系統。Unix系統實驗室(USL)的Dave Prosser為此提出了一個編碼系統的建議。它具備可更快速實作的特性,並引入一項新的改進。其中,7位元ASCII符號只代表原來的意思,所有多位元組序列則會包含第8位元的符號,也就是所謂的最高有效位元

1992年8月,這個建議由IBMX/Open的代表流傳到一些感興趣的團體。與此同時,貝爾實驗室九號計畫作業系統工作小組的肯·湯普遜對這編碼系統作出重大的修改,讓編碼可以自我同步,使得不必從字串的開首讀取,也能找出字元間的分界。1992年9月2日,肯·湯普遜羅勃·派克一起在美國新澤西州一架餐車的餐桌墊上描繪出此設計的要點。接下來的日子,Pike及湯普遜將它實現,並將這編碼系統完全應用在九號計畫當中,及後他將有關成果回饋X/Open。

1993年1月25-29日的在聖地牙哥舉行的USENIX會議首次正式介紹UTF-8。

自1996年起,微軟CAB(MS Cabinet)規格在UTF-8標準正式落實前就明確容許在任何地方使用UTF-8編碼系統。但有關的編碼器實際上從來沒有實作這方面的規格。

描述[編輯]

Unicode與UTF-8的轉換

目前有好幾份關於UTF-8詳細規格的檔案,但這些檔案在定義上有些許的不同:

  • RFC 3629 / STD 63(2003),這份檔案制定了UTF-8是標準的網際網路協議元素
  • 第四版,The Unicode Standard,§3.9-§3.10(2003)
  • ISO/IEC 10646-1:2000附加檔案D(2000)

它們取代了以下那些被淘汰的定義:

  • ISO/IEC 10646-1:1993修正案2/附加檔案R(1996)
  • 第二版,The Unicode Standard,附錄A(1996)
  • RFC 2044(1996)
  • RFC 2279(1998)
  • 第三版,The Unicode Standard,§2.3(2000)及勘誤表#1:UTF-8 Shortest Form(2000)
  • Unicode Standard附加檔案#27: Unicode 3.1(2001)

事實上,所有定義的基本原理都是相同的,它們之間最主要的不同是支援的字元範圍及無效輸入的處理方法。

Unicode字元位元被分割為數個部分,並分配到UTF-8的位元組串中較低的位元的位置。在U+0080的以下字元都使用內含其字元的單位元組編碼。這些編碼正好對應7位元的ASCII字元。在其他情況,有可能需要多達4個字元組來表示一個字元。這些多位元組的最高有效位元會設定成1,以防止與7位元的ASCII字元混淆,並保持標準的位元組主導字串運作順利。

代碼範圍
十六進制
標量值(scalar value)
二進制
UTF-8
二進制十六進制
註釋
000000 - 00007F
128個代碼
00000000 00000000 0zzzzzzz 0zzzzzzz(00-7F) ASCII字元範圍,位元組由零開始
七個z 七個z
000080 - 0007FF
1920個代碼
00000000 00000yyy yyzzzzzz 110yyyyy(C0-DF) 10zzzzzz(80-BF) 第一個位元組由110開始,接著的位元組由10開始
三個y;二個y;六個z 五個y;六個z
000800 - 00D7FF
00E000 - 00FFFF
61440個代碼 [Note 1]
00000000 xxxxyyyy yyzzzzzz 1110xxxx(E0-EF) 10yyyyyy 10zzzzzz 第一個位元組由1110開始,接著的位元組由10開始
四個x;四個y;二個y;六個z 四個x;六個y;六個z
010000 - 10FFFF
1048576個代碼
000wwwxx xxxxyyyy yyzzzzzz 11110www(F0-F7) 10xxxxxx 10yyyyyy 10zzzzzz 將由11110開始,接著的位元組由10開始
三個w;二個x;四個x;四個y;二個y;六個z 三個w;六個x;六個y;六個z
Note 1 Unicode在範圍D800-DFFF中不存在任何字元,基本多文種平面中約定了這個範圍用於UTF-16擴展標識輔助平面(兩個UTF-16表示一個輔助平面字元)。當然,任何編碼都是可以被轉換到這個範圍,但在unicode中他們並不代表任何合法的值。

例如,希伯來語字母aleph(א)的Unicode代碼是U+05D0,按照以下方法改成UTF-8:

  • 它屬於U+0080到U+07FF區域,這個表說明它使用雙位元組,110yyyyy 10zzzzzz.
  • 十六進位的0x05D0換算成二進位就是101-1101-0000.
  • 這11位數按順序放入"y"部分和"z"部分:11010111 10010000.
  • 最後結果就是雙位元組,用十六進位寫起來就是0xD7 0x90,這就是這個字元aleph(א)的UTF-8編碼。

所以開始的128個字元(US-ASCII)只需一位元組,接下來的1920個字元需要雙位元組編碼,包括帶附加符號拉丁字母希臘字母西里爾字母科普特語字母,亞美尼亞語字母,希伯來文字母和阿拉伯字母的字元。基本多文種平面中其餘的字元使用三個位元組,剩餘字元使用四個位元組。

根據這種方式可以處理更大數量的字元。原來的規範允許長達6位元組的序列,可以覆蓋到31位元(通用字元集原來的極限)。儘管如此,2003年11月UTF-8被RFC 3629重新規範,只能使用原來Unicode定義的區域,U+0000到U+10FFFF。根據這些規範,以下位元組值將無法出現在合法UTF-8序列中:

編碼(二進位 編碼(十六進位 注釋
1100000x C0, C1 過長編碼:雙位元組序列的頭位元組,但碼點 <= 127
1111111x FE, FF 無法達到:7或8位元組序列的頭位元組
111110xx
1111110x
F8, F9, FA, FB, FC, FD 被RFC 3629規範:5或6位元組序列的頭位元組
11110101
1111011x
F5, F6, F7 被RFC 3629規範:碼點超過10FFFF的頭位元組

UTF-8編碼位元組含義[編輯]

  • 對於UTF-8編碼中的任意位元組B,如果B的第一位為0,則B獨立的表示一個字元(ASCII碼);
  • 如果B的第一位為1,第二位為0,則B為一個多位元組字元中的一個位元組(非ASCII字元);
  • 如果B的前兩位為1,第三位為0,則B為兩個位元組表示的字元中的第一個位元組;
  • 如果B的前三位為1,第四位為0,則B為三個位元組表示的字元中的第一個位元組;
  • 如果B的前四位為1,第五位為0,則B為四個位元組表示的字元中的第一個位元組;

因此,對UTF-8編碼中的任意位元組,根據第一位,可判斷是否為ASCII字元;根據前二位,可判斷該位元組是否為一個字元編碼的第一個位元組;根據前四位(如果前兩位均為1),可確定該位元組為字元編碼的第一個位元組,並且可判斷對應的字元由幾個位元組表示;根據前五位(如果前四位為1),可判斷編碼是否有錯誤或資料傳輸過程中是否有錯誤。

設計UTF-8的理由[編輯]

UTF-8的設計有以下的多字元組序列的特質:

  • 單位元組字元的最高有效位元永遠為0。
  • 多位元組序列中的首個字元組的幾個最高有效位元決定了序列的長度。最高有效位為110的是2位元組序列,而1110的是三位元組序列,如此類推。
  • 多位元組序列中其餘的位元組中的首兩個最高有效位元為10

UTF-8的這些特質,保證了一個字元的位元組序列不會包含在另一個字元的位元組序列中。這確保了以位元組為基礎的部份字串比對(sub-string match)方法可以適用於在文字中搜尋字或詞。有些比較舊的可變長度8位元編碼(如Shift JIS)沒有這個特質,故字串比對的演算法變得相當複雜。雖然這增加了UTF-8編碼的字串的資訊冗餘,但是利多於弊。另外,資料壓縮並非Unicode的目的,所以不可混為一談。即使在傳送過程中有部份位元組因錯誤或干擾而完全遺失,還是有可能在下一個字元的起點重新同步,令受損範圍受到限制。

另一方面,由於其位元組序列設計,如果一個疑似為字串的序列被驗證為UTF-8編碼,那麼我們可以有把握地說它是UTF-8字串。一段兩位元組隨機序列碰巧為合法的UTF-8而非ASCII的機率為32分1。對於三位元組序列的機率為256分1,對更長的序列的機率就更低了。

UTF-8的編碼方式[編輯]

UTF-8是UNICODE的一種變長度的編碼表達方式〈一般UNICODE為雙位元組(指UCS2)〉,它由肯·湯普遜Ken Thompson於1992年建立,現在已經標准化為RFC 3629。UTF-8就是以8位元為單元對UCS進行編碼,而UTF-8不使用大尾序和小尾序的形式,每個使用UTF-8儲存的字元,除了第一個字節外,其餘字節的頭兩個位元都是以"10"開始,使文字處理器能夠較快地找出每個字元的開始位置。

但為了與以前的ASCII碼相容(ASCII為一個位元組),因此UTF-8選擇了使用可變長度字節來儲存Unicode:

Unicode 和 UTF-8 之間的轉換關係表 ( x 字元表示碼點占據的位 )
碼點的位數 碼點起值 碼點終值 位元組序列 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6
  7 U+0000 U+007F 1 0xxxxxxx
11 U+0080 U+07FF 2 110xxxxx 10xxxxxx
16 U+0800 U+FFFF 3 1110xxxx 10xxxxxx 10xxxxxx
21 U+10000 U+1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
26 U+200000 U+3FFFFFF 5 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
31 U+4000000 U+7FFFFFFF 6 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
  • 在ASCII碼的範圍,用一個位元組表示,超出ASCII碼的範圍就用位元組表示,這就形成了我們上面看到的UTF-8的表示方法,這様的好處是當UNICODE檔案中只有ASCII碼時,儲存的檔案都為一個位元組,所以就是普通的ASCII檔案無異,讀取的時候也是如此,所以能與以前的ASCII檔案相容。
  • 大於ASCII碼的,就會由上面的第一位元組的前幾位表示該unicode字元的長度,比如110xxxxx前三位的二進位表示告訴我們這是個2BYTE的UNICODE字元;1110xxxx是個三位的UNICODE字元,依此類推;xxx的位置由字元編碼數的二進製表示的位填入。越靠右的x具有越少的特殊意義。只用最短的那個足夠表達一個字元編碼數的多字節串。注意在多字節串中,第一個字節的開頭"1"的數目就是整個串中字節的數目。

ASCII字母繼續使用1字節儲存,重音文字希臘字母西里爾字母等使用2字節來儲存,而常用的漢字就要使用3字節。輔助平面字元則使用4字節。

在UTF-8檔案的開首,很多時都放置一個U+FEFF字元(UTF-8以EF,BB,BF代表),以顯示這個文字檔案是以UTF-8編碼。

UTF-8的特性[編輯]

UTF-8圖表說明
UTF-8
最小碼位 0000
最大碼位 10FFFF
每位元組所占位數 8 bits
Byte order N/A
每個字元最小位元組數 1
每個字元最大位元組數 4
  • UCS字元U+0000到U+007F(ASCII)被編碼為字節0x00到0x7F(ASCII相容),這也意味著只包含7位ASCII字元的檔案在ASCII和UTF-8兩種編碼方式下是一樣的。
  • 所有>U+007F的UCS字元被編碼為一個多個字節的串,每個字節都有標記位集。因此,ASCII字節(0x00-0x7F)不可能作為任何其他字元的一部分。
  • 表示非ASCII字元的多字節串的第一個字節總是在0xC0到0xFD的範圍裡,並指出這個字元包含多少個字節。多字節串的其餘字節都在0x80到0xBF範圍裡,這使得重新同步非常容易,並使編碼無國界,且很少受丟失字節的影響。
  • 可以編入所有可能的231個UCS代碼
  • UTF-8編碼字元理論上可以最多到6個字節長,然而16位元BMP字元最多只用到3字節長。
  • Bigendian UCS-4字節串的排列順序是預定的。
  • 字節0xFE和0xFF在UTF-8編碼中從未用到,同時,UTF-8以位元組為編碼單元,它的位元組順序在所有系統中都是一様的,沒有位元組序的問題,也因此它實際上並不需要BOM
  • 與UTF-16或其他Unicode編碼相比,對於不支援Unicode和XML的系統,UTF-8更不容易造成問題。

UTF-8編碼的優點[編輯]

總體來說,在Unicode字串中不可能由碼點數量決定顯示它所需要的長度,或者顯示字串之後在文字緩衝區中光標應該放置的位置;組合字元、變寬字型、不可列印字元和從右至左的文字都是其歸因。

所以儘管在UTF-8字串中字元數量與碼點數量的關係比UTF-32更為複雜,在實際中很少會遇到有不同的情形。

更詳細的說,UTF-8編碼具有以下幾點優點:

  • ASCII是UTF-8的一個子集。因為一個純ASCII字串也是一個合法的UTF-8字串,所以現存的ASCII文字不需要轉換。為傳統的擴充功能ASCII字元集設計的軟體通常可以不經修改或很少修改就能與UTF-8一起使用。
  • 使用標準的面向位元組的排序常式對UTF-8排序將產生與基於Unicode代碼點排序相同的結果。(儘管這只有有限的有用性,因為在任何特定語言或文化下都不太可能有仍可接受的文字排列順序。)
  • UTF-8和UTF-16都是可延伸標記式語言文件的標準編碼。所有其它編碼都必須通過顯式或文字聲明來指定。[2]
  • 任何面向位元組字串搜尋演算法都可以用於UTF-8的資料(只要輸入僅由完整的UTF-8字元組成)。但是,對於包含字元記數的正規表示式或其它結構必須小心。
  • UTF-8字串可以由一個簡單的演算法可靠地識別出來。就是,一個字串在任何其它編碼中表現為合法的UTF-8的可能性很低,並隨字串長度增長而減小。舉例說,字元值C0,C1,F5至FF從來沒有出現。為了更好的可靠性,可以使用正規表示式來統計非法過長和替代值(可以檢視W3 FAQ: Multilingual Forms上的驗證UTF-8字串的正規表示式)。
  • 與UCS-2的比較:ASCII轉換成UCS-2,在編碼前插入一個0x0。用這些編碼,會含括一些控制符,比如"或 '/',這在UNIX和一些C函式中,將會產生嚴重錯誤。因此可以肯定,UCS-2不適合作為Unicode的外部編碼,也因此誕生了UTF-8。

UTF-8編碼的缺點[編輯]

編寫不良的解析器[編輯]

一份寫得很差(並且與當前標準的版本不相容)的UTF-8解析器可能會接受一些不同的偽UTF-8表示並將它們轉換到相同的Unicode輸出上。這為設計用於處理八位表示的校驗常式提供了一種遺漏資訊的方式。

不利於正規表示式檢索[編輯]

正規表示式可以進行很多英文高階的模糊檢索。例如,[a-h]表示a到h間所有字母。

同樣GBK編碼的中文也可以這樣利用正規表示式,比如在只知道一個字的讀音而不知道怎麼寫的情況下,也可用正規表示式檢索,因為GBK編碼是按讀音排序的。只是UTF-8不是按讀音排序的,所以會對正規表示式檢索造成不利影響。但是這種使用方式並未考慮中文中的破音字,因此影響不大。Unicode是按部首排序的,因此在只知道一個字的部首而不知道如何發音的情況下,UTF-8可用正規表示式檢索而GBK不行。

其他[編輯]

與其他Unicode編碼相比,特別是UTF-16,在UTF-8中ASCII字元佔用的空間只有一半,可是在一些字元的UTF-8編碼佔用的空間就要多出1/3,特別是中文、日文和韓文(CJK)這樣的方塊文字。

utf8_unicode_ci和utf8_general_ci區別[編輯]

在資料庫系統MySQLMariaDB中有多種字元集,其中utf8_unicode_ci和utf8_general_ci是最常用的,但是utf8_general_ci對某些語言的支援有一些小問題,如果可以接受,那最好使用utf8_general_ci,因為它速度快。否則,請使用較為精確的utf8_unicode_ci,不過速度會慢一些。

UTF-8的衍生物[編輯]

Windows[編輯]

雖然不是標準,但許多Windows程式(包括Windows記事本)在UTF-8編碼的檔案的開首加入一段位元組串EF BB BF。這是位元組順序記號U+FEFF的UTF-8編碼結果。對於沒有預期要處理UTF-8的文字編輯器和瀏覽器會顯示成ISO-8859-1字串

Posix系統[編輯]

Posix系統明確不建議使用位元組序遮罩EF BB BF[2]因為很多文字檔案期望以 「#!」開頭指示要執行的程式。Linux系統選擇使用Unicode規範形式Normalization Form C(NFC),即優先使用預組裝字元(precomposed character)而非組合字元序列(combining character sequence)。

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個數量級。[2]

Java[編輯]

在通常用法下,Java程式語言在通過InputStreamReaderOutputStreamWriter讀取和寫入串的時候支援標準UTF-8。但是,Java也支援一種非標準的變體UTF-8,供物件的序列化Java本地介面和在class檔案中的嵌入常數時使用的modified UTF-8

變種UTF-8[編輯]

標準和變種的UTF-8有兩個不同點。第一,空字元(null character,U+0000)使用雙位元組的0xc0 0x80,而不是單位元組的0x00。這保證了在已編碼字串中沒有嵌入空位元組。因為C語言等語言程式中,單位元組空字元是用來標誌字串結尾的。當已編碼字串放到這樣的語言中處理,一個嵌入的空字元將把字串一刀兩斷。

第二個不同點是基本多文種平面之外字元的編碼的方法。在標準UTF-8中,這些字元使用4位元組形式編碼,而在改正的UTF-8中,這些字元和UTF-16一樣首先表示為代理對(surrogate pairs),然後再像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作業系統使用正式分解萬國碼(canonically decomposed Unicode),在檔案系統中使用UTF-8編碼進行檔案命名,這做法通常被稱為UTF-8-MAC。正式分解萬國碼中,預組合字元是被禁止使用的,必須以組合字元取代。

這種方法使分類變得非常簡單,但是會搞混那些使用預組合字元為標準、組合字元用來顯示特殊字元的軟體。Mac系統的這種NFD資料是萬國碼規範化(Unicode normalization)的一種格式。而其他系統,包括WindowsLinux,使用萬國碼規範的NFC形式,也是W3C標準使用的形式。所以通常NFD資料必須轉換成NFC才能被其他平台或者網路使用。

蘋果開發者專區有關於此問題的討論:Apple Q&A 1173

參考文獻[編輯]

統一碼聯盟出版的書[編輯]

  • The Unicode Standard, Version 5.0, Fifth Edition, The Unicode Consortium, Addison-Wesley Professional,2006年10月27日。ISBN 0-321-48091-0
  • The Unicode Standard, Version 4.0, The Unicode Consortium, Addison-Wesley Professional,2003年8月27日。ISBN 0-321-18578-1

外部連結[編輯]

參見[編輯]