配置更改后 MySQL 数据库中的 UTF-8 字符串变得混乱

Question

我有一个带有字符串的 MySQL，我将其休眠了一段时间。现在我再次拿起它，我发现所有的特殊字符都搞砸了。我的 ISP 已将服务器移植到另一台计算机，我怀疑这可能是发生的时间。

该数据库由 PHP 脚本填充。所有内容都应该采用 UTF-8 格式，这就是数据库的设置。

然而，现在的字符串是这样的：

fàªte

这四个特殊字符应该是一个字符，ê，字符串应该是 fête< /代码>。

现在看起来这只是重新编码了两次，但这似乎不对。这四个十六进制字符是：

C3 83 C6 92 C3 82 C2 AA

这看起来非常像 UTF-8，所以如果我们解码它，我们会得到

C3 3F C2 AA

这不完全是 UTF-8（因为 3F），但让我们再次解码它：

FF AA

这不是 UTF-8。

ê 字符是 EA，在 UTF-8 中，即 C3 AA。

另一个例子：西班牙语倒置问号 (¿) 为 C8 83 E2 80 9A C3 82 C2，解码为 C3 3F 82 BF< /code>，这又不是正确的 UTF-8（转换为 FF 82 BF）。 ¿ 的预期字符是 BF，即正确的 UTF-8 中的 C2 BF。

这里发生了什么？人物是怎么乱七八糟的？更重要的是，我该如何解决它？

（旁注 - 新服务器要求我编写 mysql_set_charset("utf8"); ，否则字符串也会变得混乱，尽管是“UTF-8 as latin1”方式，而不是这种奇怪的方式如上所示。）

TL;DR：

• MySQL 数据库通过 PHP 脚本以 UTF-8 填充
• 休眠多年，服务器已迁移。
• 现在字符混乱了，见上文。

Answer 1

C3 83 C6 92 C3 82 C2 AA

这看起来非常像 UTF-8，所以如果我们解码它，我们会得到

C3 3F C2 AA

如果将字节序列视为 UTF-8，然后将其编码为 ISO-8859-1，就会得到这样的结果。 3F 是 ?，它已作为替换字符包含在内，因为 UTF-8 C6 92 是 U+0192 f。但它确实存在于 Windows 代码页 1252 西欧中，该编码与 ISO-8859-1 非常相似；在那里，它是字节 0x83。

C3 83 C2 AA

经过另一轮 treat-as-UTF-8-bytes-and-encode-to-cp1252 ，你会得到：

C3 AA

最后，ê 的 UTF-8。

请注意，即使您将非 XML HTML 页面显式提供为 ISO-8859-1，由于令人讨厌的历史原因，浏览器实际上也会使用 cp1252 编码。

不幸的是 MySQL 没有 cp1252 编码； latin1（正确地）是 ISO-8859-1。因此，您将无法通过转储为 latin1 然后重新加载为 utf8（两次）来修复数据。您必须使用文本编辑器处理脚本，该文本编辑器可以另存为（或例如在Python file(path, 'rb').read().decode('utf-8').encode(' cp1252').decode('utf-8').encode('cp1252'))。

Answer 2

我怀疑您可能将字符作为 UTF8 字符串存储在 latin1 （或类似）数据库中。这就是为什么你会遇到“双重编码”问题。将数据库的 CHARSET 设置为 UTF8 应该可以解决这个问题。转储/导入数据可能也是必要的，沿着这些思路：

$ mysqldump --default-character-set=latin1  --skip-set-charset --databases xxx > xxx.sql
$ mysql --default-character-set=utf8 < xxx.sql

但这只是建议，可能有效，但在您的具体情况下不必这样做。