為什么不建議在MySQL中使用 utf8 ？

點擊關(guān)注公眾號，Java干貨及時送達

MySQL 字符編碼集中有兩套 UTF-8 編碼實現(xiàn)：utf8 和 utf8mb4。

如果使用 utf8 的話，存儲 emoji 符號和一些比較復雜的漢字、繁體字就會出錯。

為什么會這樣呢？這篇文章可以從源頭給你解答。

何為字符集？

字符是各種文字和符號的統(tǒng)稱，包括各個國家文字、標點符號、表情、數(shù)字等等。字符集 就是一系列字符的集合。字符集的種類較多，每個字符集可以表示的字符范圍通常不同，就比如說有些字符集是無法表示漢字的。

計算機只能存儲二進制的數(shù)據(jù)，那英文、漢字、表情等字符應該如何存儲呢？

我們要將這些字符和二級制的數(shù)據(jù)一一對應起來，比如說字符“a”對應“01100001”，反之，“01100001”對應 “a”。我們將字符對應二進制數(shù)據(jù)的過程稱為"字符編碼"，反之，二進制數(shù)據(jù)解析成字符的過程稱為“字符解碼”。

有哪些常見的字符集？

常見的字符集有 ASCII、GB2312、GBK、UTF-8......。

不同的字符集的主要區(qū)別在于：

• 可以表示的字符范圍
• 編碼方式

ASCII

ASCII (American Standard Code for Information Interchange，美國信息交換標準代碼) 是一套主要用于現(xiàn)代美國英語的字符集（這也是 ASCII 字符集的局限性所在）。

為什么 ASCII 字符集沒有考慮到中文等其他字符呢？ 因為計算機是美國人發(fā)明的，當時，計算機的發(fā)展還處于比較雛形的時代，還未在其他國家大規(guī)模使用。因此，美國發(fā)布 ASCII 字符集的時候沒有考慮兼容其他國家的語言。

ASCII 字符集至今為止共定義了 128 個字符，其中有 33 個控制字符（比如回車、刪除）無法顯示。

一個 ASCII 碼長度是一個字節(jié)也就是 8 個 bit，比如“a”對應的 ASCII 碼是“01100001”。不過，最高位是 0 僅僅作為校驗位，其余 7 位使用 0 和 1 進行組合，所以，ASCII 字符集可以定義 128（2^7）個字符。

由于，ASCII 碼可以表示的字符實在是太少了。后來，人們對其進行了擴展得到了 ASCII 擴展字符集 。ASCII 擴展字符集使用 8 位（bits）表示一個字符，所以，ASCII 擴展字符集可以定義 256（2^8）個字符。

GB2312

我們上面說了，ASCII 字符集是一種現(xiàn)代美國英語適用的字符集。因此，很多國家都搗鼓了一個適合自己國家語言的字符集。

GB2312 字符集是一種對漢字比較友好的字符集，共收錄 6700 多個漢字，基本涵蓋了絕大部分常用漢字。不過，GB2312 字符集不支持絕大部分的生僻字和繁體字。

對于英語字符，GB2312 編碼和 ASCII 碼是相同的，1 字節(jié)編碼即可。對于非英字符，需要 2 字節(jié)編碼。

GBK

GBK 字符集可以看作是 GB2312 字符集的擴展，兼容 GB2312 字符集，共收錄了 20000 多個漢字。

GBK 中 K 是漢語拼音 Kuo Zhan（擴展）中的“Kuo”的首字母。

GB18030

GB18030 完全兼容 GB2312 和 GBK 字符集，納入中國國內(nèi)少數(shù)民族的文字，且收錄了日韓漢字，是目前為止最全面的漢字字符集，共收錄漢字 70000 多個。

BIG5

BIG5 主要針對的是繁體中文，收錄了 13000 多個漢字。

Unicode & UTF-8 編碼

為了更加適合本國語言，誕生了很多種字符集。

我們上面也說了不同的字符集可以表示的字符范圍以及編碼規(guī)則存在差異。這就導致了一個非常嚴重的問題：使用錯誤的編碼方式查看一個包含字符的文件就會產(chǎn)生亂碼現(xiàn)象。

就比如說你使用 UTF-8 編碼方式打開 GB2312 編碼格式的文件就會出現(xiàn)亂碼。示例：“牛”這個漢字 GB2312 編碼后的十六進制數(shù)值為 “C5A3”，而 “C5A3” 用 UTF-8 解碼之后得到的卻是 “?”。

你可以通過這個網(wǎng)站在線進行編碼和解碼：https://www.haomeili.net/HanZi/ZiFuBianMaZhuanHuan

這樣我們就搞懂了亂碼的本質(zhì)：編碼和解碼時用了不同或者不兼容的字符集 。

為了解決這個問題，人們就想：“如果我們能夠有一種字符集將世界上所有的字符都納入其中就好了！”。

然后，Unicode 帶著這個使命誕生了。

Unicode 字符集中包含了世界上幾乎所有已知的字符。不過，Unicode 字符集并沒有規(guī)定如何存儲這些字符（也就是如何使用二級制數(shù)據(jù)表示這些字符）。

然后，就有了 UTF-8（8-bit Unicode Transformation Format）。類似的還有 UTF-16、 UTF-32。

UTF-8 使用 1 到 4 個字節(jié)為每個字符編碼， UTF-16 使用 2 或 4 個字節(jié)為每個字符編碼，UTF-32 固定位 4 個字節(jié)為每個字符編碼。

UTF-8 可以根據(jù)不同的符號自動選擇編碼的長短，像英文字符只需要 1 個字節(jié)就夠了，這一點 ASCII 字符集一樣 。因此，對于英語字符，UTF-8 編碼和 ASCII 碼是相同的。

UTF-32 的規(guī)則最簡單，不過缺陷也比較明顯，對于英文字母這類字符消耗的空間是 UTF-8 的 4 倍之多。

UTF-8 是目前使用最廣的一種字符編碼，。

MySQL 字符集

MySQL 支持很多種字符編碼的方式，比如 UTF-8、GB2312、GBK、BIG5。

你可以通過 SHOW CHARSET 命令來查看。

通常情況下，我們建議使用 UTF-8 作為默認的字符編碼方式。

不過，這里有一個小坑。

MySQL 字符編碼集中有兩套 UTF-8 編碼實現(xiàn)：

• utf8 ：utf8編碼只支持1-3個字節(jié) 。在 utf8 編碼中，中文是占 3 個字節(jié)，其他數(shù)字、英文、符號占一個字節(jié)。但 emoji 符號占 4 個字節(jié)，一些較復雜的文字、繁體字也是 4 個字節(jié)。
• utf8mb4 ：UTF-8 的完整實現(xiàn)，正版！最多支持使用 4 個字節(jié)表示字符，因此，可以用來存儲 emoji 符號。

為什么有兩套 UTF-8 編碼實現(xiàn)呢？ 原因如下：

因此，如果你需要存儲emoji類型的數(shù)據(jù)或者一些比較復雜的文字、繁體字到 MySQL 數(shù)據(jù)庫的話，數(shù)據(jù)庫的編碼一定要指定為utf8mb4 而不是utf8 ，要不然存儲的時候就會報錯了。

演示一下吧！（環(huán)境：MySQL 5.7+）

建表語句如下，我們指定數(shù)據(jù)庫 CHARSET 為 utf8 。

CREATE?TABLE?`user`?(
??`id`?varchar(66)?CHARACTER?SET?utf8mb4?NOT?NULL,
??`name`?varchar(33)?CHARACTER?SET?utf8mb4?NOT?NULL,
??`phone`?varchar(33)?CHARACTER?SET?utf8mb4?DEFAULT?NULL,
??`password`?varchar(100)?CHARACTER?SET?utf8mb4?DEFAULT?NULL
)?ENGINE=InnoDB?DEFAULT?CHARSET=utf8;

當我們執(zhí)行下面的 insert 語句插入數(shù)據(jù)到數(shù)據(jù)庫時，果然報錯！

INSERT?INTO?`user`?(`id`,?`name`,?`phone`,?`password`)
VALUES
?('A00003',?'guide哥??????',?'181631312312',?'123456');

報錯信息如下：

Incorrect?string?value:?'\xF0\x9F\x98\x98\xF0\x9F...'?for?column?'name'?at?row?1

參考

• 字符集和字符編碼（Charset & Encoding）：https://www.cnblogs.com/skynet/archive/2011/05/03/2035105.html
• 十分鐘搞清字符集和字符編碼：http://cenalulu.github.io/linux/character-encoding/
• Unicode-維基百科：https://zh.wikipedia.org/wiki/Unicode
• GB2312-維基百科：https://zh.wikipedia.org/wiki/GB_2312
• UTF-8-維基百科：https://zh.wikipedia.org/wiki/UTF-8
• GB18030-維基百科: https://zh.wikipedia.org/wiki/GB_18030