1  引言

XML(eXtensible Markup Language，可擴(kuò)展標(biāo)記語言)是由World Wide Web聯(lián)盟(W3C)定義的元語言，即一種關(guān)于語言的語言。XML的設(shè)計(jì)源于SGML (Standard Generalized Markup Language，標(biāo)淮通用標(biāo)記語言) ，是SGML的子集，其目的是為了促進(jìn)Internet上結(jié)構(gòu)化文檔的交換。簡(jiǎn)單的說，XML是一組規(guī)則和準(zhǔn)則的集合，用于以無格式文本來描述結(jié)構(gòu)化數(shù)據(jù)^[1]。1996年W3C聯(lián)盟就開始從事XML的標(biāo)準(zhǔn)化工作，并于1998年2月10日發(fā)布了XML1.0。

XML的出現(xiàn)給分布式計(jì)算領(lǐng)域帶來了重大影響，其力量源于它的數(shù)據(jù)獨(dú)立性^[1]。XML是純數(shù)據(jù)描述，與編程語言、操作系統(tǒng)或傳輸協(xié)議無關(guān)，從而將數(shù)據(jù)從以代碼為中心的基礎(chǔ)結(jié)構(gòu)所產(chǎn)生的約束中解放出來，讓數(shù)據(jù)能夠在Web上更自由的流通。

然而XML本身只是以純文本對(duì)數(shù)據(jù)進(jìn)行編碼的一種格式，要想利用XML，或者說利用XML文件中所編碼的數(shù)據(jù)，必須先將數(shù)據(jù)從純文本中解析出來，因此，必須有一個(gè)能夠識(shí)別XML文檔中信息的解析器，用來解釋XML文檔并提取其中的數(shù)據(jù)。然而，根據(jù)數(shù)據(jù)提取的不同需求，又存在著多種解析方式，不同的解析方式有著各自的優(yōu)缺點(diǎn)和適用環(huán)境。選擇合適的XML解析技術(shù)能夠有效提升應(yīng)用系統(tǒng)的整體性能，因此，了解和區(qū)分各種不同的XML解析技術(shù)就顯得尤為重要。

2  XML解析技術(shù)分析

所有的XML處理都從解析開始，無論是使用XSLT或Java語言，第一步都是要讀入XML文件，解碼結(jié)構(gòu)和檢索信息等等，這就是解析，即把代表XML文檔的一個(gè)無結(jié)構(gòu)的字符序列轉(zhuǎn)換為滿足XML語法的結(jié)構(gòu)化組件的過程。

2.1 XML解析技術(shù)的分類

根據(jù)從XML中獲取數(shù)據(jù)的簡(jiǎn)易性，性能和最終所得到的數(shù)據(jù)模型的不同，XML解析技術(shù)大致可分為以下四類：

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

2)       面向文檔的對(duì)象式解析；

3)       面向文檔的指針式解析；

4)       面向應(yīng)用的對(duì)象式解析；

這四類解析技術(shù)分別處于不同的抽象層次，適用于不同的應(yīng)用場(chǎng)景，有著各自的優(yōu)缺點(diǎn)。針對(duì)具體的應(yīng)用需求，選擇合適的解析技術(shù)，往往能夠減少內(nèi)存消耗，縮短處理時(shí)間，更方便地獲取數(shù)據(jù)，提高應(yīng)用系統(tǒng)的整體性能。

2.2 面向文檔的流式解析技術(shù)

流式解析是一種基于事件的解析過程，解析器順序讀取XML文檔，產(chǎn)生一個(gè)對(duì)應(yīng)的事件流，并向事件處理程序發(fā)送所捕獲的各種事件，如元素開始和元素結(jié)束等，而事件處理程序則通過不同的方法處理這些事件。

流式解析是將XML文檔作為一個(gè)數(shù)據(jù)流來處理，因此，它具有類似于流媒體的優(yōu)點(diǎn)，能夠立即開始讀取數(shù)據(jù)，而不是等待所有的數(shù)據(jù)被處理。而且，由于應(yīng)用程序只是在讀取數(shù)據(jù)時(shí)檢查數(shù)據(jù)，不需要將整個(gè)文檔一次加載到內(nèi)存中，使得在處理大型文檔時(shí)具有較好的時(shí)間和空間上的效率。然而效率的代價(jià)是易用性的降低，流式解析編程較為復(fù)雜，程序員需要負(fù)責(zé)更多的操作。并且由于應(yīng)用程序沒有以任何方式存儲(chǔ)數(shù)據(jù)，所以使得更改數(shù)據(jù)或在數(shù)據(jù)流中往后移是不可能的。再加上它的單遍解析特性，意味著它也不支持隨機(jī)訪問。

流式解析又分為兩種解析方式：推式解析(SAX)和拉式解析(StAX)。這兩種方式的主要區(qū)別在于是由解析器還是應(yīng)用程序控制讀循環(huán)(讀入文件的循環(huán))。

2.2.1 推式解析(SAX解析技術(shù))

SAX(Simple API for XML)解析技術(shù)就是一種推式解析，在這種解析方式中，解析器控制著讀循環(huán)，在文檔結(jié)束之前控制權(quán)不會(huì)返回給應(yīng)用程序^[3]。解析器通過回調(diào)的方式進(jìn)行數(shù)據(jù)處理。

SAX提供了一個(gè)用于處理XML的，基于事件驅(qū)動(dòng)的簡(jiǎn)單API。它的設(shè)計(jì)開始于XML-DEV郵件列表成員間的討論，他們開發(fā)出的第一個(gè)接口草案SAX1.0于1998年1月發(fā)布，其后在2000年5月發(fā)布了SAX2.0，目前最新版本是2004年4月發(fā)布的SAX2.0.2。SAX沒有經(jīng)過官方的標(biāo)準(zhǔn)機(jī)構(gòu)認(rèn)可，它不由W3C聯(lián)盟或其它任何官方機(jī)構(gòu)維護(hù)(現(xiàn)在，SAX由David Megginson維護(hù)) ^[4]，但它被廣泛使用并視為XML社區(qū)事實(shí)上的標(biāo)準(zhǔn)。SAX最初是為Java而定義的，但也可以用于Python、Perl、C++等其它語言。

SAX是基于事件驅(qū)動(dòng)的，即SAX解析器在讀取XML文檔的過程中生成一個(gè)事件流，并且對(duì)于每個(gè)事件通過回調(diào)事件處理程序中相應(yīng)的方法來進(jìn)行處理。比如元素開始和結(jié)束標(biāo)記，元素內(nèi)容，實(shí)體，語法分析錯(cuò)誤等事件。針對(duì)下面的簡(jiǎn)單XML文檔，所產(chǎn)生的事件如圖1所示，注意針對(duì)元素內(nèi)的空格或回車也會(huì)生成一個(gè)文本事件。

圖1 SAX解析器生成的事件

SAX中的核心事件處理程序是一個(gè)實(shí)現(xiàn)了ContentHandler接口的類。此接口中定義了處理與XML文檔本身關(guān)聯(lián)的事件的方法，如 startDocument、endDocument、startElement、endElement、Characters等

SAX解析技術(shù)具有所有流式解析技術(shù)的優(yōu)點(diǎn)和缺點(diǎn)，但是由于在整個(gè)解析過程中，解析器掌握著控制權(quán)直到文檔結(jié)束，應(yīng)用程序很難在獲得所需的部分?jǐn)?shù)據(jù)后停止解析過程(可以通過拋出異常的方式終止解析過程，但較為復(fù)雜，而且終止后也無法繼續(xù)解析過程)，因此產(chǎn)生了由應(yīng)用程序掌握控制權(quán)的拉式解析方式。

2.2.2 拉式解析(StAX解析技術(shù))

StAX(Streaming API for XML)解析技術(shù)是一種拉式解析，在這種解析方式中，應(yīng)用程序控制著讀循環(huán)。循環(huán)中，應(yīng)用程序負(fù)責(zé)反復(fù)調(diào)用解析器獲得下一個(gè)事件，直到文檔結(jié)束。通過保留解析過程的控制權(quán)，可以簡(jiǎn)化調(diào)用代碼來準(zhǔn)確地處理它預(yù)期的內(nèi)容，并且可隨時(shí)停止解析。此外，由于該方式?jīng)]有基于處理程序回調(diào)，應(yīng)用程序也不需要像SAX中那樣模擬解析器的狀態(tài)。

StAX針對(duì)同樣的XML文檔所獲得事件類型和SAX基本相同，但是StAX包含了兩套處理XML的API：基于指針的API和基于迭代器的API，分別提供了不同程度的抽象^[5]。

基于指針的API簡(jiǎn)單的返回事件，此時(shí)事件用數(shù)值形式來表示。這是一種低層API，沒有提供底層XML結(jié)構(gòu)的抽象，所有的狀態(tài)信息直接從流讀取器獲得，不需要?jiǎng)?chuàng)建額外的對(duì)象。從而節(jié)約內(nèi)存，擁有較高的效率。

而較為高級(jí)的基于迭代器的API則以對(duì)象方式返回事件，每個(gè)事件對(duì)象都封裝了它所表示的特定XML結(jié)構(gòu)固有的信息，因此可直接利用其方法獲得屬于該結(jié)構(gòu)的信息，但也需要額外的對(duì)象創(chuàng)建開銷。相對(duì)于基于指針的API，基于迭代器的API具有更多的面向?qū)ο筇卣鳎虼烁阌趹?yīng)用于模塊化的體系結(jié)構(gòu)。

StAX也是用Java定義的，其StAX1.0于2004年3月發(fā)布，并且成為了JSR-173 規(guī)范，最新版本為2006年6月發(fā)布的StAX1.2。StAX作為用Java語言處理XML的最新標(biāo)準(zhǔn)，比早期出現(xiàn)的XPP (Xml Pull Parser)拉式解析器功能更為強(qiáng)大，也得到了更為廣泛的應(yīng)用。

2.3 面向文檔的對(duì)象式解析技術(shù)

由于流式解析方式固有的無法更改數(shù)據(jù)和不支持隨機(jī)訪問特性，尤其是沒有對(duì)XML文檔的結(jié)構(gòu)建模，使得應(yīng)用程序很難對(duì)XML文檔進(jìn)行搜索、修改、添加和刪除等操作。為了解決這些問題，產(chǎn)生了面向文檔的對(duì)象式解析技術(shù)--DOM。

DOM(Document Object Model)是用與平臺(tái)和語言無關(guān)的方式對(duì)XML文檔進(jìn)行建模的官方W3C標(biāo)準(zhǔn)^[6]，其目標(biāo)是提供一個(gè)可以通用于各種程序語言、操作系統(tǒng)和應(yīng)用程序的接口。DOM最初被當(dāng)作Web瀏覽器識(shí)別和處理頁面元素的方式,即在W3C介入之前的功能，稱為“DOM Level 0”。W3C于1998年10月提出了“DOM Level 1”建議，支持XML1.0和HTML處理。隨后于2000年11月提出了“DOM Level 2”建議，對(duì)Level 1進(jìn)行了擴(kuò)展，支持XML1.0、命名空間和CSS，也支持用戶接口和樹形操作事件，并且添加了DOM樹形操作功能。最新的“DOM Level 3”建議于2003年6月提出，在level 2的基礎(chǔ)上添加了對(duì)DTD、XML模式和XPath的支持^[1]。

DOM作為一種對(duì)象式解析技術(shù)，定義了層次化對(duì)象模型來表示XML文檔。即為XML語法中的每個(gè)概念(如元素，屬性，實(shí)體，文檔等)定義對(duì)應(yīng)的類，而解析器在讀入XML文檔的時(shí)候，會(huì)建立XML語法和類之間的一一映射。實(shí)際上，DOM的層次化對(duì)象模型是一個(gè)樹形結(jié)構(gòu)，它將一個(gè)XML文檔看作一棵節(jié)點(diǎn)樹，每個(gè)節(jié)點(diǎn)代表一個(gè)XML文檔中的元素。DOM的基本節(jié)點(diǎn)對(duì)象有5個(gè)^[1]：(1)Document對(duì)象：是樹的最高節(jié)點(diǎn)，也是對(duì)整個(gè)文檔操作的入口；(2)Element和Attr對(duì)象：對(duì)文檔中元素和元素屬性的映射；(3)Text對(duì)象：作為Element和Attr對(duì)象的子節(jié)點(diǎn)，代表了元素或?qū)傩缘奈谋緝?nèi)容；(4)NodeList對(duì)象：對(duì)節(jié)點(diǎn)按指定的方式進(jìn)行遍歷。

例如對(duì)于2.2.1中的XML文檔，其對(duì)應(yīng)的DOM節(jié)點(diǎn)樹如下圖所示(注意元素內(nèi)的空格或回車也會(huì)被當(dāng)作文本對(duì)象)：

圖2 DOM節(jié)點(diǎn)樹 (矩形框表示元素節(jié)點(diǎn)，橢圓表示文本節(jié)點(diǎn))

利用DOM在內(nèi)存中建立的完整的XML文檔的樹形結(jié)構(gòu)，開發(fā)人員就可以方便的對(duì)XML文檔進(jìn)行一系列操作，如遍歷、增加、刪除、修改文檔內(nèi)容等，且具有良好的導(dǎo)航能力。同時(shí)DOM所具有的對(duì)象特性也非常便于面向?qū)ο缶幊獭Ｈ欢捎?/span>DOM在使用數(shù)據(jù)前需要完整的遍歷XML文檔，在內(nèi)存中構(gòu)建樹形結(jié)構(gòu)表示，因此需要消耗大量的內(nèi)存，尤其是對(duì)于大型文檔，性能下降的很快。而且必須一次解析整個(gè)XML文檔，不可能只做部分解析，當(dāng)只關(guān)注XML文檔的小部分?jǐn)?shù)據(jù)時(shí)，效率很低。(Axis2項(xiàng)目中的Axiom對(duì)象模型實(shí)現(xiàn)了對(duì)XML文檔的部分解析，可構(gòu)建不完整的節(jié)點(diǎn)樹，但實(shí)現(xiàn)較為復(fù)雜)

由于DOM是與語言無關(guān)的，當(dāng)DOM接口進(jìn)入指定語言的數(shù)據(jù)結(jié)構(gòu)時(shí)，會(huì)產(chǎn)生不必要的復(fù)雜性，無法利用語言本身的優(yōu)勢(shì)。因此出現(xiàn)了許多與DOM類似的針對(duì)特定語言的對(duì)象模型。如JDOM就是針對(duì)Java的特定文檔對(duì)象模型，JDOM使用具體類而不使用接口，簡(jiǎn)化了API，并在API中大量使用了Java集合類。DOM4J則是JDOM的一種智能分支，它提供了對(duì)XPath和XML Schema的支持，并且通過DOM4J API和標(biāo)準(zhǔn)DOM接口使其具有并行訪問功能^[5]。它們都屬于面向文檔的對(duì)象式解析技術(shù)。

2.4 面向文檔的指針式解析技術(shù)

前面提到的面向文檔的流式解析效率較高，但易用性差，而對(duì)象式解析易用性強(qiáng)，卻效率較低，這兩種方式似乎處于兩個(gè)極端。其效率問題主要在于兩種方式都是提取解析模式，即解析時(shí)，提取一部分源文件，一般來說是一個(gè)字符串，然后在內(nèi)存中進(jìn)行解析構(gòu)建。這種解析模式注定了需要大量的創(chuàng)建和銷毀對(duì)象，而且還存在更新效率問題，在DOM中(SAX并不支持更新)，每一次改動(dòng)都需要將DOM模型重新完整的解析成XML字符串，原文件并沒有被利用，即DOM并不支持增量更新。為了解決這些問題，提出了一種較新穎的指針式解析技術(shù)，即VTD-XML。

VTD-XML是一種無提取的XML解析方法，它較好的解決了DOM占用內(nèi)存過大的缺點(diǎn)，并且還提供了快速的解析與遍歷、對(duì)XPath的支持和增量更新等特性。VTD-XML是一個(gè)開源項(xiàng)目，目前有Java、C兩種平臺(tái)支持，第一個(gè)版本是2004年6月發(fā)布的VTD-XML0.5，其VTD- XML1.0版本于2005年10月發(fā)布，最新的版本為2007年10月發(fā)布的VTD-XML2.2。

VTD(Virtual Token Descriptor，虛擬令牌描述符)是一個(gè)64bits長(zhǎng)度的數(shù)值類型，記錄了每個(gè)元素的起始位置，長(zhǎng)度，深度以及令牌的類型等信息，如圖3所示。64bits固定長(zhǎng)度使得可以用數(shù)組這種高效的結(jié)構(gòu)來組織VTD，大幅提高性能。VTD是實(shí)現(xiàn)無提取解析的關(guān)鍵，它類似于XML文檔中元素的指針，通過它可以快速定位到某個(gè)元素。

圖3 VTD記錄的比特層格式

令牌開始偏移量(即相對(duì)于XML文檔頭部的距離)是30 bits，也就是說它能解析的最大文件是1G。令牌長(zhǎng)度為20 bits，即一個(gè)令牌的最大長(zhǎng)度是1M。令牌類型4bits，說明支持16種詞匯類型。

為了實(shí)現(xiàn)無提取這個(gè)目的，VTD-XML將原XML文件原封不動(dòng)的以二進(jìn)制的方式讀進(jìn)內(nèi)存，不做解碼，然后在這個(gè)比特?cái)?shù)組上解析每個(gè)元素的位置并把一些信息，如XML令牌的開始偏移量、長(zhǎng)度、深度和令牌類型，記錄下來，保存為VTD數(shù)組，之后的遍歷操作便可在VTD數(shù)組上進(jìn)行。如果需要提取XML內(nèi)容，就查找VTD數(shù)組，利用VTD記錄中的位置等信息在原始比特?cái)?shù)組上進(jìn)行解碼并返回字符串。

而且VTD-XML還可以高效的實(shí)現(xiàn)增量更新，例如，如果想在一個(gè)大型XML文檔中找出一個(gè)節(jié)點(diǎn)元素并刪除它，那么只需要找到這個(gè)元素的VTD，將這個(gè)VTD從VTD數(shù)組中刪除，然后再利用所有的VTD寫出到另一個(gè)二進(jìn)制數(shù)組中就可以了，因?yàn)閯h除的VTD標(biāo)明了要?jiǎng)h除的元素的位置，所以在新寫入的二進(jìn)制數(shù)組中就不會(huì)出現(xiàn)這段元素了。用VTD寫入新的二進(jìn)制數(shù)組的過程實(shí)際上就是一個(gè)二進(jìn)制數(shù)組的拷貝過程，其效率是非常高的^[2]。

由此可見，VTD很好的解決了前兩種解析方式的缺點(diǎn)，通過其巧妙的設(shè)計(jì)使得在解析XML文檔時(shí)內(nèi)存占用少，效率高，并且還能夠?qū)崿F(xiàn)XML文檔的快速解析與遍歷、提供對(duì)XPath的支持。VTD的出現(xiàn)是XML解析技術(shù)的一大進(jìn)步，會(huì)對(duì)XML解析技術(shù)的發(fā)展產(chǎn)生巨大影響。

2.5 面向應(yīng)用的對(duì)象式解析技術(shù)

前面所談到的三種解析技術(shù)都是從XML的角度來處理文檔和建立模型，這對(duì)于主要關(guān)心文檔的XML結(jié)構(gòu)的應(yīng)用程序來說是適用的，但是有很多應(yīng)用程序僅僅將XML作為數(shù)據(jù)交換的媒介，它們更關(guān)心的是文檔數(shù)據(jù)本身。此時(shí)，面向應(yīng)用的對(duì)象式解析(或稱為XML數(shù)據(jù)綁定)可以使應(yīng)用程序在很大程度上忽略XML文檔的實(shí)際結(jié)構(gòu)，而直接使用文檔的數(shù)據(jù)內(nèi)容。

數(shù)據(jù)綁定是指將數(shù)據(jù)從一些存儲(chǔ)媒介(如XML文檔、文本文件和數(shù)據(jù)庫)中取出，并通過應(yīng)用程序表示這些數(shù)據(jù)的過程，即把數(shù)據(jù)綁定到虛擬機(jī)能夠理解并且可以操作的某種內(nèi)存中的結(jié)構(gòu)^[9]。數(shù)據(jù)綁定并不是一個(gè)新鮮的概念，其在關(guān)系數(shù)據(jù)庫上早已得到了廣泛的應(yīng)用，如Hibernate就是針對(duì)數(shù)據(jù)庫的輕量級(jí)數(shù)據(jù)綁定框架。而針對(duì)XML數(shù)據(jù)綁定的Castor框架在2000年就已經(jīng)出現(xiàn)，目前已經(jīng)涌現(xiàn)出了許多類似的框架，如JBind、JAXB、JiBX、Quick和Zeus等。

其中JAXB(Java Architecture for XML Binding)是一個(gè)處于不斷發(fā)展中的應(yīng)用于Java平臺(tái)的數(shù)據(jù)綁定框架，提供了一套在XML文檔和Java對(duì)象之間自動(dòng)映射的API，符合JSR31--XML數(shù)據(jù)綁定規(guī)范（XML Data Binding Specification）。該項(xiàng)目始于1999年8月，由Java Community Process開發(fā)，其1.0版本于2002年10月發(fā)布，目前最新版本為2007年9月17日發(fā)布的JAXB2.1.5。

如圖4，顯示了數(shù)據(jù)綁定在數(shù)據(jù)庫和XML文檔中的應(yīng)用。

圖4 數(shù)據(jù)綁定

在數(shù)據(jù)綁定中有三個(gè)重要概念^[9]：

l        編組(Marshalling)：把內(nèi)存中的數(shù)據(jù)轉(zhuǎn)換到存儲(chǔ)介質(zhì)中的過程。在Java和XML環(huán)境中，編組就是把一些Java對(duì)象轉(zhuǎn)化為一個(gè)(或多個(gè))XML文檔。其核心就在于把Java中的面向?qū)ο蠼Y(jié)構(gòu)轉(zhuǎn)化成適用于XML的扁平結(jié)構(gòu)。

l        解組(Unmarshalling)：把數(shù)據(jù)從存儲(chǔ)媒介轉(zhuǎn)換到內(nèi)存中的過程。在Java和XML環(huán)境中，即將XML文檔解組到Java虛擬機(jī)中，其復(fù)雜性在于從數(shù)據(jù)到Java代碼變量的映射。

l        映射(Mapping)：用于編組和解組的一套規(guī)則。

初看起來XML數(shù)據(jù)綁定和面向文檔的對(duì)象式解析較為相似，都在內(nèi)存中構(gòu)建文檔表示，同時(shí)內(nèi)部表示和標(biāo)準(zhǔn)的XML文檔之間可以互相轉(zhuǎn)換。但兩者之間的不同在于文檔模型盡可能接近的保存XML的文檔結(jié)構(gòu)，而數(shù)據(jù)綁定只關(guān)心應(yīng)用程序使用的文檔數(shù)據(jù)^[7]。如圖5所示，同一個(gè)XML文檔的文檔模型和數(shù)據(jù)綁定模型是完全不同的。

圖5 文檔模型和數(shù)據(jù)綁定模型比較

如果應(yīng)用程序使用文檔模型方法，那么獲得所需要的數(shù)據(jù)就必須在節(jié)點(diǎn)樹中根據(jù)父子節(jié)點(diǎn)關(guān)系進(jìn)行遍歷。而使用數(shù)據(jù)綁定方法，只需進(jìn)行正常的Java編程，訪問數(shù)據(jù)更加容易，速度也比文檔模型快得多。而且，XML數(shù)據(jù)綁定并不只是簡(jiǎn)化編程，由于它把許多文檔細(xì)節(jié)抽象出來，所以數(shù)據(jù)綁定所需的內(nèi)存通常少于文檔模型所需的內(nèi)存，如上圖中，文檔模型方法使用了10個(gè)單獨(dú)的對(duì)象，而數(shù)據(jù)綁定才使用2個(gè)。此外，由于要構(gòu)建的對(duì)象少得多，所以為XML文檔構(gòu)建數(shù)據(jù)綁定表示還可能更快^[7]。

在XML數(shù)據(jù)綁定中最為核心的是怎樣由XML文檔生成Java對(duì)象。目前有兩種方式：映射綁定方式和代碼生成方式^[8]。在映射綁定方式中，構(gòu)建自己的Java類，并向綁定框架指定這些類如何與XML文檔相關(guān)聯(lián)。如框架Castor和Quick就支持這種方式。而代碼生成方式則根據(jù)XML文檔結(jié)構(gòu)(即DTD或Schema形式的文法)自動(dòng)構(gòu)建相應(yīng)的Java類，如JAXB、Castor和JBind提供了根據(jù)XML文檔的Schema描述生成Java代碼，Quick和Zeus可根據(jù)DTD描述生成Java代碼。