什么可以解释这种糟糕的字符编码？答案

【问题标题】：What can explain this bad character-encoding?什么可以解释这种糟糕的字符编码？
【发布时间】：2014-01-05 13:54:41
【问题描述】：

什么“堆栈”的错误编码会为字符串“cinéma télédiffusion”产生以下奇怪的字节？（我省略了空格字符，十六进制：20）

cinÃ%ma
in HEX: 63 69 6E C3 83 25 6D 61
mapped: c  i  n  ---�----  m  a

tÃclÃcdiffusion
in HEX: 74 C3 83 63 6C C3 83 63 64 69 66 66 75 73 69 6F 6E
mapped: t  ---�---- l  ---�---- d  i  f  f  u  s  i  o  n

---�---- 部分表示不正确的字节。

我考虑过“如果它是一个混乱的转码怎么办？双重编码怎么样？”，但是，看着http://www.fileformat.info/info/unicode/char/00e9/charset_support.htm（以及代码页版本），我注意到没有任何编码可以可能以十六进制字节 %25 或 %63 结束 é。在这一点上，它甚至看起来都不像双 UTF8 编码，因为http://en.wikipedia.org/wiki/UTF-8 澄清了 %C3 之后的字节需要将第一个位设置为 10xxxxxx。

某些程序如何将重音 é 变成“Ã 后跟 %”以及“Ã 后跟 c"？我想追溯错误编码的历史，以便我可以尝试提出一些可以采取措施来修复损坏的字符串。

也有可能 é 一开始就不是é，但我无法理解有人在相同的短语得到两个不同版本的 é，它们最终被错误编码为两个完全不同的字节集。

额外的上下文细节：我在一个 XML 文件中找到了这些错位的字符串。该文件没有标头，因此假定为 UTF-8。存在包含具有完美 é 字符的短语的节点，同时存在包含具有错位 é 字符的短语的节点。

iconv-and-family 根本没有做任何事情来帮助这种情况，就我所尝试的而言。

我现在持有的几个后续考虑是：我应该怀疑 MySQL 及其臭名昭著的惰性字符集转码吗？会不会是某些人在导出 XML 时编写的自定义编码函数真的很糟糕？

【问题讨论】：

绝对是 utf-8 编码两次。中间有一个神秘的代码页编码。不同的。一个在 c 中转 ©。另一个很难猜。发回那个 xml 文件，你不想要它。
同一个字符被转换成不同单词的不同字节，这很奇怪。
是的，我认为这永远无法恢复。对不起！那里肯定有一个双 UTF-8，但是为第二个字符吐出 ASCII 的非确定性修改既不是常见的也不是可补救的损坏。
洞察力带来了清晰，我对此表示感谢。我最初的意思是“它看起来不像——通常的、可恢复的——双 UTF8 编码”。我喜欢这种时髦的双重编码被描述为“发回那个 xml 文件，你不想要它”。 :) 从技术上讲，我觉得我的问题已经回答了......不知道如何处理空的“答案”部分。

标签： unicode encoding utf-8 character-encoding

【解决方案1】：

编码看起来有点奇怪：

从 cinéma 结果中取 é 用于 utf-8 编码：

é = C3 A9

你从哪里得到的：

C3 83 25

所以当它被双重编码时，应该会发生以下情况：

c3: Ã -> c3 83

a9: © -> c2 a9

但这并不能解释结果中的 25。

25: %

【讨论】：

两个单词的整个字符串在重音“e”周围以不同的方式错位。在“mangling”的每种情况下，都会出现额外的字符：第一种情况下的“%”（十六进制 25）和后两种情况下的“c”（十六进制 63）。我认为双编码和代码页以及编码丢失的确切堆栈将在未来相当长的一段时间内保持庞大。我怀疑这些字节在 MySQL 的“ASCII、3 字节 UTF8 和完整 UTF8”方案以及各种编程语言的“ASCII 和 UTF8”字符串中被破坏了。
仅供参考：UTF-8（取决于使用的字符）始终是 1-4 字节编码。 - 因此，与“完整”UTF-8 相比，没有 3 字节 UTF-8 - 有关更多信息，请查看 en.wikipedia.org/wiki/UTF-8 同样从我上面的示例中，我没有看到任何有效的 UTF-8 3 字节代码é的双重编码。所以必须有一些不仅仅是双重编码。同样奇怪的是，é 导致 cinéma 和 télédiffusion 的字节不同。