Today there salesman reaction, edit a user's information when there has been an exception, the exception information is as follows:
in here Incorrect String value: "xFOx9Fx92x9D vxE6 .. 'f or column' name 'AT Row 1
I asked her to send a screenshot to see, It was found that the nickname of the user as follows:
Artwork
The nickname is a micro-channel nickname, but also a bit will bring some special symbols or, since the exception is thrown by the database, we may wish to look at the character set of the field:
So that
The initial use of UTF-8 format from one to six bytes, the maximum 31 characters can be encoded. UTF-8 latest specification only one to four bytes, the maximum coding 21 can, just to represent all Unicode plane 17.
Mysql utf8 is the character set, only supports up to three bytes in UTF-8 characters, that is, Unicode text in multiple substantially planar.
Mysql in utf8 why only supports holding up three bytes in UTF-8 characters? I thought for a moment, probably because it would Mysql beginning to develop, Unicode auxiliary plane that has not yet say. At that time, Unicode Commission also doing "65535 characters enough around the world used the word" dream. Mysql string length of the number of characters is counted rather than the number of bytes for the data type is CHAR, needs to be long enough to retain the string. When the utf8 character set, need to keep the length of the longest character length is multiplied utf8 string length, so here utf8 naturally limits the maximum length of 3, such as CHAR (100) Mysql retains 300 bytes in length. As subsequent versions why not UTF-8 characters in 4-byte support, I think one is for backwards compatibility, there is the character beyond the basic multilingual plane is indeed rarely used.
要在 Mysql 中保存 4 字节长度的 UTF-8 字符，需要使用 utf8mb4 字符集，但只有 5.5.3 版本以后的才支持（查看版本： select version();）。我觉得，为了获取更好的兼容性，应该总是使用 utf8mb4 而非 utf8. 对于 CHAR 类型数据，utf8mb4 会多消耗一些空间，根据 Mysql 官方建议，使用 VARCHAR 替代 CHAR。
我们尝试作出修改：
将utf8字符集修改为utf8mb4之后，通知业务员重新操作。业务员反应操作成功了。。。心里美滋滋