XML 格式化工具

一个基于正则表达式构建的格式化工具——在每个 `<` 前插入换行,根据打开标签的累计数量来缩进——在简单的手写 XML 上表现还算过得去,但在真实世界的文档上会因为一些容易被忽视、直到它们破坏了文件才被发现的原因而失败。一个 CDATA 区块,写成 `<![CDATA[...]]>`,存在的目的正是为了容纳可能本身就包含看起来像标签的字符的任意文本,而一个扫描 `<` 的正则表达式没有办法知道应该忽略这两个标记之间的所有内容,而不是把里面的内容当作结构来处理。注释带有同样的风险,属性值的情况更糟:像 `note="a > b"` 这样的属性包含一个字面的 `>` 字符,一个简单的扫描器可能把它误认为是标签的结尾,在错误的位置悄悄截断了它。

正确地格式化 XML,意味着扫描器必须先识别出这些特殊区域——CDATA 区块、注释、处理指令、DOCTYPE 声明,以及带引号的属性值——然后才去寻找任何看起来像标签结构的内容,这样它们的内容才会被逐字节原样带过,而不是被重新解读成标记。

这个工具检查每一个标签是否被正确闭合、正确嵌套——也就是让一份文档成为"格式良好"XML 的那些结构规则——并在检查失败时报告具体是哪个标签不匹配或未闭合。它不做的,是对照 DTD 或 XML Schema(XSD)校验这份文档,那还会额外检查具体的元素、属性及其值是否符合某个特定文档类型的规则——一个必需的属性是否存在,一个元素是否出现在正确的上下文里,一个值是否匹配预期的数据类型。那是一项真正不同、也更繁复的检查,需要 schema 文档本身作为额外的输入,而不是一个通用格式化工具单靠 XML 本身就能推断出来的。

严格的 XHTML 是合法的 XML,在这里能被正确格式化,但普通的真实世界 HTML 不是,原因写在 HTML 规范本身里:像 `<br>` 和 `<img>` 这样的空元素永远不会闭合、也根本没有闭合标签,有几个标签的闭合标签是可选的、浏览器会自动推断,而且浏览器能容忍严格 XML 解析会直接拒绝的畸形嵌套。把一个严格的 XML 格式化工具用在典型的 HTML 上,会在每一个格式良好、完全正常的页面上报错,这正是为什么 HTML 需要一个围绕真正的 HTML 解析器构建的独立格式化工具,理解这些 HTML 专属的规则,而不是把文档当作严格 XML 处理。

JSON 已经取代 XML,成为新 Web API 的默认选择,但大量基础设施是在这次转变之前建成的,至今仍在使用 XML:SOAP Web 服务、RSS 和 Atom 订阅源、SVG 图像(它们本身就是 XML)、Office 文档格式的内部结构,以及一长串早于 JSON 流行起来的企业系统和配置格式。任何需要和这些较老或更正式的系统对接的人,依然需要读取、调试和生成格式良好的 XML,这正是一个专门的 XML 格式化工具即使在 XML 从新 API 设计中逐渐淡出之后,依然持续服务的那群用户。