解析xml的几种方法，他们的原理，比较 以及JAVA源码

第一种方法 

对象模型 API 定义了层次化对象模型来表示 XML 文档。换句话说，对应 XML 语法中的每个概念定义相应的类：元素、属性、实体、文档。解析器读入 XML 文档的时候，建立 XML 语法和类之间的一对一映射。比如，每遇到一个标记，就实例化一个元素类。 

毫 不奇怪，对哪种数据模型最好存在一些争议。W3C 规范化了 DOM，它的主要优点是可移植性：它是作为一种 CORBA 接口定义的，被映射到很多语言。因此如果了解了 JavaScript 中的 DOM，也就知道了 Java、C++、Perl、Python 和其他语言中的 DOM。 

另一种数据模型是 JDOM，一种针对 Java 优化的 DOM（专用于 Java），和 Java 语言结合得更紧密，但是按照定义缺乏可移植性。 

尽 管人们可以继续商讨对 XML 语法来说哪种数据模型最好，但我认为没有多少意义，因为各种基于对象的 API 其优点和不足基本上是一样的。从好的方面来说，如果熟悉 XML 语法的话，对象模型 API 更容易理解。因为它直接从 XML 语法映射到类，很容易学习、使用和调试。 

简单的代价是效率，至少对很多项目而言是这样。读入文档的时候，解析器根据语法结构创建对象。对很多应用程序来说，XML 语法并不是很合适： 

* XML 语法非常罗嗦，即使文档很小，解析器也要创建很多对象。 
* 对 XML 词汇表进行的优化通常针对的是存储和数据传输效率，而不是处理，因而应用程序可能需要对数据进行预处理，比方说，在开始真正的处理之前，先计算部分和或者 合并其他来源的数据。很多情况下，在处理之前必须将数据从 XML 对象模型复制到应用程序专用的对象模型或者数据库。 
* 因为这种对象模型是通用的，包含很多应用程序并不需要的对象之间的引用（比如，从子元素到父元素的反向引用）。这些引用进一步增加了内存消耗。 

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

第二种方法 

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

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

它的优点很明显： 

* 统计应用程序或总结信息的任何应用程序都可以从中获益，因为它们的数据模型只需计算总计而无需复制整个文档。 
* 类似的，即使动态处理文档的应用程序（比如把文档加载到数据库中）不需处理或者只需少量处理，也可从中受益，因为根本不需要存储数据。 

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

效率的代价是简单性的损失。事件 API 一向以难用著称，因为应用程序员要负责更多的操作。虽然短期看来如此，但根据我的经