谨记不要在MySQL中使用“utf8”编码

1.BUG重现

这里我做了一个简单的试验,来验证utf8在mysql中存在的问题:

建立数据表:

CREATE TABLE `user` ( `id` int(10) NOT NULL AUTO_INCREMENT COMMENT '自增id', `nickname` varchar(255) CHARACTER SET utf8 DEFAULT NULL COMMENT '昵称', `sex` varchar(255) DEFAULT NULL COMMENT '性别', `age` int(10) DEFAULT NULL COMMENT '年龄', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COMMENT='测试utf8问题重现'

这里我们直接指定了nickname字段的字符编码为utf8,然后我向里面插入一条普通数据,使用mybatis的插入数据库语句如下:

INSERT INTO `user` ( `nickname`, `sex`, `age`) VALUES ( '张三', '男', '18');

的确是像我们平时操作一样插入成功了,似乎没有什么问题,但这里我们再测试一下昵称中带有表情符(emoji)的数据尝试一下:

张三 An 😀awesome 😃string 😄with a few 😉emojis!

Caused by: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x80aw...' for column 'nickname' at row 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"的编码集恰当!