Sdílet prostřednictvím

Samostatná serializace JSON pomocí DataContractJsonSerializer

  • Článek

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, které jsou podporovány 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í a DataContractAttributeDataMemberAttribute.

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 Notes
Všechny číselné typy, například Int32, Decimal nebo Double Počet Speciální hodnoty, jako Double.NaNje například , Double.PositiveInfinity a Double.NegativeInfinity nejsou podporovány a mají za následek neplatný json.
Enum Počet Viz "Výčty a JSON" dále v tomto článku.
Boolean Logická hodnota
String, Char String
TimeSpan, , GuidUri String Formát těchto typů ve formátu JSON je stejný jako ve formátu XML (v podstatě časový rozsah ve formátu ISO 8601 Duration, GUID ve formátu "12345678-ABCD-ABCD-ABCD-1234567890AB" a identifikátor URI ve formě přirozeného řetězce, jako "http://www.example.com"je ). Přesné informace naleznete v tématu Referenční informace ke schématu kontraktu dat.
XmlQualifiedName String 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ů, můžete také vynechat dvojtečku.
Array typu Byte Matice čí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).		 String Viz část Typy XML a JSON tohoto článku.
DBNull Prázdný komplexní typ --
Kolekce, slovníky a pole Pole Podívejte se na oddíly Kolekce, Slovníky a Pole v tomto tématu.
Komplexní typy (s DataContractAttribute použitím nebo SerializableAttribute použitím) Komplexní typ Datové členy se stanou členy komplexního typu JavaScriptu.
Komplexní typy implementuje 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 Null Podporují se také typy hodnot s možnou hodnotou Null a mapují se na JSON stejným způsobem jako typy hodnot 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é. Atributy EnumMemberAttribute se NonSerializedAttribute při použití ignorují.

  • 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říznaky enum nejsou zvláštní a jsou považovány za stejné jako s jinými enum.

Data a č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 místní časový posun od času Greenwich Mean Time (GMT), který se nyní označuje také jako koordinovaný univerzální čas (UTC) přidružený k umístění události zájmu. Člen dateTime představuje instanci v čase, kdy došlo k události zájmu (opět se stane DateTime v JavaScriptu, když se používá ASP.NET AJAX, a řetězec, pokud není). Při serializaci dateTime je člen vždy serializován v GMT. Pokud tedy popisujete čas 3:00 v New Yorku, dateTime má časovou složku 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. Během serializace dojde ke ztrátě hodnot v milisekundách (mikro/nanosekund).

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 nastavit XML DOM vlastnost ResponseFormat XML na WebGetAttribute xml nebo ResponseFormat vlastnost xml v WebInvokeAttributesouboru .

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. Řetězec slovníku<, objekt> nemusí být podporován stejným způsobem jako WCF podle očekávání od práce 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 (Weakly typed JSON).

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

Additional Details

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. To je podporováno pro serializaci JSON wcf srovnatelné se způsobem, jakým je podporováno 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, pokud deserializujete komplexní typ. Pokud Uri je například serializován, kde Object se očekává, 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. Logická 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í, deserializuje, DataContractJsonSerializer 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 (odvozené z Animal), měli byste buď použít KnownTypeAttribute, na Animal typ nebo ServiceKnownTypeAttribute na operaci a zadat Cat typ 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.

Vytváření verzí

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 Kontrakty dat kompatibilní s předáváním. 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 jsou IExtensibleDataObject ze své podstaty polymorfní - to je jejich odvozený typ jsou přiřazeny Object, základní typ 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 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ě:

  • S ISerializabletypem jednotlivých datových členů není nikdy předem známo. To vede k polymorfní situaci podobné deserializaci typů do objektu. 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 zpět do enum (bez správných přetypování) selže, protože enum je serializován pomocí čísel JSON a JSON deserializovat do předdefinovaných čísel .NET (Int32, Decimal nebo Double). Takže skutečnost, že číslo použité jako enum hodnota je ztraceno.

  • Typ ISerializable , který závisí na určitém pořadí deserializace v jeho deserializační konstruktor může také selhat deserializovat některé data JSON, protože většina serializátorů JSON nezaručuje žádné konkrétní pořadí.

Typy továrny

I když je IObjectReference rozhraní obecně podporováno ve formátu JSON, nepodporují se všechny typy, které vyžadují funkci typu továrny (vrací instanci jiného typu než GetRealObject(StreamingContext) 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 druh Local - to znamená, že by se měl převést 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 DateTimea LocalUnspecified časy jsou zapsány s posunem a Utc je zapsána 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í podobný formulář, který není typu DateTime v .NET, jsou také převedeny.

Převod se provádí pouze v případě, že jsou znaky "/" uchvácené (to znamená, že JSON vypadá jako \/Date(70000+0500)\/) a z tohoto důvodu kodér JSON WCF (povolený znakem WebHttpBinding) vždy unikne znaku /.

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

Array objekty typu XmlNode jsou zabaleny v elementu s názvem 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.

IXmlSerializable Types including XElement and DataSet

ISerializable typy se rozdělí do "content types", "DataSet types" a "element types". Definice těchto typů najdete 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 nápovědou typu.

Zmenšení velikosti nápovědy typu

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 obor názvů začíná znaky "#" nebo "\", připojí se navíc 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 nápovědy 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. Pokud má například operace návratový Object typ, ale vrací kruh, může být znázornění JSON, jak je znázorněno dříve, a informace o typu se zachovají. 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 se vygenerují rady typu

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í, jestli se vygenerují rady typu:

  • Při použití ASP.NET AJAX se vždy vygenerují rady typu, kdykoli je to možné, i když neexistuje žádné základní/odvozené přiřazení – například i v případě, že je kruh přiřazen kruhu. (To je nutné k úplnému povolení procesu volání ze slabě napsaného prostředí JSON do prostředí .NET se silným typem bez překvapení ztráty informací.)

  • Při použití služeb AJAX bez ASP.NET integrace se nápovědy typu vygenerují pouze v případě, že je k dispozici základní/odvozené přiřazení – to znamená, že je vygenerováno při přiřazení kruhu k obrazci nebo Object ne při přiřazení k 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 alwaysEmitTypeInformation umožňuje parametr konstruktoru zvolit mezi předchozími dvěma režimy, přičemž výchozí hodnota je "false" (v případě potřeby vygenerujte pouze rady typu).

Duplicitní názvy č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 , kde není typ kolekce, který není IXmlSerializable (s výjimkou Object) očekávaný. Například vlastní rozhraní volal IMyInterface a typ MyType , který implementuje oba IEnumerable<T> typy int i 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 je uvedeno dříve, než nebude možné zahrnout nápovědu k 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. List<T> Například typ 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 deserializaci zpět do Object:

  • Shape musí být v seznamu Známých typů. Shape Typ List<T> 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.

Nápověda k typům a slovníky

Když je slovník přiřazen k objektu Object, každá položka klíč a hodnota ve slovníku se považuje za přiřazenou a získá nápovědu k Object 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é