错误编码的“堆栈”会为字符串“cinématé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
--- parts ----部分表示不正确的字节。
我考虑了这个想法“如果它是一个混乱的转码怎么样？怎么样的双重编码？”，但是，看着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文件中找到这些受损的字符串。该文件没有＆lt;？xml version =“1.0”？＆gt; 标头，因此它被假定为UTF-8。存在包含短语的节点，其中包含非常好的é字符，同时存在包含带有错误é字符的短语的节点。
iconv - 家庭根据我的尝试，根本不做任何事情来帮助解决这种情况。
我现在要考虑的几个尾随考虑因素是：我是否应该怀疑MySQL及其臭名昭着的懒惰字符集转码？可能是因为他们导出了XML，他们编写的自定义编码功能真的很糟糕吗？
答案 0 :(得分：1)
编码看起来有些奇怪：
从cinéma中提取é会产生utf-8编码：
é= C3 A9
您去的地方：
C3 83 25
因此，当将其进行双重编码时，应发生以下情况：
c3：Ã-> c3 83
a9：©-> c2 a9
但这不会解释结果中的25个。
25：％
所以问题是，是否将其编码一次，然后将诸如％的未知字符替换为％，然后进行第二次编码？