JSON 与 XML 的区别：数据交换两代王者的交接
在 2000 年代初，XML 是数据交换无可争议的王者；如今 Web API 的世界几乎已被 JSON 收编。但 XML 并没有死——你每天打开的 Office 文档、订阅的 RSS、Android 界面布局都还是 XML。理解两者的分野，能帮你在「新项目跟风」和「老系统兼容」之间做出正确判断。
| 对比维度 | JSON | XML |
|---|---|---|
| 语法与冗长度 | 键值对紧凑表达，同样数据通常比 XML 小 20–40%，无闭合标签负担 | 每个元素都要开闭标签，结构自解释但字符开销大 |
| 数据模型 | 对象 + 数组两层结构，映射到大多数语言的字典/列表天然对齐 | 带属性、命名空间与混合内容的树结构，表达力更强但映射更绕 |
| 类型系统 | 原生区分字符串、数字、布尔与 null | 一切都是文本，类型靠 DTD/XSD 声明或调用方约定还原 |
| 元数据与校验体系 | 相对薄弱：JSON Schema 补足校验，但没有命名空间和 XPath 这类成熟配套 | 体系完整：命名空间隔离词汇、XSD 强类型校验、XPath 查询、XSLT 转换一应俱全 |
| 解析性能 | 浏览器与语言内建快速解析器，移动端也毫无压力 | 解析器较重；超大文档需 SAX 流式处理避免内存暴涨 |
| 现存阵地 | Web 与移动 API、配置文件（多数场景）、NoSQL 文档存储 | SOAP 企业服务、OOXML/ODF 办公文档、RSS/Atom 订阅、Android 布局、SVG 矢量图 |
| 适用场景 | 新设计的 API、前后端通信、轻量级配置与日志结构化 | 需要强 schema 治理的企业文档交换、出版标记与既有 SOAP 集成 |
何时选 JSON？
从零设计对外接口、或前端要直接消费数据时选 JSON：体积小、解析快、JavaScript 原生支持零成本。配合 OpenAPI 规范同样能获得严格的接口治理能力。
何时选 XML？
对接银行、政务、大型 ERP 等 SOAP/WebService 存量接口，或需要处理 Office 文档、SVG、RSS 时必须面对 XML。它的 XSD 校验与命名空间机制在多方协作的严格场景里依然不可替代。
相关在线工具
常见问题
XML 已经过时了吗？
在 Web API 领域确实边缘化了，但在办公文档（docx/xlsx 本质是 zip 包内的 XML）、SVG、RSS、Android 布局和企业 SOAP 集成中仍是活跃标准，短期内不会消失。
JSON 有类似 XPath 的查询语言吗？
有 JSONPath，语法模仿 XPath 但没有统一标准，各实现行为略有差异。简单的键路径查询用点号或方括号即可，复杂需求建议先归一化再处理。
把 XML 转 JSON 会丢信息吗？
可能。属性与子元素的区分、命名空间前缀、注释和处理指令在 JSON 中没有直接对应物，转换工具会用约定模拟，往返转换不一定能还原原文。
延伸说明
两者并非替代关系，而是分工不同：JSON 统治「机器之间的高频小数据」，XML 守住「文档级的复杂结构」。一个实用的判断标准是看数据要不要被当作「文档」来对待——有混合内容、需要批注、章节嵌套的选 XML；纯粹的结构化记录用 JSON。站内提供 JSON 与 XML 双向转换及格式化工具，本地即可完成两种格式的互转与校验，方便在对接新旧系统时快速验证数据一致性。