ChatGPT解决这个技术问题 Extra ChatGPT

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

MySQL 中的 utf8mb4utf8 字符集有什么区别?

我已经知道 ASCIIUTF-8UTF-16UTF-32 编码;但我很想知道 utf8mb4 组编码与 MySQL Server 中定义的其他编码类型有什么区别。

使用 utf8mb4 而不是 utf8 有什么特别的好处/建议吗?

良好的阅读理解差异:eversql.com/…
utf-8 只能存储 1、2 或 3 个字节的字符,而 utf8mb4 也可以存储 4 个字节的字符。 utf-8utf8mb4 给出的字符子集。句号。

C
Community

UTF-8 是一种可变长度编码。对于 UTF-8,这意味着存储一个代码点需要一到四个字节。但是,MySQL 的编码称为“utf8”(“utf8mb3”的别名)每个代码点最多只能存储三个字节。

所以字符集“utf8”/“utf8mb3”不能存储所有的Unicode码位:它只支持0x000到0xFFFF的范围,称为“Basic Multilingual Plane”。另见Comparison of Unicode encodings

这就是(同一页面的先前版本)the MySQL documentation 不得不说的:

名为 utf8[/utf8mb3] 的字符集每个字符最多使用三个字节,并且仅包含 BMP 字符。从 MySQL 5.5.3 开始,utf8mb4 字符集每个字符最多使用四个字节,支持补充字符:对于 BMP 字符,utf8[/utf8mb3] 和 utf8mb4 具有相同的存储特性:相同的代码值、相同的编码、相同的长度。对于补充字符,utf8[/utf8mb3] 根本无法存储该字符,而 utf8mb4 需要四个字节来存储它。由于 utf8[/utf8mb3] 根本无法存储字符,因此您在 utf8[/utf8mb3] 列中没有任何补充字符,您无需担心在从旧版本升级 utf8[/utf8mb3] 数据时转换字符或丢失数据mysql。

因此,如果您希望您的列支持存储位于 BMP 之外的字符(并且您通常希望这样做),例如 emoji,请使用“utf8mb4”。另见What are the most common non-BMP Unicode characters in actual use?


(到目前为止)我遇到的唯一“需要”utf8mb4 的情况是中文和表情符号。有一些晦涩的字母需要它。
如果您用于在数据库中保存加密的密码和数据,也需要它。我使用普通的 utf8 格式将加密密码保存在 mysql 中,这给我带来了很多随机密码的麻烦,而且很难调试,所以最后我尝试使用 base64 编码并临时修复了问题。但是,现在我知道原因了。
@idealidea 加密数据是二进制的,您不应将二进制数据存储在 varchar 列中。 :)
@thomasrutter 试试这个 (𡞰) 字符以使用 UTF-8 保存。 :)
@MojtabaRezaeian 它在某种程度上取决于密码算法 - bcrypt2 将产生 ASCII。
M
Mathieu K.

utf8mb4 字符集很有用,因为现在我们不仅需要支持存储语言字符,还需要存储符号、新引入的表情符号等。

Mathias Bynens 对 How to support full Unicode in MySQL databases 的精彩阅读也可以对此有所了解。


MySQL 8.0 现在默认为 utf8mb4 字符集。 [mysql.com/products/enterprise/techspec.html]
s
simhumileco

取自 MySQL 8.0 Reference Manual

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

MySQL 中,utf8 当前是 utf8mb3 的别名,已弃用,并将在未来的 MySQL 版本中删除。此时,utf8 将成为对 utf8mb4 的引用。

因此,不管这个别名是什么,您都可以有意识地为自己设置一个 utf8mb4 编码。

为了完成答案,我想在下面添加@WilliamEntriken 的评论(也取自手册):

为避免对 utf8 的含义产生歧义,请考虑为字符集引用显式指定 utf8mb4 而不是 utf8。


t
thomasrutter

utf8 是 MySQL 较旧的、有缺陷的 UTF-8 实现,正在被弃用。

utf8mb4 是他们命名的固定 UTF-8 实现,是您现在应该使用的。

在他们有缺陷的版本中,只有前 64k 字符平面(基本的多语言平面)中的字符有效,其他字符被视为无效。该平面内的代码点值 - 0 到 65535(其中一些出于特殊原因保留)可以用 UTF-8 中最多 3 个字节的多字节编码表示,并且 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 的未来版本最终将逐步淘汰旧版本,现在它可以被视为已弃用。在可预见的未来,您需要使用 utf8mb4 来确保正确的 UTF-8 编码。经过足够的时间后,当前的 utf8 将被删除,并且在将来的某个日期 utf8 将再次上升,这一次指的是固定版本,尽管 utf8mb4 将继续明确地指代固定版本。


有缺陷!?我不这么认为。我在将我的表升级到 utf8mb4 时遇到了不好的经历。知道发生了什么吗?某天发生了不正确的密钥文件错误。为了纠正你的答案,utf8mb4 是扩展 utf8,但它有缺陷。
那是错误的信息。 utf8mb4 现在应该用于正确的 UTF-8 支持。如果您有一个损坏的数据库并且您收到了一个不正确的密钥文件错误,那是无关紧要的。
A
AppCloudData

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

原始 UTF-8 格式使用 1 到 6 个字节,最多可以编码 31 个字符。最新的 UTF-8 规范仅使用 1 到 4 个字节,最多可以编码 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。

Refer MariaDB CHARSET & COLLATE Click

CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

不。在 MariaDB 中,默认的 CHARSET 是 latin1。 (除非您的发行版为您修补此问题。)mariadb.com/kb/en/character-set-and-collation-overview/…