XML 至 JSON：每个加工商必须做出的决定

转换器无法避免的歧义

考虑`<items><item>x</item></items>`。应该`item`是一个字符串还是一个列表？ XML 没有说明，当您针对它编写代码时，差异就很重要：期望总是数组的消费者在单元素响应时中断，而期望对象的消费者在第二个项目到达时中断。成熟的转换器可以让您强制使用已知列表元素的数组，而不是默默地猜测，因为猜测正确的次数足以达到生产目的。

属性需要命名约定

JSON 没有属性，因此属性必须成为同级键或嵌套对象。广泛使用的约定是在属性名称前加上 `@` 前缀 — `<image src="a.png"/>` 变为 `{"@src": "a.png"}` — 当元素同时具有属性和内容时，元素文本将进入保留键，例如 `#text`。无论转换器使用哪种约定，都应该一致地应用，因为半转换的 XML 比未转换的 XML 更糟糕。

                <rss version="2.0"><channel><title>Feed</title></channel></rss>
→ {
  "rss": {
    "@version": "2.0",
    "channel": { "title": "Feed" }
  }
}
              

命名空间

命名空间文档（SOAP 服务、站点地图、Office 格式）将元素名称限定为 `ns:element`。 JSON 没有等效项，因此转换器要么删除前缀，将其保留为键的一部分，要么围绕名称空间 URI 重新排列文档。当两个名称空间使用相同的本地名称时，删除它是很常见的，有时甚至会造成灾难性的后果。如果您的文档使用命名空间，请在信任输出之前检查输出是否存在冲突，并且最好将前缀保留在密钥中。

实际使用此转换的地方

• RSS 和 Atom 提要 — 转换后阅读 JavaScript 中的提要要容易得多。
• SOAP 和遗留 API — 将响应转变为现代客户端可以使用的内容。
• 站点地图和配置文件——无需理解模式的编辑器即可检查结构。
• 数据迁移 — 将记录从 XML 时代的系统移至基于 JSON 的系统。

往返保真度是一个神话。将 XML 与 JSON 相互转换很少会逐字节返回原始文档，因为声明顺序、空格、注释和 CDATA 不会保留。当您需要在其他地方使用数据时进行转换，而不是作为备份策略。

先验证，再转换

XML 解析器对未封闭标签和无效实体非常严格，并且错误消息通常是精确的。在转换之前修复文档 - 格式良好的输入是获得值得保留的 JSON 结构的唯一方法。然后，转换在浏览器中本地运行，这在 XML 是客户导出或内部服务响应时很重要，并且它可以保持离线工作。