1. 首页
  2. 问题
  3. UTF-8字符有问题；我看到的不是我存储的
小编典典

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

mysql

我试图使用UTF-8并遇到麻烦。

我尝试了很多事情；这是我得到的结果：

  • ????而不是亚洲字符。即使是欧洲文字，我也能Se?or接受Señor。
  • 奇怪的乱码（变为乱码？），如Señor或新浪新闻为新浪新闻。
  • 黑钻石，例如Seor。
  • 最终，我陷入了数据丢失或至少被截断的情况：Sefor Señor。
  • 即使我 看到 正确的文本，它也无法正确 排序 。

我究竟做错了什么？我该如何修复 代码 ？我可以恢复 数据 吗？


阅读 494

收藏
2020-05-17

共1个答案

小编典典

这个问题困扰着该站点的参与者以及其他许多人。

您列出了五个主要的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表单应以开头<form accept-charset="UTF-8">。
  • 将您的字节编码为UTF-8。
  • 建立UTF-8作为客户端中使用的编码。
  • 声明列/表CHARACTER SET utf8mb4（使用进行检查SHOW CREATE TABLE。）
  • <meta charset=UTF-8> 在HTML的开头
  • 存储的例程获取当前的字符集/排序规则。他们可能需要重建。

UTF-8贯穿始终

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

测试数据

使用工具或工具查看数据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）。

仅当浏览器设置为时，才会出现黑色菱形<meta charset=UTF-8>。

问号 （常规的，不是黑钻石）（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应该以开头<meta charset=UTF-8>。

如果数据看起来正确，但排序不正确，则说明您选择了错误的排序规则，或者没有适合您的排序规则，或者您使用 Double Encoding 。

*通过执行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。

修复数据

对于 截断 和 问号 ，数据将丢失。

对于 Mojibake / 双重编码 ，…

对于 黑钻石 ，…

该 修复程序
列在这里。（针对5种不同情况的5种修复；请谨慎选择）：http
:
//mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases

2020-05-17