SAX解析实例:http://www.iteye.com/topic/763895
Java Sax解析是按照xml文件的顺序一步一步的来解析,在解析xml文件之前,我们要先了解xml文件的节点的种类,一种是ElementNode,一种是TextNode。
为了更好地解决大型 XML 处理的问题,Java 开发人员发明了 SAX。SAX 采用事件驱动的方式来处理 XML,它的处理方式是:为每一个元素、属性、内容(这些都认为是事件)定义一个回调方法,这个回调方法由应用程序提供。解析器以数据流的方式读入 XML,当遇到某个元素、属性、内容时就调用相应的回调方法。SAX 的优点是处理效率高,适合处理大型 XML。缺点是 SAX 对 XML 是只读的,不能够对 XML 进行写操作,而且 SAX 处理 XML 中前后相互关联的元素时也没有 DOM 方便,因为应用程序必须自己保留以前事件的状态信息。只会顺序读入所需要的文件内容,不会一次性全部读取,不受文件大小的限制。
但用SAX解析器的时候编码工作会比较困难,而且很难同时访问同一个文档中的多处不同数据。
Dom解析实例:http://www.iteye.com/topic/763926
Dom解析是将xml文件全部载入,组装成一颗dom树,然后通过节点以及节点之间的关系来解析xml文件
DOM 对于 XML 的处理方式就是把整个 XML 读到内存中形成一棵树状结构,然后用各种方法对这棵数进行遍历、插入、删除、修剪等操作。因为 DOM 是 W3C 的正式标准,所有的语言都有支持 DOM 的解析器,包括 Java、C/C++、Perl、JavaScript 等等。DOM 的优点是信息量丰富(全部都在内存中),而且可以随机访问,尤其是在处理前后相互关联的元素时非常方便。DOM 的缺点是 XML 应用程序在处理 XML 之前必须先由 XML 解析器把整个 XML 读进内存并生成树状结构,如果 XML 非常大,例如 10M,解析的过程是非常慢的。如果再加上 XSLT 转换(这是一种必须要使用 DOM 的操作)这类同样耗费资源的操作,可能会耗尽系统的内存资源。所以标准 DOM 只适合于中小型 XML 的处理。
DOM是以层次结构组织的节点或信息片断的集合。这个层次结构允许开发人员在树中寻找特定信息。分析该结构通常需要加载整个文档和构造层次结构,然后才能做任何工作。DOM 以及广义的基于树的处理具有几个优点。首先,由于树在内存中是持久的,因此可以 修改它以便应用程序能对数据和结构作出更改。它还可以在任何时候在树中上下导航,而不是像SAX那样是一次性的处理。
SAX:只能读,不能修改,只能顺序访问,适合对大型的XML的解析,解析速度快!
DOM:不仅能读,还能修改,而且能够实现随机访问,缺点是解析速度慢,只适合解析小型文档
解析速度慢(要在内存中生成节点树,而生成树是比较费时的)
SAX:应用于保存大量数据的XML(为什么要用XML保存大量的数据类容?答:可以实现异构系统
的数据访问,实现跨平台!)
DOM:一般应用与小型的配置XML,方便我们操作!
与DOM 比较而言,SAX是一种轻量型的方法。我们知道,在处理DOM的时候,我们需要读入整个的XML文档,然后在内存中创建DOM树,生成DOM树上的每个 Node对象。当文档比较小的时候,这不会造成什么问题,但是一旦文档大起来,处理DOM就会变得相当费时费力。特别是其对于内存的需求,也将是成倍的增 长,以至于在某些应用中使用DOM是一件很不划算的事(比如在applet中)。这时候,一个较好的替代解决方法就是SAX。
SAX 在概念上与DOM完全不同。首先,不同于DOM的文档驱动,它是事件驱动的,也就是说,它并不需要读入整个文档,而文档的读入过程也就是SAX的解析过程。所谓事件驱动,是指一种基于回调(callback)机制的程序运行方法。在XMLReader接受XML文档,在读入XML 文档的过程中就进行解析,也就是说读入文档的过程和解析的过程是同时进行的,这和DOM区别很大。解析开始之前,需要向XMLReader注册一个 ContentHandler,也就是相当于一个事件监听器,在 ContentHandler中定义了很多方法,比如startDocument(),它定制了当在解析过程中,遇到文档开始时应该处理的事情。当 XMLReader读到合适的内容,就会抛出相应的事件,并把这个事件的处理权代理给ContentHandler,调用其相应的方法进行响应。
如果想结合DOM解析和SAX解析,可以使用JDOM。
关于SAX2,有以下两篇文章:
http://www.blogjava.net/junhong/archive/2006/11/24/83188.html
http://wtnzuodan.blog.163.com/blog/static/955283002008111792141674/
还有一篇没看懂:
http://blog.csdn.net/zgjxwl/article/details/9380079