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
支持SAX的解析器及API
编辑参考
编辑- 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