FlowingDev

XML 解读：一种西装革履的数据格式

XML (可扩展标记语言) 是一种基于规则的语言，用于将文档编码成一种既人类可读又机器可读的格式。

试用工具: XML 查看器

一句话概括

XML 是一种超级严格的方法，用自定义标签来组织数据，让你和电脑都能读懂，但主要还是给电脑读的。

它解决的问题

在计算早期，不同程序之间共享数据简直就是一场噩梦。每家公司都有自己“祖传秘方”式的文件格式。想用 Microsoft Word 打开一个 WordPerfect 文档，不亚于一场折腾人的冒险。这就是所谓的“厂商锁定”，场面一度十分混乱。

互联网的兴起让这个问题恶化了十倍。现在，不再是同一台电脑上两个程序的事儿了，而是全世界成千上万个不同的服务器和客户端需要相互通信。

为了解决 Web 上的这个问题，第一个尝试是 HTML（超文本标记语言）。HTML 在告诉浏览器如何显示信息方面非常出色：这是标题（<h1>），这是段落（<p>），这是粗体（<b>）。但它在描述信息是什么方面却一塌糊涂。那段加粗的文本是产品名、警告，还是你只是觉得加粗很酷？电脑对此一无所知。

于是，XML（可扩展标记语言）在 90 年代末应运而生。它源于一个更古老、更学术化的标准 SGML，但为适应 Web 规模的使用而做了简化。“可扩展”（eXtensible）是其精髓所在：与 HTML 固定的标签集不同，XML 允许你发明自己的标签。

你可以不用 <p>，而是创建 <product_name>、<price>、<shipping_address>，甚至是 <volcano_lair_top_secret_coordinates>。

突然之间，你有了一种交换自带含义的数据的方式。数据是自描述的。这对于从企业间交易到应用程序配置文件的所有一切来说都是革命性的。它创造了一种通用语言，任何两个系统只要遵守规则，就可以用它来沟通。

底层工作原理

XML 看起来就像一堆尖括号，但在那扎手的外表之下，是一个强大而富有逻辑的系统。它建立在几个核心概念之上。

核心解剖：标签、元素和属性

XML 的基本单位是元素（element）。一个元素由一个开始标签、内容和一个结束标签组成。

<book>战争与和平</book>
  • 标签（Tags）： <book> 是开始标签，</book> 是结束标签。注意结束标签里的斜杠 /。这是强制性的。
  • 内容（Content）： 战争与和平 是元素的内容。内容可以是简单的文本，也可以是……更多的元素！正是这种嵌套赋予了 XML 结构。

元素也可以有属性（attributes），它们是存在于开始标签内部的一些元数据。

<book language="en">
  <title>War and Peace</title>
  <author>Leo Tolstoy</author>
</book>

这里，language="en" 是 book 元素的一个属性。它提供了关于元素本身的额外信息，而不是其主要内容的一部分。使用属性还是子元素是开发者之间经典的口水战，但一个好的经验法则是：如果它描述的是内容本身，就用元素；如果它描述的是容器的特性，就用属性。

树形结构（DOM）

当计算机解析一个 XML 文件时，它看到的不是一堵文本墙，而是一棵树。这种逻辑结构被称为文档对象模型（Document Object Model），或 DOM。

把它想象成一棵家族树：

  • 在最顶层，永远有且只有一个根元素（在我们的例子中是 <book>）。一个 XML 文档不能有两个根。
  • 其他每个元素都是树上的一个节点（node）。
  • 在一个元素内部的元素是子节点（child nodes）（<title> 是 <book> 的子节点）。
  • 包含元素的元素是父节点（parent node）（<book> 是 <title> 和 <author> 的父节点）。
  • 处于同一级别的元素是兄弟节点（sibling nodes）（<title> 和 <author> 是兄弟节点）。

将你的 XML 想象成一棵树，是理解如何导航和查询它的关键。你可以请求解析器“在 book 元素内部找到 author 元素”，它就知道如何沿着树走到那里。

规则：格式良好 vs. 有效

这就是 XML 以其严格著称的地方。它有两层“正确性”标准。

1. 格式良好（Well-Formed）的 XML： 这是绝对的最低要求。就像语法必须正确一样。

  • 必须有且只有一个根元素。
  • 每个开始标签都必须有一个匹配的结束标签。
  • 标签是区分大小写的：<Book> 和 <book> 不是一回事。
  • 元素必须正确嵌套。<b><i>text</i></b> 是正确的；<b><i>text</b></i> 简直是场灾难。
  • 属性值必须放在引号（" 或 '）里。

如果一个 XML 文档不是“格式良好”的，任何解析器都会立即抛出错误并罢工。绝不含糊。

2. 有效（Valid）的 XML： 这是更高一级的要求。如果一个 XML 文档是“格式良好”的，并且它遵循一套预定义的规则，即 schema，那么它就是“有效”的。

Schema 就像一份蓝图或合同。它是一个单独的文件（通常是 .xsd 或 .dtd），定义了如下内容：

  • 允许哪些元素？
  • 它们必须以什么顺序出现？
  • 哪些元素是必需的，哪些是可选的？
  • 一个元素可以有哪些属性？
  • 一个元素的内容应该是数字、字符串还是日期？

例如，我们书本示例的 schema 可能会规定：“每个 <book> 元素必须有一个 <title> 和至少一个 <author>。它可以有一个 language 属性。<price> 元素如果存在，必须包含一个正数。”

这就是 XML 的超能力。它允许两个系统（例如，买方和卖方）就一份刚性数据合同达成一致。任何违反合同的数据都会被自动拒绝，从而避免了无数的 bug 和误解。

真实世界的案例

那个不容有失的银行 API

一家大银行正在为一个系统开发功能，让大公司客户能够自动提交支付指令。我们说的是每笔交易数百万美元的级别，错误是绝对不容许的。一个丢失的货币符号或错位的小数点都可能带来灾难性后果。该团队选择了带有严格 XML Schema Definition (XSD) 的 XML。在核心银行系统处理一条支付指令之前，它会先根据 schema 进行验证。如果客户发送了 <amount>100,000</amount> 而不是 <amount>100000.00</amount>，或者 <currency>usd</currency> 而不是 <currency>USD</currency>，API 会立即拒绝它，并返回一个清晰的错误，指出违反了 schema 的哪条规则。 启示： 对于那些模糊性可能导致毁灭性代价的关键任务数据交换，经过验证的 XML 的严格性是一个特性，而不是一个 bug。

原来只是文本的矢量图

一个 Web 开发者需要为一个新网站设计一个复杂的 logo。设计师发给他一个 .svg 文件。这位开发者出于好奇，用文本编辑器打开了文件，惊讶地发现它并不是一坨二进制像素数据。它居然是 XML！像 <svg>、<path> 和 <circle> 这样的标签描述了形状、颜色和坐标。他意识到，他甚至不需要打开图形软件，只需在 XML 中查找和替换属性值，就能以编程方式更改 logo 的颜色。他甚至通过用 JavaScript 操作 XML 节点来为它制作动画。 启示： 你日常使用的许多强大的文件格式，如 SVG（可缩放矢量图形），实际上是 XML 的特定方言，这使得它们可以被检查、编辑和编写脚本。

远古时代的配置怪兽

一位新手程序员接到了一个任务，要修复一个有 15 年历史的企业级 Java 应用的 bug。问题的根源在配置里。让他惊恐的是，配置文件不是一个简单的文本文件，而是一个名为 config.xml 的、足足有 25000 行的 XML 文件。它是一个乱七八糟、没有缩进的烂摊子。想直接读它是不可能的。但当他把它加载到一个 XML 查看器中时，奇迹发生了。工具立即格式化了它，添加了颜色高亮，并让他可以折叠巨大的树节点。他可以搜索到相关的部分（<databaseConnectionPool>），看到相关设置的整个分支，并立刻发现了一个服务器名称中的拼写错误。 启示： XML 可能极其冗长，但当使用合适的工具查看时，其固有的树形结构即使是那些复杂到变态的文件也能变得易于管理。

常见错误和陷阱

  • 把它和 HTML 搞混。 它们看起来像表兄弟，但职责不同。HTML 用于表现（东西看起来怎么样）。XML 用于数据描述（东西是什么）。你的浏览器会原谅草率的 HTML；XML 解析器则不会原谅草率的 XML。
  • 纠结于用属性还是用元素。 新手常常纠结于一块数据应该是属性（<book isbn="123">）还是子元素（<book><isbn>123</isbn></book>）。没有唯一的正确答案，但一个常见的准则是：元素包含内容，而属性包含关于该内容的元数据。别太纠结，但要保持一致。
  • 试图用正则表达式解析它。 别。千万别。对于简单情况这似乎很诱人，但由于 XML 是嵌套的、递归的结构，一个简单的正则表达式在任何非平凡的文件上都会惨败。这是个经典的程序员恐怖故事。请务必使用你所选语言的专用 XML 解析库。
  • 忘记它区分大小写。 如果你的 schema 期望的是 <name>，发送 <Name> 将导致验证错误。这常常让那些从不那么挑剔的格式转过来的开发者栽跟头。
  • 忽略命名空间。 在混合了不同词汇的大型 XML 文档中（例如，混合了 SVG 和 XSLT），你会看到像 <xsl:template> 或 <svg:path> 这样的标签。那个 xsl: 部分就是命名空间，用于防止两种词汇都恰好有一个名为 <template> 的标签时发生冲突。它们可能很头疼，但对于复杂的文档来说至关重要。

为什么你应该关注它

你可能不会在启动一个新项目时，把 XML 作为简单 API 的首选（在这种情况下，JSON 通常因其简洁而胜出）。但你百分之百会遇到 XML。你应该在以下情况中想到 XML：

  • 你在与老旧的企业级系统集成，特别是那些使用 SOAP 或 WSDL 的系统。
  • 你需要在两方之间定义一个坚如磐石、不可破坏的数据契约（使用 XSD）。
  • 你正在处理以文档为中心的数据，如 RSS/Atom feed、Office 文档（OOXML）或矢量图形（SVG）。
  • 你在配置 Java 生态系统中的工具（如 Maven 或 Ant）或 .NET。
  • 你收到了一个以 .xml, .svg, .rss, .atom, 或 .plist 结尾的文件，需要理解它的结构，而不仅仅是它的内容。

了解 XML 的基础知识，就像了解化油器的工作原理一样。你可能开的是一辆现代的电喷汽车，但这些知识能让你对引擎有更深的理解，并且当你面对一辆老爷车时，能让你成为一个更出色的修理工。

深入了解

理论搞定，动手试试吧——100% 在你的浏览器中运行。

试用工具: XML 查看器