UTF-8字符有问题；我看到的不是我存储的

您列出了五个主要的CHARACTER SET麻烦案例。

最佳实践

展望未来，最好使用CHARACTER SET utf8mb4和COLLATION utf8mb4_unicode_520_ci。（管道中有更新版本的Unicode排序规则。）

utf8mb4是的超集utf8，它处理4字节utf8代码，表情符号和某些中文需要这些代码。

在MySQL之外，“ UTF-8”是指所有大小的编码，因此实际上与MySQL相同utf8mb4，而不是utf8。

在下文中，我将尝试使用这些拼写和大写字母来区分MySQL内部和外部。

您应该做什么概述

将您的编辑器等设置为UTF-8。 HTML表单应以开头

有关计算机语言的更多详细信息（及其后续部分）

测试数据

使用工具或工具查看数据SELECT是不可信的。太多这样的客户端，尤其是浏览器，试图补偿不正确的编码，并向您显示正确的文本，即使数据库已损坏。因此，选择一个包含非英语文本的表和列，然后执行

SELECT col, HEX(col) FROM tbl WHERE ... 正确存储的UTF-8的十六进制将为

对于空格（任何语言）： 20 对于英语： 4x，5x，6x，或者7x 在西欧大部分地区，带重音符号的字母应为 Cxyy 西里尔文，希伯来文和波斯文/阿拉伯文： Dxyy 亚洲大部分地区： Exyyzz 表情符号和一些中文： F0yyzzww 更多细节 出现问题的具体原因和解决方法

截断的文字（Se为Señor）：

要存储的字节未编码为utf8mb4。解决这个问题。 另外，在读取过程中检查连接是否为UTF-8。 黑钻石与问号（Se�or对Señor）; 存在以下情况之一：

情况1（原始字节不是 UTF-8）：

要存储的字节未编码为utf8。解决这个问题。 的连接（或SET NAMES为）INSERT 和所述SELECT不UTF8 / utf8mb4。解决这个问题。 另外，检查数据库中的列是否为CHARACTER SET utf8（或utf8mb4）。 情况2（原始字节为 UTF-8）：

的连接（或SET NAMES）SELECT不是utf8 / utf8mb4。解决这个问题。 另外，检查数据库中的列是否为CHARACTER SET utf8（或utf8mb4）。 仅当浏览器设置为时，才会出现黑色菱形

问号（常规的，不是黑钻石）（Se?or用于Señor）：

要存储的字节未编码为utf8 / utf8mb4。解决这个问题。 数据库中的列不是CHARACTER SET utf8（或utf8mb4）。解决这个问题。（使用SHOW CREATE TABLE。） 另外，在读取过程中检查连接是否为UTF-8。 Mojibake（Señorfor Señor）：（此讨论也适用于Double Encoding，它不一定可见。）

要存储的字节需要UTF-8编码。解决这个问题。 当INSERTing和SELECTing文本的连接需要指定utf8或utf8mb4。解决这个问题。 该列需要声明CHARACTER SET utf8（或utf8mb4）。解决这个问题。 HTML应该以开头

通过执行SELECT .. HEX ..上述操作，可以确认双重编码。

é should come back C3A9, but instead shows C383C2A9 The Emoji  should come back F09F91BD, but comes back C3B0C5B8E28098C2BD 也就是说，十六进制的长度大约是它的两倍。这是由于从latin1（或任何其他形式）转换为utf8，然后将这些字节视为latin1并重复转换而引起的。排序（和比较）无法正常进行，因为例如，排序就像字符串是Señor。来源：stack overflow