SAX 与 XmlTextReader - C# 中的 SAX答案

【问题标题】：SAX vs XmlTextReader - SAX in C#SAX 与 XmlTextReader - C# 中的 SAX
【发布时间】：2010-09-12 18:35:40
【问题描述】：

我正在尝试读取一个大型 XML 文档，并且我想以块的形式读取它，而不是 XmlDocument 将整个文件读取到内存中的方式。我知道我可以使用XmlTextReader 来执行此操作，但我想知道是否有人将 SAX 用于 .NET？我知道 Java 开发人员对此深信不疑，我想知道是否值得一试，如果值得一试，使用它有什么好处。我正在寻找细节。

【问题讨论】：

XmlTextReader 已被弃用，无法直接使用。它只能用于通过派生自XmlTextReader 创建您自己的XmlReader 类。应该改用XmlReader.Create。
@John：请问您没有任何来源可以证明吗？
请参阅XmlTextReader class 处的“备注”：“注意在 .NET Framework 2.0 版本中，推荐的做法是使用 XmlReader.Create 方法创建 XmlReader 实例。这使您可以充分利用此版本中引入的新功能的优势。有关更多信息，请参阅Creating XML Readers。"

标签： c# java xml sax

【解决方案1】：

如果您只想快速完成工作，XmlTextReader 就是为此目的而存在的（在 .NET 中）。

如果您想学习一个稳定的事实标准（并且可以在许多其他编程语言中使用），它会迫使您非常高效和优雅地编写代码，但它也非常灵活，那么请研究 SAX。 但是，除非您要创建高度深奥的 XML 解析器，否则不要浪费您的时间。相反，为您的特定平台寻找下一代解析器（如 XmlTextReader）的解析器。

SAX 资源
SAX 最初是为 Java 编写的，您可以在此处找到已稳定数年的原始开源项目： http://sax.sourceforge.net/

这里有同一个项目的 C# 端口（带有 HTML 文档作为源下载的一部分）；它也很稳定： http://saxdotnet.sourceforge.net/

如果您不喜欢 C# 实现，您可以随时使用 MSXML3 或更高版本通过 COMInterop 引用 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 时代，我只使用过 SAX，但它需要一些非常先进的编码技术。 在这一点上，这是不值得的麻烦。

混合解析器的有趣概念
该线程描述了一个混合解析器，它使用 .NET XmlTextReader 来实现一个提供 DOM 和 SAX 优势组合的解析器...
http://bytes.com/groups/net-xml/178403-xmltextreader-versus-dom

【讨论】：

【解决方案2】：

如果您说的是SAX for .NET，则该项目似乎没有得到维护。上一次发布是在 2 年前。也许他们在上一个版本中做到了完美，但我不会打赌。作者 Karl Waclawek 似乎已经从网上消失了。

Java 下的 SAX 呢？你打赌，这很棒。不幸的是，SAX 从未作为标准开发，因此所有非 Java 端口都在根据自己的需要调整 Java API。虽然 DOM 是一个非常糟糕的 API，但它的优点是针对多种语言和环境设计，因此很容易在 Java、C#、JavaScript、C 等中实现。

【讨论】：

嗯，根据这个页面，SAX 是业界事实上的标准（只是不在微软世界中）：xml.org/xml-dev
哦，可能值得注意的是，来自 Java 的官方 SAX 实现是表格，并且比 SAX for .NET 更久未修改。唯一需要对任一代码库进行改进的情况基本上是 XML 标准进一步发展。

【解决方案3】：

我认为使用 SAX 没有任何好处，至少有两个原因：

SAX 是“推”模型，而 XmlReader 是具有 a number of benefits 的拉解析器。
依赖于第 3 方库而不是使用标准的 .NET API。

【讨论】：

所以 XmlReader 基本上与 StAX 相似？

【解决方案4】：

就个人而言，我更喜欢 SAX 模型，因为 XmlReader 有一些非常烦人的陷阱，这些陷阱可能会导致代码中的错误，从而可能导致代码跳过元素。大多数代码将围绕 while(rdr.Read()) 模型构建，但如果您在该循环中有任何“ReadString”或“ReadInnerXml()”，您会发现自己在下一次迭代中跳过了元素。

由于 SAX 是基于事件的，这永远不会发生，因为您无法执行任何会导致解析器提前搜索的操作。

我个人的感觉是，微软发明了 XmlReader 更好地解释推/拉模型的概念，但我并不真正相信它。所以微软认为你不需要用 XmlReader 创建状态机，这对我来说没有意义，但无论如何，这只是我的意见。

【讨论】：

您的意见似乎是基于您对XmlReader 的一些了解。这是就技术问题形成意见的最佳方式吗？
约翰，我想你是对的，我很抱歉。虽然我确实发现 XmlReader 是软件中许多奇怪错误的错误，这些错误可以通过简单的基于 SAX 的方法来避免。
我同意布雷特的观点。 XmlTextReader 是神秘的，并且有太多的方法来做几乎同样的事情。此外，它的模型鼓励对您接受的 Xml 结构进行非常松散的定义。虽然这对某些应用程序很方便，但在我的大部分应用程序中，我想拒绝不符合我预期结构的代码。我真正想要的是一个 RDP xml 库，我很惊讶没有人写过。如果没有这个，我更喜欢 SAX。