Conversor JSON para XML

1. 1

   Cole ou solte o seu JSON

   Cole JSON na caixa ou solte um arquivo .json, .jsonl, .ndjson, .geojson ou .txt. JSON Lines é detectado sozinho — você não precisa mudar de modo.

2. 2

   Nomeie a raiz e os elementos repetidos

   Defina o elemento de nível superior (root por padrão). Escolha se todos os elementos de um array se chamam item, se recebem o nome da chave de onde o array veio, ou o singular dessa chave — assim books vira book.

3. 3

   Decida como os valores são escritos

   Escolha no que um null se transforma: um elemento vazio, xsi:nil ou nada. Ative o mapeamento de atributos se as suas chaves usam a convenção @nome e #text. Escolha a indentação, a declaração e a codificação de saída.

4. 4

   Converta e depois baixe ou copie

   Clique em Converter para XML. A pré-visualização se atualiza a cada ajuste, então você vê o formato antes de exportar. Baixe o .xml, copie-o ou gere um esquema .xsd correspondente.

Este conversor gratuito transforma JSON em XML bem formado, no seu dispositivo. Cole ou solte um arquivo, nomeie o elemento raiz e os elementos repetidos que um array produz, decida no que um null e uma chave inutilizável se transformam, e exporte. A pré-visualização se atualiza a cada ajuste, então você vê o formato antes de se comprometer. JSON inválido mostra o problema, a linha e a coluna e um trecho — além de links para o Formatador e o Validador JSON.

• Elemento raiz — A tag de nível superior que envolve o documento — root, data, response, qualquer nome XML válido. Um nome inválido é reparado e a mudança é mostrada a você em vez de aplicada em silêncio.
• Nome dos elementos de array — Uma tag fixa para cada array, a chave de onde ele veio, ou o singular dessa chave — assim um array books escreve elementos book, que é o que uma pessoa teria escrito à mão.
• Atributos e texto — Ative a convenção @nome e #text e uma chave escrita @id vira um atributo XML enquanto #text vira o texto do elemento. É o par exato da ferramenta XML para JSON.
• Null, vazio e ausente — Um null do JSON pode ser um elemento vazio, um elemento xsi:nil que um esquema entende, ou nada. Três significados realmente diferentes, e a maioria dos conversores oferece um.
• Detalhe do erro — JSON inválido mostra a mensagem, a linha e a coluna e um trecho com a posição marcada. Chaves duplicadas também são informadas, porque são válidas e ambíguas.

JSON tem seis tipos de valor e XML tem elementos, atributos e texto. A correspondência é direta, e as únicas decisões são as que os ajustes deixam à vista.

• Objetos viram elementos aninhados — Cada chave vira um elemento filho com o seu nome, na ordem em que as chaves aparecem na origem.
• Arrays viram elementos repetidos — Um array não vira um elemento com uma lista dentro; vira o mesmo elemento escrito uma vez por entrada, que é como o XML sempre expressou um valor repetido.
• Strings, números e booleanos viram texto — O XML não tem tipo próprio para nenhum deles, então cada um é escrito como conteúdo de texto. Com as anotações de tipo, cada elemento também carrega type="number", type="string" ou type="boolean".
• Números são copiados, não recalculados — Saem os mesmos dígitos que você escreveu. Um identificador de vinte dígitos continua exato, -0 continua -0 e 1e-7 continua 1e-7 — nada disso sobrevive a uma passagem por um valor de ponto flutuante.
• A raiz precisa ser inventada — O JSON pode ter um array ou até uma string solta no nível superior; o XML precisa de exatamente um elemento raiz. É isso que o ajuste de elemento raiz nomeia.

É a única coisa que a maioria dos conversores de JSON para XML erra, e não dá para ver na saída. O XML não sabe marcar espaço em branco como decorativo — cada caractere entre as tags de um elemento faz parte do seu valor. Então um elemento cujo conteúdo é texto não pode ser indentado sem mudar o que ele diz.

• A falha — Escrito de forma ingênua, o array ["a","b"] é formatado como um elemento item com uma quebra de linha antes do a e uma quebra mais dois espaços depois. Lido de volta por qualquer parser conforme, esse valor não é "a": é uma quebra de linha, um a, uma quebra e dois espaços.
• A consequência — Ligar a formatação muda os dados, e a saída compacta e a indentada do mesmo conversor discordam sobre o que o documento significa. Nada dá erro e nada parece errado.
• A regra aqui — Espaço só é acrescentado dentro de um elemento quando todos os seus filhos são outros elementos. Um elemento com qualquer texto é escrito em uma linha, com qualquer indentação. A ida e volta por dois parsers XML independentes faz parte do conjunto de testes desta ferramenta.

O JSON não tem atributos, então um conversor precisa de uma convenção para produzi-los. Esta ferramenta usa a que as bibliotecas de XML para JSON já falam: uma chave que começa com @ vira um atributo do elemento que a contém, e a chave #text vira o seu conteúdo de texto. Desativada por padrão, porque os seus dados podem usar essas chaves legitimamente.

• O que produz — {"@id": "7", "name": "Ada"} vira um elemento com id="7" e um filho name, em vez de dois elementos filhos, um deles chamado _id.
• Ida e volta — É a convenção que a ferramenta XML para JSON deste site lê, então um documento convertido nos dois sentidos mantém o formato.
• Quando um valor não pode ser atributo — Um atributo contém texto plano. Um objeto ou array sob uma chave @ é escrito como um elemento filho comum — nunca descartado, nunca transformado em um bloco JSON dentro do seu XML — e a contagem é exibida.
• Conteúdo misto — Se um elemento acabar com texto e elementos filhos, o elemento inteiro é escrito em uma linha. É a única forma de manter o texto exatamente como estava; veja a seção acima.

Chaves JSON são strings arbitrárias. Nomes de elementos XML não: precisam começar com letra ou sublinhado, não podem conter espaços nem a maioria dos sinais de pontuação, e não podem começar com as letras xml. Algo tem que ceder, e aqui o modo como cede é um ajuste, não uma decisão silenciosa.

• Reparar e mostrar a lista — "first name" vira first_name e "2024" vira _2024. Um dígito inicial recebe um prefixo em vez de ser apagado, para que 2024 e 024 não acabem com o mesmo nome. Cada renomeação aparece no painel ao lado da pré-visualização.
• Ou manter o texto original — A outra opção escreve um elemento key com name="first name", de modo que a string original sobrevive literalmente no documento. Mais feio, sem perda, e é o que esta página produzia antes do rebuild.
• Acentos e escritas não latinas são mantidos — Führung, señor e 名前 são todos nomes de elementos XML perfeitamente válidos e são escritos como estão. Conversores que removem tudo fora de A–Z destroem sem avisar os nomes de campo da maioria das exportações não inglesas.
• Colisões são separadas — Se "first name" e "first-name" forem ambos reparados para first_name, o segundo vira first_name_2 — fundi-los seria perda de dados parecendo sucesso. Uma chave que já era válida sempre mantém o próprio nome.
• Emojis viram sublinhado, de propósito — A especificação XML os permite; os parsers reais não concordam. Um parser rigoroso rejeita de vez um documento com emoji em um nome de elemento e outro descarta silenciosamente o elemento e o seu conteúdo. Um sublinhado é lido de forma idêntica em todo lugar.

"Sem valor" tem vários sentidos em JSON e várias grafias em XML, e escolher entre elas é a diferença entre um documento que um esquema consegue validar e um que não.

• Um elemento vazio — O padrão. Um null vira um elemento sem nada dentro, que é o formato que a maioria dos consumidores espera.
• xsi:nil — Escreve o elemento como nil e declara o espaço de nomes de instância de esquema na raiz. É a única grafia que um consumidor consegue distinguir de "o exportador esqueceu este campo", e é o que um XSD espera.
• Omitido — O elemento não é escrito. Isso vale apenas para membros de objetos — um item null dentro de um array continua sendo escrito, porque o tamanho de um array é informação e remover um item desloca silenciosamente todos os índices seguintes.
• Objetos e arrays vazios — Ambos viram um elemento vazio. Um array vazio não produz uma linha em branco entre duas tags, que é o que um escritor ingênuo emite.

Todo conversor concorrente escreve item para cada array do documento, perdendo a única informação que o array carregava: o que havia nele. Aqui há três opções, e ninguém mais oferece a terceira.

• Uma tag fixa — Cada item do array recebe a tag que você digitar — item por padrão. Previsível, e o que um consumidor escrito para outro conversor vai esperar.
• A chave pai — Os itens recebem o nome da chave de onde o array veio, então um array books produz elementos books dentro de um elemento books.
• O singular da chave pai — books produz book, categories produz category, children produz child. É o que uma pessoa teria escrito à mão. Quando a palavra não pode ser encurtada, a tag fixa é usada, em vez de aninhar um nome dentro dele mesmo.
• Um array no nível raiz — Um array no topo do documento não tem chave que o nomeie, então o nome do elemento raiz é usado como pai.

Os três ajustes que decidem como o arquivo se parece, não o que ele diz. O da codificação vale a leitura: é o ajuste mais frequentemente implementado como rótulo em vez de como fato.

• A declaração XML — Ligada por padrão. Ela indica a versão e a codificação, e um consumidor que a lê acredita nela — por isso os bytes precisam corresponder.
• Indentação — Dois espaços, quatro espaços, tabulações ou nenhuma. Sem indentação o documento inteiro fica em uma linha, que é o que se quer quando o consumidor é um programa e não uma pessoa.
• UTF-8 — O padrão, e quase sempre a resposta certa. Escrito sem marca de ordem de bytes, porque a declaração já diz isso e essa marca quebra consumidores que esperam o arquivo começar com um sinal de menor.
• UTF-16 — Escrito como bytes UTF-16 reais com marca de ordem de bytes, porque um documento UTF-16 sem ela não é detectável de forma confiável e vários parsers o recusam.
• ISO-8859-1 — Realmente codificado como Latin-1. Cada caractere que a codificação não comporta é escrito antes como referência numérica de caractere, o que é XML válido e não perde nada — assim um documento que diz ISO-8859-1 realmente é um. Um conversor que escreve o rótulo e emite UTF-8 mesmo assim produz um arquivo errado de um jeito que nenhum validador percebe.

Um valor JSON por linha, sem array envolvendo. É o que pipelines de log, exportações em massa de APIs e despejos de data warehouse emitem, e o parser JSON padrão recusa de imediato — então a maioria dos conversores simplesmente não consegue abrir os arquivos que as pessoas mais costumam ter.

• Detectado, não ligado — Solte um arquivo .jsonl ou .ndjson e ele é reconhecido. Um .json ou .txt que por acaso contenha um valor por linha também é reconhecido, porque a extensão é uma pista, não uma promessa.
• O que produz — Cada linha vira um elemento repetido sob a raiz, exatamente como se as linhas fossem um array. Todos os ajustes de array valem normalmente.
• Linhas em branco são ignoradas — Uma quebra de linha final é universal e não é um erro. Qualquer outra linha que não seja JSON válido informa o número da linha, a única coordenada que significa algo neste formato.

O JSON não tem esquema, então um XSD precisa ser induzido do próprio documento. Este é coletado enquanto o XML é escrito, e não por uma segunda passagem sobre o JSON, o que significa que só pode descrever elementos que foram realmente produzidos, com os nomes que realmente receberam.

• A cardinalidade vem dos dados — Um elemento filho ausente em qualquer instância do seu pai é marcado como opcional. Um filho visto mais de uma vez em uma única instância é marcado como ilimitado.
• Tipos só são estreitados com certeza — Um elemento recebe tipo inteiro apenas quando todos os valores vistos eram inteiros no texto de origem — inclusive os longos demais para sobreviver como número de ponto flutuante. Um único decimal em qualquer lugar o alarga.
• A ambiguidade alarga em vez de adivinhar — Um elemento visto com texto e filhos é marcado como misto; um visto como contêiner e como valor simples fica aberto. Um esquema que rejeita o arquivo do qual foi gerado é pior do que nenhum esquema.
• Os espaços de nomes combinam — Um espaço de nomes de destino só é declarado quando o próprio documento foi escrito dentro de um, porque um esquema que declara um espaço de nomes que a instância não usa não valida nada.

Muitos sistemas ainda falam XML e mais nada. Converter permite reaproveitar dados que você já tem em JSON sem reescrever quem os produz, e costuma ser o passo mais barato de uma integração.

• Integração corporativa e SOAP — Serviços SOAP, gateways EDI e ERPs antigos aceitam apenas XML. Uma carga convertida costuma ser todo o trabalho.
• Arquivos de configuração e build — Ant, Maven, Spring, layouts do Android e configuração .NET são XML. Dados gerados como JSON precisam chegar nesse formato.
• Validação por esquema — O XML tem XSD, que permite a um sistema receptor rejeitar uma carga malformada antes de fazer qualquer coisa com ela. O JSON Schema existe, mas bem menos sistemas o aplicam.
• Documentos em vez de dados — O XML lida com conteúdo misto — texto com marcação dentro — que o JSON não consegue expressar de forma alguma. É por isso que formatos de publicação são XML.
• Privacidade — A conversão roda no seu dispositivo. Nada da carga sai dele, o que importa quando a carga são registros de clientes e a alternativa é colá-los no servidor de outra pessoa.

Um arquivo JSON de 9 MB vira 17,8 MB de XML em cerca de seis décimos de segundo, sem travar a página.

• Elemento raiz — A única tag de nível superior. Precisa ser um nome XML válido; um inválido é reparado e a mudança é exibida.
• Tag de array — O nome de elemento usado para cada item de um array quando o modo de nomes está em tag fixa.
• Nome dos elementos de array — Tag fixa, chave pai, ou singular da chave pai.
• Chaves inválidas — Reparar a chave para um nome XML válido, ou manter o texto original em um atributo name.
• Valores null — Um elemento vazio, xsi:nil, ou omitido do documento.
• Mapeamento de atributos — Tratar chaves @ como atributos e #text como texto do elemento.
• Anotações de tipo — Adiciona type="number", type="string" ou type="boolean" a cada elemento. Pro.
• Espaço de nomes e prefixo — Uma URI de espaço de nomes de destino para o documento, ligada como padrão ou a um prefixo. Pro.
• Declaração XML — Se a linha com a versão e a codificação é escrita no topo.
• Codificação de saída — UTF-8, UTF-16 ou ISO-8859-1 — declarada e realmente codificada.
• Indentação — Dois espaços, quatro espaços, tabulações, ou uma linha compacta.
• Nome do arquivo — A base do nome para o .xml e o .xsd baixados.

Tudo o que decide se a conversão está correta é gratuito. O plano decide quanto você pode passar de uma vez e se os extras vêm junto.

• Grátis — Um arquivo por vez, até 10 MB — cerca de quarenta mil registros de uma exportação típica. Todos os ajustes de estrutura, todos os modos de nome, todas as políticas de null, o mapeamento de atributos, as quatro indentações e as três codificações.
• Pro — Sem limite de tamanho imposto — até o que o seu dispositivo aguentar. Até 50 arquivos convertidos de uma vez e baixados como um único ZIP, além de geração de XSD, espaços de nomes de destino e anotações de tipo.
• O que um arquivo recusado recebe — O tamanho real, o limite e um link para o minificador JSON, que é de fato o primeiro passo certo para um arquivo alguns megabytes acima. Nunca uma barra de progresso que depois falha.

• XML para JSON
• Formatador JSON
• JSON para YAML
• Ferramentas JSON
• Check it parses at all

  Confirms the document is valid JSON and says where it stops being valid if not

• Flatten it into a table

  When a person with a spreadsheet is the consumer rather than a system with a schema