XML解析技术研究(一)

在我们了解XML之前，我们必须要先找到HTML的原罪问题，只有知道了HTML其中的缺陷才能更好的认识XML的作用。

HTML的原罪：

不能解决所有解释数据的问题。如影音文件或化学公式、音乐符号等其它型态的内容。

效能问题。如需要下载整份文件，才能开始对文件做搜寻的动作。

扩充性、弹性、易读性均不佳。

为了解决以上问题，专家们使用SGML精简制作，并依照HTML的发展经验，产生出一套使用上规则严谨，但是简单的描述数据语言：XML。 XML是在一个这样的背景下诞生的─是不是能有一个更中立的方式，让消费端自行决定要如何消化、呈现从服务端所提供的信息？而XML目的即在于提供一个对信息能够做精准描述的机制，借以弥补 HTML 太过于表现导向的特质。

XML（eXtensible Markup Language）即可扩展标记语言，它与HTML一样，都是SGML(Standard Generalized Markup Language，标准通用标记语言)。Xml是Internet环境中跨平台的，依赖于内容的技术，是当前处理结构化文档信息的有力工具。扩展标记语言XML是一种简单的数据存储语言，使用一系列简单的标记描述数据，而这些标记可以用方便的方式建立，虽然XML占用的空间比二进制数据要占用更多的空间，但XML极其简单易于掌握和使用。

XML与Access，Oracle和SQL Server等数据库不同，数据库提供了更强有力的数据存储和分析能力，例如：数据索引、排序、查找、相关一致性等，XML仅仅是展示数据。事实上XML 与其他数据表现形式最大的不同是：他极其简单。这是一个看上去有点琐细的优点，但正是这点使XML与众不同。

XML的简单使其易于在任何应用程序中读写数据，这使XML很快成为数据交换的唯一公共语言，虽然不同的应用软件也支持其它的数据交换格式，但不久之后他们都将支持XML，那就意味着程序可以更容易的与Windows、Mac OS，Linux以及其他平台下产生的信息结合，然后可以很容易加载XML数据到程序中并分析他，并以XML格式输出结果。

为了使得SGML显得用户友好，XML重新定义了SGML的一些内部值和参数，去掉了大量的很少用到的功能，这些繁杂的功能使得SGML在设计网站时显得复杂化。XML保留了SGML的结构化功能，这样就使得网站设计者可以定义自己的文档类型，XML同时也推出一种新型文档类型，使得开发者也可以不必定义文档类型。

上面讲到了仅仅是XML的定义和定义之外的一点对比。重新回来看XML，简单说，XML 就是一种数据的描述语言，虽然它是语言，但是通常情况下，它并不具备常见语言的基本功能——被计算机识别并运行。只有依靠另一种语言，来解释它，使它达到你想要的效果或被计算机所接受。

假如你是刚接触XML的新手，那么可能并无法从定义上是了解XML是什么。也许，你可以换个角度来认识XML是什么；从应用面来认识XML，从XML可以做些什么来认识它，这应该能比那更空洞的定义对你更有帮助。

XML应用面主要分为两种类型，文档型和数据型。下面介绍一下几种常见的XML应用：

1、自定义XML+XSLT=>HTML，最常见的文档型应用之一。XML存放整个文档的XML数据，然后XSLT将XML转换、解析，结合XSLT中的HTML标签，最终成为HTML，显示在浏览器上。典型的例子就是CSDN上的帖子。

2、XML作为微型数据库，这是最常见的数据型应用之一。我们利用相关的XML API（MSXML DOM、JAVA DOM等）对XML进行存取和查询。留言板的实现中，就经常可以看到用XML作为数据库。同时，这里要告诉一些新人，数据库和数据库系统，这两个概念是不同的。这里顺便提一下XML对数据库系统的影响。在新版本的传统数据库系统中，XML成为了一种数据类型。和“传统”相对的就是一种新形态的数据库，完全以XML相关技术为基础的数据库系统。目前比较知名的eXist。

3、作为信息传递的载体。为什么说是载体呢？因为这些应用虽然还是以XML为基本形态，但是都已经发展出具有特定意义的格式形态。最典型的就是WEB SERVICE，将数据包装成XML 来传递，但是这里的XML已经有了特定的规格，即SOAP。不过这里还不得不说AJAX，AJAX的应用中，相信也有一部分的应用是以自定义XML为数据，不过没有成为工业标准，这里不做详述。

4、应用程序的配置信息数据。最典型的就是J2EE配置WEB服务器时用的web.XML。这个应用估计是很容易理解的了。我们只要将需要的数据存入XML，然后在我们的应用程序运行载入，根据不同的数据，做相应的操作。这里其实和应用2，有点类似，所不同的在于，数据库中的数据变化是个常态，而配置信息往往是较为静态，缺少变化的。

5、其他一些文档的XML格式。如WORD、EXCEL等。

6、保存数据间的映射关系。如Hibernate。

这几种常见应用中，我们还可以根据其应用广泛程度，分为：自定义XML和特定意义XML。在1和2就是属于自定义XML的范畴；3至6则属于特定意义XML，或者说是XML的延伸。

总之，XML是一种抽象的语言，它不如传统的程序语言那么具体。

解读server.xml文件

Tomcat Server的结构图

该文件描述了如何启动Tomcat Server

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

元素名属性解释

server

port

指定一个端口，这个端口负责监听关闭tomcat

的请求

shutdown 指定向端口发送的命令字符串

service name

指定service 的名字 Connector(

表示客户端

和service 之

间的连接) port

指定服务器端要创建的端口号，并在这个断口监听来自客户端的请求 minProcessors

服务器启动时创建的处理请求的线程数 maxProcessors 最大可以创建的处理请求的线程数

enableLookups 如果为true ，则可以通过调用

request.getRemoteHost()进行DNS 查询来得到远程客户端的实际主机名，若为false 则不进行DNS 查询，而是返回其ip 地址

redirectPort 指定服务器正在处理http 请求时收到了一个

SSL 传输请求后重定向的端口号

acceptCount 指定当所有可以使用的处理请求的线程数都被

使用时，可以放到处理队列中的请求数，超过

这个数的请求将不予处理

connectionTimeout

指定超时的时间数(以毫秒为单位) Engine(表示

指定service

中的请求处

理机，接收和

处理来自

Connector 的

请求)

defaultHost 指定缺省的处理请求的主机名，它至少与其中的一个host 元素的name 属性值是一样的 Context(表

示一个web 应

用程序，通常

为WAR 文件，

关于WAR 的具

体信息见

servlet 规

范)

docBase 应用程序的路径或者是WAR 文件存放的路径 path 表示此web 应用程序的url 的前缀，

这样请求的url 为

http://localhost:8080/path/***

*

reloadable 这个属性非常重要，如果为true ，

则tomcat 会自动检测应用程序的

/WEB-INF/lib 和

/WEB-INF/classes 目录的变化，自动装载新的应用程序，我们可以在

不重起tomcat 的情况下改变应用程

序

host(表示一name 指定主机名

个虚拟主机)

appBase 应用程序基本目录，即存放应用程

序的目录

unpackWARs 如果为true，则tomcat会自动将

WAR文件解压，否则不解压，直接从

WAR文件中运行应用程序Logger(表示

日志，调试和错误信息) className

指定logger使用的类名，此类必须实现

org.apache.catalina.Logger 接口

prefix 指定log文件的前缀suffix 指定log文件的后缀

timestamp 如果为true，则log文件名中要加

入时间，如下

例:localhost_log.001-10-04.txt

Realm(表示

存放用户名，密码及role 的数据库) className

指定Realm使用的类名，此类必须实现

org.apache.catalina.Realm接口

Valve(功能与Logger差不多，其

prefix和suffix属性

解释和Logger 中的

一样) className

指定Valve使用的类名，如用

org.apache.catalina.valves.AccessLogValv

e类可以记录应用程序的访问信息

directory 指定log文件存放的位置

pattern 有两个值，common方式记录远程主机名或ip地址，用户名，日期，第一行请求的字符串，HTTP响应代码，发送的字节数。combined方式比common方式记录的值更多

元素

它代表整个容器,是Tomcat实例的顶层元素.由org.apache.catalina.Server接口来定义.它包含一个元素.并且它不能做为任何元素的子元素.

注意：一个“Server”自身不是一个“Container”（容器），因此在这里你

不可以定义诸如“Valves”或者“Loggers”子组件

-->

测试：

telnet localhost 8005

输入：SHUTDOWN

结果：关闭tomcat

1>className指定实现org.apache.catalina.Server接口的类.默认值为org.apache.catalina.core.StandardServer

2>port指定Tomcat监听shutdown命令端口.终止服务器运行时,必须在Tomcat服务器所在的机器上发出shutdown命令.该属性是必须的.

3>shutdown指定终止Tomcat服务器运行时,发给Tomcat服务器的shutdown监听端口的字符串.该属性必须设置

元素

该元素由org.apache.catalina.Service接口定义,它包含一个元素,以及一个或多个,这些Connector元素共享用同一个Engine元素

第一个处理所有直接由Tomcat服务器接收的web客户请求.

第二个处理所有由Apahce服务器转发过来的Web客户请求 .

1>className 指定实现org.apahce.catalina.Service接口的类.默认为org.apahce.catalina.core.StandardService

2>name定义Service的名字

元素

由Connector接口定义.元素代表与客户程序实际交互的给件,它负责接收客户请求,以及向客户返回响应结果.

connectionTimeout:定义建立客户连接超时的时间.如果为-1,表示不限制建立客户连接的时间

其它属性略

-->

第一个Connector元素定义了一个HTTP Connector,它通过8080端口接收HTTP请求;第二个Connector元素定义了一个JD Connector,它通过8009端口接收由其它服务器转发过来的请求.

元素

每个Service元素只能有一个Engine元素.处理在同一个中所有元素接收到的客户请求.由org.apahce.catalina.Engine接口定义.

1>className指定实现Engine接口的类,默认值为StandardEngine

2>defaultHost指定处理客户的默认主机名,在中的子元素中必须定义这一主机

3>name定义Engine的名字

在可以包含如下元素, , ,

元素

它由Host接口定义.一个Engine元素可以包含多个元素.每个的元素定义了一个虚拟主机.它包含了一个或多个Web应用.

注意：XML模式确认将不能与Xerces 2.2同工作。

-->

在元素中可以包含如下子元素

, , ,

元素

它由Context接口定义.是使用最频繁的元素.每个可以包含多个元素.每个web应用有唯一

的一个相对应的Context代表web应用自身.servlet容器为第一个web应用创建一个

Tomcat Server处理一个http请求的过程

假设来自客户的请求为：

http://localhost:8080/wsota/wsota_index.jsp

1) 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector 获得

2) Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应

3) Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host

4) Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host 处理，因为该Host被定义为该Engine的默认主机）

5) localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context

6) Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）

7) path="/wsota"的Context获得请求/wsota_index.jsp，在它的mapping table 中寻找对应的servlet

8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类

9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法

10)Context把执行完了之后的HttpServletResponse对象返回给Host

11)Host把HttpServletResponse对象返回给Engine

12)Engine把HttpServletResponse对象返回给Connector

13)Connector把HttpServletResponse对象返回给客户browser。

XML解析技术研究(一)

摘要：XML作为过去十年中出现的最流行的技术之一，得到了广泛的应用，而其中

XML解析技术是XML应用的关键。本文介绍了XML解析技术的研究动向，分析和比

较了4种XML解析技术的优劣，并归纳总结了应用系统设计中选取合适的XML解析

技术的原则。

1 引言

XML(eXtensible Markup Language，可扩展标记语言)是由World Wide Web 联盟(W3C)定义的元语言，即一种关于语言的语言。XML的设计源于SGML (Standard Generalized Markup Language，标淮通用标记语言)，是SGML的子集，其目的是

为了促进Internet上结构化文档的交换。简单的说，XML是一组规则和准则的集合，用于以无格式文本来描述结构化数据[1]。1996年W3C联盟就开始从事XML的标准化

工作，并于1998年2月10日发布了XML1.0。

XML的出现给分布式计算领域带来了重大影响，其力量源于它的数据独立性[1]。

XML是纯数据描述，与编程语言、操作系统或传输协议无关，从而将数据从以代码

为中心的基础结构所产生的约束中解放出来，让数据能够在Web上更自由的流通。

然而XML本身只是以纯文本对数据进行编码的一种格式，要想利用XML，或者说利用XML文件中所编码的数据，必须先将数据从纯文本中解析出来，因此，必须

有一个能够识别XML文档中信息的解析器，用来解释XML文档并提取其中的数据。

然而，根据数据提取的不同需求，又存在着多种解析方式，不同的解析方式有着各

自的优缺点和适用环境。选择合适的XML解析技术能够有效提升应用系统的整体性

能，因此，了解和区分各种不同的XML解析技术就显得尤为重要。

2 XML解析技术分析

所有的XML处理都从解析开始，无论是使用XSLT或Java语言，第一步都是要读入XML文件，解码结构和检索信息等等，这就是解析，即把代表XML文档的一个无结构的字符序列转换为满足XML语法的结构化组件的过程。

2.1 XML解析技术的分类

根据从XML中获取数据的简易性，性能和最终所得到的数据模型的不同，XML 解析技术大致可分为以下四类：

1)面向文档的流式解析；

2)面向文档的对象式解析；

3)面向文档的指针式解析；

4)面向应用的对象式解析；

这四类解析技术分别处于不同的抽象层次，适用于不同的应用场景，有着各自的优缺点。针对具体的应用需求，选择合适的解析技术，往往能够减少内存消耗，缩短处理时间，更方便地获取数据，提高应用系统的整体性能。

2.2 面向文档的流式解析技术

流式解析是一种基于事件的解析过程，解析器顺序读取XML文档，产生一个对应的事件流，并向事件处理程序发送所捕获的各种事件，如元素开始和元素结束等，而事件处理程序则通过不同的方法处理这些事件。

流式解析是将XML文档作为一个数据流来处理，因此，它具有类似于流媒体的优点，能够立即开始读取数据，而不是等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，不需要将整个文档一次加载到内存中，使得在处理大型文档时具有较好的时间和空间上的效率。然而效率的代价是易用性的降低，流式解析编程较为复杂，程序员需要负责更多的操作。并且由于应用程序没有以任何方式存储数据，所以使得更改数据或在数据流中往后移是不可能的。再加上它的单遍解析特性，意味着它也不支持随机访问。

流式解析又分为两种解析方式：推式解析(SAX)和拉式解析(StAX)。这两种方式的主要区别在于是由解析器还是应用程序控制读循环(读入文件的循环)。

2.2.1 推式解析(SAX解析技术)

SAX(Simple API for XML)解析技术就是一种推式解析，在这种解析方式中，解析器控制着读循环，在文档结束之前控制权不会返回给应用程序[3]。解析器通过回调的方式进行数据处理。

SAX提供了一个用于处理XML的，基于事件驱动的简单API。它的设计开始于XML-DEV邮件列表成员间的讨论，他们开发出的第一个接口草案SAX1.0于1998年1月发布，其后在2000年5月发布了SAX2.0，目前最新版本是2004年4月发布的SAX2.0.2。SAX没有经过官方的标准机构认可，它不由W3C联盟或其它任何官方机构维护(现在，SAX由David Megginson维护) [4]，但它被广泛使用并视为XML社区事实上的标准。SAX最初是为Java而定义的，但也可以用于Python、Perl、C++等其它语言。

SAX是基于事件驱动的，即SAX解析器在读取XML文档的过程中生成一个事件流，并且对于每个事件通过回调事件处理程序中相应的方法来进行处理。比如元素开始和结束标记，元素内容，实体，语法分析错误等事件。针对下面的简单XML文档，所产生的事件如图1所示，注意针对元素内的空格或回车也会生成一个文本事件。

图1 SAX解析器生成的事件

SAX中的核心事件处理程序是一个实现了ContentHandler接口的类。此接口中定义了处理与XML文档本身关联的事件的方法，如 startDocument、endDocument、startElement、endElement、Characters等

SAX解析技术具有所有流式解析技术的优点和缺点，但是由于在整个解析过程中，解析器掌握着控制权直到文档结束，应用程序很难在获得所需的部分数据后停止解析过程(可以通过抛出异常的方式终止解析过程，但较为复杂，而且终止后也无法继续解析过程)，因此产生了由应用程序掌握控制权的拉式解析方式。

2.2.2 拉式解析(StAX解析技术)

StAX(Streaming API for XML)解析技术是一种拉式解析，在这种解析方式中，应用程序控制着读循环。循环中，应用程序负责反复调用解析器获得下一个事件，直到文档结束。通过保留解析过程的控制权，可以简化调用代码来准确地处理它预期的内容，并且可随时停止解析。此外，由于该方式没有基于处理程序回调，应用程序也不需要像SAX中那样模拟解析器的状态。

StAX针对同样的XML文档所获得事件类型和SAX基本相同，但是StAX包含了两套处理XML的API：基于指针的API和基于迭代器的API，分别提供了不同程度的抽象[5]。

基于指针的API简单的返回事件，此时事件用数值形式来表示。这是一种低层API，没有提供底层XML结构的抽象，所有的状态信息直接从流读取器获得，不需要创建额外的对象。从而节约内存，拥有较高的效率。

而较为高级的基于迭代器的API则以对象方式返回事件，每个事件对象都封装了它所表示的特定XML结构固有的信息，因此可直接利用其方法获得属于该结构的信息，但也需要额外的对象创建开销。相对于基于指针的API，基于迭代器的API 具有更多的面向对象特征，因此更便于应用于模块化的体系结构。

StAX也是用Java定义的，其StAX1.0于2004年3月发布，并且成为了JSR-173 规范，最新版本为2006年6月发布的StAX1.2。StAX作为用Java语言处理XML的最新标准，比早期出现的XPP (Xml Pull Parser)拉式解析器功能更为强大，也得到了更为广泛的应用。

2.3 面向文档的对象式解析技术

由于流式解析方式固有的无法更改数据和不支持随机访问特性，尤其是没有对XML文档的结构建模，使得应用程序很难对XML文档进行搜索、修改、添加和删除等操作。为了解决这些问题，产生了面向文档的对象式解析技术--DOM。

DOM(Document Object Model)是用与平台和语言无关的方式对XML文档进行建模的官方W3C标准[6]，其目标是提供一个可以通用于各种程序语言、操作系统和应用程序的接口。DOM最初被当作Web浏览器识别和处理页面元素的方式,即在W3C

介入之前的功能，称为“DOM Level 0”。W3C于1998年10月提出了“DOM Level 1”建议，支持XML1.0和HTML处理。随后于2000年11月提出了“DOM Level 2”建议，对Level 1进行了扩展，支持XML1.0、命名空间和CSS，也支持用户接口和树形操作事件，并且添加了DOM树形操作功能。最新的“DOM Level 3”建议于2003年6月提出，在level 2的基础上添加了对DTD、XML模式和XPath的支持[1]。

DOM作为一种对象式解析技术，定义了层次化对象模型来表示XML文档。即为XML语法中的每个概念(如元素，属性，实体，文档等)定义对应的类，而解析器在读入XML文档的时候，会建立XML语法和类之间的一一映射。实际上，DOM的层次化对象模型是一个树形结构，它将一个XML文档看作一棵节点树，每个节点代表一个XML文档中的元素。DOM的基本节点对象有5个[1]：(1)Document对象：是树的最高节点，也是对整个文档操作的入口；(2)Element和Attr对象：对文档中元素和元素属性的映射；(3)Text对象：作为Element和Attr对象的子节点，代表了元素或属性的文本内容；(4)NodeList对象：对节点按指定的方式进行遍历。

例如对于2.2.1中的XML文档，其对应的DOM节点树如下图所示(注意元素内的空格或回车也会被当作文本对象)：

图2 DOM节点树 (矩形框表示元素节点，椭圆表示文本节点)

利用DOM在内存中建立的完整的XML文档的树形结构，开发人员就可以方便的对XML文档进行一系列操作，如遍历、增加、删除、修改文档内容等，且具有良好的导航能力。同时DOM所具有的对象特性也非常便于面向对象编程。然而，由于DOM 在使用数据前需要完整的遍历XML文档，在内存中构建树形结构表示，因此需要消耗大量的内存，尤其是对于大型文档，性能下降的很快。而且必须一次解析整个XML 文档，不可能只做部分解析，当只关注XML文档的小部分数据时，效率很低。(Axis2项目中的Axiom对象模型实现了对XML文档的部分解析，可构建不完整的节点树，但实现较为复杂)

由于DOM是与语言无关的，当DOM接口进入指定语言的数据结构时，会产生不必要的复杂性，无法利用语言本身的优势。因此出现了许多与DOM类似的针对特定语言的对象模型。如JDOM就是针对Java的特定文档对象模型，JDOM使用具体类而不使用接口，简化了API，并在API中大量使用了Java集合类。DOM4J则是JDOM 的一种智能分支，它提供了对XPath和XML Schema的支持，并且通过DOM4J API 和标准DOM接口使其具有并行访问功能[5]。它们都属于面向文档的对象式解析技术。

2.4 面向文档的指针式解析技术

前面提到的面向文档的流式解析效率较高，但易用性差，而对象式解析易用性强，却效率较低，这两种方式似乎处于两个极端。其效率问题主要在于两种方式都是提取解析模式，即解析时，提取一部分源文件，一般来说是一个字符串，然后在内存中进行解析构建。这种解析模式注定了需要大量的创建和销毁对象，而且还存在更新效率问题，在DOM中(SAX并不支持更新)，每一次改动都需要将DOM模型重新完整的解析成XML字符串，原文件并没有被利用，即DOM并不支持增量更新。为了解决这些问题，提出了一种较新颖的指针式解析技术，即VTD-XML。

VTD-XML是一种无提取的XML解析方法，它较好的解决了DOM占用内存过大的缺点，并且还提供了快速的解析与遍历、对XPath的支持和增量更新等特性。VTD-XML 是一个开源项目，目前有Java、C两种平台支持，第一个版本是2004年6月发布的VTD-XML0.5，其VTD- XML1.0版本于2005年10月发布，最新的版本为2007年10月发布的VTD-XML2.2。

VTD(Virtual Token Descriptor，虚拟令牌描述符)是一个64bits长度的数值类型，记录了每个元素的起始位置，长度，深度以及令牌的类型等信息，如图3所示。64bits固定长度使得可以用数组这种高效的结构来组织VTD，大幅提高性能。VTD是实现无提取解析的关键，它类似于XML文档中元素的指针，通过它可以快速定位到某个元素。

图3 VTD记录的比特层格式

令牌开始偏移量(即相对于XML文档头部的距离)是30 bits，也就是说它能解析的最大文件是1G。令牌长度为20 bits，即一个令牌的最大长度是1M。令牌类型4bits，说明支持16种词汇类型。

为了实现无提取这个目的，VTD-XML将原XML文件原封不动的以二进制的方式读进内存，不做解码，然后在这个比特数组上解析每个元素的位置并把一些信息，如XML令牌的开始偏移量、长度、深度和令牌类型，记录下来，保存为VTD数组，之后的遍历操作便可在VTD数组上进行。如果需要提取XML内容，就查找VTD数组，利用VTD记录中的位置等信息在原始比特数组上进行解码并返回字符串。

而且VTD-XML还可以高效的实现增量更新，例如，如果想在一个大型XML文档中找出一个节点元素并删除它，那么只需要找到这个元素的VTD，将这个VTD从VTD 数组中删除，然后再利用所有的VTD写出到另一个二进制数组中就可以了，因为删除的VTD标明了要删除的元素的位置，所以在新写入的二进制数组中就不会出现这段元素了。用VTD写入新的二进制数组的过程实际上就是一个二进制数组的拷贝过程，其效率是非常高的[2]。

由此可见，VTD很好的解决了前两种解析方式的缺点，通过其巧妙的设计使得在解析XML文档时内存占用少，效率高，并且还能够实现XML文档的快速解析与遍历、提供对XPath的支持。VTD的出现是XML解析技术的一大进步，会对XML解析技术的发展产生巨大影响。

2.5 面向应用的对象式解析技术

前面所谈到的三种解析技术都是从XML的角度来处理文档和建立模型，这对于主要关心文档的XML结构的应用程序来说是适用的，但是有很多应用程序仅仅将XML作为数据交换的媒介，它们更关心的是文档数据本身。此时，面向应用的对象式解析(或称为XML数据绑定)可以使应用程序在很大程度上忽略XML文档的实际结构，而直接使用文档的数据内容。

数据绑定是指将数据从一些存储媒介(如XML文档、文本文件和数据库)中取出，并通过应用程序表示这些数据的过程，即把数据绑定到虚拟机能够理解并且可以操作的某种内存中的结构[9]。数据绑定并不是一个新鲜的概念，其在关系数据库上早已得到了广泛的应用，如Hibernate就是针对数据库的轻量级数据绑定框架。而针对XML数据绑定的Castor框架在2000年就已经出现，目前已经涌现出了许多类似的框架，如JBind、JAXB、JiBX、Quick和Zeus等。

其中JAXB(Java Architecture for XML Binding)是一个处于不断发展中的应用于Java平台的数据绑定框架，提供了一套在XML文档和Java对象之间自动映射的API，符合JSR31--XML数据绑定规范（XML Data Binding Specification）。该项目始于1999年8月，由Java Community Process开发，其1.0版本于2002年10月发布，目前最新版本为2007年9月17日发布的JAXB2.1.5。

如图4，显示了数据绑定在数据库和XML文档中的应用。

图4 数据绑定

在数据绑定中有三个重要概念[9]：

●编组(Marshalling)：把内存中的数据转换到存储介质中的过程。在Java

和XML环境中，编组就是把一些Java对象转化为一个(或多个)XML文档。

其核心就在于把Java中的面向对象结构转化成适用于XML的扁平结构。

●解组(Unmarshalling)：把数据从存储媒介转换到内存中的过程。在Java

和XML环境中，即将XML文档解组到Java虚拟机中，其复杂性在于从数

据到Java代码变量的映射。

●映射(Mapping)：用于编组和解组的一套规则。

初看起来XML数据绑定和面向文档的对象式解析较为相似，都在内存中构建文档表示，同时内部表示和标准的XML文档之间可以互相转换。但两者之间的不同在于文档模型尽可能接近的保存XML的文档结构，而数据绑定只关心应用程序使用的文档数据[7]。如图5所示，同一个XML文档的文档模型和数据绑定模型是完全不同的。

图5 文档模型和数据绑定模型比较

如果应用程序使用文档模型方法，那么获得所需要的数据就必须在节点树中根据父子节点关系进行遍历。而使用数据绑定方法，只需进行正常的Java编程，访问数据更加容易，速度也比文档模型快得多。而且，XML数据绑定并不只是简化编程，由于它把许多文档细节抽象出来，所以数据绑定所需的内存通常少于文档模型所需的内存，如上图中，文档模型方法使用了10个单独的对象，而数据绑定才使用2个。此外，由于要构建的对象少得多，所以为XML文档构建数据绑定表示还可能更快[7]。

在XML数据绑定中最为核心的是怎样由XML文档生成Java对象。目前有两种方式：映射绑定方式和代码生成方式[8]。在映射绑定方式中，构建自己的Java类，并向绑定框架指定这些类如何与XML文档相关联。如框架Castor和Quick就支持这种方式。而代码生成方式则根据XML文档结构(即DTD或Schema形式的文法)自动构建相应的Java类，如JAXB、Castor和JBind提供了根据XML文档的Schema 描述生成Java代码，Quick和Zeus可根据DTD描述生成Java代码。

代码生成方式所构造的类可以包括完整的数据类型信息，还能够对所构造的类进行验证。但该方式使得程序代码和文档结构之间紧密耦合，如果文档结构发生变化，就需要重新生成代码。而映射绑定方式则具有更大的灵活性，其使用自己构建的对象类将数据和行为组合在一起，通过修改映射定义(而不是改变应用程序代码)来处理XML文档结构中的微小变化，可以在一定程度上解除对象类与实际XML文档之间的耦合[8]。其缺点在于需要编写较为复杂的映射文件。

2.6 四种XML解析技术的特性比较

根据以上对四种XML解析技术的介绍和分析，对其特性进行总结和比较，如下表所示：

表1 XML解析技术特性比较

3 XML解析技术的选取

通过上述对四种XML解析技术的分析，可以大致看出XML解析技术的发展历程，在不同的时期，针对不同的应用需求，产生了不同的解析技术。这些解析技术具有各自的优缺点，在应用中，如何选择正确的解析技术，往往成为提高应用系统整体性能和效率的关键。

3.1 面向文档与面向应用的解析方式的选取

上述的四种解析技术又可分为两类：面向文档的和面向应用的。如果应用程序只是将XML文档作为数据交换的媒介，关心文档中包含的数据胜于关心文档的XML

结构，那么选择面向应用的解析方式将能够在数据获取上得到很大的简化，虽然在效率上有点损失，但相对于整个应用系统的模块化设计是值得的。

相反，如果应用程序真正关心文档结构的细节，如编写一个XML文档编辑器，又或应用程序正在处理的XML文档不遵守固定的结构，那么选择面向文档的解析方式不仅能够提高效率，还可以降低编程的复杂性。

3.2 面向文档的解析方式的选取

在面向文档的三种解析方式中，流式解析和对象式解析是出现较早的两种解析方式，提供了不同层面上的解析抽象。

流式解析是一种低级的解析方式，它能够提供比对象式解析更多的控制，并且效率更高。然而，由于流式解析没有对文档结构进行建模，使得很难对文档进行搜索、修改、添加和删除等操作，而且也无法进行随机访问。因此如果应用程序仅仅想高效率的获得XML文档中的某部分数据，并且希望对解析过程进行更多的控制，而不需要对文档进行添加和修改，那么选取流式解析更能满足需求。在流式解析中，StAX技术使得应用程序能够更方便的控制解析过程，并且其作为Java的官方规范，得到了更广泛的应用。

对象式解析作为一种高级的解析方式，它的重点在于对文档结构进行建模，而完全不关心文档的解析过程(对象式解析往往建立在流式解析的基础上，在流式解析的过程中逐步建立模型)。而一旦在内存中建立了文档的树形结构模型，那么就可以方便的通过模型对文档进行搜索，修改、添加和删除等操作，并且更适合于面向对象的编程。然而，这种便利性是以内存和效率为代价的，因此，如果应用程序需要频繁的对XML文档中的数据进行检索和修改，而对内存和效率没有过多要求，那么对象式解析将是一种很好的选择。

而指针式解析的提出是以提高效率，减少内存消耗为主要目的，可看作是介于流式解析和对象式解析之间的一种解析方式。它巧妙的设计方式使得不需要对文档建立树形模型，就可以实现搜索，修改、添加和删除等操作，同时向应用程序屏蔽了底层的解析过程，编程更加简便。因此，当应用程序不关心解析过程，而对性能有较高要求时，可以选择使用指针式解析。

3.2.1 面向文档解析方式的性能比较

根据VTD-XML的官方网站的数据[11]，VTD-XML的解析速度是DOM的5x-10x，是SAX(with NULL content handler)的1.5x - 2.0x（With NULL content handler 意味着SAX解析中没有插入任何额外的处理逻辑，也就是SAX的最高速度）。VTD-XML 的内存占用仅为原XML的1.3x-1.5x（其中1.0x部分是原XML），而DOM的内存占用则是原XML的4x-8x，对于一些大型的XML文档，使用DOM方式处理往往会出现内存溢出的错误。

以下是SAX，DOM和VTD-XML三种XML解析方式的性能测试结果[10]，如下表所示：

表2 SAX，DOM和VTD-XML性能比较

4、结论

随着XML的广泛应用，XML解析技术作为XML文档处理过程中关键的一环，对应用系统的整体性能有着重要影响。本文通过分析和比较4种主流XML解析技术的优缺点，使得开发人员能够针对具体的应用需求选择最为合适的解析技术。此外，对XML解析技术的深入研究对于促进XML的应用也有着积极的作用。