UTF-8

UTF-8是Unicode的一種可變長度的字元編碼形式。它設計來相容於ASCII,讓原本處理ASCII字元的軟體幾乎無須修改,即可處理Unicode資料。因此它成為E-mail、網頁、程式碼等各種純文字文件處理Unicode時最通用的編碼方式。

編碼方式

碼點範圍序列長度Byte 1Byte 2Byte 3Byte 4
0000~007F10xxxxxxx(00-7F)
0080~07FF2110xxxxx(C0-DF)10xxxxxx(80-BF)
0800~FFFF31110xxxx(E0-EF)10xxxxxx(80-BF)10xxxxxx(80-BF)
10000~10FFFF411110xxx(F0-F7)10xxxxxx(80-BF)10xxxxxx(80-BF)10xxxxxx(80-BF)

範例

碼位(二進位)UTF-8(二進位)
U+0041A00000000 010000014101000001
U+03C9ω00000011 11001001CF 8911001111 10001001
U+20AC00100000 10101100E2 82 AC11100010 10000010 10101100
U+2C9B0𬦰00000010 11001001 10110000F0 AC A6 B011110000 10101100 10100110 10110000

特性

CESU-8

UTF-16使用代理對的方式來處理補充平面的文字,在一些UTF-8的變形實作上,存在有誤把代理對直接依照UTF-8編碼方式進行轉換的問題。


例如U+1F44D👍的正確UTF-8應該編成F0 9F 91 8D。但某些實作卻把UTF-16的代理對D83D DC4D各自編碼ED A0 BDED B1 8D,共6個bytes。


這並不是正確的UTF-8編碼Unicode官方文件(UTF-16的8位元相容編碼方式)規定這只能做為內部編碼,不應該用來交換資料。W3C也規定HTML不應使用這種編碼形式,以免造成無法預期的XSS風險。

但實際上可能因為一些資料庫、程式語言的錯誤實作,偶爾會在網址列等處看到這樣的資料。本站編碼資訊欄的「URL Encode」處有標註CESU-8的值,僅供參考,不建議使用。

MySQL編碼

MySQL資料庫早年支援的UTF-8實際上一直只支援3 bytes為止的範圍,而無法支援補充平面裡的擴充漢字等文字。

一直到2010年,才終於推出新的「utf8mb4」編碼去支援4 bytes的Unicode文字。隨著Emoji的風行,使用MySQL的各網站、論壇逐步才改以「utf8mb4」儲存資料。

參見