Dela via

Fristående JSON-serialisering med DataContractJsonSerializer

  • Artikel

Kommentar

Den här artikeln handlar om DataContractJsonSerializer. För de flesta scenarier som omfattar serialisering och deserialisering av JSON rekommenderar vi API:erna i namnområdet System.Text.Json.

JSON (JavaScript Object Notation) är ett dataformat som är särskilt utformat för att användas av JavaScript-kod som körs på webbsidor i webbläsaren. Det är standarddataformatet som används av ASP.NET AJAX-tjänster som skapats i Windows Communication Foundation (WCF).

Det här formatet kan också användas när du skapar AJAX-tjänster utan att integrera med ASP.NET – i det här fallet är XML standard men JSON kan väljas.

Slutligen, om du behöver JSON-stöd men inte skapar en AJAX-tjänst, DataContractJsonSerializer gör det möjligt att direkt serialisera .NET-objekt till JSON-data och deserialisera sådana data tillbaka till instanser av .NET-typer. En beskrivning av hur du gör detta finns i Så här gör du: Serialisera och deserialisera JSON-data.

När du arbetar med JSON stöds samma .NET-typer, med några få undantag, som stöds av DataContractSerializer. En lista över de typer som stöds finns i Typer som stöds av Data Contract Serializer. Detta omfattar de flesta primitiva typerna, de flesta matris- och samlingstyper samt komplexa typer som använder DataContractAttribute och DataMemberAttribute.

Mappa .NET-typer till JSON-typer

I följande tabell visas korrespondensen mellan .NET-typer och JSON/JavaScript-typer när de mappas av serialiserings- och deserialiseringsprocedurer.

.NET-typer JSON/JavaScript Kommentar
Alla numeriska typer, till exempel Int32, Decimal eller Double Antal Specialvärden som Double.NaN, Double.PositiveInfinity och Double.NegativeInfinity stöds inte och resulterar i ogiltig JSON.
Enum Antal Se "Uppräkningar och JSON" senare i den här artikeln.
Boolean Booleskt
String, Char String
TimeSpan, , GuidUri String Formatet för dessa typer i JSON är detsamma som i XML (i huvudsak tidsintervallet i formatet ISO 8601 Duration, GUID i formatet "12345678-ABCD-ABCD-ABCD-1234567890AB" och URI i sin naturliga strängform som "http://www.example.com"). Mer information finns i Referens för datakontraktsschema.
XmlQualifiedName String Formatet är "name:namespace" (allt innan det första kolonet är namnet). Antingen kan namnet eller namnområdet saknas. Om det inte finns något namnområde kan kolonet också utelämnas.
Array av typen Byte Matris med tal Varje tal representerar värdet för en byte.
DateTime DateTime eller Sträng Se Datum/tider och JSON senare i den här artikeln.
DateTimeOffset Komplex typ Se Datum/tider och JSON senare i den här artikeln.
XML- och ADO.NET typer (XmlElement,

XElement. Matriser med XmlNode,

ISerializable,

DataSet).		 String Se avsnittet XML-typer och JSON i den här artikeln.
DBNull Tom komplex typ --
Samlingar, ordlistor och matriser Matris Se avsnittet Samlingar, ordlistor och matriser i det här avsnittet.
Komplexa typer (med DataContractAttribute eller SerializableAttribute tillämpade) Komplex typ Datamedlemmar blir medlemmar av den komplexa JavaScript-typen.
Komplexa typer som implementerar ISerializable gränssnittet) Komplex typ Samma som andra komplexa typer men vissa ISerializable typer stöds inte – se ISerializable Support.
Null värde för valfri typ Null Nullbara värdetyper stöds också och mappas till JSON på samma sätt som icke-nullbara värdetyper.

Uppräkningar och JSON

Uppräkningsmedlemsvärden behandlas som tal i JSON, vilket skiljer sig från hur de behandlas i datakontrakt, där de ingår som medlemsnamn. Mer information om datakontraktsbehandling finns i Uppräkningstyper i datakontrakt.

  • Om du till exempel har public enum Color {red, green, blue, yellow, pink}genererar serialisering yellow talet 3 och inte strängen "gul".

  • Alla enum medlemmar är serialiserbara. Attributen EnumMemberAttribute och ignoreras om de NonSerializedAttribute används.

  • Det är möjligt att deserialisera ett obefintligt enum värde , till exempel kan värdet 87 deserialiseras till den tidigare färguppräkningen även om det inte finns något motsvarande färgnamn definierat.

  • enum Flaggor är inte speciella och behandlas på samma sätt som andra enum.

Datum/tider och JSON

JSON-formatet stöder inte datum och tider direkt. De används dock ofta och ASP.NET AJAX ger särskilt stöd för dessa typer. När du använder ASP.NET AJAX-proxyservrar DateTime motsvarar DateTime typen i .NET fullständigt typen i JavaScript.

  • När du inte använder ASP.NET representeras en DateTime typ i JSON som en sträng med ett särskilt format som beskrivs i avsnittet Avancerad information i det här avsnittet.

  • DateTimeOffset representeras i JSON som en komplex typ: {"DateTime":d ateTime,"OffsetMinutes":offsetMinutes}. Medlemmen offsetMinutes är den lokala tidsförskjutningen från Greenwich Mean Time (GMT), som nu även kallas Coordinated Universal Time (UTC), som är associerad med platsen för händelsen av intresse. Medlemmen dateTime representerar instansen i tid när händelsen av intresse inträffade (återigen blir den en DateTime i JavaScript när ASP.NET AJAX används och en sträng när den inte är det). Vid serialisering serialiseras dateTime medlemmen alltid i GMT. Så om du beskriver 03:00 New York-tid, dateTime har en tidskomponent på 8:00 am och offsetMinutes är 300 (minus 300 minuter eller 5 timmar från GMT).

    Kommentar

    DateTime och DateTimeOffset objekt, när de serialiseras till JSON, bevarar endast information till millisekunders precision. Under millisekunder (mikro-/nanosekunder) går förlorade under serialiseringen.

XML-typer och JSON

XML-typer blir JSON-strängar.

  • Om till exempel en datamedlem "q" av typen XElement innehåller <abc/>, är JSON {"q":"<abc/>"}.

  • Det finns några särskilda regler som anger hur XML omsluts – mer information finns i avsnittet Avancerad information senare i den här artikeln.

  • Om du använder ASP.NET AJAX och inte vill använda strängar i JavaScript, men vill använda XML DOM i stället, anger du ResponseFormat egenskapen till XML på WebGetAttribute eller ResponseFormat egenskapen till XML på WebInvokeAttribute.

Samlingar, ordlistor och matriser

Alla samlingar, ordlistor och matriser representeras i JSON som matriser.

  • Alla anpassningar som använder CollectionDataContractAttribute ignoreras i JSON-representationen.

  • Ordlistor är inte ett sätt att arbeta direkt med JSON. Ordlistesträng<, objekt> kanske inte stöds på samma sätt i WCF som förväntat från att arbeta med andra JSON-tekniker. Om till exempel "abc" mappas till "xyz" och "def" mappas till 42 i en ordlista är JSON-representationen inte {"abc":"xyz","def":42} utan [{"Key":"abc","Värde":"xyz"},{"Key":"def","Värde":42}] i stället.

  • Om du vill arbeta med JSON direkt (komma åt nycklar och värden dynamiskt, utan att fördefiniera ett fast kontrakt), har du flera alternativ:

    • Överväg att använda exemplet med svag typ av JSON-serialisering (AJAX).

    • Överväg att använda ISerializable gränssnitts- och deserialiseringskonstruktorer – med dessa två mekanismer kan du komma åt JSON-nyckel/värde-par på serialisering respektive deserialisering, men fungerar inte i partiella förtroendescenarier.

    • Överväg att arbeta med mappningen mellan JSON och XML i stället för att använda en serialiserare.

    • Polymorfism i kontexten för serialisering syftar på möjligheten att serialisera en härledd typ där dess bastyp förväntas. Det finns särskilda JSON-specifika regler när du använder samlingar polymorfiskt när du till exempel tilldelar en samling till en Object. Det här problemet beskrivs mer utförligt i avsnittet Avancerad information senare i den här artikeln.

Ytterligare information

Ordningen på datamedlemmar

Ordningen på datamedlemmar är inte viktig när du använder JSON. Mer specifikt kan JSON-data fortfarande deserialiseras i valfri ordning, även om Order de har angetts.

JSON-typer

JSON-typen behöver inte matcha föregående tabell vid deserialisering. Till exempel mappar en Int normalt till ett JSON-nummer, men det kan också deserialiseras från en JSON-sträng så länge strängen innehåller ett giltigt tal. Det vill: både {"q":42} och {"q":"42"} är giltiga om det finns en Int datamedlem som heter "q".

Polymorfism

Polymorf serialisering består av möjligheten att serialisera en härledd typ där bastypen förväntas. Detta stöds för JSON-serialisering av WCF som är jämförbar med hur XML-serialisering stöds. Du kan till exempel serialisera MyDerivedType var MyBaseType som förväntas eller serialisera Int var Object som förväntas.

Typinformation kan gå förlorad vid deserialisering av en härledd typ om bastypen förväntas, såvida du inte deserialiserar en komplex typ. Om Uri till exempel serialiseras där Object förväntas resulterar det i en JSON-sträng. Om strängen sedan deserialiseras tillbaka till Objectreturneras en .NET String . Deserialiseraren vet inte att strängen ursprungligen var av typen Uri. När du förväntar dig Objectär alla JSON-strängar deserialiserade som .NET-strängar och alla JSON-matriser som används för att serialisera .NET-samlingar, ordlistor och matriser deserialiseras som .NET Array av typen Object, oavsett vilken ursprunglig typ som faktiskt hade varit. En JSON-boolesk mappning till en .NET Boolean. Men när du förväntar dig Object, deserialiseras JSON-nummer som antingen .NET Int32Decimal eller Double, där den lämpligaste typen väljs automatiskt.

När deserialiseras till en gränssnittstyp DataContractJsonSerializer deserialiseras som om den deklarerade typen var objekt.

När du arbetar med dina egna bas- och härledda typer krävs normalt med hjälp av KnownTypeAttribute, ServiceKnownTypeAttribute eller en motsvarande mekanism. Om du till exempel har en åtgärd som har ett Animal returvärde och den faktiskt returnerar en instans av Cat (härledd från Animal) bör du antingen tillämpa KnownTypeAttribute, Animal på typen eller ServiceKnownTypeAttribute på åtgärden och ange Cat typen i dessa attribut. Mer information finns i Kända typer av datakontrakt.

Mer information om hur polymorf serialisering fungerar och en diskussion om några av de begränsningar som måste respekteras när du använder den finns i avsnittet Avancerad information senare i den här artikeln.

Versionshantering

Funktionerna för versionshantering av datakontrakt, inklusive IExtensibleDataObject gränssnittet, stöds fullt ut i JSON. Dessutom är det i de flesta fall möjligt att deserialisera en typ i ett format (till exempel XML) och sedan serialisera den till ett annat format (till exempel JSON) och fortfarande bevara data i IExtensibleDataObject. Mer information finns i Framåtkompatibla datakontrakt. Kom ihåg att JSON är oordnad så att all orderinformation går förlorad. Dessutom stöder JSON inte flera nyckel/värde-par med samma nyckelnamn. Slutligen är alla åtgärder på IExtensibleDataObject till sin natur polymorfa – det är deras härledda typ som tilldelas till Object, bastypen för alla typer.

JSON i URL:er

När du använder ASP.NET AJAX-slutpunkter med HTTP GET-verbet (med attributet WebGetAttribute ) visas inkommande parametrar i begärande-URL:en i stället för meddelandetexten. JSON stöds även i begärande-URL:en, så om du har en åtgärd som tar ett Int "nummer" och en Person komplex typ som kallas "p", kan URL:en likna följande URL.

http://example.com/myservice.svc/MyOperation?number=7&p={"name":"John","age":42}

Om du använder en ASP.NET AJAX Script Manager-kontroll och proxy för att anropa tjänsten genereras den här URL:en automatiskt av proxyn och visas inte. JSON kan inte användas i URL:er på non-ASP.NET AJAX-slutpunkter.

Avancerad information

Stöd för ISerializable

ISerializable-typer som stöds och som inte stöds

I allmänhet stöds typer som implementerar ISerializable gränssnittet fullt ut vid serialisering/deserialisering av JSON. Vissa av dessa typer (inklusive vissa .NET Framework-typer) implementeras dock på ett sådant sätt att JSON-specifika serialiseringsaspekter gör att de inte deserialiseras korrekt:

  • Med ISerializableär typen av enskilda datamedlemmar aldrig känd i förväg. Detta leder till en polymorf situation som liknar deserialiserande typer i ett objekt. Som tidigare nämnts kan detta leda till förlust av typinformation i JSON. Till exempel misslyckas en typ som serialiserar en enum i implementeringen ISerializable och försöker deserialisera tillbaka direkt till en enum (utan korrekt avbildningar), eftersom en enum serialiseras med tal i JSON- och JSON-tal deserialisera till inbyggda .NET-numeriska typer (Int32, Decimal eller Double). Så det faktum att talet brukade vara ett enum värde går förlorat.

  • En ISerializable typ som är beroende av en viss deserialiseringsordning i konstruktorn för deserialisering kan också misslyckas med att deserialisera vissa JSON-data, eftersom de flesta JSON-serialiserare inte garanterar någon specifik ordning.

Fabrikstyper

IObjectReference Gränssnittet stöds i JSON i allmänhet, men alla typer som kräver funktionen "fabrikstyp" (returnerar en instans av en annan typ än GetRealObject(StreamingContext) den typ som implementerar gränssnittet) stöds inte.

DateTime Wire-format

DateTime värden visas som JSON-strängar i form av "/Date(700000+0500)/", där det första talet (700000 i det angivna exemplet) är antalet millisekunder i GMT-tidszonen, vanlig tid (icke-sommartid) sedan midnatt, 1 januari 1970. Talet kan vara negativt för att representera tidigare tider. Den del som består av "+0500" i exemplet är valfri och anger att tiden är av den Local typen , det vill säga ska konverteras till den lokala tidszonen vid deserialisering. Om den saknas kommer tiden att deserialiseras som Utc. Det faktiska talet ("0500" i det här exemplet) och dess tecken (+ eller -) ignoreras.

När serialisering DateTime, Local och Unspecified tider skrivs med en förskjutning och Utc skrivs utan.

JavaScript-koden för ASP.NET AJAX-klienten konverterar automatiskt sådana strängar till JavaScript-instanser DateTime . Om det finns andra strängar som har ett liknande formulär som inte är av typen DateTime i .NET konverteras de också.

Konverteringen sker endast om "/"-tecknen är undantagna (det vill: JSON ser ut som "\/Date(700000+0500)\/"), och av den anledningen kommer WCF:s JSON-kodare (aktiverad av WebHttpBinding) alltid att undvika tecknet "/".

XML i JSON-strängar

XmlElement

XmlElement serialiseras som den är, utan omslutning. Till exempel representeras datamedlemmen "x" av typen XmlElement som innehåller <abc/> på följande sätt:

{"x":"<abc/>"}

XmlNode-matriser

Array objekt av typen XmlNode omsluts i ett element som heter ArrayOfXmlNode i standarddatakontraktets namnområde för typen. Om "x" är en matris som innehåller attributnoden "N" i namnområdet "ns" som innehåller "värde" och en tom elementnod "M", är representationen följande.

{"x":"<ArrayOfXmlNode xmlns=\"http://schemas.datacontract.org/2004/07/System.Xml\" a:N=\"value\" xmlns:a=\"ns\"><M/></ArrayOfXmlNode>"}

Attribut i det tomma namnområdet i början av XmlNode-matriser (innan andra element) stöds inte.

IXmlSerializable-typer inklusive XElement och DataSet

ISerializable typer delas upp i "innehållstyper", "DataSet-typer" och "elementtyper". Definitioner av dessa typer finns i XML och ADO.NET typer i datakontrakt.

Typerna "Content" och "DataSet" serialiseras ungefär som Array objekt som XmlNode beskrivs i föregående avsnitt. De omsluts i ett element vars namn och namnområde motsvarar datakontraktets namn och namnområde för den aktuella typen.

"Elementtyper" som XElement serialiseras som de är, ungefär XmlElement som tidigare beskrivits i den här artikeln.

Polymorfism

Bevara typinformation

Som tidigare nämnts stöds polymorfism i JSON med vissa begränsningar. JavaScript är ett svagt skrivet språk och typidentiteten är normalt inte ett problem. Men när du använder JSON för att kommunicera mellan ett starkt skrivet system (.NET) och ett svagt skrivet system (JavaScript) är det användbart att bevara typidentiteten. Typer med datakontraktsnamnen "Square" och "Circle" härleds till exempel från en typ med ett datakontraktsnamn som "Form". Om "Circle" skickas från .NET till JavaScript och senare returneras till en .NET-metod som förväntar sig "Form" är det användbart för .NET-sidan att veta att objektet i fråga ursprungligen var en "Cirkel" – annars kan all information som är specifik för den härledda typen (till exempel "radius"-datamedlemmen i "Circle") gå förlorad.

Om du vill bevara typidentiteten kan du lägga till ett "typtips" när du serialiserar komplexa typer till JSON, och deserialiseraren känner igen tipset och agerar på rätt sätt. "Type hint" är ett JSON-nyckel/värde-par med nyckelnamnet "__type" (två understreck följt av ordet "typ"). Värdet är en JSON-sträng i formuläret "DataContractName:DataContractNamespace" (allt upp till det första kolonet är namnet). I det tidigare exemplet kan "Circle" serialiseras på följande sätt.

{"__type":"Circle:http://example.com/myNamespace","x":50,"y":70,"radius":10}

Typtipset liknar det xsi:type attribut som definieras av XML-schemainstansstandarden och används vid serialisering/deserialisering av XML.

Datamedlemmar som kallas "__type" är förbjudna på grund av potentiella konflikter med typtipset.

Minska storleken på typtips

För att minska storleken på JSON-meddelanden ersätts standardprefixet för datakontraktets namnområde (http://schemas.datacontract.org/2004/07/) med tecknet "#". (För att göra den här ersättningen reversibel används en undantagsregel: om namnområdet börjar med tecknen "#" eller "\" läggs de till med ett extra "\" tecken). Om "Circle" är en typ i .NET-namnområdet "MyApp.Shapes" är http://schemas.datacontract.org/2004/07/MyAppdess standardnamnområde för datakontrakt . Former och JSON-representationen är följande.

{"__type":"Circle:#MyApp.Shapes","x":50,"y":70,"radius":10}

Både de trunkerade (#MyApp.Shapes) och de fullständiga (http://schemas.datacontract.org/2004/07/MyApp.Shapes) namnen tolkas vid deserialisering.

Ange tipsposition i JSON-objekt

Observera att typtipset måste visas först i JSON-representationen. Detta är det enda fallet där ordningen på nyckel/värde-par är viktig vid JSON-bearbetning. Följande är till exempel inte ett giltigt sätt att ange typtipset.

{"x":50,"y":70,"radius":10,"__type":"Circle:#MyApp.Shapes"}

Både de DataContractJsonSerializer som används av WCF och ASP.NET AJAX-klientsidor genererar alltid typtipset först.

Typtips gäller endast för komplexa typer

Det finns inget sätt att generera ett typtips för icke-komplexa typer. Om en åtgärd till exempel har en Object returtyp men returnerar en cirkel, kan JSON-representationen vara som den visades tidigare och typinformationen bevaras. Men om Uri returneras är JSON-representationen en sträng och det faktum att strängen som används för att representera en Uri går förlorad. Detta gäller inte bara primitiva typer utan även för samlingar och matriser.

När genereras typtips

Typtips kan öka meddelandestorleken avsevärt (ett sätt att minimera detta är att använda kortare namnområden för datakontrakt om möjligt). Därför styr följande regler om typtips genereras:

  • När du använder ASP.NET AJAX genereras alltid typtips när det är möjligt, även om det inte finns någon bas-/härledd tilldelning, till exempel även om en cirkel tilldelas till en cirkel. (Detta krävs för att helt aktivera processen för att anropa från den svagt skrivna JSON-miljön till den starkt skrivna .NET-miljön utan överraskande informationsförlust.)

  • När du använder AJAX-tjänster utan ASP.NET integrering genereras bara typtips när det finns en bas-/härledd tilldelning , det vill: genereras när Cirkel tilldelas till form eller Object men inte när den tilldelas till Cirkel. Detta ger den minsta information som krävs för att implementera en JavaScript-klient korrekt, vilket förbättrar prestandan, men skyddar inte mot typinformationsförlust i felaktigt utformade klienter. Undvik bas-/härledda tilldelningar helt och hållet på servern om du vill undvika att hantera det här problemet på klienten.

  • När du använder DataContractSerializer typen alwaysEmitTypeInformation kan du med konstruktorparametern välja mellan de föregående två lägena, där standardvärdet är "false" (endast genererar typtips när det behövs).

Duplicera datamedlemsnamn

Härledd typinformation finns i samma JSON-objekt tillsammans med bastypsinformation och kan ske i valfri ordning. Kan till exempel Shape representeras på följande sätt.

{"__type":"Shape:#MyApp.Shapes","x":50,"y":70}

Cirkeln kan representeras på följande sätt.

{"__type":"Circle:#MyApp.Shapes","x":50, "radius":10,"y":70}

Om bastypen Shape också innehåller en datamedlem med namnet "radius" leder detta till en kollision på både serialisering (eftersom JSON-objekt inte kan ha upprepade nyckelnamn) och deserialisering (eftersom det är oklart om "radius" refererar till Shape.radius eller Circle.radius). Även om begreppet "egenskap gömmer sig" (datamedlemmar med samma namn på baserade och härledda klasser) vanligtvis inte rekommenderas i datakontraktsklasser, är det i själva verket förbjudet när det gäller JSON.

Polymorfism och IXmlSerializable-typer

IXmlSerializable typer kan polymorfiskt tilldelas till varandra så länge som kraven på kända typer uppfylls, enligt vanliga regler för datakontrakt. Men serialisering av Object en IXmlSerializable typ i stället för resulterar i förlust av typinformation eftersom resultatet är en JSON-sträng.

Polymorfism och vissa gränssnittstyper

Det är förbjudet att serialisera en samlingstyp eller en typ som implementerar där en icke-samlingstyp IXmlSerializable som inte IXmlSerializable är (förutom Object) förväntas. Till exempel ett anpassat gränssnitt med namnet IMyInterface och en typ MyType som implementerar både IEnumerable<T> av typen int och IMyInterface. Det är förbjudet att återvända MyType från en åtgärd vars returtyp är IMyInterface. Detta beror på att MyType måste serialiseras som en JSON-matris och kräver en typtips, och som anges innan du inte kan inkludera en typtips med matriser, endast med komplexa typer.

Kända typer och konfigurationer

Alla mekanismer för känd typ som används av DataContractSerializer stöds också på samma sätt av DataContractJsonSerializer. Båda serialiserarna läser samma konfigurationselement, <dataContractSerializer> i <system.runtime.serialization>, för att identifiera kända typer som lagts till via en konfigurationsfil.

Samlingar tilldelade till objekt

Samlingar som tilldelats objektet serialiseras som om de vore samlingar som implementerar IEnumerable<T>: en JSON-matris med varje post som har en typtips om det är en komplex typ. En av de typer Shape som tilldelats till ser till Object exempel List<T> ut så här.

[{"__type":"Shape:#MyApp.Shapes","x":50,"y":70},
{"__type":"Shape:#MyApp.Shapes","x":58,"y":73},
{"__type":"Shape:#MyApp.Shapes","x":41,"y":32}]

När deserialiseras tillbaka till Object:

  • Shape måste finnas i listan Kända typer. Att ha List<T> av typen Shape i kända typer har ingen effekt. Observera att du inte behöver lägga Shape till kända typer vid serialisering i det här fallet – detta görs automatiskt.

  • Samlingen deserialiseras som en Array typ som Object innehåller Shape instanser.

Härledda samlingar tilldelade till bassamlingar

När en härledd samling tilldelas till en bassamling serialiseras samlingen vanligtvis som om den vore en samling av bastypen. Men om objekttypen för den härledda samlingen inte kan tilldelas till objekttypen för bassamlingen genereras ett undantag.

Skriv tips och ordlistor

När en ordlista tilldelas till en Objectbehandlas varje nyckel- och värdepost i ordlistan som om den tilldelades till Object och får ett typtips.

När du serialiserar ordlistetyper påverkas inte JSON-objektet som innehåller medlemmarna "Key" och "Value" av alwaysEmitTypeInformation inställningen och innehåller bara ett typtips när de föregående samlingsreglerna kräver det.

Giltiga JSON-nyckelnamn

Serialiseraren XML-kodar nyckelnamn som inte är giltiga XML-namn. En datamedlem med namnet "123" skulle till exempel ha ett kodat namn som "_x0031__x0032__x0033_" eftersom "123" är ett ogiltigt XML-elementnamn (börjar med en siffra). En liknande situation kan uppstå med vissa internationella teckenuppsättningar som inte är giltiga i XML-namn. En förklaring av den här effekten av XML på JSON-bearbetning finns i Mappning mellan JSON och XML.

Se även