Conversor XML para JSON gratuito
Converta XML para JSON instantaneamente. Lida com atributos, elementos aninhados e nós de texto. Funciona inteiramente no seu navegador.
O que é XML?
XML (Extensible Markup Language) é um formato para armazenar e transportar dados. Usa tags personalizadas para descrever a estrutura dos dados, tornando-o legível por humanos e amplamente suportado. Ao contrário do JSON, o XML pode incluir atributos em elementos.
Por que converter XML para JSON?
- Tamanho de arquivo menor · JSON é mais compacto que XML.
- APIs da web · A maioria dos serviços web modernos usa JSON em vez de XML.
- Análise mais fácil · JSON mapeia diretamente para objetos JavaScript.
- Integração com sistemas legados · Converta dados XML antigos para o formato JSON moderno.
Perguntas frequentes
Como os atributos XML são tratados?
Os atributos XML são convertidos em propriedades JSON com prefixo «@». Por exemplo,
E quanto aos namespaces?
Os prefixos de namespace XML são mantidos nos nomes das chaves JSON. Declarações de namespace (xmlns) aparecerão como atributos regulares começando com «@xmlns» na saída.
Posso converter JSON de volta para XML?
Esta ferramenta converte apenas XML para JSON. Para a conversão reversa, experimente nosso conversor JSON para XML que inverte o processo usando a mesma convenção para atributos e nós de texto.
Dois formatos, três décadas de distância
O XML 1.0 tornou-se uma Recomendação do W3C em 10 de fevereiro de 1998. Os editores originais foram Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) e C. M. Sperberg-McQueen (Universidade de Illinois em Chicago); o Grupo de Trabalho foi presidido por Jon Bosak, da Sun Microsystems. A linhagem do XML remonta ao SGML (ISO 8879:1986), o padrão de marcação de documentos que, por sua vez, cresceu a partir do GML da IBM nos anos 1970. O SGML era poderoso, mas intimidador; o resumo de design do XML era «projetar uma versão 'lite' do SGML», reduzindo os recursos opcionais a um perfil que pudesse ser implementado em alguns milhares de linhas de código, preservando o Unicode, os namespaces e os documentos ricos em atributos.
O JSON (JavaScript Object Notation) foi descoberto, não projetado. Douglas Crockford e Chip Morningstar enviaram a primeira mensagem JSON em abril de 2001 na State Software, derivando o formato da sintaxe de objeto literal do JavaScript. Crockford registrou o json.org em 2002 e publicou uma especificação de uma página. O formato foi formalizado pela primeira vez como RFC 4627 em julho de 2006, reeditado como RFC 7159 em 2014, e estabilizado como RFC 8259 / STD 90 em dezembro de 2017, o mesmo ano em que a ECMA-International publicou a ECMA-404. A intenção de design do JSON (segundo a retrospectiva de Crockford): mínimo, independente de linguagem, fácil de gerar e analisar, sem número de versão («não há número de versão») e deliberadamente sem comentários («removi os comentários porque vi que as pessoas os usavam para guardar diretivas de análise»).
O JSON dominou as APIs da web no fim dos anos 2000, conforme o REST substituía o SOAP e o XMLHttpRequest cedia lugar ao JSON via fetch. Em 2015, o JSON era o formato de resposta padrão de quase toda API pública; o XML sobreviveu na SOA corporativa de cauda longa, em formatos de documento (Office Open XML, OpenDocument) e em nichos atrelados a padrões.
Onde XML e JSON divergem
| XML | JSON | |
|---|---|---|
| Atributos | Primeira classe (<item id="5"/>) | Sem atributos, tudo é um par chave/valor |
| Namespaces | Nativo (xmlns:prefix="uri") | Nomes planos; colisões de prefixo são problema do app |
| Comentários | <!-- … --> | Nenhum, conforme a spec |
| Conteúdo misto | Nativo (<p>text <b>and</b> markup</p>) | Estranho, precisa de arrays ou de conversão em string |
| Schema | DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron | JSON Schema (spec da comunidade, rascunho 2020-12) |
| Ordem | A ordem dos elementos é significativa conforme a spec | A ordem das chaves de objeto não é garantida (a maioria dos parsers preserva a ordem de inserção na prática); os arrays são ordenados |
| Números | Strings até serem tipadas por um schema | Double IEEE 754; nenhuma distinção inteiro/float no nível da spec |
| Verbosidade | Alta (cada valor envolvido em tags | Baixa) apenas pontuação |
Por que XML→JSON é fundamentalmente com perdas
Não existe um mapeamento canônico abençoado pelo W3C de XML para JSON. Todo conversor precisa inventar respostas a perguntas que o XML permite expressar, mas para as quais o JSON não tem vocabulário nativo. As decisões recorrentes:
- Atributos vs. elementos filhos: o XML permite expressar os mesmos dados das duas formas. O JSON tem apenas uma noção (chaves em um objeto), então o conversor precisa inventar um marcador. As convenções comuns: o BadgerFish usa
@para atributos e$para texto; o Parker descarta os atributos inteiramente (com perdas, mas simples); o JsonML representa os elementos como arrays com tags de tipo (preserva a ordem e a estrutura); o GData / Newtonsoft / xml2js usam um subobjeto@attributesmais uma chave#textquando necessário. Este conversor segue a convenção no estilo do GData: atributos sob@attributes, texto de conteúdo misto sob#text, e filhos repetidos viram arrays. - Elementos filhos repetidos: se o conversor criar cegamente uma chave por filho, o segundo filho sobrescreve o primeiro. Correção padrão: detectar a repetição e emitir um array. Mas isso significa que o formato do JSON depende dos dados, um
<book>produz uma string, dois produzem um array de strings. Alguns consumidores querem a forma de array mesmo para um item; alguns conversores expõem um botão «sempre array» para nomes de elemento específicos. - Conteúdo misto:
<p>Hello <b>world</b>!</p>mistura texto e elementos com ordem significativa. O JSON não consegue expressar nativamente esse entrelaçamento sem um array de tipos mistos ou uma chave sentinela#text. Muitos conversores descartam a prosa entre os elementos; os mais conservadores a dividem em várias entradas de nó de texto. - Namespaces:
<soap:Envelope xmlns:soap="…">tem tanto um prefixo quanto uma URI de vinculação. A maioria dos conversores preserva o prefixo como parte da chave JSON (soap:Envelope) e descarta a vinculação, o que é aceitável desde que o consumidor não precise resolver o namespace. - Comentários e instruções de processamento: normalmente descartados silenciosamente, já que o JSON não tem sintaxe de comentário.
- Seções CDATA: achatadas para strings simples; o invólucro
<![CDATA[…]]>é perdido. - Espaço em branco: o XML tem
xml:space="preserve"para o espaço em branco significativo; o JSON não tem equivalente. A maioria dos conversores remove os nós de texto compostos só por espaço em branco entre os elementos.
Quando você recorreria a isto
- Consumir serviços SOAP legados a partir de um frontend JS moderno. As respostas SOAP são XML; converter uma vez na fronteira deixa o resto do app trabalhar em JSON.
- Processamento de feeds RSS / Atom: ambos são formatos XML; os leitores de notícias e agregadores modernos geralmente querem JSON.
- Sitemaps XML (
sitemap.xml): converter para JSON os torna mais fáceis de inspecionar e processar programaticamente. - Dados OSM do OpenStreetMap: publicados como XML, frequentemente necessários como JSON para mapeamento do lado do cliente.
- Arquivos KML / GPX do Google Earth: formatos de dados geográficos que vêm em XML.
- Internos do Office Open XML:
.docx,.xlsxe.pptxsão arquivos XML compactados; se você extraiu um e quer inspecionar a sua estrutura como JSON, esta é a etapa de conversão. - Manipulação de SVG: o SVG é XML. Converter para JSON facilita percorrer e modificar a árvore em JavaScript antes de reserializar.
- POM do Maven, arquivos de build do Ant, configuração do Spring, recursos do Android, plists da Apple, dados financeiros XBRL, registros médicos HL7, MusicXML, documentos jurídicos NMX: formatos XML de cauda longa que muitas vezes precisam de JSON para as ferramentas a jusante.
Alternativas modernas
- APIs JSON nativas. Se o serviço upstream oferece uma variante JSON, use-a. Os serviços SOAP normalmente não oferecem, mas a maioria dos equivalentes modernos oferece.
- GraphQL. Uma linguagem de consulta que permite ao cliente solicitar exatamente o formato JSON de que precisa a partir de um schema tipado.
- Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Formatos de serialização binária com schemas e tamanhos de transmissão muito menores do que XML ou JSON. Comuns dentro de malhas de microsserviços; raramente usados na fronteira do navegador porque precisam de bibliotecas de decodificação explícitas.
- Fique no XML. Se os dados são genuinamente orientados a documento (conteúdo misto, estrutura tipada profunda, validação de schema que importa), o XML é a melhor opção. A força do JSON são os dados com formato de API; a fidelidade de documento não é a sua especialidade.
Mais perguntas
Por que o mesmo XML produz um formato JSON diferente em ferramentas diferentes?
Porque não existe um mapeamento canônico de XML→JSON. Cada conversor escolhe uma convenção (BadgerFish, Parker, JsonML, no estilo do GData) e os formatos JSON resultantes diferem em como os atributos são marcados, como o conteúdo misto é preservado e como os filhos repetidos são transformados em arrays. Fazer a ida e volta do XML por conversores diferentes produz JSONs diferentes; fazer a ida e volta do JSON de volta para XML por conversores diferentes pode mudar o posicionamento dos atributos e até a ordem dos elementos. Para a interoperabilidade, documente a convenção que você está usando e mantenha-se nela.
E quanto a CDATA, comentários e instruções de processamento?
As seções CDATA (<![CDATA[…]]>) são achatadas para conteúdo de string simples, o invólucro some, mas o texto interno é preservado verbatim. Os comentários XML (<!-- … -->) e as instruções de processamento (<?xml-stylesheet …?>) são descartados, já que o JSON não tem sintaxe para nenhum dos dois. Se você precisa de uma fidelidade de ida e volta que preserve os comentários, uma ida e volta só de XML é a abordagem certa.
Meu schema XML (XSD) sobrevive à conversão?
Não. O XSD descreve a estrutura e os tipos do XML; o JSON Schema é o padrão análogo (separado) para o JSON. Algumas ferramentas avançadas conseguem traduzir XSD para JSON Schema, mas é uma operação com perdas: o XSD tem recursos (conteúdo misto, grupos de substituição, tipos derivados) que não têm um equivalente limpo em JSON Schema. Para a validação de documentos que importa, rode o XSD contra o XML original, não contra a conversão para JSON.
Por que o JSON venceu nas APIs da web?
Algumas razões. O JSON mapeia diretamente para objetos JavaScript, então a análise no lado do navegador está a uma chamada JSON.parse() de distância. O formato é muito menor, sem tags de fechamento, sem declarações de namespace, sem o peso de schemas. O REST substituiu o SOAP na maioria das APIs públicas no fim dos anos 2000, e o JSON era a carga natural para o REST. As forças do XML (schemas estritos, namespaces, conteúdo misto) importam para documentos e sistemas corporativos legados, mas raramente para «me dê o objeto do usuário». A web otimizou para o caso mais simples.
Algo é enviado a um servidor?
Não. O XML é analisado pelo DOMParser nativo do navegador, depois percorrido recursivamente em JavaScript para construir a saída JSON. O XML colado nunca sai da página. A ferramenta funciona offline depois de carregada, o que importa quando o XML de origem contém endpoints internos de API, dados de clientes ou schemas proprietários que você prefere não enviar para lugar nenhum.