21

我可以在 .NET 中解析 XML。现在我至少可以在XmlTextReader和之间进行选择XDocument。这两者（或框架中包含的任何其他 XML 解析器）之间是否有任何比较？

也许这可以帮助我在不深入尝试两者的情况下做出决定。

XML 文件预计会相当小，与易用性相比，速度和内存使用是一个小问题。:-)

（我将从 C# 和/或 IronPython 中使用它们。）

谢谢！

4

2 回答 2

42

如果您乐于将所有内容读入内存，请使用XDocument. 它会让你的生活更轻松。LINQ to XML 是一个可爱的API。

基本上，如果您需要以流方式处理巨大的XML 文件，请使用XmlReader（例如）。这是一个更痛苦的API，但它允许流式传输（即只处理您需要的数据，因此您可以浏览一个巨大的文档并且一次只有少量内存）。XmlTextReader

但是，有一种混合方法 - 如果您有一个由小元素组成的巨大文档，您可以在元素开头创建XElement一个XmlReader定位，使用 LINQ to XML 处理该元素，然后将其移动XmlReader到下一个元素上，然后重新开始。

于 2011-11-11T15:57:31.967 回答
11

XmlTextReader有点不推荐使用，不要使用它。

  1. 来自 XmlTeam 的 msdn 博客

    有效的 Xml 第 1 部分：选择正确的 API

    避免使用XmlTextReader. 它包含许多在不破坏已经使用它的现有应用程序的情况下无法修复的错误。

    世界已经向前发展了，你呢？您应该避免使用的 XML API。

    过时的 API 很容易，因为编译器有助于识别它们，但还有两个你应该避免使用的 API——即XmlTextReader和XmlTextWriter. 我们在这些类中发现了许多错误，如果不破坏现有应用程序，我们就无法修复这些错误。简单的方法是弃用这些类并要求人们使用替代 API。不幸的是，这两个类不能被标记为过时，因为它们是 ECMA-335（公共语言基础设施）标准 ( http://www.ecma-international.org/publications/standards/Ecma-335.htm ) 的一部分 – 配套的 CLILibrary .xml 文件，它是分区 IV 的一部分）。

    好消息是，尽管这些类没有被弃用，但 .NET Framework 中已经有这些类的替代 API，并且迁移到它们相对容易。首先，有必要找到使用XmlTextReader或XmlTextWriter正在使用的地方（不幸的是，这是一个手动步骤）。现在所有出现的XmlTextReader都应该替换为XmlReader并且所有出现的XmlTextWriter都应该替换为XmlWriter（请注意，XmlTextReader派生自XmlReader和XmlTextWriter派生自，XmlWriter因此应用程序已经可以使用这些，例如作为形式参数）。最后一步是更改XmlReader/XmlWriter对象的实例化方式——而不是直接创建读取器/写入器，而是需要.Create()在两者上都存在静态工厂方法XmlReader和XmlWriterAPI。

  2. 此外，Visual Studio 中的智能感知不会XmlTextReader在 System.Xml 命名空间下列出。该类定义为：

    [EditorBrowsable(EditorBrowsableState.Never)]
public class XmlTextReader : XmlReader, IXmlLineInfo, IXmlNamespaceResolver

XmlReader.Create工厂方法根据传递的设置返回抽象类的其他内部实现。XmlReader

对于只进流 API（即不将整个内容加载到内存中），使用XmlReader viaXmlReader.Create方法。

要使用更简单的 API，请使用XDocument aka LINQ To XML。在此处和此处查找XDocumentvs。XmlDocument

于 2015-08-19T09:39:52.120 回答