从 Latin1 SQL Server 迁移到 utf8mb4 MySQL 错误字符串错误问题

Question

最终更新

我能够使用 Talend 轻松迁移数据。没有错误，第一次完美运行，没有特殊设置。这显示了 MySQL Workbench 迁移工具是多么的垃圾。虽然 Talend 的学习曲线很粗糙（根本不直观），但它似乎是目前最好的数据迁移解决方案之一。我建议使用它。请注意，我从未弄清楚迁移失败的原因（如下所示）。我只是远离甲骨文推向社区的完全垃圾。哦，Talend 顺利地将数据迁移到 utf8mb4/utf8_general_ci。

请注意底部有更新。

我们必须将导出从 TrackerRMS（幸运的是没有 FK 约束，但数据完全一团糟）迁移到 MySQL。将 TrackerRMS 数据的备份恢复到 SQL Server 是小菜一碟；没有问题。问题是将数据从 SQL Server 复制到 MySQL。

MySQL Workbench Migration 可以处理除 4 个表之外的所有表；但那 4 张桌子是关键问题。他们在他们的领域中有疯狂的内容，导致迁移工具窒息。我试图从 HeidiSQL 将数据导出为 .sql，但它也阻塞了。

源表问题字段为NVARCHAR(MAX)和SQL_Latin1_General_CP1_CI_AS排序规则。

注意，我尝试将源 SQL Server 表列的排序规则更改为 Latin1_General_100_BIN2_UTF8 和 Latin1_General_100_CI_AI_SC_UTF8，但没有任何效果。

错误是：

ERROR: `Backup_EmpowerAssociates`.`BACKUP_documents`:Inserting Data: Incorrect string value: '\xF0\x9F\x93\x8A x...' for column 'filepath' at row 13
ERROR: `Backup_EmpowerAssociates`.`BACKUP_activities`:Inserting Data: Incorrect string value: '\xF0\x9F\x91\x80' for column 'subject' at row 42
ERROR: `Backup_EmpowerAssociates`.`BACKUP_resourcehistory`:Inserting Data: Incorrect string value: '\xF0\x9D\x91\x82(\xF0...' for column 'jobdescription' at row 80

这告诉我源数据有 4 字节字符详细信息（超出标准 utf8）。注意 MySQL 中的目标数据库是 utf8mb4 和 utf8mb4_unicode_ci 整理的，并且具有这样的默认设置。没有任何连接设置会覆盖此设置。

迁移时，我使用 Microsoft SQL Server 和 ODBC（本机）作为 localhost (SQL Server) 的默认选项。我也试过关闭ANSI，但没有影响。请注意，SQL Server 的 ODBC 配置没有字符集或排序规则设置或选项。对于目标，我使用用于一般访问的 localhost 存储连接。

注意 MySQL Workbench 迁移工具将接收表列（对于上述问题列）定义为 LONGTEXT CHARACTER SET 'utf8mb4'。

问题可能是迁移代理（ODBC？）以某种方式将其转换为 utf8（即使我没有选择它）？但如果是这样的话，作为 UTF8MB4 解决方案（4 字节 vs 更少），在迁移过程中传入的数据不会出错吗？

注意我尝试创建和调整目标 MySQL 表（通过调整迁移工具中的 SQL）作为 CHARSET latin1 和 latin1_general_ci 排序规则。同样的问题。

迁移根本不想工作（这是因为 SQL Server 源为 SQL_Latin1_General_CP1_CI_AS）。我已经尝试过为驱动程序打开和关闭 UTF8。没有效果。

有迁移经验的人是否认识到这个问题，或者有关于如何解决这个问题的建议？我可以在迁移之前清理 SQL Server 中的源数据 - 我只是不知道执行此操作的最佳方法（或者是否有必要）。

谢谢！

===

更新 1

这很奇怪；使用以下技术显示不会转换的值，结果如下：

SELECT filepath, CONVERT(varchar,filepath) FROM BACKUP_documents WHERE filepath <> CONVERT(varchar, Filepath);

为什么数据在转换为文档中“c”处的简单文件名时会被截断？

这里的捕获也可能有助于解决此问题。

但奇怪的是 MSSQL 将普通文本（没有特殊字符）显示为非 ASCII。我想知道 TrackerRMS 的人是否正在运行用其他国家/地区/语言编写的代码并且它会弄乱数据，但它是不可见的？

更新 2

所以为了清楚起见，下面是其中一个搞乱数据的角色的样子。

Answer 1

我能够使用 Talend 轻松迁移数据。没有错误，第一次完美运行，没有特殊设置。这显示了 MySQL Workbench 迁移工具是多么的垃圾。虽然 Talend 的学习曲线很粗糙（根本不直观），但它似乎是目前最好的数据迁移解决方案之一。我建议使用它。请注意，我从未弄清楚迁移失败的原因（如下所示）。我只是远离甲骨文推向社区的完全垃圾。哦，Talend 顺利地将数据迁移到 utf8mb4/utf8_general_ci。