我們新建mysql資料庫的時候，需要指定資料庫的字符集，一般我們都是選擇utf8這個字符集，但是還會又乙個utf8mb4這個字符集，好像和utf8有聯絡，今天就來解析一下這兩者的區別。
起源mysql在5.5.3之後增加了這個utf8mb4的編碼，mb4就是most bytes 4的意思，專門用來相容四位元組的unicode。好在utf8mb4是utf8的超集，除了將編碼改為utf8mb4外不需要做其他轉換。當然，為了節省空間，一般情況下使用utf8也就夠了。
可以簡單的理解 utf8mb4 是目前最大的乙個字元編碼,支援任意文字。
為什麼mysql有utf8和utf8mb4兩種幾乎差不多的字符集
utf8 是 mysql 中的一種字符集，只支援最長三個位元組的 utf-8字元，也就是 unicode 中的基本多文字平面。
mysql 中的 utf8 為什麼只支援持最長三個位元組的 utf-8字元呢？我想了一下，可能是因為 mysql 剛開始開發那會，unicode 還沒有輔助平面這一說呢。那時候，unicode 委員會還做著 「65535 個字元足夠全世界用了」的美夢。mysql 中的字串長度算的是字元數而非位元組數，對於 char 資料型別來說，需要為字串保留足夠的長。當使用 utf8 字符集時，需要保留的長度就是 utf8 最長字元長度乘以字串長度，所以這裡理所當然的限制了 utf8 最大長度為 3，比如 char(100) mysql 會保留 300位元組長度。至於後續的版本為什麼不對 4 位元組長度的 utf-8 字元提供支援，我想乙個是為了向後相容性的考慮，還有就是基本多文種平面之外的字元確實很少用到。
要在 mysql 中儲存 4 位元組長度的 utf-8 字元，需要使用 utf8mb4 字符集，但只有 5.5.3 版本以後的才支援。我覺得，為了獲取更好的相容性，應該總是使用 utf8mb4 而非 utf8. 對於 char 型別資料，utf8mb4 會多消耗一些空間，根據 mysql 官方建議，使用 varchar 替代 char。
為什麼要使用utf8mb4字符集
既然utf8應付日常使用完全沒有問題，那為什麼還要使用utf8mb4呢? 低版本的mysql支援的utf8編碼，最大字元長度為 3 位元組，如果遇到 4 位元組的字元就會出現錯誤了。三個位元組的 utf-8 最大能編碼的 unicode 字元是 0xffff，也就是 unicode 中的基本多文平面(bmp)。也就是說，任何不在基本多文平面的 unicode字元，都無法使用mysql原有的 utf8 字符集儲存。這些不在bmp中的字元包括哪些呢？最常見的就是emoji 表情(emoji 是一種特殊的 unicode 編碼，常見於 ios 和 android 手機上)，和一些不常用的漢字，以及任何新增的 unicode 字元等等。
那麼utf8mb4比utf8多了什麼的呢?
多了emoji編碼支援.
如果實際用途上來看,可以給要用到emoji的庫或者說表,設定utf8mb4.
新建mysql庫的排序規則
utf8_unicode_ci比較準確，utf8_general_ci速度比較快。通常情況下 utf8_general_ci的準確性就夠我們用的了，在我看過很多程式原始碼後，發現它們大多數也用的是utf8_general_ci，所以新建資料 庫時一般選用utf8_general_ci就可以了
如果是utf8mb4那麼對應的就是 utf8mb4_general_ci utf8mb4_unicode_ci
mysql字符集問題 mysql字符集問題
用show variables like char 檢視mysql的引數,結果應如下 mysql show variables like char variable name value character set client gbk character set connection gbk ch...
mysql字符集問題 MySql字符集問題
mysql字符集問題 xinjinlong 2010 11 14 22 10 47 閱讀 1334 上次說了一下c從mysql裡面讀取資料，這次在介紹一下如何把mysql的字符集設定為utf8 第一 檢視自己mysql的字符集 mysql show variables like character ...
mysql字符集問題 mysql字符集遇到的問題？
character introducer 翻譯過來就是字元引導。也就是針對字串，顯式的給定乙個字元編碼和排序規則，不受系統引數的影響。語法很簡單 charset name string collate collation name 示例 字串 北京加油 字符集 utf8mb4，排序規則 utf8mb...