mysql字符集问题

发布时间:2021-03-6 编辑:RainNight 阅读:1445

mysql字符集问题

导读

我们新建mysql数据库的时候需要指定数据库的字符集一般我们都是选择utf8这个字符集但是还会又一个utf8mb4这个字符集好像和utf8有联系今天就来解析一下这两者的区别

起源

MySQL在5.5.3之后增加了这个utf8mb4的编码mb4就是most bytes 4的意思专门用来兼容四字节的unicode好在utf8mb4是utf8的超集除了将编码改为utf8mb4外不需要做其他转换当然为了节省空间一般情况下使用utf8也就够了
可以简单的理解 utf8mb4 是目前最大的一个字符编码,支持任意文字

为什么mysql有utf8和utf8mb4两种几乎差不多的字符集

utf8  Mysql 中的一种字符集只支持最长三个字节的 UTF-8字符也就是 Unicode 中的基本多文本平面

Mysql 中的 utf8 为什么只支持持最长三个字节的 UTF-8字符呢我想了一下可能是因为 Mysql 刚开始开发那会Unicode 还没有辅助平面这一说呢那时候Unicode 委员会还做着 65535 个字符足够全世界用了的美梦Mysql 中的字符串长度算的是字符数而非字节数对于 CHAR 数据类型来说需要为字符串保留足够的长当使用 utf8 字符集时需要保留的长度就是 utf8 最长字符长度乘以字符串长度所以这里理所当然的限制了 utf8 最大长度为 3比如 CHAR(100) Mysql 会保留 300字节长度至于后续的版本为什么不对 4 字节长度的 UTF-8 字符提供支持我想一个是为了向后兼容性的考虑还有就是基本多文种平面之外的字符确实很少用到
要在 Mysql 中保存 4 字节长度的 UTF-8 字符需要使用 utf8mb4 字符集但只有 5.5.3 版本以后的才支持我觉得为了获取更好的兼容性应该总是使用 utf8mb4 而非 utf8. 对于 CHAR 类型数据utf8mb4 会多消耗一些空间根据 Mysql 官方建议使用 VARCHAR 替代 CHAR

为什么要使用utf8mb4字符集

既然utf8应付日常使用完全没有问题那为什么还要使用utf8mb4呢? 低版本的MySQL支持的utf8编码最大字符长度为 3 字节如果遇到 4 字节的字符就会出现错误了三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xFFFF也就是 Unicode 中的基本多文平面BMP也就是说任何不在基本多文平面的 Unicode字符都无法使用MySQL原有的 utf8 字符集存储这些不在BMP中的字符包括哪些呢最常见的就是Emoji 表情Emoji 是一种特殊的 Unicode 编码常见于 ios  android 手机上和一些不常用的汉字以及任何新增的 Unicode 字符等等

那么utf8mb4比utf8多了什么的呢?

多了emoji编码支持.
如果实际用途上来看,可以给要用到emoji的库或者说表,设置utf8mb4.
比如评论要支持emoji可以用到

新建mysql库的排序规则

utf8_unicode_ci比较准确utf8_general_ci速度比较快通常情况下 utf8_general_ci的准确性就够我们用的了在我看过很多程序源码后发现它们大多数也用的是utf8_general_ci所以新建数据 库时一般选用utf8_general_ci就可以了
如果是utf8mb4那么对应的就是 utf8mb4_general_ci utf8mb4_unicode_ci

关键字词[MySQL]