我有一个MySQL转储，它不是有效的UTF-8。两个问题：
- 这可能是由某些使用 utf8mb3 又名 MySQL 的"utf8"的数据库引起的吗？它肯定使用这种编码。
- 如果是这样，我该如何修复它，而无需访问 MySQL 进行导入、更改表类型和重新导出？我可以使用任何编码转换工具吗？
编辑以添加无效的 UTF-8 特定数据：
uconv -f utf8 a.sql -o /dev/null
Conversion to Unicode from codepage failed at input byte position XXX. Bytes: ed Error: Illegal character found
下面是一个十六进制示例。
xxd -s {XXX-16} -l 30 a.sql
YYY: 6e2e 203c 2f70 3e20 cfa1 ecaf a6eb 9ea0 n. </p> ........
aabb aabb aabb aabb aaaa bbbb bbaa aaaa
YYZ: edb6 b0e1 aea5 ee9e a027 2c27 3230 .........','20
^^^^ ^^
编辑 2：在上面添加了更多上下文。看起来问题序列也符合 UTF-8 格式，它只是映射到不存在的 U+1DDB0。
根据 UTF-8，您的第一行 YYY 由以下字符组成(所有有效序列)：
U+006E n 6e LATIN SMALL LETTER N
U+002E . 2e FULL STOP
U+0020 20 SPACE
U+003C < 3c LESS-THAN SIGN
U+002F / 2f SOLIDUS
U+0070 p 70 LATIN SMALL LETTER P
U+003E > 3e GREATER-THAN SIGN
U+0020 20 SPACE
U+03E1 ϡ cf a1 GREEK SMALL LETTER SAMPI
U+CBE6 쯦 ec af a6 (Hangul)
U+B7A0 랠 eb 9e a0 (Hangul)
您的第二行 YYZ 如下：从技术上正确但逻辑上非法的序列开始，因为不允许使用代理项，尤其是在未配对时(没有相应的高代理项)。允许使用"私人使用"序列/字符，但可疑：
U+DDB0 � ed b6 b0 (low surrogate = illegal, reserved for UTF-16)
U+1BA5 ᮥ e1 ae a5 SUNDANESE VOWEL SIGN PANYUKU
U+E7A0 ee 9e a0 (private use = highly unlikely it is used intentionally)
U+0027 ' 27 APOSTROPHE
U+002C , 2c COMMA
U+0027 ' 27 APOSTROPHE
U+0032 2 32 DIGIT TWO
U+0030 0 30 DIGIT ZERO
从逻辑上讲，这些字符也没有意义(一个希腊人，两个韩国人......它也不适合任何 ANSI 编码：
a6几乎总是翻译成¦，我已经很多年没有遇到这个角色了af几乎总是转化为主要用于光学原因的¯，但即便如此，也只有一次9e很少使用，只有很少的编码映射它a0到处都是不间断的空格，没有人能够直接输入，但可能来自从 MS Word 复制文本
从 SQL 上下文中，您可以看到所有这些字符仍在字符串文本中(请参阅撇号)，并且其内容似乎是 HTML(请参阅尖括号)。由于这 17 个字节无论如何都无法存储太多信息，因此只需使用十六进制编辑器并用20(空格)覆盖每个字节。
我使用以下方法"解决"了这个问题：
uconv --from-code utf8 --from-callback substitute --to-code utf8 a.sql -o a.sql.fixed
它只是用默认字符替换任何无效序列。man unconv显示了其他几个选项，例如转义或删除无效序列。
在我的情况下，似乎只有很少的错误，所以我更感兴趣的是能够处理转储，而不是正确识别这些情况下发生的事情。
编辑：通过使用--from-callback skip，我可以通过比较输入和输出文件的长度来计算无效序列的数量。