JSON 与 XML：关键区别、优点和用例

Scrapeless Scraping API 以 JSON 或 CSV 格式返回结构化的网页数据，使 JSON 成为在比较 JSON 和 XML 时自然的应用程序参考点。

JSON和XML之间有什么区别？

JSON和XML是表示结构化信息的文本格式，但它们以不同的方式描述这些信息。JSON通过对象、数组、字符串、数字、布尔值和null建模值。XML将文档建模为一个可能包含属性、文本、子元素、注释和处理指令的元素树。这个区别比标点符号更重要：JSON从应用程序数据开始，而XML可以表示数据记录和丰富结构化的文档。

正式的 JSON 文法故意很小。 RFC 8259 定义了 JSON 对象、数组、数字、字符串、布尔值和 null, 以及交换 JSON 文本的互操作性规则。XML 具有更广泛的文档模型。 W3C XML 规范 定义元素、属性、实体、字符数据、文档声明和良构性约束。

对于包含产品、用户或搜索结果的典型 REST 响应，JSON 通常会生成一个应用程序代码可以解析为字典、映射、数组或结构的直接表示。当合同需要来自多个词汇的合格名称、有序的插入标记的散文，或与围绕 XML 架构和转换构建的系统兼容时，XML 变得更具吸引力。

数据模型的差异如何

JSON 有一个值模型。一个对象包含命名成员，而一个数组包含有序值。对象成员的顺序不应具有商业意义，因为消费者可能以不同的顺序暴露对象成员。数组是明确有序的。一个 JSON 属性无法直接区分文本内容和属性，因为 JSON 没有属性概念；应用程序必须创建自己的约定。

XML 有一个节点模型。一个元素有一个名称，可以携带属性，可以包含文本，也可以包含子节点。子节点的顺序是有意义的，这使得 XML 能够表示包含内联强调、链接、引用和嵌入域元素的段落，而无需将散文展平为特定于应用程序的字段约定。命名空间允许两个词汇表使用相同的本地元素名称而不发生冲突。

JSON 和 XML 语法并排显示

一个 JSON 记录

这个 JSON 对象代表一个目录项，它包含一个嵌套的供应商和一个标签数组：

{
  "id": "A-104",
  "name": "Desk Lamp",
  "available": true,
  "supplier": { "country": "DE", "name": "Nordlicht" },
  "tags": ["lighting", "desk"]
}

属性名称承载字段标签，JSON 字面量保留布尔值和 null 值。解析器不需要单独的约定来区分 true 从字符串 "true".

等效的 XML 记录

XML表示法可以将标识符放在属性中，并将剩余的值表示为元素：

<item id="A-104" available="true">
  <name>Desk Lamp</name>
  <supplier country="DE">Nordlicht</supplier>
  <tags>
    <tag>lighting</tag>
    <tag>desk</tag>
  </tags>
</item>

XML版本较长，但它可以通过属性附加元数据，并且可以使用命名空间限定的元素扩展文档。如果没有架构，文本 true 是词汇内容；一个应用程序或模式决定是否将其解释为布尔值。

JSON与XML比较表

架构和验证选择

解析器仅证明有效负载遵循格式语法。它并不能证明订单总额为非负，国家代码属于批准的集合，或者所需的标识符存在。这些都是合同规则。

JSON Schema 可以定义所需属性、允许的类型、数值边界、字符串模式、数组约束和可重用子架构。当 API 生产者和消费者已经以 JSON 值进行思考时，它的工作效果很好。架构还可以记录可选字段并控制是否接受未知属性，这在 API 演变中非常重要。

XML 架构定义可以定义元素顺序、属性、简单和复杂类型、出现限制以及命名空间感知结构。RELAX NG 提供另一种以语法为导向的方法，而 Schematron 可以表达依赖于文档内部关系的断言。XML 项目通常将结构验证与业务规则验证结合，而不是将每条规则强制放入一种架构语言中。

两个生态系统都需要版本控制规则。对于消费者而言，添加可选字段或元素通常比重命名现有元素要容易。生产者应记录未知成员或元素必须被忽略、保留或拒绝。消费者应避免将每个不被识别的添加都视为致命，除非合同要求闭合世界验证。

重要的安全差异

JSON 解析器的功能面较小，但是 JSON 输入仍然需要大小限制、嵌套限制、数值边界和架构检查。深度嵌套的值可能消耗内存或堆栈空间。重复的对象名称也可能导致不一致的行为，因为库可能保留第一个值、保留最后一个值或暴露每一次出现。

XML 解析器需要显式加固，因为外部实体和文档类型声明等功能可能导致意外的文件读取、网络访问或资源消耗。 OWASP XML 外部实体预防指导 建议禁用应用程序不需要的危险解析器功能。安全默认值因解析器和版本而异，因此应用程序必须配置并测试它部署的确切库。

格式选择不能替代授权或输出编码。有效的 JSON 或 XML 有效负载仍然可以包含不受信任的字符串。应用程序必须验证域值并在将其放入 HTML、SQL、shell 命令、文件路径或日志时正确编码数据。

性能、大小和流式处理

因为属性名称在每个成员中只出现一次，并且没有关闭标签，所以 JSON 通常对记录型数据使用更少的字节。XML 可以在开始和结束标签中重复元素名称。这个观察很有用，但并不是普遍基准。压缩去除了许多重复名称的开销，而使用属性的 XML 表示可能在大小上接近 JSON，而不是一个高度嵌套的元素设计。

解析器速度取决于库、语言、验证设置、内存分配和数据形状。流式 XML 解析器可以处理大型文档，而不需要构建完整的内存树。JSON 库也支持基于事件或增量解析，尽管许多应用示例先加载完整值。正确的基准测量确切的有效负载、解析器、架构检查、压缩和在生产中使用的下游转换。

XML 具有显式的流式 API，例如 SAX 和拉取解析器。JSON 流需要一个帧规则，因为连接的 JSON 值是模糊的。系统通常在数组中包裹记录，使用长度前缀，或在每个记录可以保持在一行时采用换行分隔的 JSON。

每种格式适合的地方

如何在 JSON 和 XML 之间选择

当有效负载自然是对象图，主要消费者是应用代码，并且简洁的 Web 传输很重要时，选择 JSON。当团队希望有一个小语法并且在前端和后端工具中获得广泛支持时，JSON 也是一个好的默认选择。

当有效负载是文档而不是记录时，当几个词汇需要命名空间时，当混合内容必须在没有发明的映射的情况下生存时，或者当一个已建立的合作伙伴合同已经依赖于 XML 架构和转换时，选择 XML。仅仅为了减少标点而用 JSON 替换成熟的 XML 合同可能会带来比带来价值更多的迁移工作。

如果任一选项可以表示数据，请评估周围系统：可用的验证器、调试工具、流媒体需求、合作伙伴要求、错误报告和长期模式治理。格式是合同的一个层面。命名规则、兼容性政策、安全限制和所有权决定了交换是否保持可靠。

在JSON和XML之间转换

机械转换仅对有限的子集简单。一个JSON对象可以映射到一个XML元素，属性的子元素可以映射，而数组可以映射到重复的子元素。反向映射需要属性、重复元素、命名空间、文本节点和空元素的规则。没有这些规则，两个转换器可能从相同的XML生成不同的JSON。

将映射定义为接口合同的一部分。说明属性是否成为带前缀的属性，单个重复元素是如何成为标量或一项数组的，命名空间是如何表示的，以及数字和布尔值是如何推断的。当法律或审计要求需要精确的忠实度时，请保留原始文档；转换的对象可能保留值，同时失去诸如注释、前缀、实体引用和空白等词法细节。

结论

JSON和XML存在重叠，但它们并不是结构化文本的可互换标签。JSON为应用程序开发人员提供了适合API和软件对象的简洁值模型。XML为文档系统提供了更丰富的节点模型，具有混合内容、属性、命名空间以及成熟的验证和转换工具。实际选择遵循数据模型、周围工具和兼容性义务，而不是单方面声称一种格式取代了另一种。