Question

这是我的情况。

我正在从一台服务器迁移到另一台服务器。作为其中的一部分，我将遍历数据库数据。

迁移方法包括在新服务器上运行相同的CREATE TABLE查询，然后使用一系列INSERT命令逐行插入数据。这可能会导致产生不同的数据，但是，使用CHECKSUM命令来验证内容。转移后，在整个表上，在隔离了该行的新表上以及通过应用LEFT运算符截断字符串后，CHECKSUM都在整个表上完成。每次，新旧服务器之间的结果都是相同的，这表明原始数据在字节级别上应该完全相同。

CHECKSUM TABLE `test`

我已经检查了结构，它也完全一样。

SHOW CREATE TABLE `test`

这里是结构：

CREATE TABLE test ( item varchar(32) COLLATE utf8_unicode_ci NOT NULL, amount mediumint(5) NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

该字段的类型：

`item` varchar(32) COLLATE utf8_unicode_ci NOT NULL

这是我在PHP中的连接代码：

$sql = new mysqli($db_host, $db_user, $db_pass, $db_name);
if ($sql->connect_error) {
  die('Connect Error ('.$sql->connect_errno.') '.$sql->connect_error);
}

当我用一个简单的查询来检索PHP中的数据时：

SELECT * FROM `test`

数据显示如下：

§lO

在旧服务器/主机上，我得到以下原始字节序列：

Decimal: -194-167-108-79-
HEX: -C2-A7-6C-4F-

在新服务器上，开始时我得到了几个额外的字节：

Decimal: -195-130-194-167-108-79-
HEX: -C3-82-C2-A7-6C-4F-

为什么完全相同的原始数据，表结构和查询在两个服务器之间返回不同的结果？我应该怎么做才能确保将来的结果尽可能一致？

Answer 1

Â§lO是§lO的“ Mojibake”。我认为后者（3个字符）是“正确的”吗？

原始数据看起来像这样（两种情况下我都显示）

是伪造的，因为用于显示它的技术可能与编码搞混了。

由于3个字符变成4，然后变成6，所以您可能具有“双重编码”。

这讨论了“双重编码”如何发生：Trouble with UTF-8 characters; what I see is not what I stored

如果您提供了更多信息（CREATE TABLE，十六进制，数据迁移方法等），我们也许可以进一步弄清您遇到的麻烦。

更多

使用mysqli时，请执行$sql->set_charset('utf8');

（十六进制证实了我的分析。）

迁移方法涉及在新服务器上运行相同的CREATE TABLE查询

它前面是否有一些字符集设置（例如mysqldump中？

然后使用一系列INSERT命令逐行插入数据。

您可以在文件中获取带有重音符号的十六进制吗？

... CHECKSUM ...

好的，同样可以排除一件事。

CHECKSUM在...隔离了该行的新表上完成

您是如何做到的？ SELECTing该行可能已经修改了文本，从而使测试无效。

指示原始数据在字节级别上应该完全相同。

要检查表中的数据，SELECT HEX(col)...是绕过所有可能发生的所有字符集转换的唯一方法。请为某些具有非ASCII字符的列提供十六进制值（例如给定的示例）。然后对HEX输出执行CHECKSUM。

并提供SHOW VARIABLES LIKE 'char%';

完全相同的MySQL表结构/数据，相同查询的结果不同

1 个答案: