Conversor de JSON para XML

JSON e XML, dois formatos, duas eras

XML (Extensible Markup Language) foi padronizado pela W3C como Recomendação a 10 de Fevereiro de 1998, a spec W3C XML 1.0, editada por Tim Bray, Jean Paoli e C.M. Sperberg-McQueen. O XML surgiu do SGML (a mais antiga «Standard Generalised Markup Language», ISO 8879:1986) eliminando as funcionalidades mais complexas e produzindo algo que a web podia realisticamente usar. Durante aproximadamente a primeira década do século XXI, o XML foi o formato presumido para qualquer troca de dados estruturados, serviços web SOAP, feeds RSS (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), formatos Open XML do Microsoft Office (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), layouts XML do Android, ficheiros de propriedades Java, configuração em quase todos os frameworks de servidor. Os pontos fortes do XML são os espaços de nomes, atributos, conteúdo misto (texto e elementos filho intercalados) e um rico ecossistema de esquemas (DTD, XML Schema 1.1, Relax NG). A sua fraqueza é a verbosidade, cada valor leva uma etiqueta de abertura e fecho.

JSON (JavaScript Object Notation) foi especificado por Douglas Crockford em 2001, o site json.org e o seu ensaio original «JSON: The Fat-Free Alternative to XML». O JSON é intencionalmente um subconjunto da sintaxe literal de objectos do JavaScript: objectos, arrays, strings, números, true/false/null. Padronizado como RFC 4627 em Julho de 2006, refinado como RFC 7159 (Março de 2014) e RFC 8259 (Dezembro de 2017, norma STD 90 actual, também publicada pela ECMA como ECMA-404). A tomada por JSON das APIs web ao XML aconteceu aproximadamente em 2008-2014, o calendário coincide com a ascensão das single-page apps e da era das APIs móveis. Hoje quase toda API pública se documenta como JSON; o XML sobrevive principalmente em integração empresarial, formatos de documento, ficheiros de configuração e formatos de feed. Os dois formatos continuam em uso activo porque codificam bem coisas diferentes: o JSON é adequado para dados estruturados com tipos simples e forma previsível; o XML é adequado para documentos com conteúdo misto, atributos, espaços de nomes e esquemas rigorosos.

Quando precisa realmente de converter JSON para XML

• Chamar um serviço web SOAP a partir de um cliente apenas-JSON. O SOAP é XML por design (o envelope SOAP, a descrição de serviço WSDL, os esquemas XSD). Se tem dados em forma JSON e precisa construir um corpo de pedido SOAP, JSON-para-XML é a ponte. Comum em integração empresarial quando microsserviços modernos precisam falar com endpoints SOAP legacy (banca, governo, seguros, sistemas de troca de saúde).
• Gerar documentos Office Open XML a partir de dados JSON. Os formatos .docx, .xlsx e .pptx são arquivos ZIP de ficheiros XML. Para gerar ou modificar programaticamente documentos Office a partir de dados suportados por JSON, a conversão JSON-para-XML acontece na fronteira entre a camada de dados da sua aplicação e a biblioteca de geração de documentos.
• Produzir um feed RSS ou Atom a partir de conteúdo JSON. Blogues, sites de notícias e plataformas de podcast emitem feeds RSS/Atom para sindicação. Se o seu CMS guarda os artigos como JSON, o passo de geração de feed converte as entradas JSON no formato XML que o ecossistema de leitores de feed espera.
• Gerar ficheiros de configuração XML para aplicações legacy. Muitas aplicações empresariais mais antigas (servidores de aplicação Java, ficheiros de configuração .NET, contexto de aplicação Spring XML) consomem a sua configuração como XML. O tooling moderno de infrastructure-as-code costuma trabalhar em YAML ou JSON, por isso uma conversão JSON-para-XML fica no pipeline de implantação.
• Alimentar uma transformação XSLT. XSLT (XSL Transformations, especificação de Michael Kay, Recomendação W3C) é a linguagem padrão de transformação XML e consome entrada XML. Se os seus dados começam em JSON e o seu motor de relatório é baseado em XSLT, a conversão acontece na fronteira de entrada.
• Gerar ficheiros de recursos Android. Os strings.xml, colors.xml, dimens.xml e ficheiros de layout do Android são XML. As pipelines de localização que guardam strings em JSON para facilidade de edição convertem para XML na altura do build.

O mapeamento de conversão, onde a informação sobrevive e onde se perde

JSON e XML têm primitivas estruturais diferentes, por isso qualquer conversão tem de fazer escolhas. O mapeamento JSON-para-XML padrão que a maioria dos conversores (este incluído) seguem:

• Os objectos JSON tornam-se elementos XML. Cada chave torna-se um elemento filho com a chave como nome de etiqueta. {"name": "Alice"} torna-se <name>Alice</name>.
• Os arrays JSON tornam-se elementos filho repetidos. {"items": [1, 2, 3]} torna-se três filhos <item>1</item><item>2</item><item>3</item> dentro do invólucro <items>. (Diferentes conversores usam diferentes convenções para o nome do elemento de array; alguns usam o nome do pai no singular, outros usam um <item> fixo.)
• Strings, números, booleanos tornam-se conteúdo textual do elemento. A informação de tipo não é preservada, o XML trata todo o texto como dados de carácter, por isso uma viagem de ida e volta XML → parse → serializar de volta para JSON emitiria os números como strings entre aspas a menos que o consumidor aplique inferência de tipos.
• null torna-se um elemento vazio auto-encerrante. {"middle_name": null} torna-se <middle_name/>. Alguns conversores usam xsi:nil="true" em vez disso.
• O elemento raiz envolve tudo. O JSON permite um array ou escalar de nível superior; o XML exige exactamente um elemento raiz. O invólucro <root> (configurável aqui) é a solução convencional.

Informação perdida na conversão: a distinção do JSON entre números e strings, a distinção do JSON entre true/false e strings «true»/«false», a distinção array vs objecto do JSON (quando um array se torna elementos repetidos não consegue dizer só pelo XML se a fonte tinha um array de um elemento ou um valor único). Informação potencialmente ganha mas não usada por conversores simples: atributos XML (um objecto JSON podia mapear chaves para atributos em vez de elementos filho), espaços de nomes XML (o JSON não tem nada equivalente), secções CDATA (para incorporar texto com caracteres especiais XML). Para uma conversão JSON-para-XML segura para ida e volta que preserve a informação de tipo, a convenção BadgerFish ou a convenção Parker codificam os tipos JSON como atributos XML com espaços de nomes, esta ferramenta produz a forma mais simples e legível em vez da forma segura para ida e volta.

As restrições de nome de etiqueta XML que as chaves JSON não têm

As chaves de objecto JSON são strings arbitrárias, qualquer Unicode é permitido. Os nomes de elementos XML são muito mais restritos: têm de começar por uma letra ou underscore (não um dígito, hífen ou ponto), podem conter letras, dígitos, hífenes, underscores e pontos (sem espaços, sem a maior parte da pontuação), são sensíveis a maiúsculas/minúsculas, e não podem começar com o prefixo reservado xml em qualquer combinação de capitalização. As chaves JSON com espaços ("first name": "Alice"), chaves a começar por dígitos ("3rd_choice"), ou chaves com caracteres especiais ("@type", "$value") não podem ser usadas directamente como nomes de elementos XML. A maioria dos conversores (este incluído) destorce silenciosamente os caracteres inválidos, substitui espaços por underscores, antepõe um underscore a chaves a começar por dígitos, descarta a maior parte da pontuação. Esteja consciente disso ao fazer ida e volta: um documento JSON com chaves não-seguras-para-XML não fará uma viagem de ida e volta identicamente através de XML.

Onde o XML ainda reina em 2026

O XML não está em recuo em 2026, apenas se acomodou em nichos específicos. Formatos de documento: Office Open XML (Microsoft Office), OpenDocument (LibreOffice), ebooks EPUB, SVG (Recomendação W3C 4 de Setembro de 2001), MathML, XHTML. Configuração: servidores de aplicação Java, contextos Spring XML, POMs do Maven, recursos XML do Android, ficheiros app.config e web.config do .NET. Feeds: RSS 2.0, Atom 1.0 (RFC 4287), feeds de podcast (as extensões RSS do iTunes). Troca em saúde e governo: HL7 v3, FHIR (que agora oferece JSON como alternativa mas a forma XML continua em uso intensivo), DocBook, NewsML, ISO 20022 bancário. Organismos de normas: quase todo exemplo de especificação IETF e W3C usa XML. A verbosidade do XML é uma funcionalidade nesses domínios: é auto-descritivo, validar contra um esquema está bem estabelecido, e as transformações XSLT entre dialectos XML são uma caixa de ferramentas madura. O formato não vai a lado nenhum; a conversão JSON-para-XML é a ponte entre o tooling de dados moderno e estes sistemas XML-nativos estabelecidos.

Privacidade: conversão apenas no navegador

O JSON colado num conversor contém frequentemente dados de produção reais, respostas de API com identificadores de utilizador, IDs internos de entidade que revelam taxonomia de negócio, valores de configuração que incluem URLs de endpoints e feature flags, tokens, conteúdo rascunho ainda não publicado. Os conversores do lado do servidor levam uma cópia de cada entrada para os seus logs. Este conversor faz parsing do seu JSON com o JSON.parse() incorporado do navegador, percorre a árvore de objectos resultante em JavaScript, e emite XML como string, tudo dentro do seu separador de navegador. Verifique no separador Rede das DevTools enquanto clica em Convert (não dispara nenhum pedido), ou ponha a página offline (modo de avião) após o carregamento e o conversor continua a funcionar. Seguro para respostas de API de produção, configuração interna, conteúdo rascunho, ou qualquer JSON que não queira ver copiado para o disco rígido de um estranho.

Perguntas frequentes

Como os arrays JSON são convertidos ?

Cada elemento do array torna-se um elemento filho separado. {"colors": ["red", "blue"]} torna-se <colors><item>red</item><item>blue</item></colors>. O nome de elemento convencional para entradas de array sem nome é <item>. Se o seu consumidor a jusante espera uma convenção diferente (p. ex., forma singular do nome do pai como <color>), terá de pós-processar o XML ou usar um conversor diferente que suporte a nomeação personalizada de elementos de array.

Funciona com ficheiros JSON grandes?

Sim, como tudo corre no seu navegador, o tecto prático é a memória disponível do seu dispositivo. Dezenas de milhares de linhas de JSON convertem-se em muito menos de um segundo num portátil moderno. Entradas muito grandes (multi-MB) podem congelar brevemente o separador enquanto o parser percorre a árvore. Para conversão em lote de grandes datasets, um script usando um conversor do lado do servidor (xml2js no Node, dicttoxml em Python) é mais apropriado.

O meu JSON é carregado para um servidor?

Não. A conversão corre inteiramente no seu navegador, o JSON colado nunca sai do seu dispositivo. Verifique no separador Rede das DevTools enquanto clica em Convert (não dispara nenhum pedido), ou ponha a página offline (modo de avião) após o carregamento. Seguro para respostas de API de produção, configuração interna, ou qualquer dado que não queira partilhar externamente.

Posso fazer com que algumas chaves JSON se tornem atributos XML em vez de elementos filho?

Este conversor emite todas as chaves JSON como elementos filho, não como atributos. A convenção que alguns conversores usam (chaves com prefixo @ tornam-se atributos ("@id": 5 → id="5" no pai)) é a convenção BadgerFish. Se o seu consumidor a jusante exige determinados valores como atributos, vai precisar de um conversor personalizado que entenda a convenção, ou editar à mão o XML resultante.

O que acontece com chaves JSON que contêm espaços ou caracteres XML inválidos?

Os nomes de elementos XML têm regras mais estritas que as chaves JSON: têm de começar por uma letra ou underscore, não podem conter espaços, e proíbem a maior parte da pontuação. Chaves com caracteres inválidos são higienizadas, espaços tornam-se underscores, dígitos iniciais recebem um prefixo de underscore, caracteres especiais são descartados. Isto significa que uma viagem de ida e volta JSON → XML → JSON pode não produzir os nomes de chaves originais exactamente. Se os seus dados têm chaves invulgares, inspeccione a saída para garantir que a destorção não partiu nada importante.

Ferramentas relacionadas