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

Question

什么“堆栈”的错误编码会为字符串“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。

某些程序如何将带重音的 é 转换为“à 后跟 %”以及“à<”/strong> 后跟 c”？我想追溯错误编码的历史，以便我可以尝试想出一些可以采取措施修复损坏的字符串的方法。

也有可能 é 本来就不是 é，但我无法理解有人可能在其中犯了什么样的拼写错误同一个短语得到两个不同版本的 é，最终被错误编码成两个完全不同的字节集。

额外的上下文详细信息:我在 XML 文件中发现了这些损坏的字符串。该文件没有 header ，因此假定它是 UTF-8。存在包含具有完美 é 字符的短语的节点，同时存在包含包含损坏的 é 字符的短语的节点。

iconv-and-family 根本没有做任何事情来帮助解决这种情况，据我所知。

我现在持有的一些后续考虑因素是:我是否应该怀疑 MySQL 及其臭名昭著的懒惰字符集转码？难道是某人在导出 XML 时编写的自定义编码函数写得很糟糕？

Answer 1

编码看起来有点奇怪:

从 cinema 中取出 é，得到 utf-8 编码:

é = C3 A9

你从哪里得到的:

C3 83 25

因此，当它被双重编码时，应该发生以下情况:

c3: Ã -> c3 83

a9: © -> c2 a9

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

25: %

所以问题是，如果编码一次，那么像©这样的未知字符将被替换为%，然后进行第二次编码？