XML
起因
梳理 JSON 时引出了 XML，成文便于查阅。
详情
是什么？
XML（eXtensible Markup Language，可扩展标记语言）是由 W3C 于 1998 年发布的纯文本结构化数据格式标准。核心特性：
- 自描述性：标签名即语义（如
<price currency="USD">） - 严格语法：标签必须闭合、嵌套正确、区分大小写
- 可扩展：用户自定义标签体系，无预设词汇表
- 平台无关：UTF-8 编码支持多语言，任何系统可解析
- 配套生态：DTD/XSD（验证）、XPath（查询）、XSLT（转换）、命名空间（防冲突）
没有之前？（XML 出现前的数据困境）
- SGML：XML 前身，功能强大但实现复杂（需数百页规范），难以在 Web 普及
- 二进制协议（如 CORBA GIOP）：高效但不可读、平台绑定、调试困难
- 自定义文本格式（CSV/INI）：无嵌套能力、字段冲突风险高、解析逻辑需硬编码
- HTML：标签语义固定（仅用于展示），无法表达业务数据结构
- 结果：系统间数据交换成本高，跨平台集成困难，缺乏统一轻量级标准
为什么使用？（设计初衷与历史价值）
XML 诞生旨在解决上述痛点：
- ✅ 简化 SGML：保留结构化能力，大幅降低实现门槛
- ✅ Web 友好：纯文本 + HTTP 友好，适配早期互联网传输需求
- ✅ 自描述数据：标签携带业务语义（如
<invoice><item>），降低文档依赖 - ✅ 生态支撑：推动 SOAP（Web 服务，见SOA时代）、RSS（内容聚合）、Office Open XML（文档标准）等关键协议
- ✅ 企业级验证：XSD 可定义复杂业务规则（如“订单金额必须 >0”），保障数据质量
核心概念
| 概念 | 说明 | 示例 |
|---|---|---|
| 元素 | 基本结构单元，含开始/结束标签 | <title>XML Guide</title> |
| 属性 | 标签内元数据，键值对形式 | <book id="B001" lang="zh"> |
| CDATA | 转义保护区块，内容不被解析 | <![CDATA[<code>if(a<5)</code>]]> |
| 命名空间 | 解决标签名冲突 | <svg:circle xmlns:svg="..."> |
| XSD/DTD | 结构约束规则（验证用） | 定义 <age> 必须为整数 |
| 处理指令 | 解析器指令 | <?xml-stylesheet href="style.xsl"?> |
使用步骤
- 设计：规划标签结构，编写 XSD/DTD（可选但推荐）
- 编写：创建符合语法的 XML 文档（含声明
<?xml version="1.0"?>） - 验证：用工具校验是否符合 Schema（如 xmllint）
- 解析：
- DOM：全量加载为内存树（适合小文件，随机访问）
- SAX：流式事件驱动（适合大文件，内存占用低）
- StAX：拉模式解析（平衡控制与效率）
- 处理：提取数据用于业务逻辑（存库、渲染、转换等）
- 转换（可选）：用 XSLT 转为 HTML/其他格式
示例：图书数据 XML
<?xml version="1.0" encoding="UTF-8"?>
<!-- 书籍目录示例 -->
<library xmlns:isbn="http://example.com/isbn-ns">
<book id="BK101">
<title lang="en">Design Patterns</title>
<author>Erich Gamma</author>
<price currency="USD">49.99</price>
<summary><![CDATA[Classic guide to reusable OOP solutions.]]></summary>
</book>
</library>- 包含：XML 声明、注释、命名空间、属性、CDATA、嵌套元素
- 可通过 XPath
//book[@id='BK101']/price精确查询
局限性（为何在多数新场景中被 JSON 取代）
| 维度 | XML 问题 | JSON 优势 | 现实影响 |
|---|---|---|---|
| 体积 | 标签重复（开闭标签），比 JSON 大 30%~50% | 键值紧凑（"name":"John"） | 移动端/高并发场景带宽成本高 |
| 解析 | 需 DOM/SAX 库，代码冗长易错 | JS 原生 JSON.parse() 一行搞定 | 前端开发效率显著降低 |
| JS 交互 | 需手动转换：XML → DOM → JS 对象 | 对象 ↔ 字符串无缝转换 | 增加维护成本与出错点 |
| 可读性 | 标签噪音多（<name>John</name>） | 结构简洁直观 | 团队协作与调试体验差 |
| 生态趋势 | SOAP 逐渐被 REST 取代 | RESTful API 标配，框架深度集成 | 新项目选型倾向 JSON |
当前合理使用场景（未被完全淘汰）：
- 文档型数据：Office (.docx/.xlsx)、PDF 内部结构
- 配置文件：Android
AndroidManifest.xml、Mavenpom.xml - 强验证需求：金融/医疗领域需 XSD 严格校验业务规则
- 遗留系统：企业 SOAP 服务、EDI 数据交换
- 特定标准：SVG（矢量图）、RSS/Atom（内容订阅）
总结
XML 是数据标准化史上的里程碑，解决了早期跨系统交换的混乱问题。但在“前后端分离 + 移动互联网”主导的现代开发中，JSON 凭借简洁性、JS 原生支持及生态优势，已成为轻量级数据交换的事实标准。 理解 XML 有助于维护遗留系统，但新项目应优先评估 JSON/Protocol Buffers 等更高效方案。技术选型需结合场景：重验证选 XML，重效率选 JSON。
关联网络
依赖
- XML —[依赖]→ UTF-8
对比 / 对立
- XML —[对比]→ JSON
演化日志
- v0.1 (2026-02-27)：初始版本
待办事项
- W3C
- DTD/XSD（验证）、XPath（查询）、XSLT（转换）、命名空间（防冲突）
- SGML
- 二进制协议（如 CORBA GIOP）：高效但不可读、平台绑定、调试困难
- 自定义文本格式（CSV/INI）：无嵌套能力、字段冲突风险高、解析逻辑需硬编码
- HTML：标签语义固定（仅用于展示），无法表达业务数据结构
- 结果：系统间数据交换成本高，跨平台集成困难，缺乏统一轻量级标准
- SOAP、RSS（内容聚合）、Office Open XML（文档标准）等关键协议
- 核心概念 - CDATA
- 解析：
- DOM：全量加载为内存树（适合小文件，随机访问）
- SAX：流式事件驱动（适合大文件，内存占用低）
- StAX：拉模式解析（平衡控制与效率）