Samostatná serializace JSON pomocí DataContractJsonSerializer

Poznámka:

Tento článek se týká DataContractJsonSerializer. Pro většinu scénářů, které zahrnují serializaci a deserializaci JSON, doporučujeme rozhraní API v oboru názvů System.Text.Json.

JSON (JavaScript Object Notation) je datový formát, který je speciálně navržený pro použití javascriptovým kódem spuštěným na webových stránkách v prohlížeči. Jedná se o výchozí formát dat používaný službami AJAX ASP.NET vytvořenými ve Windows Communication Foundation (WCF).

Tento formát lze použít také při vytváření služeb AJAX bez integrace s ASP.NET – v tomto případě je XML výchozí, ale json lze zvolit.

A konečně, pokud požadujete podporu JSON, ale nevytváření služby AJAX, DataContractJsonSerializer umožňuje přímo serializovat objekty .NET do dat JSON a deserializovat taková data zpět do instancí typů .NET. Popis postupu najdete v tématu Postupy: Serializace a Deserializace dat JSON.

Při práci s JSON jsou podporovány stejné typy .NET, s několika výjimkami, jako u DataContractSerializer. Seznam podporovaných typů naleznete v tématu Typy podporované serializátorem kontraktu dat. To zahrnuje většinu primitivních typů, většinu typů polí a kolekcí, stejně jako komplexní typy, které používají DataContractAttribute a DataMemberAttribute.

Mapování typů .NET na typy JSON

Následující tabulka ukazuje korespondenci mezi typy .NET a typy JSON/JavaScript při mapování serializací a deserializací procedur.

Typy .NET	JSON/JavaScript	Poznámky
Všechny číselné typy, například Int32, Decimal nebo Double	Číslo	Speciální hodnoty, jako Double.NaN, Double.PositiveInfinity a Double.NegativeInfinity nejsou podporovány a vedou k neplatnému JSON.
Enum	Číslo	Viz "Výčty a JSON" dále v tomto článku.
Boolean	Boolovská logika
String, Char	Řetězec
TimeSpan, , GuidUri	Řetězec	Formát těchto typů v JSON je stejný jako v XML (v podstatě časový rozsah ve formátu ISO 8601 Duration, GUID ve formátu "12345678-ABCD-ABCD-ABCD-1234567890AB" a identifikátor URI v jeho přirozené podobě, jako je "http://www.example.com"). Přesné informace naleznete v tématu Referenční informace ke schématu kontraktu dat.
XmlQualifiedName	Řetězec	Formát je "name:namespace" (cokoli před prvním dvojtečku je název). Název nebo obor názvů může chybět. Pokud neexistuje žádný obor názvů, dvojtečku lze vynechat.
Command typu System.Windows.Input.ICommand	Pole čísel	Každé číslo představuje hodnotu jednoho bajtu.
DateTime	DateTime nebo String	Viz data a časy a JSON dále v tomto článku.
DateTimeOffset	Komplexní typ	Viz data a časy a JSON dále v tomto článku.
Typy XML a ADO.NET (XmlElement, XElement. Pole ,XmlNode ISerializable, DataSet).	Řetězec	Viz část Typy XML a JSON tohoto článku.
DBNull	Prázdný komplexní typ	--
Kolekce, slovníky a pole	Pole	Podívejte se na sekci tohoto tématu s názvy Kolekce, Slovníky a Pole.
Komplexní typy (s použitím DataContractAttribute nebo SerializableAttribute)	Komplexní typ	Datové členy se stanou členy komplexního typu JavaScriptu.
Komplexní typy implementují ISerializable rozhraní)	Komplexní typ	Stejné jako jiné komplexní typy, ale některé ISerializable typy nejsou podporovány – viz podpora ISerializable.
Null hodnota pro libovolný typ	Nula	Podporují se také nulovatelné hodnotové typy a mapují se na JSON stejným způsobem jako hodnotové typy bez hodnoty null.

Výčty a JSON

Členské hodnoty výčtu se považují za čísla ve formátu JSON, která se liší od způsobu jejich zpracování v kontraktech dat, kde jsou zahrnuté jako názvy členů. Další informace o zpracování kontraktů dat naleznete v tématu Výčtové typy v kontraktech dat.

• Pokud máte například public enum Color {red, green, blue, yellow, pink}, serializace yellow vytvoří číslo 3, a ne řetězec "žlutá".

• Všechny enum členy jsou serializovatelné. Použijí-li se atributy EnumMemberAttribute a NonSerializedAttribute, jsou ignorovány.

• Je možné deserializovat neexistující enum hodnotu – například hodnotu 87 lze deserializovat do předchozího výčtu Color, i když neexistuje žádný odpovídající název barvy definovaný.

• Příznak enum není zvláštní a považuje se za stejný jako jakýkoliv jiný enum.

Datumy/časy a JSON

Formát JSON nepodporuje přímo kalendářní data a časy. Jsou však velmi často používány a ASP.NET AJAX poskytuje zvláštní podporu pro tyto typy. Pokud používáte proxy ASP.NET AJAX, DateTime typ v .NET plně odpovídá DateTime typu v JavaScriptu.

• Pokud nepoužíváte ASP.NET, DateTime je typ ve formátu JSON reprezentován jako řetězec se speciálním formátem, který je popsán v části Upřesnit informace v tomto tématu.

• DateTimeOffset je reprezentován ve formátu JSON jako komplexní typ: {"DateTime":d ateTime,"OffsetMinutes":offsetMinutes}. Člen offsetMinutes je odchylka místního času od času Greenwich (GMT), který je nyní také označován jako koordinovaný univerzální čas (UTC), vztahující se k místu, kde se událost koná. Člen dateTime představuje bod v čase, kdy došlo k události, o kterou se zajímáme (v JavaScriptu se opět stane DateTime, pokud je používán ASP.NET AJAX, a řetězcem, pokud není). Při serializaci je člen dateTime vždy serializován v GMT. Pokud tedy popisujete čas 3:00 ráno v New Yorku, dateTime má časový údaj 8:00 a offsetMinutes je -300 (minus 300 minut nebo 5 hodin od GMT).

  Poznámka:

  DateTime a DateTimeOffset objekty, pokud jsou serializovány do FORMÁTU JSON, zachovávají pouze informace pro přesnost milisekund. Hodnoty pod milisekundu (mikro/nanosekundy) se během serializace ztratí.

Typy XML a JSON

Typy XML se stanou řetězci JSON.

• Pokud například datový člen "q" typu XElement obsahuje <abc/>, json je {"q":"<abc/>"}.

• Existují určitá speciální pravidla, která určují, jak je xml zabalený – další informace najdete v části Rozšířené informace dále v tomto článku.

• Pokud používáte ASP.NET AJAX a nechcete používat řetězce v JavaScriptu, ale chcete místo toho XML DOM, nastavte vlastnost ResponseFormat na XML při WebGetAttribute nebo nastavte vlastnost ResponseFormat na XML při WebInvokeAttribute souboru.

Kolekce, slovníky a pole

Všechny kolekce, slovníky a pole jsou reprezentovány ve formátu JSON jako pole.

• Veškeré vlastní nastavení, které používá CollectionDataContractAttribute, se v reprezentaci JSON ignoruje.

• Slovníky nejsou způsob, jak pracovat přímo s JSON. Při použití WCF nemusí být Dictionary<string,object> podporován stejným způsobem, jak by se očekávalo při práci s jinými technologiemi JSON. Pokud je například "abc" namapován na "xyz" a "def" je ve slovníku namapován na 42, reprezentace JSON není {"abc":"xyz","def":42}, ale je [{"Klíč":"abc","Value":"xyz"},{"Klíč":"def","Hodnota":42}] místo toho.

• Pokud chcete pracovat s JSON přímo (dynamický přístup ke klíčům a hodnotám bez předem definovaného kontraktu), máte několik možností:

  • Zvažte použití ukázky serializace JSON s volně typovanými daty (AJAX).

  • Zvažte použití ISerializable konstruktorů rozhraní a deserializace – tyto dva mechanismy umožňují přístup ke dvojicám klíč/hodnota JSON při serializaci a deserializaci, ale nefungují ve scénářích částečné důvěryhodnosti.

  • Místo použití serializátoru zvažte práci s mapováním mezi JSON a XML .

  • Polymorfismus v kontextu serializace odkazuje na schopnost serializovat odvozený typ, kde se očekává jeho základní typ. Při použití kolekcí polymorfně existují speciální pravidla specifická pro JSON, například při přiřazování kolekce k objektu Object. Tento problém je podrobněji popsán v části Rozšířené informace dále v tomto článku.

Další podrobnosti

Pořadí datových členů

Pořadí datových členů není při použití formátu JSON důležité. Konkrétně platí, že i když Order je nastavená, data JSON se dají deserializovat v libovolném pořadí.

Typy JSON

Typ JSON se nemusí shodovat s předchozí tabulkou při deserializaci. Například Int obvykle se mapuje na číslo JSON, ale může být také úspěšně deserializován z řetězce JSON, pokud tento řetězec obsahuje platné číslo. To znamená, že {"q":42} i {"q":"42"} jsou platné, pokud existuje Int datový člen s názvem "q".

Polymorfismus

Polymorfní serializace se skládá z schopnosti serializovat odvozený typ, kde se očekává jeho základní typ. Toto je podporováno pro serializaci JSON WCF způsobem srovnatelným s tím, jakým je podporována serializace XML. Můžete například serializovat MyDerivedType , kde MyBaseType je očekáváno, nebo serializovat Int , kde Object se očekává.

Informace o typu mohou být ztraceny při deserializaci odvozeného typu, pokud se očekává základní typ, ledaže deserializujete komplexní typ. Například, pokud je Uri serializován v místě očekávání Object, výsledkem je řetězec JSON. Pokud je tento řetězec pak deserializován zpět do Object, vrátí se .NET String . Deserializátor neví, že řetězec byl původně typu Uri. Obecně platí, že při očekávání Objectjsou všechny řetězce JSON deserializovány jako řetězce .NET a všechna pole JSON používaná k serializaci kolekcí .NET, slovníků a polí jsou deserializovány jako .NET Array typu Object, bez ohledu na to, jaký byl skutečný původní typ. Booleovská hodnota JSON se mapuje na .NET Boolean. Pokud ale očekáváte Object, čísla JSON se deserializují jako .NET Int32Decimal nebo Double, kde je nejvhodnější typ automaticky vybrán.

Při deserializaci do typu rozhraní se DataContractJsonSerializer deserializuje, jako by deklarovaný typ byl objekt.

Při práci s vlastními základními a odvozenými typy se obvykle vyžaduje použití KnownTypeAttributeServiceKnownTypeAttribute nebo ekvivalentního mechanismu. Pokud máte například operaci, která má návratovou Animal hodnotu a ve skutečnosti vrátí instanci Cat (odvozenou z Animal), měli byste buď použít KnownTypeAttribute na typ Animal nebo ServiceKnownTypeAttribute na operaci a zadat typ Cat v těchto atributech. Další informace naleznete v tématu Známé typy kontraktů dat.

Podrobnosti o tom, jak polymorfní serializace funguje, a diskuzi o některých omezeních, která je nutné dodržovat při jeho použití, najdete v části Rozšířené informace dále v tomto článku.

Verzování

Funkce správy verzí kontraktů dat, včetně IExtensibleDataObject rozhraní, jsou plně podporované ve formátu JSON. Ve většině případů je navíc možné deserializovat typ v jednom formátu (například XML) a pak ho serializovat do jiného formátu (například JSON) a zachovat data v IExtensibleDataObject. Další informace najdete v tématu Forward-Compatible datové smlouvy. Mějte na paměti, že JSON není seřazený, takže dojde ke ztrátě informací o objednávce. Json navíc nepodporuje několik párů klíč/hodnota se stejným názvem klíče. A konečně, všechny operace na IExtensibleDataObject jsou ze své podstaty polymorfní - což znamená, že jejich odvozené typy jsou přiřazeny Object, základnímu typu pro všechny typy.

JSON v adresách URL

Při použití ASP.NET koncových bodů AJAX s příkazem HTTP GET (pomocí atributu WebGetAttribute ) se příchozí parametry zobrazí v adrese URL požadavku místo textu zprávy. JSON se podporuje i v adrese URL požadavku, takže pokud máte operaci, která přebírá Int název "číslo" a Person komplexní typ s názvem "p", adresa URL se může podobat následující adrese URL.

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

Pokud k volání služby používáte ovládací prvek ASP.NET Správce skriptů AJAX a proxy server, tato adresa URL se automaticky vygeneruje proxy serverem a nezobrazí se. Json nelze použít v adresách URL na koncových bodech non-ASP.NET AJAX.

Rozšířené informace

Podpora pro ISerializable

Podporované a nepodporované typy ISerializable

Obecně platí, že typy, které implementují ISerializable rozhraní, jsou plně podporovány při serializaci nebo deserializaci JSON. Některé z těchto typů (včetně některých typů rozhraní .NET Framework) se však implementují takovým způsobem, že aspekty serializace specifické pro JSON způsobí, že se ne deserializují správně:

• Při použití ISerializable není typ jednotlivých datových členů nikdy předem znám. To vede k polymorfní situaci, která je podobná deserializaci typů na objekt. Jak už bylo zmíněno dříve, může to vést ke ztrátě informací o typu ve formátu JSON. Například typ, který serializuje enum ve své ISerializable implementaci a pokusí se deserializovat zpět do enum (bez správných přetypování), selže, protože enum je serializován pomocí čísel ve formátu JSON a čísla JSON se deserializují do předdefinovaných číselných typů .NET (Int32, Decimal nebo Double). Skutečnost, že to číslo bývalo enum hodnotou, se ztratilo.

• Typ ISerializable, který závisí na určitém pořadí deserializace ve svém konstruktoru deserializace, může také selhat v deserializaci některých dat JSON, protože většina serializátorů JSON nezaručuje žádné konkrétní pořadí.

Typy továrny

I když je rozhraní IObjectReference obecně podporováno ve formátu JSON, nejsou podporovány žádné typy, které vyžadují funkci 'typ továrny' (vrací instanci jiného typu než je typ, který implementuje rozhraní).

Formát drátu DateTime

DateTime hodnoty se zobrazují jako řetězce JSON ve formě "/Date(700000+0500)/", kde první číslo (700000 v uvedeném příkladu) je počet milisekund v časovém pásmu GMT, pravidelný (ne letní čas) od půlnoci, 1. ledna 1970. Číslo může být záporné, aby představovalo dřívější časy. Část, která se v příkladu skládá z "+0500", je nepovinná a označuje, že čas je typu Local - to znamená, že by měl být převeden na místní časové pásmo při deserializaci. Pokud chybí, čas je deserializován jako Utc. Skutečné číslo ("0500" v tomto příkladu) a jeho znaménko (+ nebo -) se ignoruje.

Při serializaci DateTime, Local a Unspecified jsou časy zapsány s posunem a Utc je zapsán bez.

Kód javascriptového klienta ASP.NET AJAX automaticky převede tyto řetězce na instance JavaScriptu DateTime . Pokud existují další řetězce, které mají podobnou formu a nejsou typu DateTime v .NET, jsou také převedeny.

Převod se provádí pouze v případě, že jsou znaky "/" escapovány (to znamená, že JSON má podobu "\/Date(700000+0500)\/") a z tohoto důvodu kodér JSON WCF (povolený znakem WebHttpBinding) vždy escapuje znak "/".

XML v řetězcích JSON

XmlElement

XmlElement je serializován tak, jak je, bez zabalení. Například datový člen x typu XmlElement , který obsahuje <abc/> , je reprezentován takto:

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

Pole uzlů XmlNode

Array objekty typu XmlNode jsou umístěny uvnitř elementu nazvaného ArrayOfXmlNode ve standardním oboru názvů kontraktu dat pro typ. Pokud "x" je pole, které obsahuje uzel atributu "N" v oboru názvů "ns", který obsahuje "value" a prázdný uzel elementu "M", reprezentace je následující.

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

Atributy v prázdném oboru názvů na začátku polí XmlNode (před jinými elementy) nejsou podporovány.

Typy IXmlSerializable včetně XElement a DataSet

ISerializable typy se rozdělí do "content types", "DataSet types" a "element types". Definice těchto typů naleznete v tématu XML a ADO.NET Typy v kontraktech dat.

Typy "Content" a "DataSet" jsou serializovány podobně jako Array objekty XmlNode diskutované v předchozí části. Jsou zabalené do elementu, jehož název a obor názvů odpovídá názvu datového kontraktu a oboru názvů daného typu.

Typy elementů, jako XElement jsou serializovány tak, jak jsou, podobně jako XmlElement dříve popsány v tomto článku.

Polymorfismus

Zachování informací o typu

Jak jsme uvedli dříve, polymorfismus je ve formátu JSON podporován s určitými omezeními. JavaScript je slabě napsaný jazyk a identita typu obvykle nepředstavuje problém. Pokud ale ke komunikaci mezi systémem silného typu (.NET) a slabě napsaným systémem (JavaScript) používáte JSON, je vhodné zachovat identitu typu. Například typy s názvy kontraktů dat "Square" a "Circle" jsou odvozeny od typu s názvem datového kontraktu "Shape". Pokud se "Circle" odešle z .NET do JavaScriptu a později se vrátí do metody .NET, která očekává "Shape", je užitečné, aby strana .NET věděla, že daný objekt byl původně "Circle" – jinak všechny informace specifické pro odvozený typ (například datový člen radius v kruhu) mohou být ztraceny.

Chcete-li zachovat identitu typu, lze při serializaci složitých typů do formátu JSON přidat "tip typu" a deserializátor rozpozná nápovědu a správně funguje. "Tip typu" je pár klíč/hodnota JSON s názvem klíče "__type" (dvě podtržítka následovaná slovem "typ"). Hodnota je řetězec JSON formuláře "DataContractName:DataContractNamespace" (cokoli až do prvního dvojtečky je název). Pomocí předchozího příkladu lze "Circle" serializovat následujícím způsobem.

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

Tip typu je velmi podobný atributu xsi:type definovanému standardem instance schématu XML a používá se při serializaci/deserializaci XML.

Datové členy s názvem "__type" jsou zakázány kvůli potenciálnímu konfliktu s indikací typu.

Zmenšení velikosti typových nápověd

Pokud chcete zmenšit velikost zpráv JSON, výchozí předpona oboru názvů kontraktu dat (http://schemas.datacontract.org/2004/07/) se nahradí znakem #. (Chcete-li tuto náhradu vrátit zpět, použije se pravidlo escapingu: pokud jmenný prostor začíná znaky "#" nebo "\", jsou doplněny dalším znakem "\"). Proto, pokud "Circle" je typ v oboru názvů .NET "MyApp.Shapes", jeho výchozí obor názvů datového kontraktu je http://schemas.datacontract.org/2004/07/MyApp. Obrazce a reprezentace JSON jsou následující.

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

Zkrácené názvy (#MyApp.Shapes) a úplné názvy (http://schemas.datacontract.org/2004/07/MyApp.Shapes) jsou srozumitelné pro deserializaci.

Pozice indikace typu v objektech JSON

Všimněte si, že v reprezentaci JSON musí být nejprve zobrazen tip typu. Toto je jediný případ, kdy je pořadí párů klíč/hodnota důležité při zpracování JSON. Následující příklad nepředstavuje platný způsob zadání nápovědy k typu.

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

DataContractJsonSerializer Obě stránky klienta WCF i ASP.NET AJAX vždy vygenerují nápovědu typu jako první.

Nápovědy k typům se vztahují pouze na komplexní typy.

Neexistuje způsob, jak generovat nápovědu k typu pro nesložité typy. Například pokud má operace návratový typ Object, ale kruh vrátí, může být vyjádření JSON takové, jak bylo znázorněno dříve, a typová informace se zachovává. Pokud je však vrácen identifikátor URI, reprezentace JSON je řetězec a skutečnost, že řetězec použitý k reprezentaci identifikátoru URI je ztracen. To platí nejen pro primitivní typy, ale také pro kolekce a pole.

Kdy jsou využity typové nápovědy

Nápovědy typu můžou výrazně zvětšit velikost zprávy (jedním ze způsobů, jak to zmírnit, je použít kratší obory názvů kontraktů dat, pokud je to možné). Proto následující pravidla určují, zda jsou zobrazeny typové indikátory:

• Při použití ASP.NET AJAX se vždy generují typové náznaky, kdykoli je to možné, i když neexistuje žádné základní/odvozené přiřazení – například i pokud je kruh přiřazen kruhu. To je nutné k úplnému umožnění procesu volání ze slabě typovaného prostředí JSON do prostředí .NET se silným typem bez neočekávané ztráty informací.

• Při použití služeb AJAX bez ASP.NET integrace se poznámky typu vygenerují pouze tehdy, když je provedeno základní/odvozené přiřazení – což znamená, že se vygenerují, když je kruh přiřazen k obrazci nebo Object, ale ne při přiřazení ke kruhu. To poskytuje minimální informace potřebné k správné implementaci javascriptového klienta, což zlepšuje výkon, ale nechrání před ztrátou informací o typu v nesprávně navržených klientech. Pokud se chcete vyhnout řešení tohoto problému v klientovi, vyhněte se úplně základním nebo odvozeným přiřazením na serveru.

• Při použití DataContractSerializer typu parametr konstruktoru alwaysEmitTypeInformation umožňuje volbu mezi dvěma předchozími režimy, přičemž výchozí hodnota je "false" (pouze emitovat typové nápovědy, když je to vyžadováno).

Duplicitní jména členů dat

Informace o odvozených typech se nacházejí ve stejném objektu JSON společně s informacemi o základním typu a mohou nastat v libovolném pořadí. Může být například Shape reprezentována následujícím způsobem.

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

Zatímco kruh může být reprezentován následujícím způsobem.

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

Pokud základní Shape typ obsahoval také datový člen s názvem "radius", vede to ke kolizi při serializaci (protože objekty JSON nemohou mít opakující se názvy klíčů) a deserializace (protože není jasné, zda "radius" odkazuje nebo Shape.radiusCircle.radius). Koncept "skrývání vlastností" (datové členy stejného názvu na základě odvozených tříd) se proto obecně nedoporučuje v třídách kontraktů dat, ale v případě JSON je ve skutečnosti zakázáno.

Polymorfismus a typy IXmlSerializable

IXmlSerializable typy mohou být mezi sebou polymorfně přiřazeny obvyklým způsobem, pokud jsou splněny známé požadavky na typy podle obvyklých pravidel kontraktů dat. Serializace IXmlSerializable typu místo výsledku Object však způsobí ztrátu informací o typu, protože výsledkem je řetězec JSON.

Polymorfismus a určité typy rozhraní

Je zakázáno serializovat typ kolekce nebo typ, který implementuje IXmlSerializable, když je očekáván jiný než kolekce typ, který není IXmlSerializable (s výjimkou Object). Například vlastní rozhraní s názvem IMyInterface a typ MyType, který implementuje IEnumerable<T> typu int a IMyInterface. Je zakázáno vrátit MyType z operace, jejíž návratový typ je IMyInterface. Je to proto, že MyType musí být serializován jako pole JSON a vyžaduje nápovědu typu, a jak bylo uvedeno dříve, nelze zahrnout nápovědu typu s poli, pouze se složitými typy.

Známé typy a konfigurace

Všechny mechanismy známého typu používané tímto DataContractSerializer typem jsou podporovány také stejným způsobem DataContractJsonSerializer. Oba serializátory čtou stejný konfigurační prvek,< dataContractSerializer> v <system.runtime.serialization>, aby zjistily známé typy přidané prostřednictvím konfiguračního souboru.

Kolekce přiřazené k objektu

Kolekce přiřazené objektu jsou serializovány jako kolekce, které implementují IEnumerable<T>: pole JSON s každou položkou, která má nápovědu typu, pokud se jedná o komplexní typ. Například List<T> typu Shape přiřazený Object vypadá takto.

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

Při zpětné deserializaci do Object:

• Shape musí být v seznamu Známých typů. Jakékoli zařazení List<T> typu Shape ve známých typech nemá žádný vliv. Všimněte si, že v tomto případě není nutné přidávat Shape známé typy serializace - to se provádí automaticky.

• Kolekce je deserializována jako Array typ Object , který obsahuje Shape instance.

Odvozené kolekce přiřazené k základním kolekcím

Když je odvozená kolekce přiřazena k základní kolekci, kolekce je obvykle serializována, jako by se jednalo o kolekci základního typu. Pokud však typ položky odvozené kolekce nelze přiřadit k typu položky základní kolekce, vyvolá se výjimka.

Typové indikace a slovníky

Když je slovník přiřazen k objektu Object, každá položka Klíč a Hodnota ve slovníku je zpracovávána, jako by byla přiřazena k Object a získá nápovědu k typu.

Při serializaci typů slovníku není objekt JSON obsahující členy Key a Value ovlivněn alwaysEmitTypeInformation nastavením a obsahuje pouze nápovědu typu, pokud je vyžadují předchozí pravidla kolekce.

Platné názvy klíčů JSON

Serializátor XML kóduje názvy klíčů, které nejsou platné názvy XML. Například datový člen s názvem "123" by měl kódovaný název, například "_x0031__x0032__x0033_", protože "123" je neplatný název elementu XML (začíná číslicí). Podobná situace může nastat s některými mezinárodními znakovými sadami, které nejsou platné v názvech XML. Vysvětlení tohoto efektu XML na zpracování JSON najdete v tématu Mapování mezi JSON a XML.

Viz také

• Podpora formátu JSON a dalších formátů přenosu dat