為什么不建議在MySQL中使用 UTF8 ？
本文轉(zhuǎn)載自微信公眾號「JavaGuide」，作者Guide哥。轉(zhuǎn)載本文請聯(lián)系JavaGuide公眾號。
MySQL 字符編碼集中有兩套 UTF-8 編碼實現(xiàn)：utf8 和 utf8mb4。
如果使用 utf8 的話，存儲 emoji 符號和一些比較復(fù)雜的漢字、繁體字就會出錯。
為什么會這樣呢?這篇文章可以從源頭給你解答。
何為字符集?
字符是各種文字和符號的統(tǒng)稱，包括各個國家文字、標(biāo)點符號、表情、數(shù)字等等。字符集 就是一系列字符的集合。字符集的種類較多，每個字符集可以表示的字符范圍通常不同，就比如說有些字符集是無法表示漢字的。
計算機只能存儲二進(jìn)制的數(shù)據(jù)，那英文、漢字、表情等字符應(yīng)該如何存儲呢?
我們要將這些字符和二級制的數(shù)據(jù)一一對應(yīng)起來，比如說字符“a”對應(yīng)“01100001”，反之，“01100001”對應(yīng) “a”。我們將字符對應(yīng)二進(jìn)制數(shù)據(jù)的過程稱為"字符編碼"，反之，二進(jìn)制數(shù)據(jù)解析成字符的過程稱為“字符解碼”。
有哪些常見的字符集?
常見的字符集有 ASCII、GB2312、GBK、UTF-8......。
不同的字符集的主要區(qū)別在于：
- 可以表示的字符范圍
- 編碼方式
ASCII
ASCII (American Standard Code for Information Interchange，美國信息交換標(biāo)準(zhǔn)代碼) 是一套主要用于現(xiàn)代美國英語的字符集(這也是 ASCII 字符集的局限性所在)。
為什么 ASCII 字符集沒有考慮到中文等其他字符呢? 因為計算機是美國人發(fā)明的，當(dāng)時，計算機的發(fā)展還處于比較雛形的時代，還未在其他國家大規(guī)模使用。因此，美國發(fā)布 ASCII 字符集的時候沒有考慮兼容其他國家的語言。
ASCII 字符集至今為止共定義了 128 個字符，其中有 33 個控制字符(比如回車、刪除)無法顯示。
一個 ASCII 碼長度是一個字節(jié)也就是 8 個 bit，比如“a”對應(yīng)的 ASCII 碼是“01100001”。不過，最高位是 0 僅僅作為校驗位，其余 7 位使用 0 和 1 進(jìn)行組合，所以，ASCII 字符集可以定義 128(2^7)個字符。
由于，ASCII 碼可以表示的字符實在是太少了。后來，人們對其進(jìn)行了擴展得到了 ASCII 擴展字符集 。ASCII 擴展字符集使用 8 位(bits)表示一個字符，所以，ASCII 擴展字符集可以定義 256(2^8)個字符。
ASCII字符編碼
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ī)則存在差異。這就導(dǎo)致了一個非常嚴(yán)重的問題：使用錯誤的編碼方式查看一個包含字符的文件就會產(chǎn)生亂碼現(xiàn)象。
就比如說你使用 UTF-8 編碼方式打開 GB2312 編碼格式的文件就會出現(xiàn)亂碼。示例：“牛”這個漢字 GB2312 編碼后的十六進(jìn)制數(shù)值為 “C5A3”，而 “C5A3” 用 UTF-8 解碼之后得到的卻是 “?”。
你可以通過這個網(wǎng)站在線進(jìn)行編碼和解碼：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 作為默認(rèn)的字符編碼方式。
不過，這里有一個小坑。
MySQL 字符編碼集中有兩套 UTF-8 編碼實現(xiàn)：
- utf8 ：utf8編碼只支持1-3個字節(jié) 。在 utf8 編碼中，中文是占 3 個字節(jié)，其他數(shù)字、英文、符號占一個字節(jié)。但 emoji 符號占 4 個字節(jié)，一些較復(fù)雜的文字、繁體字也是 4 個字節(jié)。
- utf8mb4 ：UTF-8 的完整實現(xiàn)，正版!最多支持使用 4 個字節(jié)表示字符，因此，可以用來存儲 emoji 符號。
為什么有兩套 UTF-8 編碼實現(xiàn)呢? 原因如下：
因此，如果你需要存儲emoji類型的數(shù)據(jù)或者一些比較復(fù)雜的文字、繁體字到 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;
當(dāng)我們執(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
