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 auf Streamebene als auch auf DOM

• XML-Schemas

• XPath-Ausdrücke

• XSLT-Transformationen

• DOM Level 1 Core

• DOM Level 2 Core

Im Abschnitt Unterschiede zu den W3C-Spezifikationen finden Sie zwei Fälle, in denen sich die XML-Klassen von den W3C-Empfehlungen unterscheiden.

Verwandte Namespaces

.NET stellt auch andere Namespaces für XML-bezogene Vorgänge bereit. Eine Liste, Beschreibungen und Links finden Sie unterSystem.Xml Namespaces.

asynchrone Verarbeitung von XML

Die System.Xml.XmlReader Klassen und 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 problemlos zu asynchronem Code migrieren.

• Verwenden Sie die asynchronen Methoden in Apps, bei denen eine erhebliche Netzwerkdatenstromlatenz besteht. Vermeiden Sie die Verwendung der asynchronen APIs für Lese-/Schreibvorgänge im Arbeitsspeicherstream oder lokalen Dateistream. Der Eingabestream , XmlTextReaderund XmlTextWriter sollte ebenfalls 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, die await Schlüsselwort (keyword) zu verwenden oder eine synchrone API zu verwenden, bei der eine asynchrone API erforderlich ist.

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

• Wenn Sie vergessen, die await Schlüsselwort (keyword) anzugeben, wenn Sie eine asynchrone Methode aufrufen, sind die Ergebnisse nicht deterministisch: Sie erhalten möglicherweise das erwartete Ergebnis oder eine Ausnahme.

• Wenn ein XmlReader Objekt einen großen Textknoten liest, kann es nur einen teiligen Textwert zwischenspeichern und den Textknoten zurückgeben, sodass das Abrufen der XmlReader.Value Eigenschaft möglicherweise 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 das Blockieren eines E/A-Vorgangs zu vermeiden.

Unterschiede zu den W3C-Spezifikationen

In zwei Fällen, die Einschränkungen für Modellgruppenschemakomponenten beinhalten, 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 Substitutionsgruppen nicht die "Schemakomponenteneinschränkung: Elementdeklarationen konsistent", die im Abschnitt Einschränkungen für Modellgruppenschemakomponenten der W3C-Spezifikation beschrieben wird.

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

<?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 Sequenz von Elementen. Aufgrund der Ersetzung kann der Verweis auf das Element e1 aus der Sequenz als Ergebnis entweder das Element e1 des Typs t1 oder das Element e2 des Typs t2 haben. Der letztere Fall würde zu einer Sequenz von zwei e2 Elementen führen, wobei eines vom Typ t2 und das andere vom Typ xs:intist.

Eindeutige Partikelzuordnung:

Unter den folgenden Bedingungen erfüllt die System.Xml Implementierung nicht die "Schemakomponenteneinschränkung: Eindeutige Partikelzuordnung", die im Abschnitt Einschränkungen für Modellgruppenschemakomponenten der W3C-Spezifikation beschrieben wird.

• Eines der Elemente in der Gruppe verweist auf ein anderes Element.

• Das Element, auf das verwiesen wird, ist ein Anfangselement einer Ersetzungsgruppe.

• Die Ersetzungsgruppe enthält ein Element, das denselben Namen wie eines der Elemente in der Gruppe hat.

• Die Kardinalität des Elements, das auf das Substitutionsgruppenkopfelement und das Element mit demselben Namen wie ein Substitutionsgruppenelement verweist, ist nicht festgelegt (minOccurs < maxOccurs).

• Die Definition des Elements, das auf die Ersetzungsgruppe verweist, geht der Definition des Elements mit demselben Namen wie ein Substitutionsgruppenelement voran.

So ist das Inhaltsmodell im unten aufgeführten Schema nicht eindeutig und sollte zu einem Kompilierungsfehler führen; System.Xml kompiliert das Schema jedoch ohne Fehler.

<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>

zu

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

Hier sehen Sie 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: "Nicht behandelte Ausnahme: System.Xml. Schema.XmlSchemaValidationException: Das 'e2' el-Element ist ungültig – Der Wert 'abc' ist gemäß seinem Datentyp 'http://www.w3.org/2001/XMLSchema:int' ungültig . Die Zeichenfolge 'abc' ist kein gültiger Int32-Wert."

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

Sicherheitshinweise

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

Beachten Sie außerdem: Wenn Sie die System.Xml Typen und Member verwenden, müssen Sie, wenn der XML-Code Daten enthält, die potenzielle Auswirkungen auf den Datenschutz haben, Ihre App so implementieren, dass die Privatsphäre Ihrer Endbenutzer respektiert wird.

Externer Zugriff

Einige XML-Technologien können bei der Verarbeitung andere Dokumente abrufen. In dem gerade analysierten Dokument kann sich z. B. eine DTD (Document Type Definition) befinden. Die DTD kann sich auch in einem externen Dokument befinden, auf das in dem gerade analysierten Dokument verwiesen wird. Die XSD- und XSLT-Technologien können auch Informationen aus anderen Dateien verwenden. Diese externen Ressourcen können einige Sicherheitsbedenken darstellen. Beispielsweise sollten Sie 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 zum Laden von XML-Dokumenten und zum Auflösen externer Ressourcen wie Entitäten, DTDs oder Schemas sowie zum Importieren oder Einschließen von Anweisungen verwendet.

Sie können diese Klasse überschreiben und das XmlResolver zu verwendende Objekt angeben. Verwenden Sie die XmlSecureResolver-Klasse, wenn Sie eine Ressource öffnen möchten, die nicht von Ihnen gesteuert wird oder die nicht vertrauenswürdig ist. Der XmlSecureResolver umschließt einen XmlResolver und ermöglicht das Einschränken der Ressourcen, auf die der zu Grunde liegende XmlResolver Zugriff hat.

Denial of Service

Die folgenden Szenarios gelten als weniger empfindlich für Denial-of-Service-Angriffe, da die System.Xml-Klassen Schutz vor diesen Angriffen bieten.

• Analysieren von XML-Textdaten.

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

• Schreiben von XML-Dokumenten und -Fragmenten aus Datenquellen in ein Dateisystem, einen Stream, einen TextWriter oder einen StringBuilder.

• Laden von Dokumenten in das DOM-Objekt (Document Object Model), wenn ein XmlReader-Objekt verwendet wird und XmlReaderSettings.DtdProcessing auf DtdProcessing.Prohibit festgelegt ist.

• Navigieren im DOM-Objekt.

Die folgenden Szenarios sind nicht zu empfehlen, wenn Sie Denial-of-Service-Angriffe befürchten oder wenn Sie in einer nicht vertrauenswürdigen Umgebung arbeiten.

• DTD-Verarbeitung.

• Schema-Verarbeitung. Dazu gehört das Hinzufügen eines nicht vertrauenswürdigen Schemas zur Schemaauflistung, das Kompilieren eines nicht vertrauenswürdigen Schemas und das Validieren mit einem nicht vertrauenswürdigen Schema.

• XSLT-Verarbeitung.

• Analysieren eines beliebigen Streams von binären XML-Daten eines Benutzers

• DOM-Operationen wie Abfragen, Bearbeiten, Verschieben von Unterstrukturen zwischen Dokumenten und Speichern von DOM-Objekten.

Wenn Sie Sich um Denial-of-Service-Probleme sorgen oder mit nicht vertrauenswürdigen Quellen zu tun haben, aktivieren Sie die DTD-Verarbeitung nicht. Dies ist standardmäßig für XmlReader Objekte deaktiviert, die von der XmlReader.Create -Methode erstellt werden.

Wenn Sie die DTD-Verarbeitung aktiviert haben, können Sie die XmlSecureResolver -Klasse verwenden, um die Ressourcen einzuschränken, auf die der XmlReader zugreifen kann. Sie können Ihre App auch so entwerfen, dass die XML-Verarbeitung arbeitsspeicher- und zeitlimitiert ist. Beispielsweise können Sie Timeoutlimits in Ihrer ASP.NET-App konfigurieren.

Überlegungen zur Verarbeitung

Da XML-Dokumente Verweise auf andere Dateien enthalten können, ist es schwierig, den für die Analyse eines XML-Dokuments erforderlichen Verarbeitungsaufwand zu ermitteln. XML-Dokumente können z B. eine DTD enthalten. Wenn die DTD verschachtelte Entitäten oder komplexe Inhaltsmodelle umfasst, kann die Analyse des Dokuments außerordentlich viel Zeit beanspruchen.

Bei der Verwendung von XmlReader können Sie die Größe des zu analysierenden Dokuments mit der XmlReaderSettings.MaxCharactersInDocument-Eigenschaft begrenzen. Sie können die Anzahl von Zeichen einschränken, die sich durch das Erweitern von Entitäten ergeben, indem Sie die XmlReaderSettings.MaxCharactersFromEntities-Eigenschaft einrichten. Beispiele für das Einrichten dieser Eigenschaften finden Sie in den entsprechenden Referenzthemen.

Die XSD- und die XSLT-Technologien weisen weitere Funktionen auf, die die Verarbeitungsgeschwindigkeit beeinflussen können. Es ist z. B. möglich, ein XML-Schema zu erstellen, dessen Verarbeitung bereits bei der Auswertung für ein relativ kleines Dokument erhebliche Zeit in Anspruch nimmt. Es ist auch möglich, in einen XSLT-Stylesheet Skriptblöcke einzubetten. Beide Fälle stellen eine potenzielle Sicherheitsbedrohung für Ihre App dar.

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

• Die XSLT-Skriptverarbeitung ist standardmäßig deaktiviert. XSLT-Skripts sollten nur aktiviert werden, wenn eine Skriptunterstützung erforderlich ist und Sie mit einer vollständig vertrauenswürdigen Umgebung arbeiten.

• Die XSLT-document()-Funktion ist standardmäßig deaktiviert. Wenn Sie die document()-Funktion aktivieren, schränken Sie die verfügbaren Ressourcen ein, indem Sie der XmlSecureResolver-Methode ein XslCompiledTransform.Transform-Objekt übergeben.

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

• XSLT-Stylesheets können Verweise auf andere Dateien und eingebettete Skriptblöcke enthalten. Ein böswilliger Benutzer kann dies ausnutzen, indem er Daten oder Stylesheets bereitstellt, deren Verarbeitung die Ressourcen des Computers erschöpft.

• XSLT-Apps, die in einer gemischten Vertrauensumgebung ausgeführt werden, können zu Stylesheet-Spoofing führen. Ein böswilliger Benutzer könnte z. B. ein Objekt mit einem schädlichen Stylesheet laden und es an einen anderen Benutzer übermitteln, der die XslCompiledTransform.Transform-Methode aufruft und die Transformation ausführt.

Diese Sicherheitsprobleme können durch Deaktivieren von Skripts oder der document()-Funktion bei aus nicht vertrauenswürdigen Quellen stammenden Stylesheets und durch das Abweisen von XslCompiledTransform-Objekten, XSLT-Stylesheets und XML-Quelldaten aus nicht vertrauernswürdigen Quellen reduziert werden.

Ausnahmebehandlung

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 abfangen und entsprechend verarbeiten.

Weitere Informationen

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