今天有業務員反應，編輯某個用戶的資訊的時候出現了例外，例外資訊如下：
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之后，通知業務員重新操作，業務員反應操作成功了，，，心里美滋滋
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/226583.html
標籤：其他
上一篇：資料庫多行轉換為單一列