Partilhar via

Serialização JSON autônoma usando DataContractJsonSerializer

  • Artigo

Nota

Este artigo é sobre DataContractJsonSerializer. Para a maioria dos cenários que envolvem serialização e desserialização de JSON, recomendamos as APIs no namespace System.Text.Json.

JSON (JavaScript Object Notation) é um formato de dados que é projetado especificamente para ser usado por código JavaScript executado em páginas da Web dentro do navegador. É o formato de dados padrão usado por ASP.NET serviços AJAX criados no Windows Communication Foundation (WCF).

Esse formato também pode ser usado ao criar serviços AJAX sem integração com ASP.NET - neste caso, XML é o padrão, mas JSON pode ser escolhido.

Finalmente, se você precisar de suporte a JSON, mas não estiver criando um serviço AJAX, o DataContractJsonSerializer tornará possível serializar diretamente objetos .NET em dados JSON e desserializar esses dados de volta em instâncias de tipos .NET. Para obter uma descrição de como fazer isso, consulte Como serializar e desserializar dados JSON.

Ao trabalhar com JSON, os mesmos tipos .NET são suportados, com algumas exceções, como são suportados DataContractSerializerpelo . Para obter uma lista dos tipos suportados, consulte Tipos suportados pelo Data Contract Serializer. Isso inclui a maioria dos tipos primitivos, a maioria dos tipos de matriz e coleção, bem como tipos complexos que usam o DataContractAttribute e DataMemberAttribute.

Mapear tipos .NET para tipos JSON

A tabela a seguir mostra a correspondência entre tipos .NET e tipos JSON/JavaScript quando mapeados por procedimentos de serialização e desserialização.

Tipos .NET JSON/JavaScript Notas
Todos os tipos numéricos, por exemplo Int32, Decimal ou Double Número Valores especiais como Double.NaN, Double.PositiveInfinity e Double.NegativeInfinity não são suportados e resultam em JSON inválido.
Enum Número Consulte "Enumerações e JSON" mais adiante neste artigo.
Boolean Boolean
String, Char String
TimeSpan, Guid, Uri String O formato desses tipos em JSON é o mesmo que em XML (essencialmente, período de tempo no formato de duração ISO 8601, GUID no formato "12345678-ABCD-ABCD-ABCD-ABCD-1234567890AB" e URI em sua forma de cadeia de caracteres natural como "http://www.example.com"). Para obter informações precisas, consulte Referência de esquema de contrato de dados.
XmlQualifiedName String O formato é "name:namespace" (qualquer coisa antes dos dois pontos é o nome). O nome ou o namespace podem estar faltando. Se não houver namespace, os dois pontos também podem ser omitidos.
Array do tipo Byte Matriz de números Cada número representa o valor de um byte.
DateTime DateTime ou String Consulte Datas/Horas e JSON mais adiante neste artigo.
DateTimeOffset Tipo complexo Consulte Datas/Horas e JSON mais adiante neste artigo.
Tipos XML e ADO.NET (XmlElement,

XElement. Matrizes de XmlNode,

ISerializable,

DataSet).		 String Consulte a seção Tipos XML e JSON deste artigo.
DBNull Tipo complexo vazio --
Coleções, dicionários e matrizes Matriz Consulte a seção Coleções, dicionários e matrizes deste tópico.
Tipos complexos (com o DataContractAttribute ou SerializableAttribute aplicado) Tipo complexo Os membros de dados tornam-se membros do tipo complexo JavaScript.
Tipos complexos implementando a ISerializable interface) Tipo complexo O mesmo que outros tipos complexos, mas alguns ISerializable tipos não são suportados – consulte Suporte ISerializable.
Null valor para qualquer tipo Nulo Tipos de valor anuláveis também são suportados e mapeados para JSON da mesma forma que tipos de valor não anuláveis.

Enumerações e JSON

Os valores de membros de enumeração são tratados como números em JSON, o que é diferente de como eles são tratados em contratos de dados, onde são incluídos como nomes de membros. Para obter mais informações sobre o tratamento de contrato de dados, consulte Tipos de enumeração em contratos de dados.

  • Por exemplo, se você tiver public enum Color {red, green, blue, yellow, pink}, a serialização yellow produzirá o número 3 e não a cadeia de caracteres "amarelo".

  • Todos os enum membros são serializáveis. Os EnumMemberAttribute e os NonSerializedAttribute atributos são ignorados se usados.

  • É possível desserializar um valor inexistente enum - por exemplo, o valor 87 pode ser desserializado no enum Color anterior, mesmo que não haja um nome de cor correspondente definido.

  • Uma bandeira enum não é especial e é tratada da mesma forma que qualquer outra enum.

Datas/horas e JSON

O formato JSON não suporta diretamente datas e horas. No entanto, eles são muito comumente usados e ASP.NET AJAX fornece suporte especial para esses tipos. Ao usar ASP.NET proxies AJAX, o DateTime tipo no .NET corresponde totalmente ao DateTime tipo em JavaScript.

  • Quando não estiver usando ASP.NET, um DateTime tipo é representado em JSON como uma cadeia de caracteres com um formato especial descrito na seção Informações avançadas deste tópico.

  • DateTimeOffset é representado em JSON como um tipo complexo: {"DateTime":d ateTime,"OffsetMinutes":offsetMinutes}. O offsetMinutes membro é o deslocamento da hora local do Tempo Médio de Greenwich (GMT), também conhecido agora como Tempo Universal Coordenado (UTC), associado ao local do evento de interesse. O dateTime membro representa a instância no tempo em que o evento de interesse ocorreu (novamente, ele se torna um DateTime em JavaScript quando ASP.NET AJAX está em uso e uma cadeia de caracteres quando não está). Na serialização, o membro é sempre serializado dateTime no GMT. Assim, se descrever 3:00 AM horário de Nova York, dateTime tem um componente de tempo de 8:00 AM e offsetMinutes são 300 (menos 300 minutos ou 5 horas a partir de GMT).

    Nota

    DateTime e DateTimeOffset os objetos, quando serializados para JSON, apenas preservam informações com precisão de milissegundos. Valores de submilissegundos (micro/nanossegundos) são perdidos durante a serialização.

Tipos XML e JSON

Os tipos XML tornam-se cadeias de caracteres JSON.

  • Por exemplo, se um membro de dados "q" do tipo XElement contiver <abc/>, o JSON será {"q":"<abc/>"}.

  • Há algumas regras especiais que especificam como o XML é encapsulado - para obter mais informações, consulte a seção Informações avançadas mais adiante neste artigo.

  • Se você estiver usando ASP.NET AJAX e não quiser usar cadeias de caracteres no JavaScript, mas quiser o DOM XML, defina a ResponseFormat propriedade como XML em WebGetAttribute ou a ResponseFormat propriedade como XML no WebInvokeAttribute.

Coleções, dicionários e matrizes

Todas as coleções, dicionários e matrizes são representados em JSON como matrizes.

  • Qualquer personalização que use o CollectionDataContractAttribute é ignorada na representação JSON.

  • Os dicionários não são uma forma de trabalhar diretamente com JSON. A cadeia de dicionário,objeto<> pode não ser suportada da mesma forma no WCF como esperado do trabalho com outras tecnologias JSON. Por exemplo, se "abc" é mapeado para "xyz" e "def" é mapeado para 42 em um dicionário, a representação JSON não é {"abc":"xyz","def":42} mas é [{"Key":"abc","Value":"xyz"},{"Key":"def","Value":42}] em vez disso.

  • Se você gostaria de trabalhar com JSON diretamente (acessando chaves e valores dinamicamente, sem pré-definir um contrato rígido), você tem várias opções:

    • Considere o uso do exemplo de serialização JSON de tipo fraco (AJAX).

    • Considere o uso dos ISerializable construtores de interface e desserialização - esses dois mecanismos permitem que você acesse pares de chave/valor JSON na serialização e desserialização, respectivamente, mas não funcionam em cenários de confiança parcial.

    • Considere trabalhar com o mapeamento entre JSON e XML em vez de usar um serializador.

    • Polimorfismo no contexto da serialização refere-se à capacidade de serializar um tipo derivado onde seu tipo base é esperado. Há regras especiais específicas de JSON ao usar coleções polimorficamente, quando, por exemplo, atribuir uma coleção a um Objectarquivo . Esse problema é discutido mais detalhadamente na seção Informações avançadas mais adiante neste artigo.

Detalhes Adicionais

Ordem dos Membros de Dados

A ordem dos membros de dados não é importante ao usar JSON. Especificamente, mesmo que Order esteja definido, os dados JSON ainda podem ser desserializados em qualquer ordem.

Tipos JSON

O tipo JSON não precisa corresponder à tabela anterior na desserialização. Por exemplo, um Int normalmente mapeia para um número JSON, mas também pode ser desserializado com êxito de uma cadeia de caracteres JSON, desde que essa cadeia contenha um número válido. Ou seja, tanto {"q":42} quanto {"q":"42"} são válidos se houver um Int membro de dados chamado "q".

Polimorfismo

A serialização polimórfica consiste na capacidade de serializar um tipo derivado onde seu tipo base é esperado. Isso é suportado para serialização JSON pelo WCF comparável à maneira como a serialização XML é suportada. Por exemplo, você pode serializar MyDerivedType onde MyBaseType é esperado ou serializar Int onde Object é esperado.

As informações de tipo podem ser perdidas ao desserializar um tipo derivado se o tipo base for esperado, a menos que você esteja desserializando um tipo complexo. Por exemplo, se Uri for serializado onde Object é esperado, isso resultará em uma cadeia de caracteres JSON. Se essa cadeia de caracteres for desserializada novamente no Object, um .NET String será retornado. O desserializador não sabe que a cadeia de caracteres foi inicialmente do tipo Uri. Geralmente, ao esperar Object, todas as cadeias de caracteres JSON são desserializadas como cadeias de caracteres .NET, e todas as matrizes JSON usadas para serializar coleções, dicionários e matrizes .NET são desserializadas como .NET Array do tipo Object, independentemente de qual tenha sido o tipo original real. Um booleano JSON mapeia para um .NET Boolean. No entanto, ao esperar um Object, os números JSON são desserializados como .NET Int32ou DecimalDouble, onde o tipo mais apropriado é selecionado automaticamente.

Ao desserializar em um tipo de interface, o DataContractJsonSerializer desserializa como se o tipo declarado fosse objeto.

Ao trabalhar com sua própria base e tipos derivados, normalmente é necessário usar o KnownTypeAttribute, ServiceKnownTypeAttribute ou um mecanismo equivalente. Por exemplo, se você tiver uma operação que tem um Animal valor de retorno e ela realmente retorna uma instância de (derivada Cat de Animal), você deve aplicar o KnownTypeAttribute, ao Animal tipo ou ao ServiceKnownTypeAttribute à operação e especificar o Cat tipo nesses atributos. Para obter mais informações, consulte Tipos conhecidos de contrato de dados.

Para obter detalhes de como a serialização polimórfica funciona e uma discussão sobre algumas das limitações que devem ser respeitadas ao usá-la, consulte a seção Informações avançadas mais adiante neste artigo.

Controlo de Versão

Os recursos de controle de versão do contrato de dados, incluindo a interface, são totalmente suportados IExtensibleDataObject no JSON. Além disso, na maioria dos casos, é possível desserializar um tipo em um formato (por exemplo, XML) e, em seguida, serializá-lo em outro formato (por exemplo, JSON) e ainda preservar os dados no IExtensibleDataObject. Para obter mais informações, consulte Contratos de dados compatíveis com encaminhamento. Lembre-se de que o JSON não é ordenado, portanto, qualquer informação do pedido é perdida. Além disso, o JSON não suporta vários pares chave/valor com o mesmo nome de chave. Finalmente, todas as operações em IExtensibleDataObject são inerentemente polimórficas - ou seja, seu tipo derivado são atribuídos a Object, o tipo base para todos os tipos.

JSON em URLs

Ao usar ASP.NET pontos de extremidade AJAX com o verbo HTTP GET (usando o atributo), os WebGetAttribute parâmetros de entrada aparecem na URL da solicitação em vez do corpo da mensagem. JSON é suportado mesmo na URL de solicitação, portanto, se você tiver uma operação que usa um Int chamado "número" e um Person tipo complexo chamado "p", a URL pode se assemelhar à seguinte URL.

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

Se você estiver usando um ASP.NET controle AJAX Script Manager e proxy para chamar o serviço, essa URL é gerada automaticamente pelo proxy e não é vista. JSON não pode ser usado em URLs em non-ASP.NET pontos de extremidade AJAX.

Informações avançadas

Suporte ISerializable

Tipos ISerializable suportados e não suportados

Em geral, os tipos que implementam a ISerializable interface são totalmente suportados ao serializar/desserializar JSON. No entanto, alguns desses tipos (incluindo alguns tipos do .NET Framework) são implementados de tal forma que os aspetos de serialização específicos do JSON fazem com que eles não desserializem corretamente:

  • Com ISerializableo , o tipo de dados individuais dos membros nunca é conhecido antecipadamente. Isso leva a uma situação polimórfica semelhante à desserialização de tipos em um objeto. Como mencionado anteriormente, isso pode levar à perda de informações de tipo em JSON. Por exemplo, um tipo que serializa um enum em sua ISerializable implementação e tenta desserializar de volta diretamente em um enum (sem casts adequados) falha, porque um enum é serializado usando números em JSON e números JSON desserializar em tipos numéricos .NET internos (Int32, Decimal ou Double). Assim, o fato de que o número costumava ser um enum valor é perdido.

  • Um ISerializable tipo que depende de uma ordem específica de desserialização em seu construtor de desserialização também pode falhar ao desserializar alguns dados JSON, porque a maioria dos serializadores JSON não garante nenhuma ordem específica.

Tipos de fábrica

Embora a IObjectReference interface seja suportada em JSON em geral, quaisquer tipos que exijam o recurso "tipo de fábrica" (retornando uma instância de um tipo diferente do GetRealObject(StreamingContext) tipo que implementa a interface) não são suportados.

Formato de fio DateTime

DateTime os valores aparecem como cadeias JSON na forma de "/Date(700000+0500)/", onde o primeiro número (700000 no exemplo fornecido) é o número de milissegundos no fuso horário GMT, hora regular (não diurna) desde a meia-noite, 1º de janeiro de 1970. O número pode ser negativo para representar tempos anteriores. A parte que consiste em "+0500" no exemplo é opcional e indica que a hora é do Local tipo - ou seja, deve ser convertida para o fuso horário local na desserialização. Se estiver ausente, o tempo é desserializado como Utc. O número real ("0500" neste exemplo) e seu sinal (+ ou -) são ignorados.

Ao serializar DateTime, Local e Unspecified os tempos são escritos com um deslocamento, e Utc é escrito sem.

O código JavaScript do cliente AJAX ASP.NET converte automaticamente essas cadeias de caracteres em instâncias JavaScript DateTime . Se houver outras cadeias de caracteres que têm um formulário semelhante que não são do tipo DateTime no .NET, elas também são convertidas.

A conversão só ocorre se os caracteres "/" forem escapados (ou seja, o JSON se parece com "\/Date(700000+0500)\/"), e por esse motivo o codificador JSON do WCF (habilitado WebHttpBindingpelo ) sempre escapa do caractere "/".

XML em cadeias de caracteres JSON

XmlElement

XmlElement é serializado como está, sem embrulho. Por exemplo, o membro de dados "x" do tipo XmlElement que contém <abc/> é representado da seguinte forma:

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

Matrizes de XmlNode

Array objetos do tipo XmlNode são encapsulados em um elemento chamado ArrayOfXmlNode no namespace de contrato de dados padrão para o tipo. Se "x" é uma matriz que contém o nó de atributo "N" no namespace "ns" que contém "value" e um nó de elemento vazio "M", a representação é a seguinte.

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

Atributos no namespace vazio no início de matrizes XmlNode (antes de outros elementos) não são suportados.

Tipos IXmlSerializable, incluindo XElement e DataSet

ISerializable os tipos subdividem-se em "tipos de conteúdo", "tipos de DataSet" e "tipos de elementos". Para obter definições desses tipos, consulte Tipos XML e ADO.NET em contratos de dados.

Os tipos "Content" e "DataSet" são serializados de forma semelhante aos Array objetos discutidos XmlNode na seção anterior. Eles são encapsulados em um elemento cujo nome e namespace corresponde ao nome do contrato de dados e namespace do tipo em questão.

Tipos de "elemento" como XElement são serializados como estão, semelhante ao discutido XmlElement anteriormente neste artigo.

Polimorfismo

Preservando informações de tipo

Como dito anteriormente, o polimorfismo é suportado em JSON com algumas limitações. JavaScript é uma linguagem de tipo fraco e a identidade de tipo normalmente não é um problema. No entanto, ao usar JSON para se comunicar entre um sistema fortemente tipado (.NET) e um sistema de tipagem fraca (JavaScript), é útil preservar a identidade do tipo. Por exemplo, tipos com nomes de contrato de dados "Quadrado" e "Círculo" derivam de um tipo com um nome de contrato de dados de "Forma". Se "Circle" for enviado do .NET para JavaScript e mais tarde for retornado para um método .NET que espera "Shape", é útil para o lado .NET saber que o objeto em questão era originalmente um "Circle" - caso contrário, qualquer informação específica para o tipo derivado (por exemplo, membro de dados "radius" em "Circle") pode ser perdida.

Para preservar a identidade do tipo, ao serializar tipos complexos para JSON, uma "dica de tipo" pode ser adicionada, e o desserializador reconhece a dica e age adequadamente. A "dica de tipo" é um par chave/valor JSON com o nome da chave "__type" (dois sublinhados seguidos pela palavra "tipo"). O valor é uma cadeia de caracteres JSON do formulário "DataContractName:DataContractNamespace" (qualquer coisa até os dois pontos é o nome). Usando o exemplo anterior, "Circle" pode ser serializado da seguinte maneira.

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

A dica de tipo é muito semelhante ao xsi:type atributo definido pelo padrão de instância do esquema XML e usado ao serializar/desserializar XML.

Os membros de dados chamados "__type" são proibidos devido a um potencial conflito com a dica de tipo.

Reduzindo o tamanho das dicas de tipo

Para reduzir o tamanho das mensagens JSON, o prefixo de namespace do contrato de dados padrão (http://schemas.datacontract.org/2004/07/) é substituído pelo caractere "#". (Para tornar essa substituição reversível, uma regra de escape é usada: se o namespace começar com os caracteres "#" ou "\", eles serão acrescentados com um caractere "\" extra). Assim, se "Circle" for um tipo no namespace .NET "MyApp.Shapes", seu namespace de contrato de dados padrão será http://schemas.datacontract.org/2004/07/MyApp. As formas e a representação JSON são as seguintes.

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

Os nomes truncados (#MyApp.Shapes) e completos (http://schemas.datacontract.org/2004/07/MyApp.Shapes) são compreendidos na desserialização.

Posição da dica de tipo em objetos JSON

Observe que a dica de tipo deve aparecer primeiro na representação JSON. Este é o único caso em que a ordem dos pares chave/valor é importante no processamento JSON. Por exemplo, o seguinte não é uma maneira válida de especificar a dica de tipo.

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

DataContractJsonSerializer As páginas de cliente usadas pelo WCF e ASP.NET AJAX sempre emitem a dica de tipo primeiro.

Dicas de tipo aplicam-se apenas a tipos complexos

Não há como emitir uma dica de tipo para tipos não complexos. Por exemplo, se uma operação tiver um Object tipo de retorno, mas retornar um Circle, a representação JSON poderá ser como mostrado anteriormente e as informações de tipo serão preservadas. No entanto, se Uri for retornado, a representação JSON será uma cadeia de caracteres e o fato de que a cadeia de caracteres usada para representar um Uri será perdida. Isso se aplica não apenas a tipos primitivos, mas também a coleções e matrizes.

Quando são emitidas dicas de tipo

As dicas de tipo podem aumentar significativamente o tamanho da mensagem (uma maneira de atenuar isso é usar namespaces de contrato de dados mais curtos, se possível). Portanto, as seguintes regras regem se as dicas de tipo são emitidas:

  • Ao usar ASP.NET AJAX, as dicas de tipo são sempre emitidas sempre que possível, mesmo que não haja nenhuma atribuição base/derivada - por exemplo, mesmo que um Círculo seja atribuído a um Círculo. (Isso é necessário para habilitar totalmente o processo de chamada do ambiente JSON de tipo fraco para o ambiente .NET fortemente tipado sem perda surpreendente de informações.)

  • Ao usar serviços AJAX sem integração ASP.NET, as dicas de tipo só são emitidas quando há uma atribuição base/derivada - ou seja, emitidas quando Circle é atribuído a Shape ou Object mas não quando atribuído a Circle. Isso fornece as informações mínimas necessárias para implementar corretamente um cliente JavaScript, melhorando assim o desempenho, mas não protege contra a perda de informações de tipo em clientes projetados incorretamente. Evite completamente as atribuições base/derivadas no servidor se quiser evitar lidar com esse problema no cliente.

  • Ao usar o DataContractSerializer tipo, o alwaysEmitTypeInformation parâmetro do construtor permite que você escolha entre os dois modos anteriores, com o padrão sendo "false" (apenas emitir dicas de tipo quando necessário).

Nomes de membros de dados duplicados

As informações de tipo derivadas estão presentes no mesmo objeto JSON juntamente com as informações de tipo base e podem ocorrer em qualquer ordem. Por exemplo, Shape pode ser representado da seguinte forma.

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

Já o círculo pode ser representado da seguinte forma.

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

Se o tipo base Shape também contivesse um membro de dados chamado "radius", isso levaria a uma colisão tanto na serialização (porque os objetos JSON não podem ter nomes de chave repetidos) quanto na desserialização (porque não está claro se "radius" se refere a Shape.radius ou Circle.radius). Portanto, embora o conceito de "ocultação de propriedade" (membros de dados com o mesmo nome em classes baseadas e derivadas) geralmente não seja recomendado em classes de contrato de dados, na verdade é proibido no caso de JSON.

Polimorfismo e tipos IXmlSerializable

IXmlSerializable os tipos podem ser atribuídos polimorficamente uns aos outros, como de costume, desde que os requisitos de Tipos Conhecidos sejam atendidos, de acordo com as regras usuais do contrato de dados. No entanto, serializar um IXmlSerializable tipo no lugar de Object resulta em perda de informações de tipo como resultado é uma cadeia de caracteres JSON.

Polimorfismo e certos tipos de interface

É proibido serializar um tipo de coleção ou um tipo que implementa IXmlSerializable onde um tipo que não é de coleção que não IXmlSerializable é (exceto para Object) é esperado. Por exemplo, uma interface personalizada chamada IMyInterface e um tipo MyType que implementam ambos IEnumerable<T> do tipo int e IMyInterface. É proibido regressar MyType de uma operação cujo tipo de devolução seja IMyInterface. Isso ocorre porque MyType deve ser serializado como uma matriz JSON e requer uma dica de tipo, e como dito anteriormente, você não pode incluir uma dica de tipo com matrizes, apenas com tipos complexos.

Tipos conhecidos e configuração

Todos os mecanismos de Tipo Conhecido usados pelo DataContractSerializer também são suportados da mesma forma pelo DataContractJsonSerializer. Ambos os serializadores leem o mesmo elemento de configuração, dataContractSerializer> em <system.runtime.serialization>, para descobrir tipos conhecidos adicionados por meio de um arquivo de configuração.<

Coleções atribuídas ao objeto

As coleções atribuídas a Object são serializadas como se fossem coleções que implementam IEnumerable<T>: uma matriz JSON com cada entrada que tem uma dica de tipo se for um tipo complexo. Por exemplo, um List<T> do tipo Shape atribuído a se Object parece com o seguinte.

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

Quando desserializado novamente em Object:

  • Shape deve estar na lista Tipos conhecidos. Ter List<T> do tipo Shape em tipos conhecidos não tem efeito. Observe que você não precisa adicionar Shape a tipos conhecidos na serialização neste caso - isso é feito automaticamente.

  • A coleção é desserializada como um Array tipo que Object contém Shape instâncias.

Coleções derivadas atribuídas a coleções base

Quando uma coleção derivada é atribuída a uma coleção base, a coleção geralmente é serializada como se fosse uma coleção do tipo base. No entanto, se o tipo de item da coleção derivada não puder ser atribuído ao tipo de item da coleção base, uma exceção será lançada.

Tipo de Dicas e Dicionários

Quando um dicionário é atribuído a um Object, cada entrada de Chave e Valor no dicionário é tratada como se tivesse sido atribuída a Object e recebe uma dica de tipo.

Ao serializar tipos de dicionário, o objeto JSON que contém os membros "Key" e "Value" não é afetado pela configuração e só contém uma dica alwaysEmitTypeInformation de tipo quando as regras de coleção anteriores o exigem.

Nomes de chave JSON válidos

O serializador XML codifica nomes de chave que não são nomes XML válidos. Por exemplo, um membro de dados com o nome de "123" teria um nome codificado como "_x0031__x0032__x0033_" porque "123" é um nome de elemento XML inválido (começa com um dígito). Uma situação semelhante pode surgir com alguns conjuntos de caracteres internacionais não válidos em nomes XML. Para obter uma explicação desse efeito do XML no processamento JSON, consulte Mapeando entre JSON e XML.

Consulte também