我试图读取一个庞大的XML文档，而且我想分块读取，而不是像XmlDocument一样将整个文件读入内存。我知道我可以使用XmlTextReader来实现，但我想知道是否有人在.NET中使用SAX？我知道Java开发人员信誓旦旦，我想知道它值得尝试吗？如果是，使用它的好处是什么？我正在寻找具体的信息。
4个回答
9
如果你只是想快速完成工作，那么（在.NET中）存在XmlTextReader，可以满足这一需求。
如果你想学习一个实际的标准（也可用于许多其他编程语言），它是稳定的，并且会迫使你非常高效而优雅地编码，但同时也极其灵活，请研究SAX。 然而，除非你将创建高度奇特的XML解析器，否则不要浪费时间。相反，寻找适用于您特定平台的下一代解析器（如XmlTextReader）。 SAX资源
最初为Java编写的SAX，你可以在此处找到原始开源项目，已经稳定了数年： http://sax.sourceforge.net/ 这里有同样项目的C#移植版本（HTML文档作为源下载的一部分），也很稳定： http://saxdotnet.sourceforge.net/ 如果你不喜欢C#实现，你可以通过COMInterop使用MSXML3或更高版本的COM DLL引用：http://msdn.microsoft.com/en-us/library/ms994343.aspx 这些文章来自Java世界，但可能说明了你需要成功采用这种方法的概念（也可能有可下载的Java源代码，可能很容易转换为C#）：
此线程描述了一种混合解析器，它使用.NET XmlTextReader实现了一个解析器，提供DOM和SAX的组合优势...
http://bytes.com/groups/net-xml/178403-xmltextreader-versus-dom
如果你想学习一个实际的标准（也可用于许多其他编程语言），它是稳定的，并且会迫使你非常高效而优雅地编码，但同时也极其灵活，请研究SAX。 然而，除非你将创建高度奇特的XML解析器，否则不要浪费时间。相反，寻找适用于您特定平台的下一代解析器（如XmlTextReader）。 SAX资源
最初为Java编写的SAX，你可以在此处找到原始开源项目，已经稳定了数年： http://sax.sourceforge.net/ 这里有同样项目的C#移植版本（HTML文档作为源下载的一部分），也很稳定： http://saxdotnet.sourceforge.net/ 如果你不喜欢C#实现，你可以通过COMInterop使用MSXML3或更高版本的COM DLL引用：http://msdn.microsoft.com/en-us/library/ms994343.aspx 这些文章来自Java世界，但可能说明了你需要成功采用这种方法的概念（也可能有可下载的Java源代码，可能很容易转换为C#）：
- 输出大型XML文档，第1部分 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc.html)
- 输出大型XML文档，第2部分 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc2.html)
- 使用SAX过滤器操作数据(http://www.ibm.com/developerworks/xml/library/x-tipsaxfilter/)
此线程描述了一种混合解析器，它使用.NET XmlTextReader实现了一个解析器，提供DOM和SAX的组合优势...
http://bytes.com/groups/net-xml/178403-xmltextreader-versus-dom
- EnocNRoll
8
如果你在谈论.NET的SAX，那么该项目似乎已经不再维护。上一个版本发布已经超过两年了。也许他们在上一个版本中完美解决了问题，但我不会打赌。作者Karl Waclawek似乎已经从网络上消失了。
至于Java下的SAX？当然，它很好用。不幸的是，SAX从未作为标准开发，因此所有非Java端口都在为自己的需要适应Java API。虽然DOM是一个相当糟糕的API，但它有一个优点，就是被设计用于多种语言和环境，因此易于在Java、C#、JavaScript、C等中实现。
至于Java下的SAX？当然，它很好用。不幸的是，SAX从未作为标准开发，因此所有非Java端口都在为自己的需要适应Java API。虽然DOM是一个相当糟糕的API，但它有一个优点，就是被设计用于多种语言和环境，因此易于在Java、C#、JavaScript、C等中实现。
- W. Craig Trader
2
根据这个页面，SAX是业界的事实标准（只是在微软世界中不是）：http://www.xml.org/xml-dev - EnocNRoll - AnandaGopal Pardue
1哦，值得注意的是，来自Java的官方SAX实现是稳定的，并且未被修改，甚至比.NET的SAX更长时间。基本上，只有在XML标准进一步发展时，才需要对任一代码库进行改进。 - EnocNRoll - AnandaGopal Pardue
5
我认为至少有两个原因不建议使用SAX：
- SAX是“推”模型，而XmlReader是一种拉解析器，具有许多优点。
- 依赖于第三方库而不是使用标准的.NET API。
- Greg
1
那么XmlReader基本上类似于StAX吗？ - stephanmg
5
个人而言，我更喜欢SAX模型，因为XmlReader有一些非常恼人的陷阱，可能会导致您的代码跳过元素而出现错误。大多数代码都会围绕while（rdr.Read（））模型进行结构化，但是如果在循环内部有任何“ReadString”或“ReadInnerXml（）”，则会发现自己在下一次迭代中跳过元素。
由于SAX是基于事件的，因此这种情况永远不会发生，因为您无法执行任何操作，这可能会导致解析器寻找前面的内容。
我个人的感觉是，微软发明了XmlReader更好的概念，并解释了推/拉模型，但我并不完全认同。所以微软认为您不需要使用XmlReader创建状态机，但这对我来说没有意义，但无论如何，这只是我的观点。
由于SAX是基于事件的，因此这种情况永远不会发生，因为您无法执行任何操作，这可能会导致解析器寻找前面的内容。
我个人的感觉是，微软发明了XmlReader更好的概念，并解释了推/拉模型，但我并不完全认同。所以微软认为您不需要使用XmlReader创建状态机，但这对我来说没有意义，但无论如何，这只是我的观点。
- Brett Ryan
3
1你的观点似乎基于你通过艰难的方式学到了一些关于
XmlReader的知识。这是形成技术观点的最佳方式吗？ - John Saunders约翰，我想你是对的，我道歉。尽管我发现XmlReader是许多奇怪的软件错误的根源，这些错误可以通过简单的基于SAX的方法避免。 - Brett Ryan
我同意Brett的观点。XmlTextReader过于古老，而且有太多几乎相同的方法。此外，它的模型鼓励对接受的Xml结构进行非常宽松的定义。虽然这对某些应用程序很方便，但在我的大多数应用程序中，我希望拒绝不符合预期结构的代码。我真正想要的是一个RDP xml库，我很惊讶没有人写过这样的库。尽管如此，我更喜欢SAX。 - user430788
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
XmlTextReader已经被弃用，不建议直接使用。应该通过从XmlTextReader派生出自己的XmlReader类来使用它。应该使用XmlReader.Create代替直接使用XmlTextReader。 - John Saunders