SAX
Simple API for XML（简称SAX）是个循序访问XML的解析器API。SAX提供一个机制从XML文档读取数据。它是除了文档对象模型（DOM）的另外一种流行选择。
使用SAX处理XML
实现SAX了的解析器拥有事件驱动式的API，并像流读取器那样工作。由用户定义回调函数，解析时，若发生事件的话会被调用。SAX事件包括：
- XML 文本 节点<!-- (Text nodes) -->
- XML 元素 节点<!-- (Element nodes) -->
- XML 处理指令<!-- (Processing Instructions) -->
- XML 注释<!-- (Comments) -->
事件在遇到任一XML特性时触发，以及遇到他们结尾时再次触发。XML属性也作为传给元素事件资料的一部分。
SAX运行时是单向的；解析过的资料无法在不重新开始的情况下再次读取。
定义
不像 DOM，对于SAX并没有「正式的」规格。Java对于SAX的实现被认为是一种规范，在其他语言的实现尝试遵循着该实现的进程，必要时根据语言差异而调整。
优点
SAX解析器在某些方面优于DOM风格解析器。SAX解析器的内存使用量一般远低于DOM解析器使用量。DOM解析器在任何处理开始之前，必须把整棵树放在内存，所以DOM解析器的内存使用量完全根据输入数据的大小。相对来说，SAX解析器的内存内容，是只基于XML文件的最大深度（XML树的最大深度）和单一XML项目上XML属性保存的最大数据。这两个总是比整颗解析树本身还小。
因为SAX事件驱动的本质，处理文档通常会比DOM风格的解析器快。内存访问耗时，所以DOM较大的内存使用也是一个性能议题。
因为SAX的本质，从磁盘串流读取是可行的。无法放入内存的XML文档只可能使用SAX解析器（或另外的串流XML解析器）来处理。
缺点
SAX事件驱动的模型对于XML解析很有用，但它确实有某些缺点。
某些种类的XML验证需要访问整份文档。例如，一个DTD IDREF属性需要文档内有项目使用指定字符串当成DTD ID属性。要在SAX解析器内验证，必须追踪每个之前遇过的ID和IDREF属性，检查是否有任何相符。更甚者，一个IDREF找不到对应的ID，用户只会在整份文档都解析完后才发现，若这种链接对于创建有效输出是重要的，那用在处理整份文档的时间只是浪费。
另外，某些XML处理能简单的访问文档。举例来说，XSLT及XPath需要能够随时访问已解析的XML树中的任何节点。 编辑者和浏览器同样也需要能够随时显示，修改和重新验证XML树。虽然一开始可能会使用SAX解析器来编辑建构XML树，但SAX整体上对于以上处理没有任何优化。
参见
其他XML处理技术
- 文档对象模型
- XSL Transformations (XSLT)
- Streaming Transformations for XML (STX)
- System Integrated Automation parser
参考
- David Brownell：SAX2, O'Reilly, ISBN 0-596-00237-8
- W. Scott Means，Michael A. Bodie：The Book of SAX, No Starch Press, ISBN 1-886411-77-8
