XML的操作（一）

Java提供了两种xml解析器的方式，一种dom，一种sax，这个大家基本上都知道，实际上这两种方式，jdk提供了默认的实现，同时apache也提供了更高效更简单的实现，同时目前也出现了新的xml解析方式

XML Pull Parser，据说这个很高效，我会在后面把这里提到的都作出应用实现，留个纪念，

 

Dennis Sosnoski 写道

DOM

DOM（“文档对象模型”）是用与平台和语言无关的方式表示 XML 文档的官方 W3C 标准。对于任何 Java 特定的模型，它是很好的对照。为了值得与 DOM 标准分开，Java 特定模型应该提供比 Java DOM 实现更优越的性能和／或易用性的优势。

DOM 定义充分利用了 XML 文档不同组件的接口和继承性。这为开发者带来了将公共接口用于几个不同类型组件的优势，但是同时增加了 API 的复杂性。因为 DOM 是与语言无关的，所以接口不需要利用公共 Java 组件，例如，Collections 类。

本文涉及两个 DOM 实现：Crimson 和 Xerces Java。Crimson 是基于 Sun Project X 解析器的 Apache 项目。它合并一个包含 DTD 支持的完整验证解析器。可以通过 SAX2 接口访问该解析器，并且 DOM 实现可以与其它 SAX2 解析器一起工作。Crimson 是在 Apache 许可证下发布的开放源码。用于性能比较的版本是 Crimson 1.1.1（jar 文件大小是 0.2MB），它包含有用于从文本文件的 DOM 构建的 SAX2 解析器。

另一个测试的 DOM 实现，即 Xerces Java 是另一个 Apache 项目。初始时，Xerces 基于 IBM Java 解析器（通常称为 XML4J）。（当前还处于早期 beta 测试版的重新开发的 Xerces Java 2 将最终继承它。当前版本有时称为 Xerces Java 1。）如同使用 Crimson 一样，可以通过 SAX2 接口和 DOM 来访问 Xerces 解析器。然而，Xerces 不提供将 Xerces DOM 与不同的 SAX2 解析器一起使用的任何方法。Xerces Java 包含对 DTD 和 XML Schema 的验证支持（仅带有对 Schema 支持的最小限制）。

Xerces Java 还支持 DOM 的延迟节点扩展方式（请参考本文中的 延迟 Xerces或 Xerces def.），其中文档组件初始时是以压缩格式表示的，仅当使用时才将它扩展成完整的 DOM 表示。这种方式的用意是允许更快的解析并降低内存的使用，尤其对于那些可能仅使用部分输入文档的应用程序。与 Crimson 类似，Xerces 是在 Apache 许可证下发布的开放源码。用于性能比较的版本是 Xerces 1.4.2（jar 文件大小是 1.8MB）。

JDOM

JDOM 的目的是成为 Java 特定文档模型，它简化与 XML 的交互并且比使用 DOM 实现更快。由于是第一个 Java 特定模型，JDOM 一直得到大力推广和促进。正在考虑通过“Java 规范请求 JSR-102”将它最终用作“Java 标准扩展”。虽然实际将采用的格式仍在开发中，还是对两个 beta 测试版的 JDOM API 做了很大的更改，。从 2000 年初就已经开始了 JDOM 开发。

JDOM 与 DOM 主要有两方面不同。首先，JDOM 仅使用具体类而不使用接口。这在某些方面简化了 API，但是也限制了灵活性。第二，API 大量使用了 Collections 类，简化了那些已经熟悉这些类的 Java 开发者的使用。

JDOM 文档声明其目的是“使用 20%（或更少）的精力解决 80%（或更多）Java/XML 问题”（根据学习曲线假定为 20%）。JDOM 对于大多数 Java/XML 应用程序来说当然是有用的，并且大多数开发者发现 API 比 DOM 容易理解得多。JDOM 还包括对程序行为的相当广泛检查以防止用户做任何在 XML 中无意义的事。然而，它仍需要您充分理解 XML 以便做一些超出基本的工作（或者甚至理解某些情况下的错误）。这也许是比学习 DOM 或 JDOM 接口都更有意义的工作。

JDOM 自身不包含解析器。它通常使用 SAX2 解析器来解析和验证输入 XML 文档（尽管它还可以将以前构造的 DOM 表示作为输入）。它包含一些转换器以将 JDOM 表示输出成 SAX2 事件流、DOM 模型或 XML 文本文档。JDOM 是在 Apache 许可证变体下发布的开放源码。用于性能比较的版本是 JDOM Beta 0.7（jar 文件大小是 0.1MB）它带有用于从文本文件构建 JDOM 表示的 Crimson SAX2 解析器。

dom4j

虽然 dom4j 代表了完全独立的开发结果，但最初，它是 JDOM 的一种智能分支。它合并了许多超出基本 XML 文档表示的功能，包括集成的 XPath 支持、XML Schema 支持（当前为 alpha 格式）以及用于大文档或流化文档的基于事件的处理。它还提供了构建文档表示的选项，它通过 dom4j API 和标准 DOM 接口具有并行访问功能。从 2000 下半年开始，它就一直处于开发之中，保留了最近发行版之间的现有 API。

为支持所有这些功能，dom4j 使用接口和抽象基本类方法。dom4j 大量使用了 API 中的 Collections 类，但是在许多情况下，它还提供一些替代方法以允许更好的性能或更直接的编码方法。直接好处是，虽然 dom4j 付出了更复杂的 API 的代价，但是它提供了比 JDOM 大得多的灵活性。

在添加灵活性、XPath 集成和对大文档处理的目标时，dom4j 的目标与 JDOM 是一样的：针对 Java 开发者的易用性和直观操作。它还致力于成为比 JDOM 更完整的解决方案，实现在本质上处理所有 Java/XML 问题的目标。在完成该目标时，它比 JDOM 更少强调防止不正确的应用程序行为。

dom4j 使用相同方法作为 JDOM 输出，这依靠 SAX2 解析器输入处理，依靠转换器将输出处理成 SAX2 事件流、DOM 模型或 XML 文本文档。dom4j 是在 BSD 样式许可证下发布的开放源码，该许可证本质上等价于 Apache 样式许可证。用于性能比较的版本是 dom4j 0.9（jar 文件大小是 0.4MB），带有用于从文本文件构建表示的受绑定 AElfred SAX2 解析器（由于 SAX2 选项设置，测试文件之一无法由 dom4j 使用用于 JDOM 测试的同一 Crimson SAX2 解析器来处理）。

XML Pull Parser

XML Pull Parser (XPP）是最近开发的，它演示了 XML 解析的不同方法。与 EXML 一样，XPP 只能适当支持 XML 文档的子集并且不提供验证的任何支持。它同样具有尺寸小的优势。这种优势再与拉回解析器方法结合，使它成为该比较中的良好替换项。

XPP 几乎独占地使用接口，但是它仅使用所有类中的一小部分。和 EXML 一样，XPP 避免使用 API 中的 Collections 类。总的来说，它是本文中最简单的文档模型 API。

将 XPP 限制成 XML 文档子集的局限性是它不支持文档中的实体、注释或处理指示信息。XPP 创建仅包含元素、属性（包括“名称空间”）和内容文本的文档结构。这对于某些类型的应用程序来说是一种非常严格的限制。但是通常它对性能的影响比 EXML 空白处理对性能的影响小。在本文中我仅使用了一个与 XPP 不兼容的测试文件，并且在带有注释的图表中显示了 XPP 结果，该注释不包含该文件。

XPP 中的拉回解析器支持（本文中称为 XPP 拉回）通过将解析实际上推迟到访问文档的一个组件时才进行，然后按照构造那个组件的需要对文档进行解析。该技术想实现允许非常快速的文档显示或分类应用，尤其在需要转发或除去（而不是对文档进行完全解析和处理）文档时。该方法的使用是可选的，如果以非拉回型方式使用 XPP，它对整个文档进行解析并且同时地构建完整的表示。

与 EXML 一样，XPP 使用依据文本文档构建文档表示的集成语法解析器，并且除了通过文本方式外，它不提供从 DOM（或 SAX2）转换或转换成 SAX2（或 DOM）事件流的任何方式。XPP 是具有 Apache 样式许可证的开放源代码。用于性能比较的版本是 PullParser 2.0.1 Beta 8（jar 文件大小是 0.04MB）。