原文： https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
翻譯： www.reibang.com/p/ab9aa8d4df7d
用MySQL的朋友們請(qǐng)不要使用"utf8"呻惕，請(qǐng)使用"utf8mb4"
今天我試圖把UTF-8編碼的字符串插入使用“utf8”編碼的MariaDB數(shù)據(jù)庫(kù)中专酗，Rails拋出一個(gè)古怪的異常:
Incorrect string value: ‘\xF0\x9F\x98\x83 <…’ for column ‘summary’ at row 1
一切都很UTF-8：UTF-8 client鳞尔，UTF-8的服務(wù)器嬉橙，UTF-8編碼的數(shù)據(jù)庫(kù)，使用UTF-8的字符集铅檩≡饕模“?? <…”是個(gè)有效的UTF-8字符串。
但是問(wèn)題的關(guān)鍵是：MySQL數(shù)據(jù)庫(kù)的 “utf8”并不是真正概念里的* UTF-8昧旨。*
MySQL中的“utf8”編碼只支持最大3字節(jié)每字符拾给。真正的大家正在使用的UTF-8編碼是應(yīng)該能支持4字節(jié)每個(gè)字符。
MySQL的開發(fā)者沒(méi)有修復(fù)這個(gè)bug兔沃。他們?cè)?010年增加了一個(gè)變通的方法：一個(gè)新的字符集“utf8mb4”
當(dāng)然蒋得，他們并沒(méi)有對(duì)外公布（可能因?yàn)檫@個(gè)bug有點(diǎn)尷尬）。現(xiàn)在很多指南推薦用戶使用“utf8”其實(shí)都錯(cuò)了乒疏。
簡(jiǎn)單的說(shuō):
MySQL中的 “utf8mb4” 才是 真正意義上的“UTF-8”额衙。
MySQL的“utf8”是個(gè)“特殊的字符編碼”。這種編碼很多Unicode字符保存不了怕吴。
我強(qiáng)烈建議MySQL和MariaDB用戶使用“utf8mb4”而不是“utf8”窍侧。
編碼是什么？什么是UTF-8转绷？
Joel on Software上有一遍我最喜歡的介紹伟件，我精簡(jiǎn)描述如下：
計(jì)算機(jī)使用0和1存儲(chǔ)文字。比如第一段第一個(gè)字符存儲(chǔ)為“01000011”表示“C”议经，計(jì)算機(jī)通過(guò)以下兩個(gè)步驟選擇用“C”表示：
計(jì)算機(jī)讀取到“01000011”后計(jì)算出這是數(shù)字67斧账。
計(jì)算機(jī)通過(guò)查找Unicode字符集來(lái)確認(rèn)67代表的“C”谴返。
同樣的事情發(fā)生在我打字輸入C的時(shí)候。
計(jì)算機(jī)通過(guò)Unicode字符集將“C” 映射為67咧织。
計(jì)算機(jī)把67編碼為“01000011”發(fā)送給web服務(wù)器嗓袱。
幾乎所有的程序和互聯(lián)網(wǎng)應(yīng)用使用Unicode字符集。
Unicode字符集里有超過(guò)100萬(wàn)個(gè)字符(“C” 和 “??” 是兩種不同的字符习绢。)渠抹。UTF-32是最簡(jiǎn)單的編碼方式，它在表示每個(gè)字符的時(shí)候使用32個(gè)bits毯炮。這樣編碼簡(jiǎn)單逼肯，但是并不實(shí)用，明顯浪費(fèi)了太多的空間桃煎。
UTF-8相比UTF-32更加節(jié)約空間篮幢。在UTF-8中，像“C”這樣的字符占用8bits为迈，“??”這樣的占用32 bits三椿。其他字符占用16或者24 bits。如本篇這樣的文章用UTF-8存儲(chǔ)比用UTF-32節(jié)省4倍左右的空間葫辐。更小的空間占用也意味著加載速度會(huì)快上4倍搜锰。
而MySQL中的 “utf8”字符集則和其他應(yīng)用行為不一樣。比如根本沒(méi)法表示“??”耿战。
一點(diǎn)關(guān)于MySQL的歷史****
為什么MySQL的開發(fā)者開發(fā)了一個(gè)奇怪的“utf8”蛋叼。我們可以通過(guò)提交的日志來(lái)揣測(cè)一下。
MySQL從4.1版開始支持UTF-8剂陡。那是在比今天UTF-8 RFC 3629標(biāo)準(zhǔn)更早的2003年狈涮。
在此之前的UTF-8標(biāo)準(zhǔn),RFC 2279中規(guī)定6個(gè)bytes表示一個(gè)字符。MySQL的開發(fā)者在2002.3.28編碼實(shí)現(xiàn)了RFC 2279 鸭栖。并發(fā)布了pre-pre-release 的 MySQL 4.1
然后在9月出現(xiàn)了一個(gè)神秘的字節(jié)調(diào)整歌馍。“UTF8 now works with up to3 byte sequences only.”
是誰(shuí)提交了這次更新晕鹊？為什么松却？我無(wú)法解答。MySQL的源碼移到Git后丟失了舊的作者信息（MySQL 曾經(jīng)和linux內(nèi)核一樣使用BitKeeper）
但是我大概能猜出來(lái)原因溅话。
回到2002年晓锻，如果用戶可以保證表中的每一行具有相同的字節(jié)數(shù)，MySQL就可以提高用戶的速度飞几。為了得到這個(gè)提升带射，用戶就需要定義保存文字的列為“CHAR”。一個(gè)“CHAR”列總是擁有相同的字符數(shù)循狰。如果存入的字符較少則會(huì)在最后補(bǔ)齊空白窟社。如果存入的數(shù)據(jù)過(guò)多則會(huì)被拋棄多余的字符。
當(dāng)MySQL的開發(fā)者第一次嘗試以6字節(jié)每字符實(shí)現(xiàn)UTF-8時(shí)绪钥，他們意識(shí)到CHAR(1)的列會(huì)占用6字節(jié)灿里，CHAR(2)會(huì)占用12字節(jié)，以此類推程腹。
顯而易見的是匣吊，這個(gè)沒(méi)有被使用的實(shí)現(xiàn)方式是正確的，任何一個(gè)理解UTF-8的開發(fā)者將會(huì)認(rèn)同這一點(diǎn)寸潦。
我的猜測(cè)是：MySQL的開發(fā)者違背了“utf8”編碼去幫助那些1)試圖去優(yōu)化空間和速度的人色鸳，2）嘗試優(yōu)化空間和速度失敗的人。
這是個(gè)無(wú)人獲益的改動(dòng)见转。那些想要更快性能命雀，更小空間的得到的依然是比他們?cè)?jīng)使用版本更大更慢的實(shí)現(xiàn)，而那些想要正確的“utf8”的人得到的是個(gè)“??”都存儲(chǔ)不了的實(shí)現(xiàn)斩箫。
MySQL發(fā)布了這個(gè)錯(cuò)誤的版本后吏砂，在也沒(méi)有修復(fù)它：因?yàn)槟菢雍芏嗍褂谜邔⒈黄戎亟ㄋ麄兊臄?shù)據(jù)庫(kù)。MySQL最終在2010年更新了一個(gè)以“utf8mb4”命名的UTF-8實(shí)現(xiàn)乘客。
Why it’s so frustrating
為什么這么操蛋
這周我過(guò)得很操蛋狐血。我遇到一個(gè)很難發(fā)現(xiàn)的bug，就因?yàn)槲冶弧皍tf8”這個(gè)名字給愚弄了易核。而且我也不是個(gè)案匈织，我發(fā)現(xiàn)幾乎每篇推薦使用“utf8”的文章都錯(cuò)了。
“utf8”的命名在mysql依然是錯(cuò)的牡直。這是個(gè)專有的實(shí)現(xiàn)缀匕。這造成了新的問(wèn)題，而且沒(méi)有解決他應(yīng)該解決的問(wèn)題井氢。
如果你使用MySQL或者 MariaDB,不要使用“utf8”弦追，應(yīng)該總是使用“utf8mb4”，否則總有一天會(huì)遇到頭疼的事情花竞。
