Definieren der Serialisierung von XML-Daten

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-InstanzSQL-Datenbank in Microsoft Fabric

Beim Umwandeln des xml-Datentyps in eine SQL-Zeichenfolge oder einen Binärtyp wird der Inhalt des xml-Datentyps entsprechend der in diesem Artikel beschriebenen Regeln serialisiert.

Serialisierungscodierung

Wenn der SQL-Zieltyp VARBINARY ist, erfolgt die Serialisierung des Ergebnisses in UTF-16 mit einer UTF-16-Markierung für die Bytereihenfolge am Anfang, jedoch ohne eine XML-Deklaration. Wenn der Zieltyp zu klein ist, wird ein Fehler ausgelöst.

Zum Beispiel:

select CAST(CAST(N'<Δ/>' as XML) as VARBINARY(MAX))

Dies ist das Ergebnis:

0xFFFE3C0094032F003E00

Wenn der SQL-Zieltyp NVARCHAR oder NCHAR ist, erfolgt die Serialisierung des Ergebnisses in UTF-16 ohne die Markierung für die Bytereihenfolge am Anfang und ohne eine XML-Deklaration. Wenn der Zieltyp zu klein ist, wird ein Fehler ausgelöst.

Zum Beispiel:

select CAST(CAST(N'<Δ/>' as XML) as NVARCHAR(MAX))

Dies ist das Ergebnis:

<Δ/>

Wenn der SQL-Zieltyp VARCHAR oder CHAR ist, erfolgt die Serialisierung des Ergebnisses in der Codierung, die der Codepage der Datenbanksortierung entspricht, ohne Markierung zur Bytereihenfolge oder XML-Deklaration. Wenn der Zieltyp zu klein ist oder der Wert nicht zur Codeseite der Zielsortierung zugeordnet werden kann, wird ein Fehler ausgelöst.

Zum Beispiel:

select CAST(CAST(N'<Δ/>' as XML) as VARCHAR(MAX))

Dies kann zu einem Fehler führen, wenn die Codepage der aktuellen Kollation das Unicode-Zeichen Δ nicht darstellen kann, oder es wird in der jeweiligen Codierung dargestellt.

Beim Zurückgeben der XML-Ergebnisse an die Clientseite werden die Daten in UTF-16-Codierung gesendet. Der clientseitige Anbieter macht die Daten dann entsprechend seinen API-Regeln verfügbar.

Serialisierung der XML-Strukturen

Der Inhalt eines xml -Datentyps wird auf die herkömmliche Art und Weise serialisiert. Das heißt konkret, dass Elementknoten dem Elementmarkup zugeordnet und Textknoten dem Textinhalt zugeordnet werden. Jedoch werden in den folgenden Abschnitten die Umstände beschrieben, unter denen Zeichen als Entitäten dargestellt werden, und wie typisierte atomare Werte serialisiert werden.

Umwandlung von XML-Zeichen in Entitäten während der Serialisierung

Jede serialisierte XML-Struktur muss in der Lage sein, neu analysiert zu werden. Deshalb müssen einige Zeichen in entitätskodierter Form serialisiert werden, damit die Roundtrip-Fähigkeit der Zeichen während der Normalisierungsphase des XML-Parsers erhalten bleibt. Allerdings müssen einige Zeichen als Entitäten codiert werden, damit das Dokument wohlgeformt ist und somit geparst werden kann. Im Folgenden werden die bei der Serialisierung geltenden Regeln für die Umwandlung in Entitäten aufgeführt:

  • Die Zeichen &, <, und > werden immer als &amp;, &lt; beziehungsweise &gt; als Entitäten kodiert, wenn sie innerhalb eines Attributwerts oder Elementinhalts auftreten.

  • Da SQL Server zum Umschließen von Attributwerten ein Anführungszeichen (U+0022) verwendet, wird das Anführungszeichen innerhalb von Attributwerten als &quot; codiert.

  • Ein Surrogatpaar wird jedoch nur bei der Umwandlung auf dem Server als einzelne numerische Zeichenreferenz dargestellt. Zum Beispiel wird das Surrogatpaar U+D800 U+DF00 in den numerischen Zeichenverweis &#x00010300; umgewandelt.

  • Um zu verhindern, dass ein TAB (U+0009) und ein Linefeed (LF, U+000A) beim Parsen normalisiert werden, werden sie innerhalb von Attributwerten jeweils in ihre numerischen Zeichenreferenzen &#x9; bzw. &#xA; umgewandelt.

  • Um zu verhindern, dass ein Carriage Return (CR, U+000D) während des Parsens normalisiert wird, wird er sowohl in Attributwerten als auch im Elementinhalt als numerischer Zeichenverweis, &#xD;, dargestellt.

  • Um Textknoten zu schützen, die nur aus Leerraumzeichen bestehen, wird eines der Leerraumzeichen, in der Regel das letzte, als numerische Zeichenreferenz maskiert. Auf diese Weise bleibt der Leerraum-Textknoten beim erneuten Parsen erhalten, unabhängig von der Einstellung für die Leerraumbehandlung während des Parsens.

Zum Beispiel:

DECLARE @u NVARCHAR(50)
set @u = N'<a a="
    '+NCHAR(0xD800)+NCHAR(0xDF00)+N'>">   '+NCHAR(0xA)+N'</a>'
SELECT CAST(CONVERT(XML,@u,1) as NVARCHAR(50));

Dies ist das Ergebnis:

<a a="
    𐌀>">
</a>

Wenn Sie die letzte Leerzeichenschutzregel nicht anwenden wollen, können Sie die explizite CONVERT-Option 1 beim Umwandeln von xml in einen Zeichenfolgen- oder Binärtyp verwenden. Um beispielsweise die Entitätsbildung zu vermeiden, können Sie Folgendes tun:

SELECT CONVERT(NVARCHAR(50), CONVERT(XML, '<a>   </a>', 1), 1);

Die query()-Methode (xml-Datentyp) ergibt eine xml-Datentypinstanz. Deshalb wird jedes Ergebnis der query()-Methode, das in einen Zeichenfolgen- oder Binärtyp umgewandelt wird, entsprechend den zuvor beschriebenen Regeln in Entitäten geändert. Wenn Sie Zeichenfolgenwerte erhalten wollen, die nicht in Entitäten geändert wurden, sollten Sie stattdessen die value()-Methode (xml-Datentyp) verwenden. Es folgt ein Beispiel zum Verwenden der query()-Methode:

DECLARE @x xml
SET @x = N'<a>This example contains an entitized char: .</a>'
SELECT @x.query('/a/text()');

Dies ist das Ergebnis:

This example contains an entitized char: .

Es folgt ein Beispiel zum Verwenden der value()-Methode:

SELECT @x.value('(/a/text())[1]', 'nvarchar(100)');

Dies ist das Ergebnis:

This example contains an entitized char: .

Serialisieren eines typisierten xml-Datentyps

Eine typisierte xml -Datentypinstanz enthält Werte, die entsprechend ihren XML-Schematypen typisiert sind. Diese Werte werden entsprechend ihrem XML-Schematyp in dasselbe Format serialisiert, wie es bei der XQuery-Umwandlung in xs:string entsteht. Weitere Informationen finden Sie unter Typumwandlungsregeln in XQuery.

So wird z. B. der xs:double-Wert 1.34e1 zu 13.4 serialisiert, wie das im folgenden Beispiel gezeigt wird.

declare @x xml
set @x =''
select CAST(@x.query('1.34e1') as nvarchar(50));

Dies gibt die Zeichenfolge „13.4“ zurück.