XML解析 DOM（文档对象模型）与 SAX（XML简易应用应用程序编程接口）
1．DOM
文档对象模型一词在We b浏览器领域并不陌生。窗口、文档和历史等对象都被认为是浏览器
对象模型的一部分。然而，任何做过We b开发的人都知道各种浏览器实现这些对象的方式不尽相
同。对于如何通过We b访问和操作文档结构这个问题，为了创建更加标准化的方法， W 3 C提出
了目前的W3C DOM规范。
W3C DOM是一种独立于语言和平台的定义，即：它定义了构成D O M的不同对象的定义，
却没有提供特定的实现，实际上，它能够用任何编程语言实现。例如，为了通过D O M访问传统
的数据存储，可以将D O M实现为传统数据访问功能之外的一层包装。利用D O M中的对象，开发
人员可以对文档进行读取、搜索、修改、添加和删除等操作。D O M为文档导航以及操作H T M L
和X M L文档的内容和结构提供了标准函数。
D O M提供了强大的接口集合，以简化对D O M节点树的操作。
，使用D O M有以下几点优越性：
• DOM能够保证正确的语法和格式正规性。
• DOM能够从语法中提取内容。
• DOM能够简化内部文档操作。
• DOM能够贴切地反映典型的层次数据库和关系数据库的结构。
1. DOM能够保证正确的语法和格式正规性
由于D O M将文本文件转化为抽象的节点树表示，因此能够完全避免无结束标记和不正确的
标记嵌套等问题。使用D O M操作X M L文档时，开发人员不必担心文档的文本表示—只需要关
注父子关系和相关的信息。另外， D O M能够避免文档中不正确的父子关系。例如，一个A t t r对
象永远也不能成为另一个A t t r对象的父对象。
2. DOM能够从语法中提取内容
由D O M创建的节点树是X M L文件内容的逻辑表示—它显示了文件提供的信息，以及它们
之间的关系，而不受限于X M L语法。例如，节点树蕴含的信息可以用于更新关系数据库，或者
创建H T M L页面—开发人员不必纠缠于X M L语法规范。
3. DOM能够简化内部文档操作
就修改X M L文件的结构而言，使用D O M比使用传统的文件操作机制更加简单。正如我们在
前面的例子中所描述的，利用D O M在文档中增加元素非常简便。另外，你可以通过几条命令执
行全局性操作（例如：从文档中删除具有特定标记名称的所有元素），而不必采用繁琐的方法
—首先对文件进行扫描，然后删除相关的标记。
4. DOM能够贴切地反映典型的层次数据库和关系数据库的结构
D O M表示数据元素关系的方式非常类似于现代层次型和关系型数据库表示信息的方法。这
使得利用D O M在数据库和X M L文件之间移动信息变得相当简单。
大部分数据库都使用“雪花”结构表示层次型信息，数据库中的信息从中心“顶级”表向
外辐射，类似于车轮的车条（参见图5 - 3）。
图5-3
注意，每个客户可能有多张发票，而且每张发票可能包含多个行式项目。为了支持这种行
为，X M L允许我们包含一个子元素的多个拷贝。上图中的每个元素基本上都对应着一张表，每
张表都包含多列（这些列在X M L中作为属性出现）。
上图的结构等价于以下X M L文件：
2．SAX
S A X的接口风格完全不同于文档对象模型。文档对象模型应用程序通过遵循内存中的对象
参照来要求文档中的内容；使用S A X ,解析器通过向应用程序报告解析事件流来告知应用程序文
档的内容。
S A X即X M L简易应用程序编程接口，全称是扩展标记语言简易应用程序编程接口。
从程序中读取X M L文档基本上有三种方式：
• 把X M L只当做一个文件读取，然后自己挑选出其中的标签。这是黑客们的方法，我们不推
荐这种方式。你很快会发现处理所有的特殊情况（包括不同的字符编码，例外约定，内部
和外部实体，缺省属性等）比想象的困难得多；你可能不能够正确地处理所有的特殊情况，
这样你的程序会接收到一个非常规范的X M L文档，却不能正确地处理它。要避免这种想法：
X M L解析器似乎并不昂贵（大多数是免费的）。
• 可以用解析器分析文档并在内存里创建对文档内容树状的表达方式：解析器将输出传递给
文档对象模型，即D O M。这样程序可以从树的顶部开始遍历，按照从一个树单元到另一
个单元的引用，从而找到需要的信息。
• 也可以用解析器读取文档，当解析器发现标签时告知程序它发现的标签。例如它会告知它
何时发现了一个开始标签，何时发现了一些特征数据，以及何时发现了一个结束标签。这
叫做事件驱动接口，因为解析器告知应用程序它遇到的有含义的事件。如果这正是你需要
的那种接口，可以使用S A X。
1. SAX 的优点
下面的部分简述了S A X接口最显著的一些优点。
(1) 可以解析任意大小的文件
因为S A X不需要把整个文件加载到内存，所以对内存的占用一般比D O M小得多，而且不随
着文件大小的增加而增加。当然D O M使用的实际内存数量要视解析器而定，但在大多数情况下
一个1 0 0 K b的文档至少要占用1 M b的内存。
但是有一点要注意：如果S A X应用程序自身在内存中创建文档的表达，它会占用和允许
解析器创建空间一样大小的内存。
(2) 适合创建自己的数据结构
应用程序可能会想用如书、作者以及出版者这样的高级对象而不是一些低级元素、属性和
处理指令来创建数据结构。这些“交易对象”可能只是和X M L文件内容有一点关系；例如它们
可能只是组合X M L文件和其他数据源的数据。在这种情况下，如果想在内存中创建面向应用的
数据结构，首先创建一个低级D O M结构然后毁坏它是很不合算的。可以仅在每个事件发生时处
理它，这样保证商务对象模型合理地增加变动。
(3) 适合小信息子集
如果仅对计算本周图书馆购进的书籍数量或确定它们的平均价s格感兴趣，那么把不需要的
全部数据和需要的少量数据一起读入内存是非常低效和不必要的。SAX 一个非常好的特点就是
可以非常容易地忽略不感兴趣的数据信息。
(4) 简单
如题所示， S A X非常易于使用。
(5) 快速
如果可以从经由文档的简单序列中获取你需要的信息， S A X几乎一定是最快的方法。
2. SAX 的缺点
在论述完其优点之后应该指出使用S A X时可能遇到的不足之处。
(1) 不能对文档做随机存取
因为文档并不加载到内存，所以必须按照数据提交的次序进行处理。对于文档中包含许多
内部交叉引用如使用I D和I D R E F属性的情况，S A X使用起来会困难一些。
(2) 难以实现复杂的查询
复杂的查询对程序而言是非常凌乱的，因为必须自己维护含有你所需要保留信息的数据结
构，如当前元素祖先的属性。
(3) 不能使用文档类型定义（ D T D）
S A X 1 . 0不会告知D T D的任何内容。实际上D O M也不会告知太多内容什么，尽管有些提供商
已经扩展了D O M接口以支持这种功能。这对大多数应用程序来说并不是个问题： D T D主要是解
析器感兴趣的问题；而且在本章末尾可以看到这个问题在SAX 2.0中得到了解决。
(4) 不可获取词法信息
S A X的设计原理是它不提供词法信息。S A X设法告知文档作者想要说明什么，而不是让你
忙于研究他们说明方式的细节。例如：
第6章SAX 1.0: XML简易API使用147
下载
• 你不能查明原始文档中是否包含“& # x a ; " 或" & # 1 0或 ; ”它是否包含一个换行字符：所有这三
种情况以相同的方式报告给应用程序。
• 你不会被告知文档中的注释说明： S A X假设注释是为方便作者而不是读者设计的。
• 你不会得知属性书写的顺序：这被认为是无关紧要的。
只有当你考虑到以后可能会需要编辑文档，想按照文档原先书写的方式重新创建它时，这
些限制才会导致一些问题。例如你需要编写这样一个应用程序，它用来在完整无缺地保留文档
原有内容的基础上，从另外一个文档添加某些额外信息到原文档中。这样如果你随意改变了属
性的顺序或丢弃了所有的注释，原文档作者会不满意的。实际上，大多数限制和D O M是一样的，
尽管D O M的确在某些方面提供了稍多一些的信息：例如它保留了注释。此外，很多这样的限制
在SAX 2.0里得到改进；尽管没有完全解决，例如属性的顺序和分割符（单引号或双引号）的选
取一样仍然是个难题。
(5) SAX是只读的
D O M可以从X M L原文件中读取文档，也可以创建和修改内存中的文档。相比较而言， S A X
是用来读取X M L文档而不是书写文档。
实际结果是S A X接口可以很容易地和读取X M L文档一样书写文档。稍后可以看到，解析器
读取X M L文档时发送给应用程序的事件流同样可以被应用程序发送到文档生成器以创建文档。
(6) 当前的浏览器不支持S A X
尽管有许多支持S A X接口的X M L解析器。在编写本书时还没有一个主流的We b浏览器内置
X M L解析器以支持S A X接口。你当然可以把兼容S A X的解析器合成到一个Java applet程序中去，
但是从服务器下载a p p l e t的开销会使低速接入Internet 的用户失去耐心。实际上客户端X M L编程
可选择的接口是相当有限的。
一个简单的S A X应用程序的构成如图6 - 1所示。
