Conversor XML para JSON

1. 1

   Adicione seu XML

   Cole a marcação no editor ou solte um arquivo sobre a página. XML, SVG, RSS, Atom, WSDL, XSD, KML, GPX, plist e OPML são aceitos, e a codificação é detectada pela marca de ordem de bytes ou pela declaração XML.

2. 2

   Escolha uma forma de saída

   Compacta é a forma familiar que a maioria das ferramentas produz. BadgerFish e GData são as duas convenções usadas por APIs antigas. Parker entrega os valores mais simples possíveis. JsonML preserva a ordem do documento e permite voltar ao XML original.

3. 3

   Ajuste a leitura dos valores

   Decida se os atributos são mantidos e com que prefixo, se um elemento único vira um array de um item, no que se transforma um elemento vazio e se números e booleanos são inferidos em vez de ficarem como texto. A prévia se atualiza a cada mudança.

4. 4

   Converta e baixe ou copie

   Clique em Converter para escrever o arquivo. Escolha 2 espaços, 4 espaços, tabulações ou saída minificada, depois baixe o .json ou copie-o. Com Pro você converte até 50 arquivos de uma vez e leva todos em um único ZIP.

A maioria dos conversores de XML para JSON toma uma decisão silenciosa por você e não dá meio de mudar: escolhe uma forma, descarta seus atributos e devolve um JSON que parece certo. Este pergunta. Você escolhe a convenção de saída, se os atributos sobrevivem e com que prefixo, se um elemento único é um valor ou um array de um item, o que significa um elemento vazio e o que acontece com os prefixos de namespace — e a prévia ao lado dos controles mostra a resposta enquanto você muda cada um.

• Nada é descartado — Atributos, seções CDATA, texto misto e instruções de processamento sobrevivem à conversão. Cada um tem seu controle, então você decide o que manter em vez de descobrir depois o que se perdeu.
• Cinco formas de saída — Compacta, BadgerFish, GData, Parker e JsonML. Quatro são as convenções que APIs reais usam; JsonML é a que preserva a ordem do documento e converte de volta exatamente.
• Erros acionáveis — Uma análise que falha dá a linha, a coluna, a linha de origem e um cursor sob o caractere culpado, com uma mensagem que nomeia a falha em vez de repetir que o arquivo é inválido.
• Arquivos grandes sem travar — Leitura e gravação acontecem fora da interface, então a página nunca congela. Um documento de 25 MB converte em cerca de um segundo, com barra de progresso e um Cancelar que funciona.

Não existe uma única maneira correta de representar XML como JSON, por isso várias convenções existem e por isso bibliotecas sérias deixam você escolher. XML tem atributos, filhos ordenados, texto misto e namespaces; JSON tem objetos, arrays e strings. Todo mapeamento abre mão de um deles. Escolher a troca certa para o que você vai fazer em seguida é quase todo o trabalho.

• Compacta — o padrão — Elementos viram chaves, atributos recebem o prefixo @_ e o texto fica sob #text. É a forma que a maioria das ferramentas e tutoriais produz, então será familiar para quem ler o arquivo depois. Escolha-a a menos que tenha motivo para não escolher.
• BadgerFish — uniforme — Todo elemento é um objeto, o texto fica sempre sob $, os atributos sob @nome e as declarações de namespace sob @xmlns. Nada é jamais uma string solta, então o código que consome nunca precisa testar se um campo voltou como objeto ou como valor. Verbosa, e previsível em troca.
• GData — a forma do Google — Atributos viram chaves comuns ao lado dos elementos filhos e o texto fica sob $t. Compacta de ler, é a escolha certa quando você está se ajustando a uma forma Google Data ou Atom existente.
• Parker — a mais simples — Atributos são descartados, o nome do elemento raiz some e as folhas viram seus valores. O resultado é o mais próximo do que você escreveria à mão se tivesse começado em JSON. Use para configuração e dados simples em que os atributos não carregam nada de que você precise.
• JsonML — sem perdas — Cada elemento vira um array com seu nome de tag, seus atributos e seus filhos na ordem do documento. É a única forma aqui que sobrevive a uma ida e volta, e a única que consegue representar um elemento, depois outro, depois o primeiro de novo.

Um elemento XML carrega três coisas diferentes ao mesmo tempo — seus atributos, seu texto e seus elementos filhos — e um objeto JSON tem um único espaço de chaves para as três. Cada convenção resolve essa colisão de um jeito, e a colisão é real: um elemento com um atributo chamado nome e um elemento filho chamado nome precisa que os dois sobrevivam.

• O prefixo de atributo — @_ por padrão, e configurável. Sua única função é impedir que a chave de um atributo colida com um elemento filho de mesmo nome, então qualquer prefixo que não apareça nos seus nomes de tag serve. Deixe vazio se você sabe que não há colisões e quer a saída mais plana.
• A chave de texto — #text por padrão. É usada quando um elemento tem texto e algo mais: atributos, elementos filhos, ou ambos. Um elemento com nada além de texto é escrito diretamente como esse texto, então documentos simples continuam simples.
• Conteúdo misto — Um parágrafo com um trecho em negrito tem texto antes, dentro e depois dos filhos. Esse texto é reunido e mantido sob a chave de texto em vez de descartado, o que significa que um documento que você descreveria como prosa e não como dados ainda converte para algo legível.
• Espaços em branco — O texto é aparado por padrão, porque o recuo de um XML formatado é apresentação e não dado. Colapsar reduz cada sequência de espaços a um só; Como escrito mantém o texto exatamente como está, que é o que você quer para qualquer coisa cuja formatação importe, como código embutido.

A surpresa mais comum na conversão de XML para JSON é que a forma da saída depende da quantidade de registros na entrada. Um pedido no arquivo dá um objeto; dois dão um array. O código escrito contra uma amostra com dois pedidos quebra no dia em que um cliente manda um, e a falha parece um problema de dados em vez de um mapeamento ambíguo.

• Quando repetido (padrão) — Uma tag que aparece várias vezes como irmã vira array, preservando ordem e quantidade. Uma tag que aparece uma vez continua um valor simples. É o que quase todo conversor faz, e é a saída mais legível.
• Sempre — Todo elemento que poderia repetir vira array, mesmo com uma única ocorrência. A saída fica um pouco mais verbosa e totalmente previsível, que é o que você quer quando o JSON vai direto para código em vez de ser lido por uma pessoa.
• Ordem entre tags diferentes — Arrays preservam a ordem de irmãos de mesmo nome, mas nenhuma forma indexada por chave preserva a de nomes diferentes — as chaves de um objeto não carregam sequência. Se o intercalamento importa, JsonML é a forma que o mantém.

Namespaces são o motivo do XML corporativo ter a cara que tem, e são onde um conversor ingênuo produz em silêncio algo errado. Um prefixo como soap: não faz parte do nome do elemento — é um ponteiro para uma URI declarada acima, e o mesmo prefixo pode significar coisas diferentes em partes diferentes de um mesmo documento.

• Manter — Os prefixos ficam exatamente como escritos, então soap:Envelope continua soap:Envelope e o JSON bate com o documento que você está olhando. É o padrão certo para respostas SOAP e para WSDL, onde os prefixos são aquilo a que todo mundo se refere.
• Remover — Os prefixos saem para uma forma mais limpa e curta. Dois elementos de namespaces diferentes podem então cair na mesma chave, o que é perda real de informação — quando acontece, a ferramenta conta as colisões e avisa em vez de deixar a fusão passar em silêncio.
• Expandir — Cada prefixo é substituído pela URI completa entre chaves. Nada fica ambíguo e nada pode colidir, ao custo de chaves longas. É a forma a escolher quando o JSON vai ser validado ou comparado em vez de lido.
• Atributos sem prefixo — Um atributo sem prefixo não está em namespace nenhum — ele não herda o namespace padrão do elemento. É uma regra que conversores erram com frequência, e errar nela inventa um namespace que o documento nunca declarou.

XML não tem tipos. Todo valor de um documento é texto, e qualquer conversor que devolva um número decidiu por você que o texto parecia numérico o bastante. Essa decisão é útil com frequência e destrutiva de vez em quando, por isso aqui é um controle e por isso vem desligada até você ligar.

• O que é convertido — Inteiros e decimais simples, true, false e null. Nada mais.
• O que deliberadamente não é — Um valor com zeros à esquerda continua texto, porque um número de pedido escrito 007 não é 7. Um sinal de mais inicial continua texto, porque um prefixo telefônico não é um número. Um valor além da faixa de inteiros seguros continua texto, porque convertê-lo mudaria os dígitos em silêncio. O mesmo vale para notação exponencial ou hexadecimal, e para Infinity e NaN, que uma conversão numérica ingênua aceita e que nenhum documento XML quer dizer.
• A regra da ida e volta — Um valor só vira número se escrever esse número de volta der exatamente os caracteres que estavam no arquivo. É isso que protege 1.0, que a maioria dos conversores transforma em 1 e devolve como se nada tivesse acontecido.
• Elementos vazios — Um elemento vazio pode razoavelmente ser uma string vazia, um null ou um objeto vazio, e qual é o certo depende do que você vai fazer depois. Em vez de escolher por você é um controle, para dar para distinguir um campo anulável de um realmente em branco.

XML quebrado é o caso normal, não a exceção, e costuma estar quebrado por uma de umas seis razões. Um conversor que responde com a palavra Inválido não te disse nada que você já não soubesse; o que você precisa é do caractere que causou isso.

• A linha, a coluna e um cursor — Toda falha informa onde aconteceu, mostra a linha de origem e coloca um cursor sob o caractere exato. Documentos longos de uma linha só são recortados em volta da falha, para que um arquivo minificado não se imprima inteiro na caixa de erro.
• Um e comercial sem escape — A falha mais comum de XML escrito a mão. Um & solto em Q&A ou numa string de consulta de URL não é marcação válida e precisa ser escrito &. A mensagem diz isso, em vez de relatar um erro de entidade misterioso.
• Tags que não combinam — Uma tag de abertura fechada com outro nome, ou uma tag deixada aberta no fim do arquivo. Ambas nomeiam a tag envolvida, e o caso não fechado aponta para onde o elemento foi aberto, e não para o fim do documento.
• Namespaces e duplicatas — Um prefixo usado sem ser declarado, ou o mesmo atributo escrito duas vezes num elemento. Ambos são erros e não fusões silenciosas, porque ficar com um de dois valores sem avisar põe na sua saída dados que ninguém escreveu.
• Entidades e DTDs — Um DOCTYPE é analisado e pulado, não seguido. Entidades declaradas são reconhecidas pelo nome mas nunca expandidas, então uma referência a uma delas é relatada com clareza em vez de substituída — o que também torna impossível aqui o clássico ataque de expansão de entidades.

Tudo abaixo é XML, e cada um era um arquivo que a versão anterior desta página deixava você escolher para depois não fazer nada com ele, porque só reconhecia a extensão .xml enquanto o sistema operacional não informa tipo nenhum para a maioria dos outros.

• Feeds e sindicação — RSS e Atom, incluindo os conjuntos item e entry que dão a saída delimitada por linhas mais útil. OPML para listas de assinaturas.
• Serviços web — Definições de serviço WSDL e esquemas XSD, ambos carregados de namespaces e o motivo de Manter ser a política padrão.
• Gráficos e geografia — Documentos SVG, onde converter para JSON é como um script de build lê um path ou um viewBox. KML e GPX para dados de mapa e trilhas gravadas.
• Configuração e documentos — Listas de propriedades plist da Apple, arquivos .config e .csproj, arquivos POM do Maven, folhas de estilo XSLT e XHTML.

O documento é lido e gravado fora da interface, então a página continua respondendo enquanto um arquivo grande é convertido, com progresso real e um Cancelar que age na hora.

• Forma de saída — Compacta, BadgerFish, GData, Parker ou JsonML. Muda toda a estrutura; a prévia atualiza na hora.
• Atributos — Mantenha ou descarte, e defina o prefixo das chaves. Ignorado em Parker, que descarta atributos por definição.
• Chave de texto — A chave que carrega o texto próprio de um elemento quando ele também tem atributos ou filhos.
• Arrays — Somente elementos repetidos, ou force array para todo elemento repetível.
• Namespaces — Manter o prefixo, remover, ou expandir para a URI completa.
• Tipos — Deixar todo valor como texto, ou inferir números, booleanos e null com a regra da ida e volta.
• Elementos vazios — Uma string vazia, um null, ou um objeto vazio.
• Espaços em branco — Aparar, colapsar sequências em um espaço, ou manter o texto como escrito.
• CDATA — Fundir com o texto do elemento, ou manter sob a própria chave.
• Comentários e instruções — Descartados por padrão; mantenha qualquer um quando precisar, algo que só as formas que preservam a ordem conseguem expressar por completo.
• Recuo — 2 espaços, 4 espaços, tabulações, ou minificado numa linha só.
• Codificação — Detectada pela marca de ordem de bytes ou pela declaração XML, e sobrescrevível quando um arquivo declara a errada.

Muito dado real ainda vive em XML — extratos bancários, feeds oficiais, serviços SOAP, arquivos de build, exportações de mapa e todo feed RSS já publicado — enquanto quase tudo que se constrói hoje para consumir dados espera JSON. Converter costuma ser o caminho mais curto entre os dois, e só continua curto se a conversão não perder nada no meio.

• Serviços antigos para código moderno — Uma resposta SOAP vira algo que uma chamada fetch lê sem uma biblioteca XML no bundle.
• Feeds para pipelines — Um feed RSS ou Atom vira um conjunto de registros, e com a saída delimitada por linhas vira algo que uma ferramenta de dados consegue processar em fluxo.
• Configuração para ferramentas — Um plist, um POM ou um arquivo .config vira legível para um script sem analisador XML.
• Inspeção — Um documento muito aninhado se lê melhor como JSON num editor que o dobra, o que muitas vezes é a verdadeira razão para converter.
• Continua privado — Extratos bancários e respostas de serviços são exatamente os documentos que ninguém deveria colar num site que os envia. Este não envia.

• JSON para XML
• Formatador JSON
• Validador JSON
• Visualizador JSON
• YAML para JSON
• Minificador JSON