XML 与 JSON：深入理解 API 和配置文件的数据格式

显示器上的数据可视化

每个与外部世界通信的应用程序都需要以某种结构化格式交换数据。XML 统治了 2000 年代，JSON 则在 2010 年代后来居上。但 XML 并未消亡——它仍驱动着 SOAP API、RSS 订阅源、SVG 图形、Android 布局以及无数企业系统。同时掌握这两种格式，能让你成为一名更全面的开发者。

JSON 概览

JSON（JavaScript Object Notation）是现代 Web API 的通用语言，能直接映射到大多数编程语言中的数据类型：

{
  "user": {
    "id": 42,
    "name": "Alice Chen",
    "roles": ["admin", "editor"],
    "active": true,
    "score": 98.6,
    "avatar": null
  }
}

类型： string、number、boolean、null、array、object。

JSON 简洁、易读，且在各种语言中解析都极为方便。它是 REST API、配置文件和浏览器存储的默认格式。

XML 概览

XML（eXtensible Markup Language，可扩展标记语言）以带标签的元素树形式表示数据：

<?xml version="1.0" encoding="UTF-8"?>
<user id="42">
  <name>Alice Chen</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
  <active>true</active>
  <score>98.6</score>
</user>

XML 较为冗长，但表达能力强。它支持属性（如上面的 id="42"）、命名空间（用于混合词汇表）、注释、处理指令以及用于严格验证的模式（schema）。

两者对比

特性	JSON	XML
冗余度	简洁	冗长
数据类型	6 种原生类型	一切皆文本
注释	❌ 不支持	✅ `<!-- -->`
属性	❌ 无此概念	✅ 支持
命名空间	❌ 无此概念	✅ 支持
模式验证	JSON Schema	XSD、DTD、RelaxNG
查询语言	JSONPath、jq	XPath、XQuery
XSLT 转换	❌	✅
可读性	高	中
解析复杂度	低	较高

何时使用 JSON

REST API（几乎是通用标准）
浏览器 localStorage / sessionStorage
配置文件（package.json、tsconfig.json）
NoSQL 文档数据库（MongoDB、Firestore）
微服务之间的通信
任何需要快速、轻量数据交换的场景

何时使用 XML

SOAP Web 服务（金融、医疗、政务领域）
RSS 和 Atom 订阅源
SVG 图形
Android 资源文件（布局、字符串、清单文件）
Office 文档格式（.docx、.xlsx 本质上是包含 XML 的 ZIP 文件）
需要混合内容（带内联标记的文本）时
尚未迁移到 JSON 的企业系统

格式互转

XML 转 JSON 很少能做到一一对应——XML 拥有一些 JSON 中不存在的概念（属性、文本节点、命名空间）。常见的转换策略如下：

属性转换为属性字段

<user id="42" active="true">Alice</user>

可能转换为：

{ "@id": "42", "@active": "true", "#text": "Alice" }

或扁平化后：

{ "id": 42, "active": true, "name": "Alice" }

具体采用哪种方式取决于你的使用场景。使用我们的 XML to JSON Converter 可灵活处理属性转换选项。

使用 JSON Schema 验证 JSON

JSON Schema 允许你定义 JSON 文档的预期结构：

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["id", "name", "email"],
  "properties": {
    "id": { "type": "integer", "minimum": 1 },
    "name": { "type": "string", "minLength": 1 },
    "email": { "type": "string", "format": "email" },
    "roles": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}

使用我们的 JSON Schema Validator 对照 schema 验证你的 JSON 文档——在问题进入生产环境之前捕获结构性错误。

JSONPath：查询嵌套数据

JSONPath 之于 JSON，正如 XPath 之于 XML。查询语法示例：

$.store.book[*].author          — 所有作者
$.store.book[0].title           — 第一本书的标题
$.store.book[?(@.price < 10)]   — 价格低于 $10 的书籍
$..price                        — 任意位置的所有价格值

XML 对应的 XPath 语法：

/store/book/author               — 所有作者
/store/book[1]/title             — 第一本书的标题
/store/book[@price < 10]         — 价格低于 $10 的书籍
//price                          — 任意位置的所有价格值

格式化与美化输出

两种格式在压缩后都会变得难以阅读。调试和人工审查时，务必进行美化输出。

压缩后的 JSON：

{"user":{"id":42,"name":"Alice Chen","roles":["admin","editor"]}}

美化后的 JSON（2 空格缩进）：

{
  "user": {
    "id": 42,
    "name": "Alice Chen",
    "roles": [
      "admin",
      "editor"
    ]
  }
}

使用我们的 JSON Formatter 即可快速美化、压缩和验证 JSON。如需对比两段 JSON 的差异，JSON Diff 能精确高亮显示所有变更内容。

常见陷阱

JSON

尾随逗号 — JSON 中不合法（但在 JavaScript 中合法）
单引号 — JSON 中字符串必须使用双引号
数字写成字符串 — "42" ≠ 42，请保持一致
深层嵌套 — 难以阅读和查询，尽量扁平化处理

XML

未转义的字符 — <、>、&、"、' 必须转义为实体引用
BOM 头部 — 某些解析器会在遇到 UTF-8 BOM 时报错
命名空间混乱 — 在混合词汇表文档中容易出错

这两种格式都有成熟的理解基础和完善的工具支持，并将长期并存。掌握各自的适用场景，做好数据验证，你的集成方案将会更加可靠。