覺得好就贊一下~~
原文地址：https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
用MySQL的朋友們請不要使用"utf8"鲫尊，請使用"utf8mb4"
今天我試圖把UTF-8編碼的字符串插入使用“utf8”編碼的MariaDB數(shù)據(jù)庫中逊彭，Rails拋出一個古怪的異常:
Incorrect string value: ‘\xF0\x9F\x98\x83 <…’ for column ‘summary’ at row 1
一切都很UTF-8：UTF-8 client然磷，UTF-8的服務器紫谷，UTF-8編碼的數(shù)據(jù)庫，使用UTF-8的字符集额港〗攘“?? <…”是個有效的UTF-8字符串。
但是問題的關鍵是：MySQL數(shù)據(jù)庫的 “utf8”并不是真正概念里的?UTF-8移斩。
MySQL中的“utf8”編碼只支持最大3字節(jié)每字符肚医。真正的大家正在使用的UTF-8編碼是應該能支持4字節(jié)每個字符。
MySQL的開發(fā)者沒有修復這個bug向瓷。他們在2010年增加了一個變通的方法：一個新的字符集“utf8mb4”
當然肠套，他們并沒有對外公布（可能因為這個bug有點尷尬）。現(xiàn)在很多指南推薦用戶使用“utf8”其實都錯了猖任。
簡單的說:
MySQL中的 “utf8mb4” 才是 真正意義上的“UTF-8”你稚。
MySQL的“utf8”是個“特殊的字符編碼”。這種編碼很多Unicode字符保存不了朱躺。
我強烈建議MySQL和MariaDB用戶使用“utf8mb4”而不是“utf8”刁赖。
編碼是什么？什么是UTF-8长搀？
Joel on Software上有一遍我最喜歡的介紹宇弛，我精簡描述如下：
計算機使用0和1存儲文字。比如第一段第一個字符存儲為“01000011”表示“C”源请，計算機通過以下兩個步驟選擇用“C”表示：
計算機讀取到“01000011”后計算出這是數(shù)字67枪芒。
計算機通過查找Unicode字符集來確認67代表的“C”。
同樣的事情發(fā)生在我打字輸入C的時候谁尸。
計算機通過Unicode字符集將“C” 映射為67舅踪。
計算機把67編碼為“01000011”發(fā)送給web服務器。
幾乎所有的程序和互聯(lián)網(wǎng)應用使用Unicode字符集良蛮。
Unicode字符集里有超過100萬個字符(“C” 和 “??” 是兩種不同的字符抽碌。)。UTF-32是最簡單的編碼方式决瞳，它在表示每個字符的時候使用32個bits货徙。這樣編碼簡單泽裳，但是并不實用，明顯浪費了太多的空間破婆。
UTF-8相比UTF-32更加節(jié)約空間。在UTF-8中胸囱，像“C”這樣的字符占用8bits祷舀，“??”這樣的占用32 bits。其他字符占用16或者24 bits烹笔。如本篇這樣的文章用UTF-8存儲比用UTF-32節(jié)省4倍左右的空間裳扯。更小的空間占用也意味著加載速度會快上4倍。
而MySQL中的 “utf8”字符集則和其他應用行為不一樣谤职。比如根本沒法表示“??”饰豺。
一點關于MySQL的歷史
為什么MySQL的開發(fā)者開發(fā)了一個奇怪的“utf8”。我們可以通過提交的日志來揣測一下允蜈。
MySQL從4.1版開始支持UTF-8。那是在比今天UTF-8 RFC 3629標準更早的2003年漩蟆。
在此之前的UTF-8標準,RFC 2279中規(guī)定6個bytes表示一個字符怠李。MySQL的開發(fā)者在2002.3.28編碼實現(xiàn)了RFC 2279 蛤克。并發(fā)布了pre-pre-release 的 MySQL 4.1
然后在9月出現(xiàn)了一個神秘的字節(jié)調(diào)整构挤。“UTF8 now works with up to3 byte sequences only.”
是誰提交了這次更新版保？為什么夫否？我無法解答凰慈。MySQL的源碼移到Git后丟失了舊的作者信息（MySQL 曾經(jīng)和linux內(nèi)核一樣使用BitKeeper）
但是我大概能猜出來原因。
回到2002年森篷，如果用戶可以保證表中的每一行具有相同的字節(jié)數(shù)，MySQL就可以提高用戶的速度仲智。為了得到這個提升钓辆，用戶就需要定義保存文字的列為“CHAR”前联。一個“CHAR”列總是擁有相同的字符數(shù)。如果存入的字符較少則會在最后補齊空白似嗤。如果存入的數(shù)據(jù)過多則會被拋棄多余的字符烁落。
當MySQL的開發(fā)者第一次嘗試以6字節(jié)每字符實現(xiàn)UTF-8時，他們意識到CHAR(1)的列會占用6字節(jié)谓厘，CHAR(2)會占用12字節(jié)竟稳，以此類推熊痴。
顯而易見的是果善，這個沒有被使用的實現(xiàn)方式是正確的巾陕，任何一個理解UTF-8的開發(fā)者將會認同這一點。
我的猜測是：MySQL的開發(fā)者違背了“utf8”編碼去幫助那些1)試圖去優(yōu)化空間和速度的人晾匠，2）嘗試優(yōu)化空間和速度失敗的人凉馆。
這是個無人獲益的改動澜共。那些想要更快性能，更小空間的得到的依然是比他們曾經(jīng)使用版本更大更慢的實現(xiàn)母谎，而那些想要正確的“utf8”的人得到的是個“??”都存儲不了的實現(xiàn)销睁。
MySQL發(fā)布了這個錯誤的版本后存崖，在也沒有修復它：因為那樣很多使用者將被迫重建他們的數(shù)據(jù)庫来惧。MySQL最終在2010年更新了一個以“utf8mb4”命名的UTF-8實現(xiàn)演顾。
Why it’s so frustrating
為什么這么操蛋
這周我過得很操蛋钠至。我遇到一個很難發(fā)現(xiàn)的bug棉钧，就因為我被“utf8”這個名字給愚弄了。而且我也不是個案宪卿，我發(fā)現(xiàn)幾乎每篇推薦使用“utf8”的文章都錯了佑钾。
“utf8”的命名在mysql依然是錯的休溶。這是個專有的實現(xiàn)兽掰。這造成了新的問題禾进，而且沒有解決他應該解決的問題。
如果你使用MySQL或者 MariaDB,不要使用“utf8”狐蜕，應該總是使用“utf8mb4”卸夕，否則總有一天會遇到頭疼的事情贡羔。
