MySQL中的utf8mb4和utf8字符集有什么区别?

Moj*_*ian 294 mysql encoding utf-8 character-encoding utf8mb4

MySQL中utf8mb4utf8charsets有什么区别?

我已经知道ASCII,UTF-8,UTF-16UTF-32编码; 但我很想知道utf8mb4编码组与MySQL服务器中定义的其他编码类型的区别.

是否有任何特殊利益/建议使用utf8mb4而不是utf8

Cod*_*ter 341

UTF-8是可变长度编码.在UTF-8的情况下,这意味着存储一个代码点需要一到四个字节.但是,名为"utf8"(别名为"utf8mb3")的MySQL编码每个代码点最多只能存储三个字节.

因此字符集"utf8"/"utf8mb3"不能存储所有Unicode代码点:它只支持0x000到0xFFFF的范围,称为" 基本多语言平面 ".另请参见Unicode编码的比较.

这是MySQL文档必须说明的(同一页面的先前版本):

名为utf8 [/ utf8mb3]的字符集每个字符最多使用三个字节,仅包含BMP字符.从MySQL 5.5.3开始,utf8mb4字符集每个字符最多使用四个字节,支持补充字符:

  • 对于BMP字符,utf8 [/ utf8mb3]和utf8mb4具有相同的存储特性:相同的代码值,相同的编码,相同的长度.

  • 对于补充字符,utf8 [/ utf8mb3]根本不能存储字符,而utf8mb4需要四个字节来存储它.由于utf8 [/ utf8mb3]根本无法存储字符,因此在utf8 [/ utf8mb3]列中没有任何补充字符,并且在升级旧版本的utf8 [/ utf8mb3]数据时无需担心转换字符或丢失数据MySQL的.

因此,如果您希望列支持存储位于BMP之外的字符(通常是您想要的),例如表情符号,请使用"utf8mb4".另请参见实际使用中最常见的非BMP Unicode字符是什么?.

  • @idealidea加密数据是二进制的,您不应将二进制数据存储在varchar列中.:) (34认同)
  • 我遇到的(到目前为止)utf8mb4'需要'的唯一案例是中文和表情符号.有些模糊的字母表需要它. (9认同)
  • @thomasrutter尝试使用此()字符以UTF-8保存.:) (8认同)
  • 如果您使用加密的密码和数据保存在数据库中,也需要它.我使用正常的utf8格式在mysql中保存加密密码,这导致我随机地使用一些密码很麻烦,很难调试,所以最后我尝试使用base64编码并临时解决问题.但是,现在我知道原因了. (7认同)
  • @MojtabaRezaeian 它在某种程度上取决于密码算法 - bcrypt2 将产生 ASCII。 (5认同)
  • @KevinKyaw你刚才做到了. (3认同)
  • @work,因为代码点需要编码为字节。它需要花费一些位来指示“这是多字节代码点的第一部分,后面有更多字节”。另请参阅 https://www.fileformat.info/info/unicode/char/ffff/index.htm 和 https://www.fileformat.info/info/unicode/utf8.htm。 (2认同)

Jim*_*ane 52

utf8mb4,因为现在我们需要为存储不仅语言文字,而且是符号,新引进的表情符号,支持,等等字符集是非常有用的.

如何在 Mathias Bynens中支持MySQL数据库中完整Unicode,这也很好地解读了这一点.

  • MySQL 8.0现在默认为utf8mb4字符集.[https://www.mysql.com/products/enterprise/techspec.html] (8认同)

sim*_*eco 38

摘自MySQL 8.0参考手册:

  • utf8mb4:Unicode字符集的UTF-8编码,每个字符使用一到四个字节.

  • utf8mb3:Unicode字符集的UTF-8编码,每个字符使用一到三个字节.

MySQL的 utf8是目前的别名utf8mb3,其已被弃用,并且将在未来被删除的MySQL版本.届时utf8 将成为参考 utf8mb4.

因此,无论这个别名如何,您都可以有意识地为自己设置utf8mb4编码.

  • 很好的参考。多谢兄弟 :) (2认同)

tho*_*ter 7

  • utf8 是 MySQL 较旧的、有缺陷的 UTF-8 实现,它正在被弃用。
  • utf8mb4 是他们命名的固定 UTF-8 实现,也是您现在应该使用的。

在他们有缺陷的版本中,只有第一个 64k 字符平面(基本的多语言平面)中的字符有效,其他字符被视为无效。该平面内的代码点值 - 0 到 65535(其中一些因特殊原因而保留)可以由最多 3 个字节的 UTF-8 中的多字节编码表示,而 MySQL 早期版本的 UTF-8 任意决定将其设置为限制。这种限制绝不是对 UTF-8 规则的正确解释,因为 UTF-8 从未被定义为每个字符最多允许 3 个字节。事实上,UTF-8 的最早定义将其定义为最多 6 个字节(自修订为 4 个)。MySQL的原始版本总是被任意残废。

回到 MySQL 发布此版本时,此限制的后果还不错,因为大多数 Unicode 字符都在第一个平面中。从那时起,越来越多的新定义的字符范围被添加到 Unicode,其值在第一个平面之外。Unicode 本身定义了 17 个平面,但目前只使用了其中的 7 个。

为了不破坏做出任何特定假设的旧代码,MySQL 保留了破坏的实现并调用了较新的固定版本utf8mb4。这导致了一些混淆,名称被误解为好像它是 UTF-8 的某种扩展或 UTF-8 的替代形式,而不是 MySQL 对真正 UTF-8 的实现。

MySQL 的未来版本最终将淘汰旧版本,现在它可以被视为已弃用。在可预见的将来,您需要使用utf8mb4UTF-8 来确保正确的编码。经过足够的时间后,当前utf8将被删除,并且在将来的某个日期utf8将再次上升,这次是指固定版本,但utf8mb4将继续明确地指固定版本。

  • 那是错误信息。现在应该使用 utf8mb4 来正确支持 UTF-8。如果您的数据库已损坏,并且出现了不正确的密钥文件错误,则这是无关的问题。 (5认同)

App*_*ata 5

MySQL在5.5.3之后添加了这个utf8mb4编码,Mb4是最多字节4的意思,专门设计用于兼容四字节Unicode。幸运的是,UTF8MB4 是 UTF8 的超集,只不过不需要将编码转换为 UTF8MB4。当然,为了节省空间,一般使用UTF8就足够了。

原始的 UTF-8 格式使用 1 到 6 个字节,最多可以编码 31 个字符。最新的UTF-8规范仅使用一到四个字节,最多可以编码21位,正好代表所有17个Unicode平面。UTF8是Mysql中的字符集,最多只支持三个字节的UTF-8字符,这是Unicode中基本的多文本平面。

Mysql中要保存4字节长的UTF-8字符,需要使用UTF8MB4字符集,但只有5.5。后支持3个版本(查看版本:选择版本();)。我认为为了获得更好的兼容性,您应该始终使用UTF8MB4而不是UTF8。对于char类型数据,UTF8MB4消耗空间较多,根据Mysql官方推荐,使用VARCHAR代替char。

在 MariaDB 中,当未在服务器配置中显式设置时,将 utf8mb4 作为默认 CHARSET,因此使用 COLLATE utf8mb4_unicode_ci。

请参阅 MariaDB CHARSET & COLLATE 点击

CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Run Code Online (Sandbox Code Playgroud)

  • 使用有缺陷的实现而不是 utf8mb4 并不能节省空间。对于任何可变长度列,相同的字符串将在任一字符串中占用相同数量的字节。对于像 CHAR 这样的固定长度列,它取决于所使用的存储引擎是否像 VARCHAR 那样进行空间优化(我认为 innodb 默认情况下这样做),或者它保留最大字节数,例如(每个字符的最大字节数)x(数字字符数)。 (2认同)