mysql中utf8和utf8mb4區別（轉）

MySQL在5.5.3以後增長了這個utf8mb4的編碼，mb4就是most bytes 4的意思，專門用來兼容四字節的unicode。好在utf8mb4是utf8的超集，除了將編碼改成utf8mb4外不須要作其餘轉換。固然，爲了節省空間，通常狀況下使用utf8也就夠了。

   2、內容描述

   那上面說了既然utf8可以存下大部分中文漢字,那爲何還要使用utf8mb4呢? 原來mysql支持的 utf8 編碼最大字符長度爲 3 字節，若是遇到 4 字節的寬字符就會插入異常了。三個字節的 UTF-8 最大能編碼的 Unicode 字符是 0xffff，也就是 Unicode 中的基本多文種平面(BMP)。也就是說，任何不在基本多文本平面的 Unicode字符，都沒法使用 Mysql 的 utf8 字符集存儲。包括 Emoji 表情(Emoji 是一種特殊的 Unicode 編碼，常見於 ios 和 android 手機上)，和不少不經常使用的漢字，以及任何新增的 Unicode 字符等等。

   3、問題根源

   最初的 UTF-8 格式使用一至六個字節，最大能編碼 31 位字符。最新的 UTF-8 規範只使用一到四個字節，最大能編碼21位，正好可以表示全部的 17個 Unicode 平面。

   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 版本之後的才支持(查看版本： select version();)。我以爲，爲了獲取更好的兼容性，應該老是使用 utf8mb4 而非 utf8.  對於 CHAR 類型數據，utf8mb4 會多消耗一些空間，根據 Mysql 官方建議，使用 VARCHAR  替代 CHAR。