XML处理器（XML Processor）是所有XML应用的基础组件，它的职责是读取XML文档，检查文档是否满足格式规范，然后把文档内容以某种形式交给上层应用程序使用。很多人天天和XML打交道，却从没认真想过这个中间环节到底发生了什么。简单来说，XML处理器就是介于XML文档和应用程序之间的一座桥梁，它把纯文本形式的标记语言转换成程序能够理解和操作的数据结构。这座桥怎么搭、用什么材料搭、搭完之后长什么样，就是本文要讲清楚的内容。
XML处理器的整体工作流程：从字节流到数据结构
一份XML文档在磁盘上只是一串字节，处理器要做的第一件事是把它读进来并正确解码。XML规范允许文档通过XML声明指定编码方式，比如<?xml version="1.0" encoding="UTF-8"?>。处理器会先读取文件头部的前几个字节来判断编码（比如UTF-8的BOM标志EF BB BF，或UTF-16的FE FF），这个过程发生在正式解析之前，因为只有确定了编码，后续的字符才有意义。
编码确定后，处理器进入词法分析阶段。词法分析器把字符流切分成一个个有意义的记号（Token）：开始标签、结束标签、属性名、属性值、文本内容、注释、处理指令、CDATA段落等等。比如遇到<book>，词法分析器识别出这是一个元素开始标签，标签名为book；遇到id="101"，识别出这是一个属性及其取值。这个阶段处理器非常较真，任何细微的不规范都会被记录下来，比如属性值没有加引号、标签名包含非法字符等。
词法分析之后是语法校验阶段。处理器检查这些记号的排列是否符合XML规范定义的语法规则：开始标签和结束标签是否配对、元素嵌套是否正确、文档是否有且仅有一个根元素、属性是否重复等等。要注意的是，语法校验和有效性校验是两回事：前者检查的是XML格式规范（well-formedness），任何XML处理器都必须做；后者检查的是文档是否符合DTD或XML Schema定义的约束（validity），只有验证式处理器才做。一个文档可以格式良好但不有效，这在实际开发中是最常见的困惑点之一。
DOM与SAX：两种解析模型的底层实现差异
解析完成后，处理器需要把结果交给应用程序，这里就分化出两大流派：DOM（Document Object Model）和SAX（Simple API for XML）。两者的根本区别在于数据交付方式：DOM一次性把整个文档构建成一棵驻留在内存中的对象树，应用程序可以随意遍历、修改；SAX则是事件驱动的流式处理，文档从头读到尾，遇到什么就报告什么，不会在内存里保留完整文档。
DOM处理器内部维护着一个节点工厂。解析器每识别出一个元素，就创建一个Element节点对象；识别出文本，就创建一个Text节点；识别出属性，就创建Attr节点并挂到对应元素上。所有节点通过父子引用连接成树。以Java中的实现为例，代码大致是这样的：
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(new File("books.xml"));
// 获取根元素
Element root = doc.getDocumentElement();
// 遍历所有 book 节点
NodeList list = root.getElementsByTagName("book");
for (int i = 0; i < list.getLength(); i++) {
Element book = (Element) list.item(i);
String id = book.getAttribute("id");
String title = book.getElementsByTagName("title").item(0).getTextContent();
System.out.println(id + " - " + title);
}
SAX处理器的实现思路完全不同。它基于回调机制：应用程序向处理器注册一个事件处理器（Handler），解析过程中处理器依次触发startElement、characters、endElement等回调方法。文档读完后回调也就结束了，内存里什么都不留。下面是一个典型的SAX用法：
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.parse(new File("books.xml"), new DefaultHandler() {
@Override
public void startElement(String uri, String localName, String qName, Attributes attrs) {
// 每遇到一个开始标签，此方法被调用一次
if (qName.equals("book")) {
System.out.println("书ID: " + attrs.getValue("id"));
}
}
@Override
public void characters(char[] ch, int start, int length) {
// 文本内容可能分多次回调返回，不能假设一次到位
System.out.print(new String(ch, start, length));
}
});
两者的取舍很清晰：DOM方便随机访问和修改，但内存开销与文档大小成正比，解析一个几百MB的文件可能直接把堆内存撑爆；SAX内存占用恒定，解析速度也快，适合大文件和只读场景，但程序只能顺序处理，无法回头，修改文档结构更是无从谈起。此外还有Pull解析（常见于Android开发）和StAX（JDK自带的拉式解析），它们本质上和SAX同属流式模型，区别在于控制权：SAX是解析器推着应用程序走，Pull和StAX是应用程序主动拉取下一个事件，写起来更直观。
命名空间、实体展开与常见解析错误
现代XML应用几乎都离不开命名空间（Namespace）。命名空间通过xmlns声明引入，处理器在解析时会把带前缀的标签名（如ns:book）解析成URI加本地名的组合，也就是SAX回调里那两个参数uri和localName的由来。这里有个历史遗留坑：如果处理器没有开启命名空间感知（namespace-aware），所有回调只会给出带前缀的限定名qName，前缀冲突就会造成数据混乱。使用DOM时，getElementsByTagName和getElementsByTagNameNS的行为差异也源于此，前者按限定名匹配，后者按命名空间URI加本地名匹配。
实体展开是另一个容易被忽视的环节。XML允许通过DTD定义内部实体，比如<!ENTITY hello "你好">，处理器在解析时遇到&hello;引用就会替换成实体内容。这个机制被滥用就成了著名的 Billion Laughs 攻击：恶意文档定义层层嵌套的实体，展开后体积呈指数级膨胀，直接耗尽服务器内存。成熟的处理器默认限制了实体展开深度和总数，做外部输入解析时一定要确认这些防护是开启的，并且禁用外部实体加载。
实际开发中最常见的解析错误大概有这么几类。第一类是格式错误，比如结束标签与开始标签不匹配、根元素不唯一、非法字符直接出现（比如裸写的&没有转义成&），这类错误会导致处理器直接抛出致命错误并停止解析。第二类是编码问题，文件实际编码和声明的编码不一致，就会出现乱码或解析失败，特别是Windows下编辑器默认保存GBK而声明UTF-8的情况。第三类是DTD或Schema校验失败，这类属于有效性错误，验证式处理器会报告但不一定中断，取决于错误处理器的配置。遇到问题时，先用格式化工具检查well-formedness，再核对编码声明，最后检查Schema约束，按这个顺序排查效率最高。
理解了XML处理器的工作原理，再去看XPath查询、XSLT转换、SOAP协议这些上层技术，你会发现它们都是建立在处理器输出的数据结构之上的应用。选型时记住一个原则：小文件、需要频繁修改选DOM；大文件、顺序读取选SAX或StAX；对外部来源的文档，永远做好实体限制和输入校验。这些原则放在JSON解析的场景里同样适用，底层逻辑是相通的。