UTF-8

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

編碼方式

碼點範圍	序列長度	Byte 1	Byte 2	Byte 3	Byte 4
0000～007F	1	0xxxxxxx(00-7F)
0080～07FF	2	110xxxxx(C0-DF)	10xxxxxx(80-BF)
0800～FFFF	3	1110xxxx(E0-EF)	10xxxxxx(80-BF)	10xxxxxx(80-BF)
10000～10FFFF	4	11110xxx(F0-F7)	10xxxxxx(80-BF)	10xxxxxx(80-BF)	10xxxxxx(80-BF)

範例

碼位	(二進位)	UTF-8	(二進位)
U+0041A	00000000 01000001	41	01000001
U+03C9ω	00000011 11001001	CF 89	11001111 10001001
U+20AC€	00100000 10101100	E2 82 AC	11100010 10000010 10101100
U+2C9B0𬦰	00000010 11001001 10110000	F0 AC A6 B0	11110000 10101100 10100110 10110000

特性

• 完全向下相容ASCII編碼範圍，所以多數既有的編譯器等軟體可以正常處理UTF-8資料。
• 基本多語言平面內的一般常用漢字佔3個bytes，比UTF-16與傳統Big5、Shift_JIS等編碼的2 bytes要長。
• 但實際上因為多數文件還是ASCII文字比例最高（如HTML文件有大量的HTML tag），多數情況下UTF-8會比UTF-16檔案總長度更短。
• UTF-8容易檢查錯誤，例如一個 0xE0～0xEF 的位元組可判斷其後面必須跟隨剛好兩個 0x80～0xBF 的位元組。但也因此造成一定程度的浪費。

CESU-8

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

例如U+1F44D👍的正確UTF-8應該編成F0 9F 91 8D。但某些實作卻把UTF-16的代理對D83D DC4D各自編碼為ED A0 BD與ED 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」儲存資料。

參見

• Unicode
• UTF-16
• 基本多語言平面
• 補充平面