掉坑回顾:
最近在工作中遇到一个BUG,用于记录客户昵称的数据表,在插入带有表情的字符时候报错.使用的存储引擎是INNODB,当我查看数据库字段的时候确实是设置的utf8,我传入的字符也是utf8的编码集,这有什么错?直到我深入了解才发自己使用的姿势并不对,mysql数据库中的”utf8”并不是真正的utf8编码,关于这个问题mysql官方一直未能修复,取而代之的推出了utf8mb4,这一点让我记忆犹新,切记mysql中不要再使用utf8编码!
1.BUG重现
这里我做了一个简单的试验,来验证utf8在mysql中存在的问题:
建立数据表:
1 |
|
这里我们直接指定了nickname字段的字符编码为utf8,然后我向里面插入一条普通数据,使用mybatis的插入数据库语句如下:
1 |
|
的确是像我们平时操作一样插入成功了,似乎没有什么问题,但这里我们再测试一下昵称中带有表情符(emoji)的数据尝试一下:
张三 An 😀awesome 😃string 😄with a few 😉emojis!
1 |
|
这个时候报的错误就很明显是指的这个表情符无法存入该字段,那为什么emoji无法存入utf8编码的字段呢,这又是怎么回事呢?
2.Mysql遗留问题
这个问题的症结在于,Mysql的”utf8”并不是真正的UTF-8.
“utf8”只支持每个字符三个字节,而真正的 UTF-8 是每个字符最多四字节,MySQL 一直没有修复这个 bug,他们在 2010 年发布了一个叫作“utf8mb4”的字符集,绕过了这个问题,但为什么没有修复”utf8”问题?具体原因不详.
简单归纳综合如下: MySQL 的“utf8mb4”是真正的“UTF-8”,MySQL 的“utf8”是一种“专属的编码”,它能够编码的 Unicode 字符其实不多,所以在使用mysql的时候还是用”utf8mb4”的编码集恰当!