Définir la sérialisation des données XML

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Lors du cast du type de données xml explicitement ou implicitement vers une chaîne SQL ou un type binaire, le contenu du type de données xml est sérialisé en fonction des règles décrites dans cet article.

Encodage de sérialisation

Si le type cible SQL est VARBINARY, le résultat est sérialisé au format UTF-16 avec une marque d'ordre d'octet UTF-16 au début, mais sans déclaration XML. Si le type cible est trop petit, une erreur est générée.

Par exemple :

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

Voici le résultat obtenu :

0xFFFE3C0094032F003E00

Si le type cible SQL est NVARCHAR ou NCHAR, le résultat est sérialisé au format UTF-16 sans marque d'ordre d'octet au début ni déclaration XML. Si le type cible est trop petit, une erreur est générée.

Par exemple :

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

Voici le résultat obtenu :

<Δ/>

Si le type cible SQL est VARCHAR ou CHAR, le résultat est sérialisé dans l’encodage correspondant à la page de codes du classement de la base de données sans marque d’ordre d’octet ni déclaration XML. Si le type cible est trop petit ou si la valeur ne peut pas être mappée à la page de codes du classement cible, une erreur est générée.

Par exemple :

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

Cela peut entraîner une erreur, si la page de codes du classement actuel ne peut pas représenter le caractère Unicode Δ, ou qu’elle la représentera dans l’encodage spécifique.

Lors du renvoi des résultats XML côté client, les données seront transmises en UTF-16. Le fournisseur côté client exposera ensuite les données d'après les règles de son API.

Sérialisation des structures XML

Le contenu d’un type de données xml est sérialisé de manière habituelle. Plus précisément, les nœuds d'élément sont mappés au balisage d'élément et les nœuds de texte sont mappés au contenu texte. Les circonstances dans lesquelles les caractères sont décomposés en entités et la façon dont les valeurs atomiques typées sont sérialisées sont décrites dans les sections suivantes.

Titre des caractères XML lors de la sérialisation

Chaque structure XML sérialisée doit pouvoir subir une nouvelle analyse. C’est pourquoi certains caractères doivent être sérialisés à l’aide du codage d’entité de façon à autoriser les accès répétés aux caractères, tout au long de la phase de normalisation de l’analyseur XML. Il s'avère aussi nécessaire de spécifier le codage d'entité de certains caractères afin d'assurer la bonne formation du document et son analyse. Voici les règles de codage d'entité qui s'appliquent au cours de la sérialisation :

• Les caractères &, <et > sont toujours entités à &, <et > respectivement, s’ils se produisent à l’intérieur d’une valeur d’attribut ou d’un contenu d’élément.

• Étant donné que SQL Server utilise les guillemets (U+0022) pour délimiter les valeurs des attributs, le guillemet des valeurs de l’attribut est codé par ".

• Une paire de substitution est codée sous forme d'une seule référence de caractère numérique, lors de la conversion sur le serveur uniquement. Par exemple, la paire de substitution U+D800 U+DF00 est entitisée à la référence 𐌀de caractères numériques .

• Pour protéger une tabulation (U+0009) et un flux de lignes (LF, U+000A) d’être normalisé pendant l’analyse, ils sont intitulés à leurs références 	 de caractères numériques et 
 respectivement, dans les valeurs d’attribut.

• Pour empêcher un retour chariot (CR, U+000D) d’être normalisé pendant l’analyse, il est entitisé à sa référence de caractères numériques, 
 à l’intérieur des valeurs d’attribut et du contenu d’élément.

• Pour protéger les nœuds de texte contenant des espaces, l'un des espaces (généralement le dernier) est codé par sa référence de caractère numérique. De cette façon, l'analyse préserve le nœud de texte contenant des espaces, quel que soit le mode de traitement choisi pour les espaces au cours de l'analyse.

Par exemple :

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

Voici le résultat obtenu :

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

Si vous ne souhaitez pas appliquer la dernière règle de protection de l’espace blanc, vous pouvez utiliser l’option CONVERT explicite 1 lors du cast de xml vers une chaîne ou un type binaire. Par exemple, vous pouvez éviter le codage d'entité en procédant ainsi :

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

La méthode query() (type de données xml) entraîne une instance de type de données xml . Par conséquent, tout résultat de la query() méthode qui est castée en chaîne ou type binaire est intitisé en fonction des règles décrites précédemment. Si vous souhaitez obtenir les valeurs de chaîne qui ne sont pas entitisées, vous devez utiliser la méthode value() (type de données xml) à la place. Voici un exemple d’utilisation de la query() méthode :

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

Voici le résultat obtenu :

This example contains an entitized char: .

Voici un exemple d’utilisation de la value() méthode :

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

Voici le résultat obtenu :

This example contains an entitized char: .

Sérialisation d’un type de données xml typé

Une instance typée xml contient des valeurs qui sont typées en fonction de leurs types de schémas XML. Ces valeurs sont sérialisées selon leur type de schéma XML au format que produit la conversion XQuery vers xs:string. Pour plus d’informations, consultez Règles de conversion de types dans XQuery.

Par exemple, la valeur xs:double 1.34e1 est sérialisée en 13.4 comme le montre l'exemple suivant :

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

Cela renvoie la valeur de chaîne 13.4.

Voir aussi

• Règles de conversion de types dans XQuery
• CAST et CONVERT (Transact-SQL)