在用DOM耗费较长时间解析XML文件以后，你可能注意到在用DOM处理大型文件时其性能下降的非常厉害。这个问题是由DOM的树结构所造成的：这种结构占用的内存较多，而且DOM必须在解析文件之前把整个文档装入内存。在采用DOM之后性能受到严重影响的情况下，你不妨考虑使用Simple API for XML（SAX）。在这篇文章中，我们就为你介绍SAX API，同时提出若干采用不同语言实现的SAX链接。
SAX最初是由David Megginson采用Java语言开发的，之后SAX很快在Java开发者中流行起来。SAN项目现在负责管理其原始API的开发工作，这是一种公开的、开放源代码软件。不同于其他大多数XML标准的是，SAX没有语言开发商必须遵守的标准SAX参考版本。因此，SAX的不同实现可能采用区别很大的接口。不过，所有的这些实现至少有一个特性是完全一样的，这就是事件驱动。
事件驱动的文档解析
在SAX解析器装载XML文件时，它遍历文件文档并在其主机应用程序中产生事件（经由回调函数、指派函数或者任何可调用平台完成这一功能）表示这一过程。这样，编写SAX应用程序就如同采用最现代的工具箱编写GUI程序。
大多数SAX实现都会产生以下若干类型的事件：
在文档的开始和结束时触发文档处理事件。
在文档内每一XML元素接受解析的前后触发元素事件。任何元数据通常都由单独的事件交付。
在处理文档的DTD或Schema时产生DTD或Schema事件。
错误事件用来通知主机应用程序解析错误。
显而易见，在处理文档时你最关心的就是元素事件了。通常，SAX解析器会向你的主机应用程序提供包含元素信息的事件参数；在最低程度下也会提供元素的名字。具体取决于你的特定实现，可以定义不同类型的元素事件代表不同类型元素的处理。例如，注释元素（它可能包含主机应用程序的处理指令）就经常在接受处理时产生特殊的事件。
下面我们就举个比较基本的例子。假如你把程序清单A中的XML文件装入了SAX解析器，那么你可能会在你的主机应用程序中收到以下事件通知：
Document Start
Element Start "catalog"
Element Start "book"
Element Start "author"
Data "Adams, Lamont"
Element End "author"
Element Start "title"
Data "Lamont’s First Book"
Element End "title"
Element End "book"
Element End "catalog"
Document End
SAX对DOM
在什么情况下采用这种或者那种API并没有确定的严格规则；具体情况具体分析。所有的SAX处理都在一次遍历中完成的；因此，在解析同等大小的文档时SAX通常会相比DOM提供更好的性能（因为DOM必须遍历树结构）。此外，与DOM是比，因为在给定的时间之内只需要XML文档的一部分装入内存，所以SAX 通常在处理更大文件时内存的利用效率也来得更高（我已经提到过，DOM在开始解析文档之前必须把全部XML文档装入内存）。
然而，SAX也不是没有缺点。SAX应用程序一般都比较长，程序中充斥着大量的if/else结构用来确定处理特定元素时所采用的运动。同样的，处理多个XML元素之间散布的数据结构也很成问题，因为解析事件之间必须保存中间数据。最后， SAX应用程序的事件处理结构一般意味着SAX应用程序是针对特定文件结构定制构建的，而DOM应用程序则更具一般性。
从哪里获得SAX
相当多的SAX实现都可以从网上获得。不幸的是，它们之间稍有不同，但其大多数都提供了相应的帮助文档。以下是一些流行的SAX实现：
当然，最“标准”的Java版本在SAX项目网站。
Microsoft XML Core Services 4.0 库包括了采用COM的SAX解析器，对VB程序员特别有用（或开发Windows的程序员）。
支持Perl的binding of SAX 2.0。
SAX in C++ 是一套用在SAX和C++应用程序中的C++接口和封装类。
许多编程语言，比如Python和所有的.NET语言都在其核心功能中内建支持SAX。
