很多MySQL DBA搞不清楚MySQL中utf8字符集与utf8mb4的区别,部分人有模糊认识,认为现在应该使用utf8mb4,而不应该使用utf8字符集,但是具体是为什么,说不清楚,本文把这个问题解释清楚。
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目前的实现就是这样。
如宋末元初官员、书法家、画家、诗人赵孟𫖯,𫖯字念“俯”,这个字就是生僻字:
我们在utf8字符集的表执行下面的SQL语句:
CREATE TABLE `test01` (
`id` int(11) DEFAULT NULL,
`t` varchar(30) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
insert into test01 values(1, '赵孟𫖯');
在MySQL的命令行中,这个字转换成一个UNICODE的值了,并报错了:
root@localhost : db01 03:35:39> insert into test01 values(1, '赵孟\U+2B5AF');
ERROR 1366 (HY000): Incorrect string value: '\xF0\xAB\x96\xAF' for column 't' at row 1
Warning (Code 1300): Invalid utf8 character string: 'F0AB96'
Error (Code 1366): Incorrect string value: '\xF0\xAB\x96\xAF' for column 't' at row 1
如果把表的字符集改成utf8mb4,排序规则为COLLATE=utf8mb4_unicode_ci:
CREATE TABLE `test01` (
`id` int(11) DEFAULT NULL,
`t` varchar(30) COLLATE utf8_bin DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
这时再插入就没有问题了:
root@localhost : db01 04:07:36> insert into test01 values(1, '赵孟\U+2B5AF');
Query OK, 1 row affected (0.02 sec)
root@localhost : db01 04:08:00> select * from test01;
+------+------------+
| id | t |
+------+------------+
| 1 | 赵孟𫖯 |
+------+------------+
1 row in set (0.00 sec)
可以看:
datax使用中的一些问题,需要在jdbc的url中添加:jdbc:
mysql://ip:3306/testabc?com.mysql.jdbc.faultInjection.serverCharsetIndex=45
具体见:
DataX:导入4字节UTF8编码(生僻字)到Mysql数据库的utf8mb4数据表
为了避免后续插入不了一些生僻字,在建库时就应该把默认字符集设置为utf8mb4,my.cnf的配置应该为:
[client]
loose_default-character-set = utf8mb4
...
...
[mysqldump]
default-character-set = utf8mb4
...
...
[mysql]
default-character-set = utf8mb4
...
...
[mysqld]
character-set-server=utf8mb4
collation_server = utf8mb4_unicode_ci
...
...
注意MySQL中的默认的utf8字符集实际上是utf8mb3,而不是完整的utf8,这个问题目前只在MySQL数据库中存在,PostgreSQL和Oracle是没有这个问题的,PostgreSQL数据库默认就是utf8字符集,是可以插入这些生僻字的,是没有问题的。这个问题主要是MySQL在设计之初不够严谨导致的。