MySQL保存微信暱稱中的特殊符號造成：（Incorrect string value: "xxxx'for column ‘name’ at row 1）異常

今天有業務員反應，編輯某個用戶的信息的時候出現了異常，異常信息如下：
Incorrect string value: "xFOx9Fx92x9D vxE6…'f or column ‘name’ at row 1
我讓她發個截圖看看，結果發現該用戶的暱稱如下：

原圖：

該暱稱是微信暱稱，也未免會帶一些特殊符號或者，既然異常由數據庫拋出，我們不妨查看一下該字段的字符集
:

原來如此

最初的 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。

我們嘗試作出修改：

將utf8字符集修改爲utf8mb4之後，通知業務員重新操作。業務員反應操作成功了。。。心裏美滋滋