XmlTextReader与XDocument

Mar*_*ber 17 .net c# xml linq-to-xml xmltextreader

我能够在.NET中解析XML.现在我至少可以选择XmlTextReaderXDocument.这两者(或框架中包含的任何其他XML解析器)之间是否有任何比较?

也许这可以帮助我做出决定而不必深入尝试它们.

与易于使用相比,XML文件预计相当小,速度和内存使用是一个小问题.:-)

(我将从C#和/或IronPython中使用它们.)

谢谢!

Jon*_*eet 37

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

如果您需要以流式方式处理大型 XML文件,请使用XmlReader(例如XmlTextReader).这是一个更痛苦的API,但它允许流式传输(即只根据需要处理数据,因此您可以浏览一个巨大的文档,一次只有少量的内存).

然而,有一种混合方法 - 如果你有一个由小元素组成的巨大文档,你可以在元素的开头创建XElement一个XmlReader定位,使用LINQ to XML处理元素,然后移动XmlReader到下一个元素和重新开始.


naw*_*fal 10

XmlTextReader 有点不赞成,不要使用它.

  1. 来自XmlTeam的msdn博客

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

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

    世界已经转移,对吗?您应该避免使用的Xml API.

    过时的API很容易,因为编译器有助于识别它们,但是还有两个应该避免使用的API - 即XmlTextReaderXmlTextWriter.我们在这些类中发现了许多错误,我们无法在不破坏现有应用程序的情况下修复这些错误.简单的方法是弃用这些类,并要求人们使用替换API.不幸的是,这两个类不能被标记为过时,因为它们是ECMA-335(公共语言基础结构)标准(http://www.ecma-international.org/publications/standards/Ecma-335.htm)的一部分 - 伴侣CLILibrary .xml文件,它是分区IV的一部分).

    好消息是,尽管这些类没有被弃用,但在.NET Framework中已经有替换这些类,并且转移它们相对容易.首先,有必要找到使用XmlTextReaderXmlTextWriter正在使用的地方(不幸的是,这是一个手动步骤).现在,所有的事件XmlTextReader应改为XmlReader和所有的事件XmlTextWriter应改为XmlWriter(注意,XmlTextReader从派生XmlReaderXmlTextWriter派生自XmlWriter这样的应用程序已经可以使用这些例如作为正式参数).最后一步是更改XmlReader/ XmlWriter对象的实例化方式 - 而不是直接创建读取器/ 编写器,必须使用静态工厂方法和API..Create(),两者都XmlReaderXmlWriter

  2. 此外,Visual Studio中的intellisense不会XmlTextReader在System.Xml命名空间下列出.该类定义为:

    [EditorBrowsable(EditorBrowsableState.Never)]
    public class XmlTextReader : XmlReader, IXmlLineInfo, IXmlNamespaceResolver
    
    Run Code Online (Sandbox Code Playgroud)

XmlReader.Create工厂方法返回其他内部抽象类的实现XmlReader依赖于通过设置.


对于仅转发流API(即不将整个内容加载到内存中),请使用XmlReader via XmlReader.Create方法.

要使用更简单的API,请转到XDocument又称LINQ To XML.查找XDocumentVS XmlDocument 这里这里.