首页
产品
CLup:PostgreSQL高可用集群平台 CMiner: PostgreSQL中的CDC CData高性能数据库云一体机 CBackup数据库备份恢复云平台 CPDA高性能双子星数据库机 CSYun超融合虚拟机产品
解决方案
数据库专业技术服务全栈式PostgreSQL解决方案Oracle分布式存储化数据库云
文章
客户及伙伴
中启开源
关于我们
公司简介 联系我们
中启开源

1. 背景

很多MySQL DBA搞不清楚MySQL中utf8字符集与utf8mb4的区别,部分人有模糊认识,认为现在应该使用utf8mb4,而不应该使用utf8字符集,但是具体是为什么,说不清楚,本文把这个问题解释清楚。

2. MySQL中的utf8字符集核utf8mb4字符集

MySQL在5.5版本之前,虽然实现了utf8字符集,但是此utf8字符集并不是完整的utf8字符集,而是只能存储UNICODE中基本多文种平面(BMP)中的字符,即65536个字符,即早些UNICODE中用2字节编码的字符。而不在这个范围内字符则不能存储。UNICODE中用2字节编码的字符用UTF-8来编码,则需要1~3个字符。utf8是一种变长编码,理论上是1~6个字节来表示4字节的UNICODE编码的字符。我们知道英文在UTF-8中是用1个字节来表示,欧洲的一些字符用2个字节来表示,而在UTF-8中绝大多数汉字是用3个字节来表示,但一些生僻汉字或表情符号是使用4个字节来表示的。

所以在MySQL中的utf8字符集只能表示1~3字节长的utf8字符,而不能表示4字节长的utf8字符。

这里解释一下基本多文种平面,BMP(Basic Multilingual Plane),或称第零平面(Plane 0),是Unicode中的一个编码区段。编码从U+0000至U+FFFF。

除了基本多文种平面,还有其它平面:

Plane 范围 名称
Plane 0 U+0000 ~ U+FFFF 基本多文种平面(Basic Multilingual Plane, BMP)
Plane 1 U+10000 ~ U+1FFFF 多文种补充平面(Supplementary Multilingual Plane, SMP)
Plane 2 U+20000 ~ U+2FFFF 表意文字补充平面(Supplementary Ideographic Plane, SIP)
Plane 3 U+30000 ~ U+3FFFF 表意文字第三平面(Tertiary Ideographic Plane, TIP)
Plane 4 ~ 13 U+40000 ~ U+4FFFF 未使用(unassigned)
Plane 14 U+E0000 ~ U+EFFFF 特别用途补充平面(Supplementary Special-purpose Plane, SSP)
Plane 15 ~ 16 U+F0000 ~ U+10FFFF 保留作为私人使用区(Private Use Area, PUA)

所以在MySQL中utf8字符集时,发现一些需要用4个字节表示的utf-8的字符,如一些生僻字无法插入到MySQL中,为了解决这个问题,MySQL在5.5.3之后增加了utf8mb4 字符编码,mb4即 most bytes 4,简单说MySQL中utf8mb4是utf8的超集并完全兼容utf8,能够用四个字节存储更多的字符。所以从这里可以知道原先 MySQL中的utf8字符集实际上是utf8mb3,即只能存最多3个字节的utf8字符。了解的utf8编码的同学可能知道utf8编码理论的长度是1~6字节,那么来一个5字节的utf8字符怎么办?从目前的情况看,全世界当前的的字符用4个字节的utf-8编码都可以容纳,还没有5个字节的utf8字符。当然未来,如果有5个字节的utf8字符出现时,MySQL的编码从utf8mb4再扩展成utf8mb5,这看着有点傻。还不如象Oracle、PostgreSQL等数据库一样,自动适应1~6个字节的utf8编码,多好?但没有办法,MySQL目前的实现就是这样。

3. 生僻字的例子:

如宋末元初官员、书法家、画家、诗人赵孟𫖯,𫖯字念“俯”,这个字就是生僻字:

我们在utf8字符集的表执行下面的SQL语句:

  1. CREATE TABLE `test01` (
  2. `id` int(11) DEFAULT NULL,
  3. `t` varchar(30) COLLATE utf8_bin DEFAULT NULL
  4. ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
  5. insert into test01 values(1, '赵孟𫖯');

在MySQL的命令行中,这个字转换成一个UNICODE的值了,并报错了:

  1. root@localhost : db01 03:35:39> insert into test01 values(1, '赵孟\U+2B5AF');
  2. ERROR 1366 (HY000): Incorrect string value: '\xF0\xAB\x96\xAF' for column 't' at row 1
  3. Warning (Code 1300): Invalid utf8 character string: 'F0AB96'
  4. Error (Code 1366): Incorrect string value: '\xF0\xAB\x96\xAF' for column 't' at row 1

如果把表的字符集改成utf8mb4,排序规则为COLLATE=utf8mb4_unicode_ci:

  1. CREATE TABLE `test01` (
  2. `id` int(11) DEFAULT NULL,
  3. `t` varchar(30) COLLATE utf8_bin DEFAULT NULL
  4. ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

这时再插入就没有问题了:

  1. root@localhost : db01 04:07:36> insert into test01 values(1, '赵孟\U+2B5AF');
  2. Query OK, 1 row affected (0.02 sec)
  3. root@localhost : db01 04:08:00> select * from test01;
  4. +------+------------+
  5. | id | t |
  6. +------+------------+
  7. | 1 | 赵孟𫖯 |
  8. +------+------------+
  9. 1 row in set (0.00 sec)

4. 一些注意事项

可以看:

datax使用中的一些问题,需要在jdbc的url中添加:jdbc:mysql://ip:3306/testabc?com.mysql.jdbc.faultInjection.serverCharsetIndex=45
具体见:
DataX:导入4字节UTF8编码(生僻字)到Mysql数据库的utf8mb4数据表

5. 总结

为了避免后续插入不了一些生僻字,在建库时就应该把默认字符集设置为utf8mb4,my.cnf的配置应该为:

  1. [client]
  2. loose_default-character-set = utf8mb4
  3. ...
  4. ...
  5. [mysqldump]
  6. default-character-set = utf8mb4
  7. ...
  8. ...
  9. [mysql]
  10. default-character-set = utf8mb4
  11. ...
  12. ...
  13. [mysqld]
  14. character-set-server=utf8mb4
  15. collation_server = utf8mb4_unicode_ci
  16. ...
  17. ...

注意MySQL中的默认的utf8字符集实际上是utf8mb3,而不是完整的utf8,这个问题目前只在MySQL数据库中存在,PostgreSQL和Oracle是没有这个问题的,PostgreSQL数据库默认就是utf8字符集,是可以插入这些生僻字的,是没有问题的。这个问题主要是MySQL在设计之初不够严谨导致的。