為什么不建議在MySQL中使用 UTF8 ？
本文轉載自微信公眾號「JavaGuide」，作者Guide哥。轉載本文請聯系JavaGuide公眾號。
MySQL 字符編碼集中有兩套 UTF-8 編碼實現：utf8 和 utf8mb4。
如果使用 utf8 的話，存儲 emoji 符號和一些比較復雜的漢字、繁體字就會出錯。
為什么會這樣呢?這篇文章可以從源頭給你解答。
何為字符集?
字符是各種文字和符號的統稱，包括各個國家文字、標點符號、表情、數字等等。字符集 就是一系列字符的集合。字符集的種類較多，每個字符集可以表示的字符范圍通常不同，就比如說有些字符集是無法表示漢字的。
計算機只能存儲二進制的數據，那英文、漢字、表情等字符應該如何存儲呢?
我們要將這些字符和二級制的數據一一對應起來，比如說字符“a”對應“01100001”，反之，“01100001”對應 “a”。我們將字符對應二進制數據的過程稱為"字符編碼"，反之，二進制數據解析成字符的過程稱為“字符解碼”。
有哪些常見的字符集?
常見的字符集有 ASCII、GB2312、GBK、UTF-8......。
不同的字符集的主要區別在于：
- 可以表示的字符范圍
- 編碼方式
ASCII
ASCII (American Standard Code for Information Interchange，美國信息交換標準代碼) 是一套主要用于現代美國英語的字符集(這也是 ASCII 字符集的局限性所在)。
為什么 ASCII 字符集沒有考慮到中文等其他字符呢? 因為計算機是美國人發明的，當時，計算機的發展還處于比較雛形的時代，還未在其他國家大規模使用。因此，美國發布 ASCII 字符集的時候沒有考慮兼容其他國家的語言。
ASCII 字符集至今為止共定義了 128 個字符，其中有 33 個控制字符(比如回車、刪除)無法顯示。
一個 ASCII 碼長度是一個字節也就是 8 個 bit，比如“a”對應的 ASCII 碼是“01100001”。不過，最高位是 0 僅僅作為校驗位，其余 7 位使用 0 和 1 進行組合，所以，ASCII 字符集可以定義 128(2^7)個字符。
由于，ASCII 碼可以表示的字符實在是太少了。后來，人們對其進行了擴展得到了 ASCII 擴展字符集 。ASCII 擴展字符集使用 8 位(bits)表示一個字符，所以，ASCII 擴展字符集可以定義 256(2^8)個字符。
ASCII字符編碼
GB2312
我們上面說了，ASCII 字符集是一種現代美國英語適用的字符集。因此，很多國家都搗鼓了一個適合自己國家語言的字符集。
GB2312 字符集是一種對漢字比較友好的字符集，共收錄 6700 多個漢字，基本涵蓋了絕大部分常用漢字。不過，GB2312 字符集不支持絕大部分的生僻字和繁體字。
對于英語字符，GB2312 編碼和 ASCII 碼是相同的，1 字節編碼即可。對于非英字符，需要 2 字節編碼。
GBK
GBK 字符集可以看作是 GB2312 字符集的擴展，兼容 GB2312 字符集，共收錄了 20000 多個漢字。
GBK 中 K 是漢語拼音 Kuo Zhan(擴展)中的“Kuo”的首字母。
GB18030
GB18030 完全兼容 GB2312 和 GBK 字符集，納入中國國內少數民族的文字，且收錄了日韓漢字，是目前為止最全面的漢字字符集，共收錄漢字 70000 多個。
BIG5
BIG5 主要針對的是繁體中文，收錄了 13000 多個漢字。
Unicode & UTF-8 編碼
為了更加適合本國語言，誕生了很多種字符集。
我們上面也說了不同的字符集可以表示的字符范圍以及編碼規則存在差異。這就導致了一個非常嚴重的問題：使用錯誤的編碼方式查看一個包含字符的文件就會產生亂碼現象。
就比如說你使用 UTF-8 編碼方式打開 GB2312 編碼格式的文件就會出現亂碼。示例：“牛”這個漢字 GB2312 編碼后的十六進制數值為 “C5A3”，而 “C5A3” 用 UTF-8 解碼之后得到的卻是 “?”。
你可以通過這個網站在線進行編碼和解碼：https://www.haomeili.net/HanZi/ZiFuBianMaZhuanHuan
這樣我們就搞懂了亂碼的本質：編碼和解碼時用了不同或者不兼容的字符集 。
為了解決這個問題，人們就想：“如果我們能夠有一種字符集將世界上所有的字符都納入其中就好了!”。
然后，Unicode 帶著這個使命誕生了。
Unicode 字符集中包含了世界上幾乎所有已知的字符。不過，Unicode 字符集并沒有規定如何存儲這些字符(也就是如何使用二級制數據表示這些字符)。
然后，就有了 UTF-8(8-bit Unicode Transformation Format)。類似的還有 UTF-16、 UTF-32。
UTF-8 使用 1 到 4 個字節為每個字符編碼， UTF-16 使用 2 或 4 個字節為每個字符編碼，UTF-32 固定位 4 個字節為每個字符編碼。
UTF-8 可以根據不同的符號自動選擇編碼的長短，像英文字符只需要 1 個字節就夠了，這一點 ASCII 字符集一樣 。因此，對于英語字符，UTF-8 編碼和 ASCII 碼是相同的。
UTF-32 的規則最簡單，不過缺陷也比較明顯，對于英文字母這類字符消耗的空間是 UTF-8 的 4 倍之多。
UTF-8 是目前使用最廣的一種字符編碼。
MySQL 字符集
MySQL 支持很多種字符編碼的方式，比如 UTF-8、GB2312、GBK、BIG5。
你可以通過 SHOW CHARSET 命令來查看。
通常情況下，我們建議使用 UTF-8 作為默認的字符編碼方式。
不過，這里有一個小坑。
MySQL 字符編碼集中有兩套 UTF-8 編碼實現：
- utf8 ：utf8編碼只支持1-3個字節 。在 utf8 編碼中，中文是占 3 個字節，其他數字、英文、符號占一個字節。但 emoji 符號占 4 個字節，一些較復雜的文字、繁體字也是 4 個字節。
- utf8mb4 ：UTF-8 的完整實現，正版!最多支持使用 4 個字節表示字符，因此，可以用來存儲 emoji 符號。
為什么有兩套 UTF-8 編碼實現呢? 原因如下：
因此，如果你需要存儲emoji類型的數據或者一些比較復雜的文字、繁體字到 MySQL 數據庫的話，數據庫的編碼一定要指定為utf8mb4 而不是utf8 ，要不然存儲的時候就會報錯了。
演示一下吧!(環境：MySQL 5.7+)
建表語句如下，我們指定數據庫 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;
當我們執行下面的 insert 語句插入數據到數據庫時，果然報錯!
- 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
