原文地址:https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
用MySQL的朋友們請不要使用"utf8",請使用"utf8mb4"
今天我試圖把UTF-8
編碼的字符串插入使用“utf8”
編碼的MariaDB
數據庫中,Rails
拋出一個古怪的異常:
Incorrect string value: ‘\xF0\x9F\x98\x83 <…’ for column ‘summary’ at row 1
一切都很UTF-8:UTF-8 client
,UTF-8
的服務器,UTF-8
編碼的數據庫,使用UTF-8
的字符集。“😃 <…”
是個有效的UTF-8
字符串。
但是問題的關鍵是:MySQL
數據庫的 “utf8
”並不是真正概念裏的 UTF-8
。MySQL
中的“utf8
”編碼只支持最大3字節每字符。真正的大家正在使用的UTF-8
編碼是應該能支持4字節每個字符。MySQL
的開發者沒有修復這個bug
。他們在2010年增加了一個變通的方法:一個新的字符集“utf8mb4
”。當然,他們並沒有對外公佈(可能因爲這個bug
有點尷尬)。現在很多指南推薦用戶使用“utf8
”其實都錯了。
簡單的說:
MySQL
中的 “utf8mb4
” 纔是 真正意義上的“UTF-8
”。MySQL
的“utf8
”是個“特殊的字符編碼”。這種編碼很多Unicode
字符保存不了。
我強烈建議
MySQL
和MariaDB
用戶使用“utf8mb4
”而不是“utf8
”。
編碼是什麼?什麼是UTF-8?
Joel on Software上有一遍我最喜歡的介紹,我精簡描述如下:
計算機使用0和1存儲文字。比如第一段第一個字符存儲爲“01000011
”表示“C”,計算機通過以下兩個步驟選擇用“C
”表示:
- 計算機讀取到“
01000011
”後計算出這是數字67。 - 計算機通過查找
Unicode
字符集來確認67
代表的“C
”。
同樣的事情發生在我打字輸入C
的時候。
- 計算機通過Unicode字符集將“
C
” 映射爲67
。 - 計算機把
67
編碼爲“01000011
”發送給web
服務器。
幾乎所有的程序和互聯網應用使用Unicode
字符集。Unicode
字符集裏有超過100萬個字符(“C” 和 “💩” 是兩種不同的字符。)。UTF-32
是最簡單的編碼方式,它在表示每個字符的時候使用32個bits
。這樣編碼簡單,但是並不實用,明顯浪費了太多的空間。
UTF-8
相比UTF-32
更加節約空間。在UTF-8
中,像“C”這樣的字符佔用8bits
,“💩”這樣的佔用32 bits
。其他字符佔用16或者24 bits
。如本篇這樣的文章用UTF-8
存儲比用UTF-32
節省4倍左右的空間。更小的空間佔用也意味着加載速度會快上4倍。
而MySQL
中的 “utf8
”字符集則和其他應用行爲不一樣。比如根本沒法表示“💩”。
一點關於MySQL
的歷史
爲什麼MySQL
的開發者開發了一個奇怪的“utf8
”。我們可以通過提交的日誌來揣測一下。MySQL
從4.1版開始支持UTF-8
。那是在比今天UTF-8
RFC 3629標準更早的2003年。在此之前的UTF-8
標準,RFC 2279中規定6個bytes
表示一個字符。MySQL
的開發者在2002.3.28編碼實現了RFC 2279
。併發布了pre-pre-release 的 MySQL 4.1然後在9月出現了一個神祕的字節調整。“UTF8 now works with up to 3 byte sequences only.”是誰提交了這次更新?爲什麼?我無法解答。MySQL
的源碼移到Git後丟失了舊的作者信息(MySQL
曾經和Linux
內核一樣使用BitKeeper
)
但是我大概能猜出來原因。
回到2002年,如果用戶可以保證表中的每一行具有相同的字節數,MySQL
就可以提高用戶的速度。爲了得到這個提升,用戶就需要定義保存文字的列爲“CHAR
”。一個“CHAR
”列總是擁有相同的字符數。如果存入的字符較少則會在最後補齊空白。如果存入的數據過多則會被拋棄多餘的字符。
當MySQL的開發者第一次嘗試以6字節每字符實現UTF-8
時,他們意識到CHAR(1)
的列會佔用6字節,CHAR(2)
會佔用12字節,以此類推。
顯而易見的是,這個沒有被使用的實現方式是正確的,任何一個理解UTF-8
的開發者將會認同這一點。
我的猜測是:MySQ
L的開發者違背了“utf8
”編碼去幫助那些
- 試圖去優化空間和速度的人
- 嘗試優化空間和速度失敗的人。
這是個無人獲益的改動。那些想要更快性能,更小空間的得到的依然是比他們曾經使用版本更大更慢的實現,而那些想要正確的“utf8”的人得到的是個“💩”都存儲不了的實現。
MySQL
發佈了這個錯誤的版本後,在也沒有修復它:因爲那樣很多使用者將被迫重建他們的數據庫。MySQL
最終在2010年更新了一個以“utf8mb4
”命名的UTF-8實
現。
Why it’s so frustrating
爲什麼這麼操蛋
這周我過得很操蛋。我遇到一個很難發現的bug
,就因爲我被“utf8
”這個名字給愚弄了。而且我也不是個案,我發現幾乎每篇推薦使用“utf8
”的文章都錯了。
“utf8
”的命名在MySQL
依然是錯的。這是個專有的實現。這造成了新的問題,而且沒有解決他應該解決的問題。
如果你使用MySQL
或者 MariaDB,
不要使用“utf8
”,應該總是使用“utf8mb4
”,否則總有一天會遇到頭疼的事情。