Partage via

Mappage entre JSON et XML

Les modules de lecture et les auteurs produits par le JsonReaderWriterFactory fournissent une API XML sur le contenu de JavaScript Object Notation (JSON). JSON encode des données à l'aide d'un sous-ensemble de littéraux d'objet JavaScript. Les lecteurs et écrivains produits par ce fabricant sont également utilisés lorsque du contenu JSON est envoyé ou reçu par des applications de la 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 (à l’exception de certaines restrictions assouplies et d'autres ajoutées) et le jeu d’informations XML (et non le XML textuel), comme décrit dans le jeu d’informations XML. 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, les espaces blancs précédant et les espaces blancs finaux 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ée 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, dans le cas d'un DII, il convient de prendre en compte les éléments suivants :

  • 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'information DTD.

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

  • L'ensemble [notations] est vide.

  • L'ensemble [entités non analysées] est vide.

Exemple : le document suivant ne possède pas de mappage vers JSON parce que [children] 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 pas le DataContractJsonSerializer, dans la plupart des cas, cet attribut est ignoré.

  • [espaces de noms en cours] contient la liaison de "xml" vers http://www.w3.org/XML/1998/namespace comme exigé 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 doivent pas avoir de membres, mais ne vous fiez pas à ces faits lorsque vous lisez le 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="myattributevalue">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 "Nom du Contrat de Données" a les propriétés suivantes :

  • [nom d'espace de noms] n'a aucune valeur.
  • [préfixe] n'a aucune valeur.
  • [nom local] est "__type" (avec deux traits de soulignement suivis de "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 racine JSON.

Dans l'élément JSON racine et les éléments internes, l'attribut de type JSON définit le mappage dans JSON, ainsi que les éléments 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.

[valeur normalisée] de l’attribut AII de type JSON Les [enfants] autorisés de l'élément EII correspondant Mappage à JSON
string (ou absence de l'élément AII de type JSON)

L'élément string et l'absence de l'élément AII de type JSON ont le même effet : par défaut, cela définit string.

Ainsi, <root> string1</root> correspond à string JSON "string1".		 0 ou plusieurs éléments CII JSON string (JSON RFC, section 2.5). Chaque char est un caractère qui correspond au [code de caractère] du CII. En l'absence d'élément CII, cela correspond à un string JSON vide.

Exemple : L'élément suivant correspond à un fragment JSON :

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

Le fragment JSON est "42".

Dans le mappage XML vers JSON, les caractères qui doivent être échappés sont mappés aux caractères échappés, tous les autres sont mappés aux caractères non échappés. Le caractère "/" est spécial – il est échappé même si ce n'est pas nécessaire (écrit sous la forme "\/").

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

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

Le fragment JSON est "the \"da\/ta \".

Sur le mappage JSON à XML, les caractères échappés et les caractères non échappés sont correctement mappés au [code de caractère] correspondant.

Exemple : le fragment JSON "\u0041BC" correspond à l'élément XML suivant.

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

La chaîne peut être entourée par les espaces blancs ('ws' dans la section 2 de la RFC JSON) qui ne sont pas convertis au format XML.

Exemple : Le fragment JSON "ABC", (il y a des espaces avant le premier guillemet double), se mappe à l’élément XML suivant.

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

Tout espace blanc dans XML est mappé à l’espace blanc dans JSON.

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

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

Le fragment JSON est " A BC ".
number 1 ou plusieurs CII Un JSON number (JSON RFC, section 2.4), peut-être entouré par un espace blanc. Chaque caractère dans la combinaison chiffre/espace blanc est un caractère qui correspond au [code de caractère] du CII.

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

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

Le fragment JSON est 42.

(Les espaces blancs sont conservés.)
boolean 4 ou 5 éléments CII (qui correspondent à true ou false), éventuellement entourés de CIIs supplémentaires qui représentent un espace blanc. Une séquence CII qui correspond à la chaîne "true" est mappée au littéral true, et une séquence CII qui correspond à la chaîne "false" est mappée au littéral false. L’espace blanc encadrant est conservé.

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

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

Le fragment JSON est false.
null Aucune autorisation. Le terme littéral null. Sur le mappage JSON à XML, null peut être entouré par un espace blanc ('ws' dans section 2) qui n’est pas mappé au XML.

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

<root type="null"/>

ou

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

:

Le fragment JSON dans les deux cas est Null.
object 0 ou plusieurs EII. Un begin-object (accolade ouvrante) comme dans la section 2.2 de la FRC JSON, suivi d'un enregistrement membre pour chaque élément EII décrit plus loin. En présence de plusieurs éléments EII, il y a des séparateurs de valeur (virgules) entre les enregistrements membre. Cet ensemble est suivi par un objet de fin (accolade fermante).

Exemple : l'élément suivant correspond au fragment JSON.

<root type="object">

<type1 type="string">aaa\</type1>

<type2 type="string">bbb\</type2>

</root >

Le fragment est JSON {"type1":"aaa","type2":"bbb"}.

Si l'attribut de type de contrat de données est présent sur le mappage XML vers JSON, un enregistrement de membre supplémentaire est inséré au début. Son nom est le [nom local] de l'attribut de type de contrat de données ("__type"), et sa valeur est la [valeur normalisée] de l'attribut. Inversement, sur le mappage JSON à XML, si le premier nom de l'enregistrement membre est le [nom local] de l'attribut de type de contrat de données (autrement dit, "__type"), un attribut de type de contrat de données correspondant est présent dans le XML mappé, mais un élément EII correspondant n'est pas présent. Notez que cet enregistrement membre doit se produire en premier dans l'objet JSON pour que ce mappage spécial s'applique. Il s'agit d'une nouveauté par rapport au traitement JSON habituel dans lequel l'ordre des enregistrements membres n'est pas significatif.

Exemple :

Le fragment JSON suivant est converti en XML.

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

Le XML est le code suivant.

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

Remarquez que le __type AII est présent, mais il n'y a pas de __type EII.

Toutefois, si l'ordre dans le JSON est inversé comme indiqué dans l'exemple suivant.

{"name":"John","\_\_type":"Person"}

Le XML correspondant est indiqué.

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

Autrement dit, __type cesse d'avoir une signification spéciale et correspond à un élément EII, pas un élément AII.

Les règles d'échappement et déséchappement de la [valeur normalisée] de l'AII lors du mappage à une valeur JSON sont les mêmes que celles des chaînes JSON spécifiées dans la ligne "chaîne" de ce tableau.

Exemple :

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

L'exemple précédent peut être traduit par le JSON suivant.

{"__type":"\\abc"}

Dans un mappage XML vers JSON, le premier EII [nom local] ne doit pas être "__type".

L’espace blanc (ws) n’est jamais généré sur le mappage XML à JSON pour les objets et est ignoré sur le mappage JSON à XML.

Exemple : le fragment JSON suivant correspond à un élément XML.

{ "ccc" : "aaa", "ddd" :"bbb"}

L'élément XML est indiqué dans le code suivant.

<root type="object"> <ccc type="string">aaa</ccc> <ddd type="string">bbb</bar> </root >
tableau 0 ou plusieurs EII Un début d'un tableau (crochet ouvrant) comme dans la section 2.3 de la RFC JSON, suivi d'un enregistrement de tableau pour chaque élément EII, comme décrit plus loin. S'il y a plus d'un EII, des séparateurs de valeurs (virgules) sont placés entre les éléments du tableau. L'ensemble est suivi d'un tableau de fin.

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

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

Le fragment JSON est ["aaa","bbb"].

L’espace blanc (ws) n’est jamais généré sur le mappage XML à JSON pour les tableaux et est ignoré sur le mappage JSON à XML.

Exemple : fragment JSON.

["aaa", "bbb"]

L'élément XML auquel il correspond.

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

Les dossiers des membres fonctionnent de la manière suivante :

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

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

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

Le fragment JSON suivant est affiché.

{"myLocalName":"aaa"}

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

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

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

Exemple : l'élément suivant correspond à 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}}

Note

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 valides 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 déséchappement JSON.

Les enregistrements de tableau fonctionnent comme suit :

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

  • Les nœuds enfants de l'élément interne correspondent à la valeur dans la section 2.3, en fonction de l'attribut de type JSON, comme c'est le cas 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 correspond à 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>

L'élément suivant est le fragment JSON.

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

Voir aussi

  • Last updated on