Unicode 和 UTF-8 有什麼不同？

先有碼位，再有位元組

Unicode 定義的編碼空間從 U+0000 到 U+10FFFF，可容納 1,114,112 個碼位，分成 17 個平面，每個平面 65,536 個。其中超過 150,000 個已分配給字元，涵蓋現代與古代文字、符號和表情符號。碼位的寫法是 U+ 後面接至少四位十六進位數字。

碼位只是一個數字。要儲存或傳送文字，就得把它轉成位元組，而方法不只一種：UTF-8、UTF-16 和 UTF-32 都是同一套 Unicode 字元的編碼方式。

UTF-8 如何決定用 1、2、3 或 4 個位元組

UTF-8 規範於 RFC 3629，是一種變長編碼。第一個位元組的開頭位元表示後面還有幾個位元組，而每個後續位元組都以 10 開頭。這讓資料流能自我同步：解碼器即使從字元中間開始讀，也能往後跳到下一個起始位元組。

計算範例：「é」是 U+00E9，二進位為 000 1110 1001，需要 2 個位元組的模式。高 5 位元 00011 填入 110xxxxx，得到 11000011（C3）；低 6 位元 101001 填入 10xxxxxx，得到 10101001（A9）。

由於前 128 個碼位編碼後與 ASCII 的單一位元組完全相同，任何合法的 ASCII 檔案本身就是合法的 UTF-8。這種向下相容性正是 UTF-8 成為網路預設編碼的主要原因，目前約 98% 的網站使用它。

UTF-8、UTF-16 與 UTF-32 比較

UTF-16 會把 U+FFFF 以上的字元存成由兩個 16 位元單位組成的代理對（surrogate pair）。這就是為什麼在 JavaScript 中 "😀".length 是 2：這個語言計算的是 UTF-16 單位，而不是字元。改用 [..."😀"].length 迭代則會得到 1。

英文文字用 UTF-8 最精簡。若文字以中文、日文或韓文為主，UTF-16 可能更小，因為這些字元在 UTF-8 中佔 3 個位元組，在 UTF-16 中只佔 2 個。

位元組順序記號（BOM）

BOM 是放在檔案最開頭的字元 U+FEFF。在 UTF-16 和 UTF-32 中，它告訴讀取端位元組是大端序還是小端序。在 UTF-8 中它編碼為 EF BB BF，只是一個簽章，因為 UTF-8 沒有位元組順序之分。

Unicode 的常見問答指出，UTF-8 BOM 既非必要，也不建議使用。但有些 Windows 編輯器還是會加上它，結果讓 shell 指令碼（#! 那行不再是第一行）、CSV 標題列，以及沒預期到它的 JSON 剖析器出錯。如果檔案開頭出現 ，那就是被當成 Windows-1252 讀取的 UTF-8 BOM。

文字為什麼會變成 é 或 ���

亂碼（mojibake）會在解碼使用的編碼和寫入時不同時出現：

• é 變成 é：UTF-8 位元組 C3 A9 被當成 Windows-1252 或 Latin-1 讀取，C3 對應到 Ã，A9 對應到 ©。
• �（U+FFFD，替代字元）：解碼器遇到不合法的 UTF-8 位元組，常見於把 Latin-1 文字當成 UTF-8 讀取。
• 資料庫裡出現問號：欄位或連線使用的字元集裝不下該字元，寫入時就被替換掉，資料已經不在了。

解決方法是在每個交界處都宣告編碼：HTML 中的 <meta charset="utf-8">、HTTP 標頭中的 Content-Type: text/html; charset=utf-8，資料庫欄位和連線也都用 UTF-8。MySQL 請使用 utf8mb4；較舊的 utf8 字元集每個字元最多只存 3 個位元組，會拒收表情符號。