SQL转储中的UTF-8无效

如何解决SQL转储中的UTF-8无效

我有一个MySQL转储，它不是有效的UTF-8。两个问题：

1. 这可能是由于某些使用utf8mb3的数据库（又称为MySQL的“ utf8”）引起的吗？它肯定会使用这种编码。
2. 如果是这样，如何在不访问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上下文中，您可以看到所有这些字符仍然在String文字内（请参见撇号），并且其内容似乎是HTML（请参见尖括号）。由于这17个字节无论如何都无法存储太多信息，因此只需使用十六进制编辑器并用20（空格）覆盖每个字节即可。

,

我使用以下方法“解决”了这个问题：

uconv --from-code utf8 --from-callback substitute --to-code utf8 a.sql -o a.sql.fixed

仅将默认字符替换为任何无效序列。 man unconv显示了其他几个选项，例如转义或删除无效序列。

在我的情况下，似乎只出现了很少的错误，所以我对能够处理转储比对正确识别在这些情况下发生的事情更感兴趣。

编辑：通过使用--from-callback skip，我可以通过比较输入和输出文件的长度来计算无效序列的数量。