第三方导出XML含未知编码异常字符，咨询损坏成因

嘿，我之前处理过不少这类XML损坏的问题，你提到的重复出现的损坏特征其实是个很关键的线索，大概率指向固定逻辑或流程上的问题，而非随机损坏。下面是几种最可能的成因：

• 编码转换/声明不匹配的批量错误
  这是最常见的情况：第三方系统生成XML时用的编码（比如GBK、ISO-8859-1）和文件头部声明的编码（比如UTF-8）不一致，或者在导出/传输时做了错误的编码转码。如果是批量处理相同结构的内容，某个特定的多字节字符每次转码都会出错，就会在相同位置或相同类型的字段里重复出现未知编码字符。

• 批量生成脚本/模板的逻辑bug
  如果第三方是用脚本、模板引擎批量生成XML，那脚本里处理特殊字符的逻辑很可能有问题。比如：

  • 没有正确转义XML特殊字符（比如把&直接输出，而非&），但更底层的编码错误会直接产生未知字符；
  • 处理非ASCII字符（比如中文、特殊符号）时，脚本的编码处理逻辑有漏洞，每次遇到这类内容就会输出错误字节。
    这种bug会导致相同场景下的损坏重复出现。

• 传输/存储环节的固定位置损坏
  如果文件是通过老旧的传输工具（比如未正确设置二进制模式的FTP）传输，或者存储在有坏块的介质上，可能会在固定的字节位置出现损坏。如果XML文件是由重复的记录结构组成，那损坏就会在每条记录的对应位置重复显现。比如FTP用ASCII模式传输二进制内容时，会把某些字节错误替换，而这些字节刚好落在每条记录的相同位置。

• 第三方系统的字符集配置冲突
  比如他们的数据库字符集和应用读取的字符集不匹配：数据库存的是UTF-8内容，但应用读取时强制用ISO-8859-1解析，之后又转成UTF-8输出，这种二次编码错误会导致特定字符反复变成未知编码。如果是系统级的配置问题，所有生成的XML都会有相同的损坏特征。

另外，既然你已经发现了重复损坏的规律，下次联系第三方时可以把损坏的位置、对应的正常内容（如果能对比出来的话）整理给他们，这会帮他们快速定位到问题根源——毕竟重复出现的问题基本都是固定逻辑的bug，比随机损坏好排查太多了。

内容的提问来源于stack exchange，提问作者Stuffy