详解XML各种解析方法

对 XML 词汇表进行的优化通常针对的是存储和数据传输效率，而不是处理，因而应用程序可能需要对数据进行预处理，比方说，在开始真正的处理之前，先计算部分和或者 合并其他来源的数据。很多情况下，在处理之前必须将数据从 XML 对象模型复制到应用程序专用的对象模型或者数据库。

因为这种对象模型是通用的，包含很多应用程序并不需要的对象之间的引用(比如，从子元素到父元素的反向引用)。这些引用进一步增加了内存消耗。

在桌面上处理小型文档这可能不是大问题，但是在其他环境中，比如服务器上，对象模型固有的低效率是不可接受的。

第二种方法

第二种选择是事件API，比如 SAX。这个概念是上述对象模型方式的一种反映。只不过这种方法不根据 XML 语法定义通用的数据模型，其解析器依赖应用程序程序员建立定制的数据模型。

因此解析器可以做得更小，因为只需要传递最少量的信息。更重要的是，和一个型号打天下的对象模型（不管对象模型多么好）相比总的效率更高，程序员可以根据应用程序的需要定制对象模型。

它的优点很明显：

统计应用程序或总结信息的任何应用程序都可以从中获益，因为它们的数据模型只需计算总计而无需复制整个文档。

类似的，即使动态处理文档的应用程序（比如把文档加载到数据库中）不需处理或者只需少量处理，也可从中受益，因为根本不需要存储数据。

由于减少了内存需求，事件 API 可以处理任意大小的文档，包括大小超过可用内存的文档。基于同样的原因，这类 API 也非常适合多个进程并发执行和共享内存的服务器。

效率的代价是简单性的损失。事件 API 一向以难用著称，因为应用程序员要负责更多的操作。虽然短期看来如此，但根据我的经验，从中期和长期来看，效率上的改进足以抵消略微增加的复杂度。

流式API 有两种形式：推式和拉式。从历史上看，推式方法更加流行，因为这正是 SAX 采用的模型。推式方法正在实现标准化，很快将作为 StAX 集成到 Java 平台中。

两者有什么区别呢？区别在于由谁控制读循环。和读取文件的任何软件一样，解析器也是围绕着读循环（读入文件的循环）创建的。

在推模式（SAX）下，解析器控制循环。实际上应用程序调用解析器的时候，在文件结束之前控制权不会返回给应用程序。前面已经提到，解析器回调应用程序以建立数据模型，解析器处于控制地位。

在拉模式下，应用程序控制循环。循环中应用程序负责反复调用解析器，直到文件结束。

推模式最适合边读入边处理 XML 文档，比如读入 RSS 提要并显示为 HTML 网页。对于使用 XML 存储数据的多数应用程序来说，“读文档”用对解析器的一次调用实现最方便。

拉模式更适合于处理不同 XML 词汇表的文档。这类应用程序通常需要嗅探输入（读入前几行）以根据词汇表决定调用子例程。

对于控制解析器的应用程序而言，一次循环是必要的，因为应用程序很容易在嗅探前面几行之后停止读入。

第三种方法

如果不提到另一种选择，即 XML 编组库形式的解析，如 Castor，本文就不完整。该方法介于对象模型和事件方法之间。

其思想是从 XML Schema 生成一个对象模型而不是通用模型（如 DOM），解析器生成更加针对所用词汇表的数据模型。比方说，如果词汇表处理的是发货单，那么可以预料其中会包含发送方、接收方、日期、产品类别、产品标 识、单价和总价。DOM 将这些元素映射到一个一般性的元素类。编组库 为发送方、接收方、日期、产品类别、产品标识、单价、总价和文档中出现的其他元素创建专门的类。

从处理的是根据词汇表定制（与根据应用程序的需要定制可能相同，也可能不同）的而不是通用数据模型这方面来讲，编组库具备事件 API 的一些优点。

如何写入XML 呢？

解析器读取和解码 XML 文档，将其从磁盘上转到内存中。那么另一个方向上的移动该如何处理呢？如果应用程序需要将数据存储到 XML 文件中怎么办？

虽然我建议您避免使用特殊的例程解码 XML 文档，但是对于写入 XML 没有这样的疑虑。读的时候必须保证实现了所有的规则，包括一些隐晦之处。但是写入的时候，则可以实现一个小型的、可工作的词汇表子集。

但是多数对象模型 API 仍然承担了双重职责，除了读以外还要能将对象树写入磁盘。如果使用事件 API，就可以从数据结构生成写事件。