＋设为首页 ＋添加到收藏夹
自问世以来的八年间,xml已经流行起来,成为一种开放.半结构化的数据格式,用于保存数据以及通过web交换数据.由于具有简洁性与易读性,xml在应用开发人员当中备受欢迎,已成为企业架构中必不可少的一部分.
虽然很难列举xml的使用方式有几种,但有一点是可以肯定的::在进行其他操作之前,必须先对xml进行解析.实际上,选择合适的解析器往往是企业开发人员在项目中必须处理的早期决策之一.而这种决策一次又一次地归结为对两种流行的xml处理模型的选择:文档对象模型（dom）与用于xml的简单api（sax）.
乍一看,dom与sax各自的优缺点似乎是互为补充的:dom在内存中建立对象图;sax基于事件,内存中不保存任何内容.所以,如果文档很小.数据读取模式很复杂,dom就是很好的选择,不然,就使用sax.
不过,实际情况从来没有这么简单.开发人员之所以往往不愿意使用sax,原因是它很复杂,不过又只好使用它,因为没有其他切实可行的选择.不然,如果xml文件超过几百kb,dom的内存开销与性能下降对应用开发人员来说就会成为棘手的绊脚石,这样就无法满足项目对性能的最低要求.
但sax果真好得多吗?sax宣称的解析性能（通常比dom快好几倍）实际上往往带有欺骗性.事实证明,sax解析具有的笨拙.只向前（forward-only）的性质不但要求额外的实现工作,而且只要文档结构变得稍稍复杂,性能就会受到影响.如果开发人员决定不对文档进行多次扫描,就必须缓存文档,或者创建定制的对象模型.
不管怎样,性能都会受到影响,尽管可以通过内部使用sax来创建更高性能的实现方案,可它仍要创建自己的对象模型,该模型酷似dom,结果与其前身（apache soap）相比,性能几乎没什么提升.此外,sax与xpath的兼容性也不是很好,通常无法驱动可扩展样式表语言转换（xslt）处理.所以,sax解析绕开了xml处理存在的重大问题.
在寻求比sax更易使用的替代方案的过程中,越来越多的开发人员求助于用xml的流式api（stax）.与sax相比,stax解析器可以从xml文件拉取标记,而不是使用回调.虽然它们会显著提高易用性,但还是存在根本问题——stax的只向前解析方式仍需要繁琐的实现工作以及伴随而来的隐性性能成本.
因此,任何xml处理模型要具有广泛用途,必须完整呈现xml的层次结构.原因在于,由于xml被设计成通过web传送复杂数据,所以传送结构信息是xml固有的一项功能.
vtd-xml改变游戏规则
假设我们从头开始使用xml处理来克服dom与sax存在的上述问题.... 下一页