Converter JSON para XML

Um documento XML tem um único elemento mais externo. Um documento JSON pode ser um objeto com quinze chaves, um array ou um número solto, e nenhum deles vem com um nome para o contêiner. Então a conversão tem uma regra: um objeto com exatamente uma chave usa essa chave como raiz, e tudo mais é envolvido num elemento chamado root.

A exceção é a que pega o formato mais comum de todos: se essa única chave guardar um array, {"items": [1, 2]}, usá-la como raiz escreveria <items> duas vezes e produziria um documento sem elemento mais externo — então <root> envolve a repetição.

XML não tem tipo array e nunca precisou: uma lista é a mesma tag escrita várias vezes no mesmo pai. Um objeto guardando três tags produz três elementos <tags> em sequência.

É o único lugar onde XML se encaixa melhor no JSON do que os formatos tabulares. Converter o mesmo array para CSV força uma escolha entre colunas extras, uma string juntada ou linhas extras — em XML a repetição é nativa.

XML tem duas formas de anexar um valor a um elemento — um atributo dentro da tag ou um elemento filho — e schemas se importam bastante com qual. JSON tem uma só. A convenção aqui faz a ponte: uma chave começando com @ é escrita como atributo, e uma chave chamada #text fornece o texto do próprio elemento.

Essa convenção não é arbitrária; é o que o leitor de XML deste site produz na direção oposta. Um documento convertido para JSON, editado e convertido de volta devolve os atributos como atributos.

Chaves JSON podem ser qualquer string: espaços, barras, emoji, um dígito no começo. Nomes de elemento XML não podem. O escritor reescreve em vez de falhar, contra uma lista deliberadamente estreita — A-Z, a-z, 0-9, sublinhado, ponto e hífen sobrevivem, o resto vira sublinhado.

A lista é mais estreita que a própria regra do XML 1.0, e esse é o caso mais provável de pegar você: XML permite letras acentuadas, então uma chave chamada "café" chega como <caf_> e "nome" em outro alfabeto chega como <__>. Renomeie essas chaves no JSON antes de converter.

XML traz namespaces, schemas XSD, DTDs, instruções de processamento, seções CDATA e assinaturas digitais — o registro deste site lista suporte a assinatura como uma característica do formato, e é o motivo dele continuar sendo a espinha dorsal de câmbio bancário e governamental.

O que isso significa na prática: a saída é um documento bem formado, não um válido. Se o receptor valida contra um XSD, espere adicionar uma declaração de namespace no elemento raiz e possivelmente reordenar elementos.

E comercial, colchetes angulares e aspas duplas num valor são escapados na saída, o que impede uma descrição de produto contendo "Isso é <especial> & único" de encerrar o documento cedo. Tudo mais, incluindo apóstrofos, é escrito como UTF-8.

Um null do JSON vira um elemento vazio: a tag está presente sem nada entre a abertura e o fechamento. XML também tem xsi:nil para exatamente isso, e alguns schemas exigem essa forma.

O documento é escrito com indentação de dois espaços e um elemento por linha, o que torna legível e torna um diff entre dois payloads compreensível. Não começa com a linha <?xml version="1.0"?>. XML 1.0 torna a declaração opcional e define UTF-8 como padrão.

Vários receptores mais antigos discordam disso, e alguns falham com mensagem pouco clara quando a linha falta. É uma linha para adicionar no topo — vale saber antes da primeira submissão.

Todo valor fica envolvido numa tag de abertura e outra de fechamento, então os nomes de campo aparecem duas vezes por registro em vez de uma. Para um payload de valores pequenos com nomes de campo longos, o documento pode ficar de duas a três vezes o tamanho do JSON de origem.

Isso é um custo real numa fila com limite de tamanho de mensagem e nenhum custo numa transferência de arquivo, que é para onde a maioria dessas entregas vai. Onde importa, a resposta é compressão — XML é texto altamente repetitivo e comprime muito bem com gzip.

Duas checagens, em ordem. Boa formação primeiro: qualquer editor de XML, navegador ou parser de linha de comando diz em um segundo se o documento é interpretável, e isso deve sempre passar aqui.

Validação contra o schema em segundo, e espere que falhe na primeira vez. As falhas são informativas — um namespace faltando, um elemento na ordem errada — e cada uma é um pequeno ajuste no JSON ou na saída.

A conversão é JavaScript nesta aba: o navegador interpreta o JSON, um pequeno escritor produz o XML, e nenhuma requisição carrega o documento a lugar nenhum. Não há cadastro, fila nem limite diário, e o nível gratuito aceita até 100 MB.

Para esse público isso costuma ser o fator decisivo em vez de um detalhe. Os payloads que precisam virar XML são pagamentos, sinistros, declarações fiscais e registros de cliente — exatamente as categorias onde colar um arquivo num serviço web desconhecido é motivo de preocupação com LGPD.