XML 与 JSON 对比

本章定位 ：全面对比 JSON 和 XML——语法、数据类型、可读性、解析性能、Schema 支持、适用场景决策树。理解"选择哪个"背后的工程权衡。

定义与作用

JSON （JavaScript Object Notation）和 XML 都是结构化数据表示格式。JSON 源自 JavaScript 对象字面量语法，2000 年代初随 AJAX 兴起成为 Web 数据交换的事实标准。XML 是更早的标准（1998），最初设计为 SGML 的简化版。

两者都解决了"不同系统间如何交换结构化数据"的问题，但设计哲学完全不同：XML 追求完整性和可验证性，JSON 追求简洁和易用。

核心原理：表达式能力对比

XML 文档模型：丰富的文档标记体系——属性/元素区分、命名空间、Schema 验证、XPath/XSLT 查询转换。"重"带来了验证和转换能力。

JSON 数据模型：精简的数据序列化格式——只有对象/数组，6 种类型。"轻"带来了易用性和性能。

语法/结构要点

相同数据：XML vs JSON

XML：

<bookstore>
  <book category="web">
    <title lang="en">Learning XML</title>
    <author>Erik T. Ray</author>
    <year>2003</year>
    <price currency="USD">39.95</price>
  </book>
</bookstore>

JSON：

{
  "bookstore": {
    "book": {
      "category": "web",
      "title": {"lang": "en", "#text": "Learning XML"},
      "author": "Erik T. Ray",
      "year": 2003,
      "price": {"currency": "USD", "#text": 39.95}
    }
  }
}

XML 的属性 category="web" 和 lang="en" 在 JSON 中没有天然对应，需要用嵌套对象 + 特殊键（如 #text）模拟。

全面对比表

完整示例：白歌做数据格式选型

场景说明

飞翔科技的架构师 白歌 面临两个子系统的数据格式选型：

• 场景 A ：REST API 响应，前端是 React SPA
• 场景 B ：政府机构数据交换，需要 XSD 验证，包含混合内容（段落中嵌入引用）

选型分析

场景 A → JSON ：

{
  "students": [
    {"id": "S001", "name": "小崔", "gpa": 3.8},
    {"id": "S002", "name": "黄俪", "gpa": 3.5}
  ]
}

• JavaScript 原生解析：const data = await response.json()
• 体积约为 XML 的 60%（无结束标签）
• 前端不需要担心 Schema 验证

场景 B → XML ：

<report>
  <section>
    <p>根据<ref id="law-2024"/>第3条，教育机构应当...</p>
  </section>
</report>

• 混合内容（文本中嵌入子元素）JSON 无法优雅表达
• 政府系统通常已有一套 XSD 验证体系
• 需要 ref 到 law 的 IDREF 关联（DTD 原生支持）

选型决策树

需要混合内容（文本+子元素）？ → 是 → XML
需要 Schema 严格验证？       → 是 → XML
需要 XSLT 转换为多格式？      → 是 → XML
前端是 JavaScript？           → 是 → JSON
REST API / 微服务通信？       → 是 → JSON
需要最小带宽？                → 是 → JSON

易错场景

错误一：JSON 中丢失 XML 属性信息

XML 的属性（如 currency="USD"）在 JSON 中没有直接对应。简单映射会导致信息丢失，需要约定映射规则（如 "@currency": "USD" 或嵌套对象）。

错误二：JSON 没有日期类型

{"date": "2024-06-10"}  // 这是字符串，不是日期！

XML 有 xs:date 类型（通过 XSD 约束），JSON 没有。双方需要约定日期格式（ISO 8601）。

面试考点