1  引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

流式解析是將XML文檔作為一個數(shù)據(jù)流來處理，因此，它具有類似于流媒體的優(yōu)點，能夠立即開始讀取數(shù)據(jù)，而不是等待所有的數(shù)據(jù)被處理。而且，由于應(yīng)用程序只是在讀取數(shù)據(jù)時檢查數(shù)據(jù)，不需要將整個文檔一次加載到內(nèi)存中，使得在處理大型文檔時具有較好的時間和空間上的效率。然而效率的代價是易用性的降低，流式解析編程較為復(fù)雜，程序員需要負責更多的操作。并且由于應(yīng)用程序沒有以任何方式存儲數(shù)據(jù)，所以使得更改數(shù)據(jù)或在數(shù)據(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)不會返回給應(yīng)用程序^[3]。解析器通過回調(diào)的方式進行數(shù)據(jù)處理。

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

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

圖1 SAX解析器生成的事件

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

SAX解析技術(shù)具有所有流式解析技術(shù)的優(yōu)點和缺點，但是由于在整個解析過程中，解析器掌握著控制權(quán)直到文檔結(jié)束，應(yīng)用程序很難在獲得所需的部分數(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ù)調(diào)用解析器獲得下一個事件，直到文檔結(jié)束。通過保留解析過程的控制權(quán)，可以簡化調(diào)用代碼來準確地處理它預(yù)期的內(nèi)容，并且可隨時停止解析。此外，由于該方式?jīng)]有基于處理程序回調(diào)，應(yīng)用程序也不需要像SAX中那樣模擬解析器的狀態(tài)。

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

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

而較為高級的基于迭代器的API則以對象方式返回事件，每個事件對象都封裝了它所表示的特定XML結(jié)構(gòu)固有的信息，因此可直接利用其方法獲得屬于該結(jié)構(gòu)的信息，但也需要額外的對象創(chuàng)建開銷。相對于基于指針的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的最新標準，比早期出現(xiàn)的XPP (Xml Pull Parser)拉式解析器功能更為強大，也得到了更為廣泛的應(yīng)用。

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

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

DOM(Document Object Model)是用與平臺和語言無關(guān)的方式對XML文檔進行建模的官方W3C標準^[6]，其目標是提供一個可以通用于各種程序語言、操作系統(tǒng)和應(yīng)用程序的接口。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的基礎(chǔ)上添加了對DTD、XML模式和XPath的支持^[1]。

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

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

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

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

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

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

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

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

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

圖3 VTD記錄的比特層格式

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

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

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

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

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

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

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

其中JAXB(Java Architecture for XML Binding)是一個處于不斷發(fā)展中的應(yīng)用于Java平臺的數(shù)據(jù)綁定框架，提供了一套在XML文檔和Java對象之間自動映射的API，符合JSR31--XML數(shù)據(jù)綁定規(guī)范（XML Data Binding Specification）。該項目始于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ù)綁定中有三個重要概念^[9]：

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

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

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

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

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

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

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