Cookies para estatística e publicidade
Usamos cookies de estatística e de publicidade, ambos enviados ao Google. Recusar não muda nada do que você vê.Ler a página de privacidade
Aqui você converte XML para JSON de graça e sem conta: solte o arquivo acima e em poucos segundos o resultado está pronto para baixar. A conversão acontece dentro do seu próprio navegador, então o arquivo nunca é enviado. Funciona igual no Windows, no macOS e no Linux e também no iPhone e no Android, e continua funcionando mesmo se você cortar a conexão.
Até 100 arquivos de uma vez. Formatos misturados não são problema.
Eles são convertidos um após o outro e baixados juntos em um ZIP.
XML para JSON
XML carrega informação em três lugares — nomes de elemento, atributos e texto —, e JSON só tem chaves e valores, então o mapeamento precisa de uma convenção. Esta é a comum: cada elemento vira uma chave cujo valor é um objeto de seus filhos, cada atributo vira uma chave nesse mesmo objeto prefixada com @, e o texto próprio de um elemento, onde ele tem filhos ou atributos junto, fica guardado sob a chave #text.
Um elemento com nada além de texto é mais simples: vira um valor de string puro, sem objeto envolvendo. Essa inconsistência é inevitável, e vale internalizar cedo, porque significa que o valor num caminho dado às vezes é uma string e às vezes um objeto, dependendo de o elemento de origem por acaso carregar um atributo ou não.
Esta é a coisa mais cara de consumir num XML convertido. Um documento XML não diz quais elementos se repetem — só um esquema diz isso, e o analisador não está lendo um. Então um canal contendo um elemento item produz um objeto, e um canal contendo dois produz um array de objetos. O formato do seu JSON depende de quanto dado havia no arquivo.
Código escrito contra um feed RSS completo, portanto, quebra no dia em que o feed tem uma entrada só, e código escrito contra uma resposta SOAP com um único registro quebra na primeira vez que dois voltam. Não há opção aqui que conserte isso, porque consertar exigiria conhecer o esquema. Escreva o consumidor para aceitar os dois: force toda coleção a virar array como a primeira coisa que você faz, antes de qualquer outra lógica tocar nela.
Um envelope SOAP chega com seus prefixos intactos: soap:Envelope vira uma chave literalmente chamada «soap:Envelope», e as declarações de namespace atravessam como atributos tipo «@xmlns:soap». Nada é resolvido e nada é removido.
Isso é fiel e é frágil, porque um prefixo é arbitrário. Um serviço que emite soapenv:Envelope numa semana e soap:Envelope na outra produziu dois documentos equivalentes e duas estruturas JSON incompatíveis. Se você controla o consumidor, compare pelo nome local depois dos dois-pontos em vez da chave completa, e nunca fixe no código um prefixo que você não definiu.
Um documento que abre com uma declaração de versão e codificação produz uma chave de primeiro nível chamada «?xml» guardando seus atributos, ao lado da chave do elemento raiz. Não é parte do conteúdo do documento e está no seu JSON.
Trate isso ignorando ou apagando, mas não presuma que o elemento raiz é a única chave de primeiro nível. Código que lê a primeira chave do objeto para achar a raiz vai achar a declaração em vez disso em qualquer documento que a tenha, que é a maioria.
Valores que parecem numéricos viram números JSON, tanto em atributos quanto em texto de elemento. Um atributo de versão escrito 1.0 vira 1. Um identificador escrito 007 vira 7. Um valor de elemento com zero à esquerda escrito 0755 vira 755.
Isso é conveniente para uma contagem e destrutivo para qualquer coisa que você tratava como um token opaco. Números de pedido, códigos de produto, CEPs, versões de protocolo e modos de arquivo falham todos do mesmo jeito, e nenhum levanta erro. O hábito que vale construir é olhar todo atributo na saída que você pretende comparar como string, uma vez, antes de o código que o lê existir — é muito mais barato do que descobrir por um chamado de suporte que o pedido 007 e o pedido 7 são o mesmo pedido.
Comentários são descartados sem rastro, o que num payload costuma ser inofensivo e num arquivo de configuração é uma perda real. CDATA é desembrulhado: o que estava dentro da seção vira uma string comum, então um trecho HTML envolvido em CDATA — a forma normal de um feed RSS carregar o corpo de um post — chega como texto contendo colchetes angulares, e converter de volta para XML os escaparia em vez de restaurar a seção CDATA.
Conteúdo misto é o caso sem resposta boa. Um elemento contendo texto, depois um elemento filho, depois mais texto guarda o filho na própria chave e concatena as duas sequências de texto num único valor #text, sem marcador de onde o filho estava entre elas. Qualquer documento onde prosa e marcação se entrelaçam — XHTML, DocBook, qualquer coisa narrativa — perde a ordem aqui, e JSON simplesmente é o destino errado para isso.
Um elemento autofechado e um elemento com corpo vazio viram os dois uma string vazia. XML tampouco distingue entre eles, então nada se perde, mas JSON tem null disponível e não é usado — um elemento vazio é «» e não null.
A distinção que de fato desaparece é entre um elemento que estava ausente e um que estava presente e vazio, uma vez que seu código aplica um padrão. Os dois acabam falsy. Onde a diferença importa — um campo opcional explicitamente limpo versus nunca definido —, confira pela presença da chave em vez do seu valor.
Somando tudo, uma resposta SOAP lê como chaves aninhadas: a chave do envelope, a chave do corpo dentro dela, depois a resposta da operação, depois o payload. Todo nível mantém seu prefixo, e a coisa toda tem três ou quatro objetos de profundidade antes de qualquer dado seu aparecer, exatamente tão verboso quanto o XML era e mais fácil de percorrer a partir de código.
Uma falha é o caso a testar primeiro. Falhas SOAP usam uma estrutura de elemento diferente de uma resposta bem-sucedida, então o JSON de um erro não se parece nada com o JSON de um resultado, e um cliente que só viu o caminho feliz vai ler undefined num caminho que não existe mais. Converta uma resposta de falha real aqui e escreva o ramo de erro contra ela antes de precisar.
A saída é indentada com dois espaços, então lê bem numa revisão e cola direto num fixture de teste. Fixtures são o uso certo para isso: converter uma resposta real e colocá-la no repositório dá ao consumidor algo honesto para ser testado, incluindo toda a estranheza acima.
Três hábitos defensivos cobrem quase todo problema desta página. Normalize tudo que pode repetir para um array. Compare identificadores como strings, e converta-os de volta a strings na fronteira se o analisador os tornou números. Combine chaves com namespace pela parte local. Com isso em prática, a conversão é confiável, e tudo mais que ela faz é previsível.
| XML | JSON | |
|---|---|---|
| Nome completo | Extensible Markup Language | JavaScript Object Notation |
| Extensão do arquivo | .xml | .json |
| Tipo de mídia | application/xml | application/json |
| Publicado pela primeira vez | 1998 | 2001 |
| Publicado por | W3C | — |
| Especificação | XML 1.0 | RFC 8259 |
| Licença | Padrão aberto | Padrão aberto |
| Situação hoje | Atual | Atual |
| Abre no navegador | Todos os navegadores | Todos os navegadores |
| Considerado no lugar | YAML | YAML, NDJSON |
Os comentários não sobrevivem. XML permite anotar um arquivo e JSON não tem sintaxe para isso, então cada linha de explicação se perde — e isso atinge justamente os arquivos que se comentam: configuração que outra pessoa vai manter.
Visual Studio Code lê tanto XML quanto JSON, então dá para comparar o resultado com o original sem um segundo programa.
XML é o formato da W3C, publicado em 1998. Está descrito em XML 1.0, e vale conhecer se o arquivo precisa sobreviver à ferramenta que o escreveu.
JSON e de 2001, descrito em RFC 8259. Visual Studio Code, jq e Postman leem o formato.
Não. Esta conversão acontece inteiramente no seu navegador, então o arquivo não sai do seu aparelho. Você mesmo pode conferir: abra a aba de rede das ferramentas de desenvolvedor e converta alguma coisa. Você verá a própria página e as requisições de estatística e de publicidade com que este serviço é pago, e nenhuma que leve o seu arquivo.
É. Sem conta, sem marca d’água e sem cota diária para gastar: roda no seu próprio aparelho, então você pode voltar quantas vezes quiser. O navegador processa arquivos de até 100 MB, 100 por vez.
XML e JSON descrevem o conteúdo de maneiras radicalmente diferentes. A conversão é, portanto, uma reconstrução e não uma cópia: fiel, mas não idêntica byte a byte. Atributos e nós de texto do XML viram ambos chaves, e essa é uma decisão que o conversor toma por você.
Os comentários não sobrevivem. XML permite anotar um arquivo e JSON não tem sintaxe para isso, então cada linha de explicação se perde — e isso atinge justamente os arquivos que se comentam: configuração que outra pessoa vai manter.
Esta página converte um no outro. Se a sua dúvida é escolher e não converter, XML vs JSON responde qual usar, para quê, e no que cada um é ruim.