Mappage entre JSON et XML

Les lecteurs et writers produits par le JsonReaderWriterFactory fournissent une API XML sur le contenu de JavaScript Objet Notation (JSON). JSON encode des données à l'aide d'un sous-ensemble de littéraux d'objet JavaScript. Les lecteurs et writers produits par cette fabrique sont également utilisés lorsque le contenu JSON est envoyé ou reçu par les applications Windows Communication Foundation (WCF) à l'aide du WebMessageEncodingBindingElement ou du WebHttpBinding.

En cas d'initialisation avec le contenu JSON, le lecteur JSON se comporte de la même façon qu'un lecteur XML textuel sur une instance de XML. Le writer JSON, lorsqu'il reçoit une séquence d'appels qui sur un lecteur XML textuel produit une certaine instance XML, écrit un contenu JSON. Le mappage entre cette instance de XML et le contenu JSON est décrit dans cette rubrique pour une utilisation dans des scénarios avancés.

En interne, JSON est représenté comme un jeu d'informations XML lorsqu'il est traité par WCF. Il n'est pas nécessaire généralement de vous préoccuper de cette représentation interne étant donné que le mappage est uniquement un mappage logique : JSON n'est pas généralement converti physiquement en XML en mémoire ou converti vers JSON à partir du XML. Le mappage signifie que les API XML sont utilisées pour accéder au contenu JSON.

Lorsque WCF utilise JSON, le scénario habituel est que le DataContractJsonSerializer est branché automatiquement par le comportement WebScriptEnablingBehavior, ou par le comportement WebHttpBehavior le cas échéant. Le DataContractJsonSerializer comprend le mappage entre JSON et les jeux d'informations XML et fonctionne comme s'il traite directement avec JSON. (Il est possible d'utiliser le DataContractJsonSerializer avec tout lecteur ou writer XML à condition que le XML se conforme au mappage suivant).

Dans les scénarios avancés, il peut devenir nécessaire d'accéder directement au mappage suivant. Ces scénarios se produisent lorsque vous souhaitez sérialiser et désérialiser JSON de manières personnalisées, sans avoir à compter sur le DataContractJsonSerializer, ou lors d'un traitement direct avec le type Message pour les messages qui contiennent JSON. Le mappage JSON-XML est également utilisé pour l'enregistrement des messages. Lors de l'utilisation de la fonctionnalité d'enregistrement des messages dans WCF, les messages JSON sont enregistrés au format XML selon le mappage décrit dans la section suivante.

Pour clarifier le concept d'un mappage, l'exemple suivant est celui d'un document JSON.

{"product":"pencil","price":12}

Pour lire ce document JSON à l'aide de l'un des lecteurs évoqués précédemment, utilisez la même séquence d'appels XmlDictionaryReader que pour lire le document XML suivant.

    <root type="object">
        <product type="string">pencil</product>
        <price type="number">12</price>
    </root>

En outre, si le message JSON dans l'exemple est reçu par WCF et enregistré, vous pouvez consulter le fragment XML dans le journal précédent.

Mappage entre JSON et le jeu d'informations XML

De manière formelle, le mappage se fait entre JSON, comme décrit dans la RFC 4627 (sauf avec certaines restrictions assouplies et d'autres restrictions ajoutées) et le jeu d'informations XML (et pas XML textuel), comme décrit dans le jeu d'informations XML (page pouvant être en anglais). Consultez cette rubrique pour les définitions des éléments d'informations et des champs entre [crochets].

Un document JSON vide est mappé aux documents XML vierges, et un document XML vierge est mappé à un document JSON vierge. Sur le mappage XML à JSON, des espaces blanc précédents et des caractères d'espace blanc de fin après le document ne sont pas autorisés.

Le mappage est défini entre un élément DII (Document Information Item) ou un élément EII (Element Information Item) et JSON. L'élément EII, ou la propriété de l'élément DII [élément de document] est appelé l'élément JSON racine. Notez que les fragments de document (XML avec plusieurs éléments racine) ne sont pas pris en charge dans ce mappage.

Exemple : Document suivant :

<?xml version="1.0"?>

<root type="number">42</root>

Et les éléments suivants :

<root type="number">42</root>

Ces deux éléments ont un mappage à JSON. L'élément <root> est l'élément racine JSON dans les deux cas.

De plus, les éléments suivants doivent être pris en compte dans le cas d'un élément DII :

• Certains éléments dans la liste [enfants] ne doivent pas être présents. Ne comptez pas sur ce fait pour la lecture du XML mappé à partir de JSON.

• La liste [enfants] ne contient aucun élément d'informations de commentaire.

• La liste [enfants] ne contient aucun élément d'informations DTD.

• La liste [enfants] ne contient aucun élément d'informations PI (Personal Informations) (la déclaration <?xml...> n'est pas considérée comme un élément d'informations PI)

• Le jeu [notations] est vide.

• Le jeu [entités non analysées] est vide.

Exemple : le document suivant n'a aucun mappage à JSON parce que [enfants] contient un PI et un commentaire.

<?xml version="1.0"?>

<!--comment--><?pi?>

<root type="number">42</root>

L'EII pour l'élément JSON racine a les caractéristiques suivantes :

• [nom local] a la valeur "racine".

• [nom d'espace de noms] n'a aucune valeur.

• [préfixe] n'a aucune valeur.

• [enfants] peut contenir des éléments EII (qui représentent des éléments internes décrits plus loin) ou des éléments CII (éléments d'informations de caractère décrits plus loin) ou aucun d'entre eux, mais pas les deux.

• [attributs] peut contenir les éléments AII (Attribute Information Items) facultatifs suivants

• L'attribut de type JSON ("type") décrit plus loin. Cet attribut est utilisé pour conserver le type JSON (chaîne, nombre, booléen, objet, tableau ou null) dans le XML mappé.

• L'attribut de nom de contrat de données ("__type") décrit plus loin. Cet attribut peut être présent uniquement si l'attribut de type JSON est aussi présent et sa [valeur normalisée] est "objet." Cet attribut est utilisé par le DataContractJsonSerializer pour conserver des informations de type de contrat de données - par exemple, dans les cas polymorphes où un type dérivé est sérialisé et où un type de base est attendu. Si vous n'utilisez le DataContractJsonSerializer, dans la plupart des cas, cet attribut est ignoré.

• [espaces de noms dans l'étendue] contient la liaison de "xml" vers "http://www.w3.org/XML/1998/namespace" comme mandaté par la spécification infoset.

• [enfants], [attributs] et [espaces de noms dans l'étendue] ne doivent pas avoir d'éléments autres que ceux spécifiés précédemment et [attributs d'espace de noms] ne doit pas avoir de membres, mais ne compte pas sur ces faits pour la lecture du XML mappé à partir de JSON.

Exemple : le document suivant n'a aucun mappage à JSON parce que [attributs d'espace de noms] n'est pas vide.

<?xml version="1.0"?>

<root xmlns:a="foo">42</root>

L'élément AII pour l'attribut de type JSON a les caractéristiques suivantes :

• [nom d'espace de noms] n'a aucune valeur.

• [préfixe] n'a aucune valeur.

• [nom local] est "type".

• [valeur normalisée] est une des valeurs de type possibles décrite dans la section suivante.

• [spécifié] a la valeur true.

• [type d'attribut] n'a aucune valeur.

• [références] n'a aucune valeur.

L'élément AII pour l'attribut de nom de contrat de données a les caractéristiques suivantes :

• [nom d'espace de noms] n'a aucune valeur.

• [préfixe] n'a aucune valeur.

• [nom local] est "__type (deux traits de soulignement puis "type").

• [valeur normalisée] est toute chaîne Unicode valide. Le mappage de cette chaîne à JSON est décrit dans la section suivante.

• [spécifié] a la valeur true.

• [type d'attribut] n'a aucune valeur.

• [références] n'a aucune valeur.

Les éléments internes contenus dans l'élément JSON racine ou d'autres éléments internes ont les caractéristiques suivantes :

• [nom local] peut avoir toute valeur décrite plus loin

• [nom d'espace de noms], [préfixe], [enfants], [attributs], [attributs d'espace de noms], et [espaces de noms dans l'étendue] sont soumis aux mêmes règles que l'élément JSON racine.

Dans l'élément JSON racine et les éléments internes, l'attribut de type JSON définit le mappage à JSON et les [enfants] possibles et leur interprétation. La [valeur normalisée] de l'attribut respecte la casse et doit être en minuscule et ne peut pas contenir d'espace blanc.

<root type="string">42</root>

<root type="string">the "da/ta"</root>

<root type="string">ABC</root>

<root type="string">ABC</root>

<root type="string">  A BC      </root>

<root type="number">    42</root>

<root type="boolean"> false</root>

<root type="null"/>

<root type="null"></root>

{"__type":"Person","name":"John"}

<root type="object" __type="Person">
  <name type="string">John</name>
</root>

<root type="object">
  <name type="string">John</name>
  <__type type="string">Person</__type>
</root>

<root type="object" __type="\abc" />

{"__type":"\\abc"}

<root type="object">
   <ccc type="string">aaa</ccc>
   <ddd type="string">bbb</bar>
</root >

<root type="array"/>
   <item type="string">aaa</item>
   <item type="string">bbb</item>
</root >

<root type="array"/>
   <item type="string">aaa</item>
   <item type="string">bbb</item>
</root >

Les enregistrements membres fonctionnent comme suit :

• Le [nom local] de l'élément interne mappe à la partie string du member défini dans la section 2.2 de la RFC JSON.

Exemple : l'élément suivant mappe à un fragment JSON.

<root type="object"/>

<myLocalName type="string">aaa</myLocalName>

</root >

Le fragment JSON suivant est affiché.

{"myLocalName":"aaa"}

• Sur le mappage XML à JSON, les caractères qui doivent faire l'objet d'une séquence d'échappement dans JSON le sont, et tous les autres ne le sont pas. Le caractère "/", même s'il ne s'agit pas d'un caractère qui doit faire l'objet d'une séquence d'échappement, est néanmoins échappé (ce qui n'est pas nécessaire sur le mappage JSON à XML). Cela est requis pour prendre en charge le format ASP.NET AJAX pour les données DateTime dans JSON.

• Sur le mappage JSON au XML, tous les caractères (y compris les caractères non échappés, si nécessaire) sont acceptés pour former un string qui produit un [nom local].

• Les éléments internes [enfants] mappent à la valeur dans section 2.2, selon JSON Type Attribute comme pour Root JSON Element. Plusieurs niveaux d'imbrication des éléments EII (y compris l'imbrication dans des tableaux) sont autorisés.

Exemple : l'élément suivant mappe à un fragment JSON.

<root type="object">

<myLocalName1 type="string">myValue1</myLocalName1>

<myLocalName2 type="number">2</myLocalName2>

<myLocalName3 type="object">

<myNestedName1 type="boolean">true</myNestedName1>

<myNestedName2 type="null"/>

</myLocalName3>

</root >

Le fragment JSON suivant est celui auquel il est mappé.

{"myLocalName1":"myValue1","myLocalName2":2,"myLocalName3":{"myNestedName1":true,"myNestedName2":null}}

Remarque :
Il n'y a aucune étape d'encodage XML dans le mappage précédent. Par conséquent, WCF prend en charge seulement des documents JSON où tous les caractères dans les noms clé sont des caractères valides dans les noms d'élément XML. Par exemple, le document JSON {"<":"a"} n'est pas pris en charge parce que < n'est pas un nom valide pour un élément XML.

La situation inverse (caractères valide dans XML mais pas dans JSON) ne provoque pas de problèmes étant donné que le mappage précédent inclut des étapes d'échappement et de non échappement JSON.

Les enregistrements du tableau fonctionnent comme suit :

• Le [nom local] de l'élément interne est "élément."

• [enfants] de l'élément interne mappe à la valeur dans la section 2.3, selon l'attribut de type JSON comme pour l'élément JSON racine. Plusieurs niveaux d'imbrication des éléments EII (y compris l'imbrication dans des objets) sont autorisés.

Exemple : l'élément suivant mappe à un fragment JSON.

<root type="array"/>

<item type="string">myValue1</item>

<item type="number">2</item>

<item type="array">

<item type="boolean">true</item>

<item type="null"/>

</item>

</root >

Les éléments suivants sont le fragment JSON.

["myValue1",2,[true,null]]

Voir aussi

Référence

JsonReaderWriterFactory
DataContractJsonSerializer

Concepts

Sérialisation JSON autonome