Delen via


Toewijzing tussen JSON en XML

De lezers en schrijvers die door de JsonReaderWriterFactory api zijn geproduceerd, bieden een XML-API via JSON-inhoud (JavaScript Object Notation). JSON codeert gegevens met behulp van een subset van de letterlijke waarden van het object van JavaScript. De lezers en schrijvers die door deze fabriek worden geproduceerd, worden ook gebruikt wanneer JSON-inhoud wordt verzonden of ontvangen door WCF-toepassingen (Windows Communication Foundation) die gebruikmaken van de WebMessageEncodingBindingElement of de WebHttpBinding.

Wanneer de JSON-inhoud is geïnitialiseerd, gedraagt de JSON-lezer zich op dezelfde manier als een tekstuele XML-lezer doet via een exemplaar van XML. De JSON-schrijver schrijft JSON-inhoud wanneer een reeks aanroepen wordt gegeven die op een tekstuele XML-lezer een bepaald XML-exemplaar produceert. De toewijzing tussen dit exemplaar van XML en de JSON-inhoud wordt beschreven in dit onderwerp voor gebruik in geavanceerde scenario's.

Intern wordt JSON weergegeven als een XML-infoset wanneer deze wordt verwerkt door WCF. Normaal gesproken hoeft u zich niet bezig te houden met deze interne weergave, omdat de toewijzing slechts een logische is: JSON wordt normaal gesproken niet fysiek geconverteerd naar XML in het geheugen of geconverteerd naar JSON vanuit XML. De toewijzing betekent dat XML-API's worden gebruikt voor toegang tot JSON-inhoud.

Wanneer WCF gebruikmaakt van JSON, is het gebruikelijke scenario dat het DataContractJsonSerializer automatisch wordt aangesloten op het WebScriptEnablingBehavior gedrag of door het WebHttpBehavior gedrag, indien van toepassing. De DataContractJsonSerializer toewijzing tussen JSON en de XML-infoset begrijpt en fungeert alsof deze rechtstreeks met JSON te maken heeft. (Het is mogelijk om de DataContractJsonSerializer met elke XML-lezer of schrijver te gebruiken, met het begrip dat de XML voldoet aan de volgende toewijzing.)

In geavanceerde scenario's kan het nodig zijn om rechtstreeks toegang te krijgen tot de volgende toewijzing. Deze scenario's treden op wanneer u JSON op aangepaste manieren wilt serialiseren en deserialiseren zonder dat u afhankelijk bent van het DataContractJsonSerializertype of wanneer u het Message type rechtstreeks voor berichten met JSON wilt verwerken. De JSON-XML-toewijzing wordt ook gebruikt voor logboekregistratie van berichten. Wanneer u de functie voor berichtregistratie in WCF gebruikt, worden JSON-berichten geregistreerd als XML volgens de toewijzing die in de volgende sectie wordt beschreven.

Om het concept van een toewijzing te verduidelijken, is het volgende voorbeeld van een JSON-document.

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

Als u dit JSON-document wilt lezen met een van de eerder genoemde lezers, gebruikt u dezelfde reeks aanroepen als voor het lezen van XmlDictionaryReader het volgende XML-document.

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

Als het JSON-bericht in het voorbeeld wordt ontvangen door WCF en is vastgelegd, ziet u bovendien het XML-fragment in het voorgaande logboek.

Toewijzing tussen JSON en xml-infoset

Formeel is de toewijzing tussen JSON zoals beschreven in RFC 4627 (met uitzondering van bepaalde beperkingen die zijn versoepeld en bepaalde andere beperkingen toegevoegd) en de XML-infoset (en niet tekstuele XML) zoals beschreven in de XML-gegevensset. Zie dit onderwerp voor de definities van informatie-items en velden in [vierkante haken].

Een leeg JSON-document wordt toegewezen aan een leeg XML-document en een leeg XML-document wordt toegewezen aan een leeg JSON-document. In de xml-naar-JSON-toewijzing zijn voorafgaande witruimte en volgspaties na het document niet toegestaan.

De toewijzing wordt gedefinieerd tussen een Document Information Item (DII) of een Element Information Item (EII) en JSON. Het EII, of de eigenschap [documentelement] van de DII, wordt het JSON-hoofdelement genoemd. Houd er rekening mee dat documentfragmenten (XML met meerdere hoofdelementen) niet worden ondersteund in deze toewijzing.

Voorbeeld: Het volgende document:

<?xml version="1.0"?>
<root type="number">42</root>

En het volgende element:

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

Beide hebben een toewijzing aan JSON. Het <root> element is in beide gevallen het JSON-hoofdelement.

In het geval van een DII moet bovendien rekening worden gehouden met het volgende:

  • Sommige items in de lijst [onderliggende items] mogen niet aanwezig zijn. Vertrouw niet op dit feit wanneer u XML leest die is toegewezen vanuit JSON.

  • De lijst [onderliggende items] bevat geen items voor opmerkingen.

  • De lijst [onderliggende items] bevat geen DTD-gegevensitems.

  • De lijst met [onderliggende items] bevat geen persoonlijke gegevens (PI) (de <?xml…> declaratie wordt niet beschouwd als een PI-informatie-item)

  • De set [notaties] is leeg.

  • De set [niet-geparseerde entiteiten] is leeg.

Voorbeeld: Het volgende document heeft geen toewijzing aan JSON omdat [onderliggende] een PI en een opmerking bevat.

<?xml version="1.0"?>
<!--comment--><?pi?>
<root type="number">42</root>

Het EII voor het JSON-hoofdelement heeft de volgende kenmerken:

  • [lokale naam] heeft de waarde 'root'.

  • [naamruimtenaam] heeft geen waarde.

  • [voorvoegsel] heeft geen waarde.

  • [onderliggende items] kunnen EI's bevatten (die inner elements vertegenwoordigen zoals verder beschreven) of CI's (tekeninformatie-items zoals verder beschreven) of geen van deze, maar niet beide.

  • [kenmerken] kan de volgende optionele kenmerkinformatie-items (AII's) bevatten

  • Het JSON-typekenmerk ('type') zoals verder beschreven. Dit kenmerk wordt gebruikt om het JSON-type (tekenreeks, getal, booleaanse waarde, object, matrix of null) in de toegewezen XML te behouden.

  • Het kenmerk Naam van gegevenscontract ('__type') zoals verder beschreven. Dit kenmerk kan alleen aanwezig zijn als het JSON-typekenmerk ook aanwezig is en de [genormaliseerde waarde] object is. Dit kenmerk wordt gebruikt voor het DataContractJsonSerializer bewaren van gegevenscontracttypegegevens, bijvoorbeeld in polymorfe gevallen waarin een afgeleid type wordt geserialiseerd en waar een basistype wordt verwacht. Als u niet met het kenmerk werkt, wordt dit kenmerk in de DataContractJsonSerializermeeste gevallen genegeerd.

  • [naamruimten binnen het bereik] bevat de binding van 'xml' aan http://www.w3.org/XML/1998/namespace als verplicht door de infosetspecificatie.

  • [onderliggende items], [kenmerken] en [naamruimten binnen het bereik] mogen geen andere items bevatten dan eerder is opgegeven en [naamruimtekenmerken] mogen geen leden hebben, maar zijn niet afhankelijk van deze feiten bij het lezen van XML die zijn toegewezen vanuit JSON.

Voorbeeld: Het volgende document heeft geen toewijzing aan JSON omdat [naamruimtekenmerken] niet leeg is.

<?xml version="1.0"?>
<root xmlns:a="myattributevalue">42</root>

De AII voor het JSON-typekenmerk heeft de volgende kenmerken:

  • [naamruimtenaam] heeft geen waarde.
  • [voorvoegsel] heeft geen waarde.
  • [lokale naam] is 'type'.
  • [genormaliseerde waarde] is een van de mogelijke typewaarden die in de volgende sectie worden beschreven.
  • [opgegeven] is true.
  • [kenmerktype] heeft geen waarde.
  • [verwijzingen] heeft geen waarde.

De AII voor het kenmerk Naam van gegevenscontract heeft de volgende kenmerken:

  • [naamruimtenaam] heeft geen waarde.
  • [voorvoegsel] heeft geen waarde.
  • [lokale naam] is '__type' (twee onderstrepingstekens en vervolgens 'type').
  • [genormaliseerde waarde] is een geldige Unicode-tekenreeks. De toewijzing van deze tekenreeks aan JSON wordt beschreven in de volgende sectie.
  • [opgegeven] is true.
  • [kenmerktype] heeft geen waarde.
  • [verwijzingen] heeft geen waarde.

Binnenste elementen in het JSON-hoofdelement of andere binnenste elementen hebben de volgende kenmerken:

  • [lokale naam] kan een waarde hebben zoals nader beschreven.
  • [naamruimtenaam], [voorvoegsel], [onderliggende], [kenmerken], [naamruimtekenmerken] en [binnen bereiknaamruimten] zijn onderworpen aan dezelfde regels als het JSON-element Root.

In zowel het hoofd-JSON-element als de binnenste elementen definieert het JSON-typekenmerk de toewijzing aan JSON en de mogelijke [onderliggende] en hun interpretatie. De [genormaliseerde waarde] van het kenmerk is hoofdlettergevoelig en moet kleine letters bevatten en mag geen witruimte bevatten.

[genormaliseerde waarde] van de AII van het JSON-typekenmerk Toegestaan [kinderen] van het bijbehorende EII Toewijzing aan JSON
string (of afwezigheid van het JSON-type AII)

A string en het ontbreken van het JSON-type AII zijn hetzelfde, maakt string de standaardwaarde.

Dus, <root> string1</root> wordt toegewezen aan de JSON string 'string1'.
0 of meer URI's Een JSON string (JSON RFC, sectie 2.5). Elk char is een teken dat overeenkomt met de [tekencode] van de CII. Als er geen URI's zijn, wordt deze toegewezen aan een lege JSON string.

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment:

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

Het JSON-fragment is '42'.

Bij xml-naar-JSON-toewijzingen moeten tekens die moeten worden toegewezen aan escape-tekens, alle andere tekens worden toegewezen aan tekens die niet zijn ontsnapt. Het teken '/' is speciaal - het is ontsnapt, ook al hoeft het niet te zijn (uitgeschreven als "\/").

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment.

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

Het JSON-fragment is "the \"da\/ta\".

Bij JSON-naar-XML-toewijzing worden escape-tekens en -tekens die niet correct zijn gekoppeld aan de bijbehorende [tekencode] toegewezen.

Voorbeeld: Het JSON-fragment \u0041BC, wordt toegewezen aan het volgende XML-element.

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

De tekenreeks kan worden omgeven door witruimte ('ws' in sectie 2 van de JSON RFC) die niet wordt toegewezen aan XML.

Voorbeeld: het JSON-fragment 'ABC', (er zijn spaties vóór de eerste dubbele aanhalingsteken), wordt toegewezen aan het volgende XML-element.

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

Eventuele witruimte in XML-toewijzingen aan witruimte in JSON.

Voorbeeld: Het volgende XML-element wordt toegewezen aan een JSON-fragment.

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

Het JSON-fragment is " A BC ".
number 1 of meer URI's Een JSON number (JSON RFC, sectie 2.4), mogelijk omgeven door witruimte. Elk teken in de combinatie van getal/witruimte is een teken dat overeenkomt met de [tekencode] van de CII.

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment.

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

Het JSON-fragment is 42

(Witruimte blijft behouden).
boolean 4 of 5 CI's (die overeenkomen met true of false), mogelijk omgeven door extra witruimte-CI's. Een CII-reeks die overeenkomt met de tekenreeks 'true' wordt toegewezen aan de letterlijke tekenreeks trueen een CII-reeks die overeenkomt met de tekenreeks 'false' wordt toegewezen aan de letterlijke .false Omringende witruimte blijft behouden.

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment.

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

Het JSON-fragment is false.
null Geen toegestaan. De letterlijke null. Bij JSON-naar-XML-toewijzing is de null ruimte mogelijk omgeven door witruimte ('ws' in sectie 2) die niet wordt toegewezen aan XML.

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment.

<root type="null"/>

or

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

:

Het JSON-fragment in beide gevallen is Null.
object 0 of meer EII's. A begin-object (accolade links) zoals in sectie 2.2 van de JSON RFC, gevolgd door een ledenrecord voor elke EII, zoals verder beschreven. Als er meer dan één EII is, zijn er waardenscheidingstekens (komma's) tussen de lidrecords. Dit alles wordt gevolgd door een eindobject (rechter accolade).

Voorbeeld: Het volgende element wordt toegewezen aan het JSON-fragment.

<root type="object">

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

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

</root >

Het JSON-fragment is {"type1":"aaa","type2":"bbb"}.

Als het kenmerk voor het gegevenscontracttype aanwezig is in xml-naar-JSON-toewijzing, wordt er aan het begin een extra lidrecord ingevoegd. De naam is de [lokale naam] van het kenmerk Gegevenscontracttype ("__type") en de waarde is de [genormaliseerde waarde] van het kenmerk. Omgekeerd is bij JSON naar XML-toewijzing, als de naam van de eerste lidrecord de [lokale naam] is van het kenmerk Gegevenscontracttype (d.w.z. '__type'), is er een bijbehorend kenmerk voor gegevenscontracttype aanwezig in de toegewezen XML, maar er is geen bijbehorende EII aanwezig. Houd er rekening mee dat deze lidrecord eerst moet plaatsvinden in het JSON-object om deze speciale toewijzing toe te passen. Dit vertegenwoordigt een afwijking van de gebruikelijke JSON-verwerking, waarbij de volgorde van lidrecords niet significant is.

Voorbeeld:

Het volgende JSON-fragment wordt toegewezen aan XML.

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

De XML is de volgende code.

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

U ziet dat de __type AII aanwezig is, maar er is geen __type EII.

Als de volgorde in de JSON echter wordt omgekeerd, zoals wordt weergegeven in het volgende voorbeeld.

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

De bijbehorende XML wordt weergegeven.

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

Dat wil zeggen dat __type geen speciale betekenis meer heeft en zich zoals gebruikelijk aan een EII toezet, niet AII.

Escape-/unescaping-regels voor de [genormaliseerde waarde] van de AII wanneer deze is toegewezen aan een JSON-waarde, zijn hetzelfde als voor JSON-tekenreeksen, die zijn opgegeven in de rij 'tekenreeks' van deze tabel.

Voorbeeld:

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

aan het vorige voorbeeld kan worden toegewezen aan de volgende JSON.

{"__type":"\\abc"}

Bij een XML-naar-JSON-toewijzing mag de [lokale naam] van de eerste EII niet '__type' zijn.

Witruimte (ws) wordt nooit gegenereerd op XML naar JSON-toewijzing voor objecten en wordt genegeerd op JSON-naar-XML-toewijzing.

Voorbeeld: Het volgende JSON-fragment wordt toegewezen aan een XML-element.

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

Het XML-element wordt weergegeven in de volgende code.

<root type="object"> <ccc type="string">aaa</ccc> <ddd type="string">bbb</bar> </root >
matrix 0 of meer EII's Een beginmatrix (vierkante haak links) zoals in sectie 2.3 van de JSON RFC, gevolgd door een matrixrecord voor elke EII, zoals verder wordt beschreven. Als er meer dan één EII is, zijn er waardenscheidingstekens (komma's) tussen de matrixrecords. Dit alles wordt gevolgd door een eindmatrix.

Voorbeeld: Het volgende XML-element wordt toegewezen aan een JSON-fragment.

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

Het JSON-fragment is ["aaa","bbb"]

Witruimte (ws) wordt nooit gegenereerd op XML-naar-JSON-toewijzing voor matrices en wordt genegeerd op JSON-naar-XML-toewijzing.

Voorbeeld: een JSON-fragment.

["aaa", "bbb"]

Het XML-element waaraan het wordt toegewezen.

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

Lidrecords werken als volgt:

  • De [lokale naam] van het binnenste element wordt toegewezen aan het deel van de string member zoals gedefinieerd in sectie 2.2 van de JSON RFC.

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment.

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

Het volgende JSON-fragment wordt weergegeven.

{"myLocalName":"aaa"}
  • Op de XML-naar-JSON-toewijzing worden de tekens die moeten worden ontsnapt in JSON, ontsnapt en worden de andere tekens niet ontsnapt. Het '/'-teken, ook al is het geen teken dat moet worden ontsnapt, is niettemin escaped (het hoeft niet te worden escaped op JSON naar XML-toewijzing). Dit is vereist ter ondersteuning van de ASP.NET AJAX-indeling voor DateTime gegevens in JSON.

  • Op de JSON naar XML-toewijzing worden alle tekens (inclusief de niet-escape-tekens, indien nodig) genomen om een string te vormen die een [lokale naam] produceert.

  • Binnenste elementen [onderliggende elementen] worden toegewezen aan de waarde in sectie 2.2, afhankelijk van de JSON Type Attribute achtige voor de Root JSON Element. Er zijn meerdere niveaus voor het nesten van EII's (inclusief nesten binnen matrices) toegestaan.

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment.

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

Het volgende JSON-fragment is waaraan het is toegewezen.

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

Notitie

Er is geen XML-coderingsstap in de voorgaande toewijzing. WcF ondersteunt daarom alleen JSON-documenten waarbij alle tekens in sleutelnamen geldige tekens zijn in XML-elementnamen. Het JSON-document {":<"a"} wordt bijvoorbeeld niet ondersteund omdat < dit geen geldige naam is voor een XML-element.

De omgekeerde situatie (tekens die geldig zijn in XML maar niet in JSON) veroorzaakt geen problemen omdat de voorgaande toewijzing JSON-stappen voor escape-/unescaping bevat.

Matrixrecords werken als volgt:

  • De [lokale naam] van het binnenste element is 'item'.

  • De [onderliggende] waarde van het binnenste element wordt toegewezen aan de waarde in sectie 2.3, volgens het JSON-typekenmerk, net als voor het JSON-hoofdelement. Er zijn meerdere niveaus voor het nesten van EI's (inclusief nesten binnen objecten) toegestaan.

Voorbeeld: Het volgende element wordt toegewezen aan een JSON-fragment.

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

Hier volgt het JSON-fragment.

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

Zie ook