Quatro modelos de dados comparados: por que JSON, YAML, TOML e XML nunca mapeiam 1:1

A configuração que não seria de ida e volta — um arquivo convertido em três formatos e os campos que retornaram diferentes

Um objeto comum contendo números seguros, strings, booleanos, matrizes e objetos aninhados pode sobreviver aos testes JSON-to-YAML-to-JSON e JSON-to-TOML-to-JSON. Adicione um nulo antes de TOML, uma data e hora de TOML, conteúdo misto de XML ou um comentário de YAML e algumas alterações de valor ou informações de origem.

A questão útil não é se a conversão tem perdas universais. É qual classe de entrada e qual direção preservam as propriedades que você precisa. Os avisos e recusas de ToolAcre tornam essa matriz observável, em vez de reduzir cada par a uma promessa de marketing.

Uma configuração representativa pode percorrer alguns pares, mas não todas as formas suportadas

JSON fornece nulos, booleanos, números, strings, arrays e objetos neste analisador. Não possui comentários, tipo de data e hora ou sintaxe de referência compartilhada. JavaScript analisa números à medida que IEEE-754 duplica, portanto, um número inteiro já sem aspas além do intervalo seguro pode perder precisão antes que outro escritor o veja.

As chaves dos objetos são strings e a classificação opcional altera sua apresentação. As matrizes permanecem ordenadas. A análise rigorosa rejeita comentários, vírgulas finais e tokens numéricos não finitos, estabelecendo uma linha de base compacta para os outros leitores.

Modelo de valor de JSON conforme usado por esta implementação de JavaScript

ToolAcre aceita YAML por meio de esquemas restritos JSON ou Core. Âncoras e aliases são resolvidos, comentários desaparecem, fluxos tornam-se arrays, chaves duplicadas mantêm o último valor com um aviso e aliases recursivos ou explosivos são recusados.

Tags personalizadas, binários, carimbo de data/hora, conjuntos e construtores de objetos de linguagem são rejeitados. Core Infinity e NaN tornam-se nulos em formatos de destino com avisos. Este é intencionalmente um subconjunto do sistema de tags mais amplo de YAML, e não uma reivindicação de suporte completo ao objeto YAML.

O modelo YAML restrito ToolAcre aceita

TOML começa com uma tabela e suporta strings, inteiros assinados, floats, booleanos, arrays, tabelas e quatro tipos temporais. Não tem nulo. ToolAcre converte datas e horas em strings orientadas à fonte e inteiros largos em strings decimais em vez de perder dígitos.

Ao escrever TOML, as chaves de objeto nulas são omitidas e as entradas nulas do array tornam-se strings vazias. Matrizes raiz e escalares são recusados. Comentários e a escolha do autor entre cabeçalhos, chaves pontilhadas e tabelas embutidas não retornam através de um valor simples.

Tabela raiz de TOML, valores temporais e limite nulo

XML é projetado como uma árvore com atributos `@`, chaves filhas comuns, `#text`, `#cdata`, matrizes de irmãos repetidos e prefixos de namespace literais. Comentários, declarações e instruções de processamento são descartados. A posição do texto misto é perdida e um contra muitos não pode ser conhecido antes que as repetições apareçam.

Os valores são lidos como strings, a menos que a inferência seja selecionada. Nulo escrito a partir de JSON torna-se um elemento vazio e não pode ser distinguido da string vazia no retorno. Cada DOCTYPE é recusado e nomes inválidos interrompem a serialização em vez de serem reescritos.

Projeção XML de ToolAcre: elementos, atributos, texto e prefixos literais

Navio em nove direções: JSON para YAML, XML, TOML e CSV; YAML a JSON e TOML; TOML a JSON e YAML; XML a JSON. Valores comuns em formato de JSON têm melhor desempenho entre JSON e YAML. TOML introduz data e limites nulos. XML requer convenções de nomenclatura e categoria de nó.

CSV é um outlier plano e apenas saída. Matrizes ou objetos selecionados tornam-se linhas, caminhos aninhados são achatados em colunas pontilhadas, mesclagens nulas com texto vazio e strings semelhantes a fórmulas são neutralizadas. CSV-to-JSON, XML-to-TOML e outros pares ausentes são recusados ​​em vez de inferidos.

Matriz de compatibilidade para as nove direções enviadas, com CSV apenas como saída

Formatos binários e linguagens de esquema estão fora do escopo. Um esquema pode restaurar a cardinalidade da lista ou validar formas de negócios, enquanto as codificações binárias introduzem tipos e enquadramentos em nível de byte não representados aqui. O conversor nunca reivindica essas capacidades.

A conversão de sintaxe também não prova a validade do aplicativo. Uma mensagem de pedido YAML, XML limpa ou arquivo de projeto TOML em forma de Kubernetes ainda pode violar o contrato de destino. Use o validador de domínio depois de inspecionar o mapeamento de sintaxe.

Conclusão: escolha o modelo, depois a sintaxe - e como o painel Conversores de sintaxe permite testar uma conversão antes de confirmá-la

Escolha o modelo de dados antes de escolher sua pontuação. Se comentários e aliases forem importantes, um salto JSON não poderá preservá-los. Se nulo for importante, a saída TOML o altera. Se o conteúdo misto ordenado for importante, uma projeção JSON simples é insuficiente. Se o destino for uma tabela, JSON aninhado requer uma convenção de nivelamento explícita.

Use ToolAcre para testar um documento representativo e ler todos os avisos. O resultado é evidência sobre um par e entrada concretos, e não permissão para chamar todas as conversões sem perdas ou todos os analisadores suportados completos.

Crie o documento representativo a partir dos limites que são importantes para o seu serviço: nulo, texto vazio, um identificador grande, uma string semelhante a uma data, um registro repetido, um comentário ou alias se YAML estiver envolvido e texto misto se XML estiver envolvido. Compare os valores normalizados após cada salto suportado e retenha os avisos com o resultado. Essa matriz torna-se um artefato de decisão para o modelo escolhido, em vez de uma vaga preferência por uma sintaxe familiar.