最近我遇到了(le)一(yī)個(gè) bug，我試着通過 Rails 在以“utf8”編碼的 MariaDB 中保存一(yī)個(gè) UTF-8 字符串，然後出現(xiàn)了(le)一(yī)個(gè)離奇的錯誤：

Incorrect string value: ‘\xF0\x9F\x98\x83 <…’ for column ‘summary’ at row 1

我用的是 UTF-8 編碼的客戶端，服務(wù)器(qì)也(yě)是 UTF-8 編碼的，數據庫也(yě)是，就(jiù)連要保存的這(zhè)個(gè)字符串“ <…”也(yě)是合法的 UTF-8。

問題的症結在于，MySQL 的“utf8”實際上(shàng)不是真正的 UTF-8。

“utf8”隻支持每個(gè)字符最多三個(gè)字節，而真正的 UTF-8 是每個(gè)字符最多四個(gè)字節。

MySQL 一(yī)直沒有修複這(zhè)個(gè) bug，他們在 2010 年發布了(le)一(yī)個(gè)叫作(zuò)“utf8mb4”的字符集，繞過了(le)這(zhè)個(gè)問題。

當然，他們并沒有對新(xīn)的字符集廣而告之（可能(néng)是因為(wèi)這(zhè)個(gè) bug 讓他們覺得很尴尬），以緻于現(xiàn)在網絡上(shàng)仍然在建議(yì)開發者使用“utf8”，但(dàn)這(zhè)些(xiē)建議(yì)都是錯誤的。

簡單概括如(rú)下(xià)：

• MySQL 的“utf8mb4”是真正的“UTF-8”。

• MySQL 的“utf8”是一(yī)種“專屬的編碼”，它能(néng)夠編碼的 Unicode 字符并不多。

我要在這(zhè)裏澄清一(yī)下(xià)：所有在使用“utf8”的 MySQL 和 MariaDB 用戶都應該改用“utf8mb4”，永遠(yuǎn)都不要再使用“utf8”。

我們都知道，計算(suàn)機使用 0 和 1 來(lái)存儲文本。比如(rú)字符“C”被存成“01000011”，那麽計算(suàn)機在顯示這(zhè)個(gè)字符時(shí)需要經過兩個(gè)步驟：

1. 計算(suàn)機讀取“01000011”，得到數字 67，因為(wèi) 67 被編碼成“01000011”。

2. 計算(suàn)機在 Unicode 字符集中查找 67，找到了(le)“C”。

同樣的：

1. 我的電腦将“C”映射成 Unicode 字符集中的 67。

2. 我的電腦将 67 編碼成“01000011”，并發送給 Web 服務(wù)器(qì)。

幾乎所有的網絡應用都使用了(le) Unicode 字符集，因為(wèi)沒有理(lǐ)由使用其他字符集。

Unicode 字符集包含了(le)上(shàng)百萬個(gè)字符。最簡單的編碼是 UTF-32，每個(gè)字符使用 32 位。這(zhè)樣做最簡單，因為(wèi)一(yī)直以來(lái)，計算(suàn)機将 32 位視(shì)為(wèi)數字，而計算(suàn)機最在行的就(jiù)是處理(lǐ)數字。但(dàn)問題是，這(zhè)樣太浪費空間(jiān)了(le)。

UTF-8 可以節省空間(jiān)，在 UTF-8 中，字符“C”隻需要 8 位，一(yī)些(xiē)不常用的字符，比如(rú)“”需要 32 位。其他的字符可能(néng)使用 16 位或 24 位。一(yī)篇類似本文這(zhè)樣的文章，如(rú)果使用 UTF-8 編碼，占用的空間(jiān)隻有 UTF-32 的四分(fēn)之一(yī)左右。

MySQL 的“utf8”字符集與其他程序不兼容，它所謂的“”，可能(néng)真的是一(yī)坨……

為(wèi)什(shén)麽 MySQL 開發者會讓“utf8”失效？我們或許可以從提交日志中尋找答(dá)案。

MySQL 從 4.1 版本開始支持 UTF-8，也(yě)就(jiù)是 2003 年，而今天使用的 UTF-8 标準（RFC 3629）是随後才出現(xiàn)的。

舊版的 UTF-8 标準（RFC 2279）最多支持每個(gè)字符 6 個(gè)字節。2002 年 3 月(yuè)(yuè) 28 日，MySQL 開發者在第一(yī)個(gè) MySQL 4.1 預覽版中使用了(le) RFC 2279。

同年 9 月(yuè)(yuè)，他們對 MySQL 源代碼進行了(le)一(yī)次調整：“UTF8 現(xiàn)在最多隻支持 3 個(gè)字節的序列”。

是誰提交了(le)這(zhè)些(xiē)代碼？他為(wèi)什(shén)麽要這(zhè)樣做？這(zhè)個(gè)問題不得而知。在遷移到 Git 後（MySQL 最開始使用的是 BitKeeper），MySQL 代碼庫中的很多提交者的名字都丢失了(le)。2003 年 9 月(yuè)(yuè)的郵件列表中也(yě)找不到可以解釋這(zhè)一(yī)變更的線索。

不過我可以試着猜測一(yī)下(xià)。

2002 年，MySQL 做出了(le)一(yī)個(gè)決定：如(rú)果用戶可以保證數據表的每一(yī)行都使用相同的字節數，那麽 MySQL 就(jiù)可以在性能(néng)方面來(lái)一(yī)個(gè)大提升。為(wèi)此，用戶需要将文本列定義為(wèi)“CHAR”，每個(gè)“CHAR”列總是擁有相同數量的字符。如(rú)果插入的字符少于定義的數量，MySQL 就(jiù)會在後面填充空格，如(rú)果插入的字符超過了(le)定義的數量，後面超出部分(fēn)會被截斷。

MySQL 開發者在最開始嘗試 UTF-8 時(shí)使用了(le)每個(gè)字符 6 個(gè)字節，CHAR(1) 使用 6 個(gè)字節，CHAR(2) 使用 12 個(gè)字節，并以此類推。

應該說(shuō)，他們最初的行為(wèi)才是正确的，可惜這(zhè)一(yī)版本一(yī)直沒有發布。但(dàn)是文檔上(shàng)卻這(zhè)麽寫了(le)，而且廣為(wèi)流傳，所有了(le)解 UTF-8 的人(rén)都認同文檔裏寫的東西(xī)。

不過很顯然，MySQL 開發者或廠商(shāng)擔心會有用戶做這(zhè)兩件事(shì)：

1. 使用 CHAR 定義列（在現(xiàn)在看來(lái)，CHAR 已經是老古董了(le)，但(dàn)在那時(shí)，在 MySQL 中使用 CHAR 會更快(kuài)，不過從 2005 年以後就(jiù)不是這(zhè)樣子(zǐ)了(le)）。

2. 将 CHAR 列的編碼設置為(wèi)“utf8”。

我的猜測是 MySQL 開發者本來(lái)想幫助那些(xiē)希望在空間(jiān)和速度上(shàng)雙赢的用戶，但(dàn)他們搞砸了(le)“utf8”編碼。

所以結果就(jiù)是沒有赢家。那些(xiē)希望在空間(jiān)和速度上(shàng)雙赢的用戶，當他們在使用“utf8”的 CHAR 列時(shí)，實際上(shàng)使用的空間(jiān)比預期的更大，速度也(yě)比預期的慢(màn)。而想要正确性的用戶，當他們使用“utf8”編碼時(shí)，卻無法保存像“”這(zhè)樣的字符。

在這(zhè)個(gè)不合法的字符集發布了(le)之後，MySQL 就(jiù)無法修複它，因為(wèi)這(zhè)樣需要要求所有用戶重新(xīn)構建他們的數據庫。最終，MySQL 在 2010 年重新(xīn)發布了(le)“utf8mb4”來(lái)支持真正的 UTF-8。

因為(wèi)這(zhè)個(gè)問題，我整整抓狂了(le)一(yī)個(gè)禮拜。我被“utf8”愚弄了(le)，花了(le)很多時(shí)間(jiān)才找到這(zhè)個(gè) bug。但(dàn)我一(yī)定不是唯一(yī)的一(yī)個(gè)，網絡上(shàng)幾乎所有的文章都把“utf8”當成是真正的 UTF-8。

“utf8”隻能(néng)算(suàn)是個(gè)專有的字符集，它給我們帶來(lái)了(le)新(xīn)問題，卻一(yī)直沒有得到解決。

如(rú)果你在使用 MySQL 或 MariaDB，不要用“utf8”編碼，改用“utf8mb4”。這(zhè)裏提供了(le)一(yī)個(gè)指南(nán)用于将現(xiàn)有數據庫的字符編碼從“utf8”轉成“utf8mb4”：

https://mathiasbynens.be/notes/mysql-utf8mb4#utf8-to-utf8mb4