MySQL中Latin1转UTF8MB4出现问号问题及解决咨询

1. 错误的编码转换逻辑
   你的SQL中额外添加了CONVERT(d.actualresults USING latin1)转换步骤，这是核心问题。如果actualresults字段虽定义为Latin1字符集，但实际存储的是UTF8编码的字节（这种场景很常见，因为Latin1会直接存储任意单字节，不做编码校验），这一步会把原本的UTF8多字节字符按Latin1单字节解析，破坏原有编码结构，再转utf8mb4时无法识别这些无效字符，最终被替换成?。

比如示例2中的✓是UTF8多字节字符（占3字节），存在Latin1列中时是直接存储这3个字节；当你用USING latin1转换时，会把这3个字节当成3个独立的Latin1字符，再转utf8mb4时这些字符无法映射为有效的UTF8编码，就变成了?。

2. 原数据包含Latin1不支持的字符或隐形控制字符
   示例1中的隐形字符（比如零宽空格U+200B）属于UTF8扩展字符，Latin1无法表示。如果这些字符以UTF8字节形式存在Latin1列中，经过错误的Latin1转换后，会被拆成无效的单字节，转utf8mb4时同样会变成?。

1. 移除多余的Latin1转换步骤
   直接将原字段转换为utf8mb4，无需先转Latin1。修正后的查询SQL：

SELECT (SELECT CONVERT(d.actualresults USING utf8mb4)  
        FROM document d  
        WHERE d.origindocumentid = 2711460)
FROM documentfield df
WHERE LOWER(df.name) = 'actualresults';

如果要永久修改表结构（推荐，避免每次查询都做转换）：

ALTER TABLE document 
MODIFY COLUMN actualresults TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

注意：执行表结构修改前请先备份数据，同时确保数据库连接的字符集设置为utf8mb4，避免转换过程中再次出现编码问题。

2. 处理"UTF8字节存于Latin1列"的场景
   如果确认原字段实际存储的是UTF8字节（而非Latin1字符），更安全的方式是先把字段转为二进制，再转utf8mb4，跳过字符集解析的中间步骤：

SELECT (SELECT CONVERT(BINARY d.actualresults USING utf8mb4)  
        FROM document d  
        WHERE d.origindocumentid = 2711460)
FROM documentfield df
WHERE LOWER(df.name) = 'actualresults';

这种方式会直接把存储的字节按UTF8编码解析，避免错误的Latin1解析导致的乱码。

3. 清理无效/隐形字符
   如果数据中存在零宽空格这类不需要的控制字符，可以先清理再转换，比如使用正则替换：

SELECT (SELECT CONVERT(REGEXP_REPLACE(d.actualresults, '[\x{200B}-\x{200D}\x{FEFF}]', '') USING utf8mb4)  
        FROM document d  
        WHERE d.origindocumentid = 2711460)
FROM documentfield df
WHERE LOWER(df.name) = 'actualresults';

内容的提问来源于stack exchange，提问作者gunnersboy