什么“堆栈”错误编码会导致字符串“cinéma télédiffusion”产生以下奇怪的字节?(我省略了空格字符,十六进制:20)
额外的上下文细节:我在一个XML文件中发现了这些混乱的字符串。该文件没有<?xml version="1.0"?>头,因此被认为是UTF-8。存在包含完全正确的é字符的节点,同时也存在包含混乱的é字符的短语节点。 iconv等工具对于解决这种情况毫无作用,至少我尝试了没有效果。
我现在考虑的几点是:我应该怀疑MySQL及其臭名昭著的懒惰字符集转换吗?这可能是某个人编写的非常糟糕的自定义编码函数,因为他们导出XML吗?
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文件中发现了这些混乱的字符串。该文件没有<?xml version="1.0"?>头,因此被认为是UTF-8。存在包含完全正确的é字符的节点,同时也存在包含混乱的é字符的短语节点。 iconv等工具对于解决这种情况毫无作用,至少我尝试了没有效果。
我现在考虑的几点是:我应该怀疑MySQL及其臭名昭著的懒惰字符集转换吗?这可能是某个人编写的非常糟糕的自定义编码函数,因为他们导出XML吗?