详解XML解析(一)—解析接口浅析

前端之家收集整理的这篇文章主要介绍了详解XML解析(一)—解析接口浅析前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在DRP项目中接触到了一个XML解析工具DOM4J,它作为解析工具的据说性能非常优秀。但是刚刚接触解析工具不久,并且也没有使用过其他的解析工具,因此对于DOM4J的性能没有直接的感受(没有参照物)。不过,本篇博客先暂时不直接讲DOM4J。之前说过,对于工具特别是优秀的工具,我们要学习的不只是使用而已,而需要更深层次的学习。好了,开始吧,首先我们要先了解一下解析器。

解析器

解析器的作用就是将XML文档转换为应用程序可操作的对象。即读入一个XML文档并分析其结构。然后,应用程序通过解析接口访问或者操作XML文档。下面以DOM为例,了解一下解析器和解析接口在应用中的位置。


基于DOM(Document Object Model)

DOM之前的博客有过介绍了,即文档对象模型。XML转换是通过解析器完成的,之后我们才能对XML文档进行读取操作。使用DOM操作XML文档主要需要通过以下几种操作:加载XML文档→遍历XML文档→操作控制XML文档节点(增、删、改)。

DOM基本接口:

Document:是对文档进行操作的接口,同时该节点是DOM对象树的根节点。提供了对文档中的数据进行访问和操作的入口。另外,元素、节点、注释、处理指令都无法脱离文档的上下文关系而独立存在。所以在Document接口还提供了创建其他节点对象的方法
Node:代表DOM树中的一个节点。Node 接口在整个DOM树中具有举足轻重的地位,DOM接口中有很大一部分接口是从Node接口继承过来的,例如,Element、Attr、 CDATASection等接口,都是从Node继承过来的。
NodeList:提供了对节点集合的抽象定义,它并不包含如何实现这个节点集的定义。NodeList用于表示有顺序关系的一组节点,比如某个节点的子节点序列。在 DOM中,NodeList的对象是"live"的,换句话说,对文档的改变,会直接反映到相关的NodeList对象中。例如,如果通过DOM获得一个 NodeList对象,该对象中包含了某个Element节点的所有子节点的集合,那么,当再通过DOM对Element节点进行操作(添加删除、改动 节点中的子节点)时,这些改变将会自动地反映到NodeList对象中,而不需DOM应用程序再做其他额外的操作。
NamedNodeMap:表示可以通过名字来访问的一组节点集合。

DOM接口优缺点分析

首先我们要了解DOM是要在内存中建立文档树。这是它的特点的决定性因素。因为,树在内存中的存在是持久的。所以,这就保证了DOM接口随机访问的特点。同时,也是因为树在内存中的存在,因此对于大型的XML文档的解析会耗费内存。而接下来介绍的SAX接口则与DOM接口完全相反。

基于SAX(Simple API for XML)

相对与SAX是一种轻量型的方法,它针对的就是DOM接口处理大文档时比较费时、费力、非资源的问题。它是一种替代。SAX接口依序读入文件并产生相应的事件。

  主要接口:

SAXParserFactory:用来按照系统属性中定义的创建一个分析器实例。
Parser:定义了类似setDocumentHandler的方法来创建事件处理函数
  DocumentHandler :当分析器遇到XML文档中的标记时激活该接口中的startDocument,endDocument,startElement,endElement等方法
ErrorHandler:当分析器遇到不用的错误时,就会激活error、fatalError等方法
DTDHandler:处理DTD中定义时,调用该接口中的方法

优缺点分析

这种处理的优点非常类似于流媒体的优点。分析能够立即开始,而不是等待所有的数据被处理。而且,由于应用程序只是在读取数据时检查数据, 因此不需 要将数据存储在内存中。这对于大型文档来说是个巨大的优点。事实上,应用程序甚至不必解析整个文档;它可以在某个条件得到满足时停止解析。一般来说,SAX 比 DOM 快许多。
另一方面,由于应用程序没有以任何方式存储数据,使用 SAX 来更改数据或在数据流中往后移是不可能的。

基于JDOM(Java Document Object Model)

这种接口类似于DOM接口因此不再复述。

总的来说,对于XML的访问和操作要通过接口来实现,而解析器则实现接口。这也就是上面图所表达的意思。另外关于选择使用哪个接口来访问XML数据,这还是根据各个接口的特点自己选择。并且,博客里介绍的两种接口特点还是比较鲜明的,因此适用的环境应该也比较清晰。对解析接口应该有所了解了,下篇介绍DOM4J。

猜你在找的XML相关文章