像 SAX 和 StAX 这样的流式 xml 解析器比构建像 DOM 解析器这样的树结构的解析器更快,内存效率更高.SAX 是一个推送解析器,这意味着它是观察者模式(也称为侦听器模式)的一个实例.SAX 首先出现,但随后出现了 StAX - 一个拉式解析器,这意味着它基本上像迭代器一样工作.
Streaming xml-parsers like SAX and StAX are faster and more memory efficient than parsers building a tree-structure like DOM-parsers. SAX is a push parser, meaning that it's an instance of the observer pattern (also called listener pattern). SAX was there first, but then came StAX - a pull parser, meaning that it basically works like an iterator.
您可以在任何地方找到为什么更喜欢 StAX 而不是 SAX 的原因,但通常归结为:它更易于使用".
You can find reasons why to prefer StAX over SAX everywhere, but it usually boils down to: "it's easier to use".
在关于 JAXP 的 Java 教程中,StAX 被模糊地表示为 DOM 和 SAX 之间的中间:它比 SAX 更容易,比 DOM 更高效".但是,我从未发现任何迹象表明 StAX 会比 SAX 更慢或内存效率更低.
In the Java tutorial on JAXP StAX is vaguely presented as the middle between DOM and SAX: "it's easier than SAX and more efficient than DOM". However, I never found any clues that StAX would be slower or less memory efficient than SAX.
这一切让我想知道:有什么理由选择 SAX 而不是 StAX?
概括一下,我认为 StAX
可以和 SAX
一样高效.随着 StAX
的改进设计,我真的找不到任何首选 SAX
解析的情况,除非使用遗留代码.
To generalize a bit, I think StAX
can be as efficient as SAX
. With the improved design of StAX
I can't really find any situation where SAX
parsing would be preferred, unless working with legacy code.
编辑:根据这个博客 Java SAX 与 StAX StAX
不提供模式验证.
EDIT: According to this blog Java SAX vs. StAX StAX
offer no schema validation.
这篇关于我什么时候应该选择 SAX 而不是 StAX?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!