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

Question

最终更新

我能够使用 Talend 轻松迁移数据。没有错误，第一次就可以完美运行，无需特殊设置。这表明 MySQL Workbench 迁移工具是多么垃圾。虽然 Talend 的学习曲线很粗糙（一点也不直观），但它似乎是最好的数据迁移解决方案之一。我建议使用它。请注意，我从未弄清楚迁移失败的原因（如下所示）。我只是从 Oracle 向社区推送的垃圾中走开。哦，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（本机）作为本地主机 (SQL Server) 的默认选项。我也尝试过关闭 ANSI，但没有任何影响。请注意，SQL Server 的 ODBC 配置没有字符集或排序规则设置或选项。对于目标，我使用本地主机存储的连接，用于一般访问。

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

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

注意我尝试创建和调整目标 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 的学习曲线很粗糙（一点也不直观），但它似乎是最好的数据迁移解决方案之一。我建议使用它。请注意，我从未弄清楚迁移失败的原因（如下所示）。我只是从 Oracle 向社区推送的垃圾中走开。哦，Talend 顺利地将数据迁移到 utf8mb4/utf8_general_ci。