System.Xml Namespace

Klassen

Schnittstellen

Enumerationen

Delegaten

Hinweise

Unterstützte Standards

Der System.Xml Namespace unterstützt die folgenden Standards:

• XML 1.0, einschließlich DTD-Unterstützung
• XML-Namespaces, sowohl stream-level als auch DOM
• XML-Schemas
• XPath-Ausdrücke
• XSLT-Transformationen
• DOM Level 1 Core
• DOM Level 2 Core

Lesen Sie den Abschnitt Unterschiede zwischen den W3C-Spezifikationen für zwei Fälle, in denen sich die XML-Klassen von den W3C-Empfehlungen unterscheiden.

Asynchrones Verarbeiten von XML

Die System.Xml.XmlReader Klassen System.Xml.XmlWriter enthalten eine Reihe asynchroner Methoden, die auf dem asynchronen Programmiermodell basieren. Diese Methoden können durch die Zeichenfolge "Async" am Ende ihrer Namen identifiziert werden. Mit diesen Methoden können Sie asynchronen Code schreiben, der Ihrem synchronen Code ähnelt, und Sie können ihren vorhandenen synchronen Code ganz einfach zu asynchronen Code migrieren.

• Verwenden Sie die asynchronen Methoden in Apps, bei denen es erhebliche Netzwerkdatenstromlatenz gibt. Vermeiden Sie die Verwendung der asynchronen APIs für Speicherdatenstrom- oder lokalen Dateistream-Lese-/Schreibvorgänge. Der Eingabedatenstrom XmlTextReaderund XmlTextWriter sollte auch asynchrone Vorgänge unterstützen. Andernfalls werden Threads weiterhin durch E/A-Vorgänge blockiert.

• Es wird nicht empfohlen, synchrone und asynchrone Funktionsaufrufe zu mischen, da Sie möglicherweise vergessen, das await Schlüsselwort zu verwenden oder eine synchrone API zu verwenden, bei der eine asynchrone API erforderlich ist.

• Legen Sie das XmlReaderSettings.AsyncXmlWriterSettings.Async Attribut nicht auf true fest, wenn Sie keine asynchrone Methode verwenden möchten.

• Wenn Sie vergessen, das await Schlüsselwort beim Aufrufen einer asynchronen Methode anzugeben, sind die Ergebnisse nicht deterministisch: Möglicherweise erhalten Sie das erwartete Ergebnis oder eine Ausnahme.

• Wenn ein XmlReader Objekt einen großen Textknoten liest, kann es nur einen Teiltextwert zwischenspeichern und den Textknoten zurückgeben, sodass das Abrufen der XmlReader.Value Eigenschaft durch einen E/A-Vorgang blockiert wird. Verwenden Sie die XmlReader.GetValueAsync Methode, um den Textwert im asynchronen Modus abzurufen, oder verwenden Sie die XmlReader.ReadValueChunkAsync Methode, um einen großen Textblock in Blöcken zu lesen.

• Wenn Sie ein XmlWriter Objekt verwenden, rufen Sie die XmlWriter.FlushAsync Methode vor dem Aufrufen XmlWriter.Close auf, um zu verhindern, dass ein E/A-Vorgang blockiert wird.

Unterschiede zu den W3C-Spezifikationen

In zwei Fällen, die Einschränkungen für Modellgruppenschemakomponenten umfassen, unterscheidet sich der System.Xml Namespace von den W3C-Empfehlungen.

Konsistenz in Elementdeklarationen:

In einigen Fällen erfüllt die System.Xml Implementierung bei Verwendung von Ersetzungsgruppen nicht die "Schemakomponenteneinschränkung: Elementdeklarationen konsistent", die im Abschnitt "Einschränkungen für Modellgruppenschemakomponenten " der W3C-Spezifikation beschrieben wird.

Das folgende Schema enthält z. B. Elemente, die denselben Namen haben, aber verschiedene Typen im gleichen Inhaltsmodell, und Ersetzungsgruppen werden verwendet. Dies sollte zu einem Fehler führen, das Schema wird jedoch System.Xml ohne Fehler kompiliert und überprüft.

<?xml version="1.0" encoding="utf-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

   <xs:element name="e1" type="t1"/>
   <xs:complexType name="t1"/>

   <xs:element name="e2" type="t2" substitutionGroup="e1"/>
      <xs:complexType name="t2">
         <xs:complexContent>
            <xs:extension base="t1">
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>

   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1"/>
         <xs:element name="e2" type="xs:int"/>
      </xs:sequence>
   </xs:complexType>
</xs:schema>

In diesem Schema enthält der Typ t3 eine Abfolge von Elementen. Aufgrund der Ersetzung kann der Verweis auf das Element e1 aus der Sequenz entweder in element e1 des Typs t1 oder im Element e2 des Typs t2resultieren. Der letztere Fall würde zu einer Abfolge von zwei e2 Elementen führen, wobei ein Element vom Typ t2 und das andere vom Typ xs:intist.

Einzigartige Partikelzuordnung:

Unter den folgenden Bedingungen erfüllt die System.Xml Implementierung nicht die "Schema Component Constraint: Unique Particle Attribution", die im Abschnitt "Constraints on Model Group Schema Components " der W3C-Spezifikation beschrieben wird.

• Eines der Elemente in der Gruppe verweist auf ein anderes Element.
• Das referenzierte Element ist ein Kopfelement einer Ersetzungsgruppe.
• Die Ersetzungsgruppe enthält ein Element mit demselben Namen wie eines der Elemente in der Gruppe.
• Die Kardinalität des Elements, das auf das Ersetzungsgruppenkopfelement verweist, und das Element mit demselben Namen wie ein Ersetzungsgruppenelement ist nicht behoben (minOccurs maxOccurs < ).
• Die Definition des Elements, das auf die Ersetzungsgruppe verweist, steht vor der Definition des Elements mit demselben Namen wie ein Ersetzungsgruppenelement.

Beispielsweise ist im Schema unterhalb des Inhaltsmodells mehrdeutig und sollte einen Kompilierungsfehler verursachen, das Schema jedoch System.Xml ohne Fehler kompiliert.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

  <xs:element name="e1" type="xs:int"/>
  <xs:element name="e2" type="xs:int" substitutionGroup="e1"/>

  <xs:complexType name="t3">
    <xs:sequence>
      <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
      <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="e3" type="t3"/>
</xs:schema>

Wenn Sie versuchen, den folgenden XML-Code anhand des obigen Schemas zu überprüfen, schlägt die Überprüfung mit der folgenden Meldung fehl: "Das Element 'e3' hat ein ungültiges untergeordnetes Element 'e2'" und eine XmlSchemaValidationException Ausnahme wird ausgelöst.

<e3>
  <e2>1</e2>
  <e2>2</e2>
</e3>

Um dieses Problem zu umgehen, können Sie Elementdeklarationen im XSD-Dokument austauschen. Beispiel:

<xs:sequence>
  <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
  <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
</xs:sequence>

wird wie folgt:

<xs:sequence>
  <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
  <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
</xs:sequence>

Hier ist ein weiteres Beispiel für dasselbe Problem:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
   <xs:element name="e1" type="xs:string"/>
   <xs:element name="e2" type="xs:string" substitutionGroup="e1"/>

   <xs:complexType name="t3">
      <xs:sequence>
         <xs:element ref="e1" minOccurs="0" maxOccurs="1"/>
         <xs:element name="e2" type="xs:int" minOccurs="0" maxOccurs="1"/>
      </xs:sequence>
   </xs:complexType>
   <xs:element name="e3" type="t3"/>
</xs:schema>

Wenn Sie versuchen, den folgenden XML-Code anhand des obigen Schemas zu überprüfen, schlägt die Überprüfung mit der folgenden Ausnahme fehl: "Unhandled Exception: System.Xml.Schema.XmlSchemaValidationException: The 'e2' el element is invalid - The value 'abc' is invalid according to its datatype 'http://www.w3.org/2001/XMLSchema:int' - The string 'abc' is not a valid Int32 value."

<e3><e2>abc</e2></e3>

Sicherheitsüberlegungen

Die Typen und Member im System.Xml Namespace basieren auf dem .NET-Sicherheitssystem. In den folgenden Abschnitten werden Sicherheitsprobleme behandelt, die für XML-Technologien spezifisch sind.

Beachten Sie außerdem, dass Sie beim Verwenden der System.Xml Typen und Member, wenn die XML Daten enthält, die potenzielle Auswirkungen auf den Datenschutz haben, Ihre App auf eine Weise implementieren müssen, die den Datenschutz Ihrer Endbenutzer berücksichtigt.

Externer Zugriff

Mehrere XML-Technologien haben die Möglichkeit, andere Dokumente während der Verarbeitung abzurufen. Beispielsweise kann sich eine Dokumenttypdefinition (DTD) im zu analysierenden Dokument befinden. Die DTD kann auch in einem externen Dokument leben, auf das vom analysierten Dokument verwiesen wird. Die XML-Schemadefinitionssprache (XSD) und XSLT-Technologien haben auch die Möglichkeit, Informationen aus anderen Dateien einzuschließen. Diese externen Ressourcen können einige Sicherheitsbedenken darstellen. Sie möchten beispielsweise sicherstellen, dass Ihre App Dateien nur von vertrauenswürdigen Websites abruft und dass die abgerufene Datei keine schädlichen Daten enthält.

Die XmlUrlResolver Klasse wird verwendet, um XML-Dokumente zu laden und externe Ressourcen wie Entitäten, DTDs oder Schemas aufzulösen und Direktiven zu importieren oder einzuschließen.

Sie können diese Klasse überschreiben und das XmlResolver zu verwendende Objekt angeben. Verwenden Sie die XmlSecureResolver Klasse, wenn Sie eine Ressource öffnen müssen, die Sie nicht steuern oder die nicht vertrauenswürdig ist. Der XmlSecureResolver Umbruch ermöglicht XmlResolver es Ihnen, die Ressourcen einzuschränken, auf die der zugrunde liegende XmlResolver Zugriff hat.

Denial of Service

Die folgenden Szenarien gelten als weniger anfällig für Denial-of-Service-Angriffe, da die System.Xml Klassen eine Möglichkeit zum Schutz vor solchen Angriffen bieten.

• Analysieren von TEXT-XML-Daten.

• Analysieren von binär-XML-Daten, wenn die binär-XML-Daten von Microsoft SQL Server generiert wurden.

• Schreiben von XML-Dokumenten und Fragmenten aus Datenquellen in das Dateisystem, Datenströme, ein TextWriteroder ein StringBuilder.

• Laden von Dokumenten in das DOM -Objektobjekt (Document Object Model), wenn Sie ein XmlReader Objekt verwenden und XmlReaderSettings.DtdProcessing auf .DtdProcessing.Prohibit

• Navigieren im DOM-Objekt.

Die folgenden Szenarien werden nicht empfohlen, wenn Sie sich Gedanken über Denial-of-Service-Angriffe machen oder wenn Sie in einer nicht vertrauenswürdigen Umgebung arbeiten.

• DTD-Verarbeitung.

• Schemaverarbeitung. Dazu gehört das Hinzufügen eines nicht vertrauenswürdigen Schemas zur Schemaauflistung, das Kompilieren eines nicht vertrauenswürdigen Schemas und das Validieren mithilfe eines nicht vertrauenswürdigen Schemas.

• XSLT-Verarbeitung.

• Analysieren beliebiger Datenströme des Benutzers, die binäre XML-Daten bereitgestellt haben.

• DOM-Vorgänge wie Abfragen, Bearbeiten, Verschieben von Unterstrukturen zwischen Dokumenten und Speichern von DOM-Objekten

Wenn Sie sich gedanken über Denial-of-Service-Probleme oder wenn Sie mit nicht vertrauenswürdigen Quellen umgehen, aktivieren Sie die DTD-Verarbeitung nicht. Dies ist standardmäßig für XmlReader Objekte deaktiviert, die von der XmlReader.Create Methode erstellt werden.

Wenn die DTD-Verarbeitung aktiviert ist, können Sie die XmlSecureResolver Klasse verwenden, um die Ressourcen einzuschränken, auf die der XmlReader Zugriff möglich ist. Sie können Ihre App auch so entwerfen, dass die XML-Verarbeitung arbeitsspeicher- und zeitschränkt ist. Sie können beispielsweise Zeitlimits in Ihrer ASP.NET-App konfigurieren.

Überlegungen zur Verarbeitung

Da XML-Dokumente Verweise auf andere Dateien enthalten können, ist es schwierig zu bestimmen, wie viel Verarbeitungsleistung erforderlich ist, um ein XML-Dokument zu analysieren. Beispielsweise können XML-Dokumente eine DTD enthalten. Wenn die DTD geschachtelte Entitäten oder komplexe Inhaltsmodelle enthält, kann es zu viel Zeit dauern, bis das Dokument analysiert wird.

Bei Verwendung XmlReaderkönnen Sie die Größe des Dokuments einschränken, das analysiert werden kann, indem Sie die XmlReaderSettings.MaxCharactersInDocument Eigenschaft festlegen. Sie können die Anzahl der Zeichen einschränken, die sich aus der Erweiterung von Entitäten ergeben, indem Sie die XmlReaderSettings.MaxCharactersFromEntities Eigenschaft festlegen. Beispiele zum Festlegen dieser Eigenschaften finden Sie in den entsprechenden Referenzthemen.

Die XSD- und XSLT-Technologien verfügen über zusätzliche Funktionen, die sich auf die Verarbeitungsleistung auswirken können. Beispielsweise ist es möglich, ein XML-Schema zu erstellen, das bei der Auswertung über ein relativ kleines Dokument einen erheblichen Zeitaufwand erfordert. Es ist auch möglich, Skriptblöcke in ein XSLT-Stylesheet einzubetten. Beide Fälle stellen eine potenzielle Sicherheitsrisiken für Ihre App dar.

Beim Erstellen einer App, die die XslCompiledTransform Klasse verwendet, sollten Sie die folgenden Elemente und deren Auswirkungen beachten:

• XSLT-Skripting ist standardmäßig deaktiviert. XSLT-Skripting sollte nur aktiviert werden, wenn Sie Skriptunterstützung benötigen und in einer voll vertrauenswürdigen Umgebung arbeiten.

• Die XSLT-Funktion document() ist standardmäßig deaktiviert. Wenn Sie die document() Funktion aktivieren, beschränken Sie die Ressourcen, auf die zugegriffen werden kann, indem Sie ein XmlSecureResolver Objekt an die XslCompiledTransform.Transform Methode übergeben.

• Erweiterungsobjekte sind standardmäßig aktiviert. Wenn ein XsltArgumentList Objekt, das Erweiterungsobjekte enthält, an die XslCompiledTransform.Transform Methode übergeben wird, werden die Erweiterungsobjekte verwendet.

• XSLT-Stylesheets können Verweise auf andere Dateien und eingebettete Skriptblöcke enthalten. Ein böswilliger Benutzer kann dies ausnutzen, indem Sie Daten oder Stylesheets bereitstellen, die bei ausführung dazu führen können, dass Ihr System verarbeitet wird, bis der Computer wenig Ressourcen aufweist.

• XSLT-Apps, die in einer gemischten Vertrauensumgebung ausgeführt werden, können zu Stylesheetspoofing führen. Beispielsweise kann ein böswilliger Benutzer ein Objekt mit einem schädlichen Stylesheet laden und an einen anderen Benutzer übergeben, der die XslCompiledTransform.Transform Methode anschließend aufruft und die Transformation ausführt.

Diese Sicherheitsprobleme können behoben werden, indem skripting oder die document() Funktion nicht aktiviert wird, es sei denn, das Stylesheet stammt aus einer vertrauenswürdigen Quelle und akzeptiert keine XslCompiledTransform Objekte, XSLT-Stylesheets oder XML-Quelldaten aus einer nicht vertrauenswürdigen Quelle.

Ausnahmenbehandlung

Ausnahmen, die von Komponenten auf niedrigerer Ebene ausgelöst werden, können Pfadinformationen offenlegen, die für die App nicht verfügbar gemacht werden sollen. Ihre Apps müssen Ausnahmen erfassen und entsprechend verarbeiten.

Weitere Informationen

• System.Xml.Xsl
• System.Xml.Schema
• System.Xml.Linq
• XML-Dokumente und -Daten