Conversor XML ⇄ JSON
XML ↔ JSON bidireccional com gestão de atributos, preservação CDATA, BOM, fim de linha e controlo de indentação
Entrada
Saída
Conversor XML ⇄ JSON
XML ↔ JSON bidireccional com gestão de atributos, preservação CDATA, BOM, fim de linha e controlo de indentação
Recursos
- Modo de auto-detecção identifica se o texto colado é XML ou JSON e executa a conversão na direcção oposta — cole qualquer lado sem mudar o modo manualmente
- Duas estratégias de atributo: modo Prefixo emite atributos XML com um prefixo configurável (padrão `@`) como chaves JSON irmãs; modo Objecto recolhe-os num objecto `$` separado, para que texto de elemento e atributos nunca colidam
- Tratamento CDATA e nó de texto: com "Tratar CDATA/Texto como #text" ligado, o conteúdo textual do elemento é dobrado numa propriedade `#text`; o conteúdo misto sobrevive ao round-trip JSON; desligado preserva a distinção estrutural
- Alternância pretty-print com indentação seleccionável (2 / 4 / 8 espaços) para saída JSON e XML — ligado para leitura humana, desligado para transporte compacto
- Controlo de fim de linha (LF vs CRLF) para compatibilidade Unix vs Windows, mais alternância UTF-8 BOM opcional para sistemas que exigem a byte-order mark
- Prefixo de atributo configurável para corresponder às convenções a jusante: `@` (padrão), `_`, `xml:` ou qualquer outra string — mantém a saída convertida compatível directamente com o seu pipeline existente
- Copiar e Descarregar (`converted.txt`) num clique para a saída; erros de conversão surgem inline com a mensagem do parser subjacente — sabe se o XML estava malformado ou o JSON não era representável como XML
- Puramente do lado cliente: parsing via DOMParser para XML e JSON.parse para JSON. Sem chamadas de rede, funciona offline após cache da página
Como usar
- Cole o seu XML ou JSON no painel Entrada. Com Modo em Auto-detectar, o conversor identifica o formato automaticamente.
- Ajuste a alternância Pretty e o tamanho de Indentação para controlar a formatação; alterne Fim de linha entre LF e CRLF conforme as suas ferramentas a jusante exigirem.
- Abra Definições avançadas para escolher Modo de atributo (Prefixo ou Objecto), definir Prefixo de atributo e alternar CDATA/Texto-#text.
- Clique Converter. O painel Saída mostra o resultado; a conversão corre no seu navegador via DOMParser + JSON.parse.
- Use Copiar para a área de transferência, ou Descarregar para guardar como `converted.txt`.
- Se o parsing falhar, uma linha de erro inline mostra a mensagem subjacente — corrija a entrada e converta de novo.
Dicas e Melhores Práticas
- Ao depurar uma carga XML de um serviço SOAP, Auto-detecção + modo atributo Objecto + CDATA-#text dá a vista JSON mais limpa.
- Defina Fim de linha como CRLF e active o BOM ao gerar saída destinada a ferramentas Windows legacy.
- Mude o Prefixo de atributo de `@` para `_` se os seus consumidores JSON rejeitam chaves que começam por `@` (alguns parsers derivados de YAML fazem-no).
- Se a saída JSON-para-XML colocar elementos na ordem errada, reinsira as suas chaves de topo no JSON-fonte na ordem que quer emiti-las.
- Combine com JSON Formatter quando quiser inspeccionar ou transformar o JSON convertido; XML Formatter no lado XML.
Perguntas Frequentes
Como é que o Modo de atributo muda a saída JSON?
No modo Prefixo, atributos XML aparecem como chaves irmãs com o prefixo configurado — `<user id="42"/>` torna-se `{ "user": { "@id": "42" } }`. No modo Objecto, atributos são recolhidos sob uma única chave `$`, para que conteúdo de elemento e de atributo não partilhem namespace. Escolha Prefixo quando consumidores esperam chaves planas; Objecto quando precisar round-trip de atributos para XML sem ambiguidade.
Para que serve CDATA-como-#text?
XML tem duas formas de transportar texto — `<a>plain</a>` e `<a><![CDATA[plain]]></a>`. Com a opção ligada, ambas colapsam numa chave `#text` em JSON; conteúdo misto como `<p>Olá <b>mundo</b></p>` sobrevive ao round-trip. Desligado preserva a distinção estrutural; útil quando os marcadores CDATA originais são semanticamente significativos (ex. scripts embutidos).
Porque importa a alternância BOM?
Algumas ferramentas Windows (Excel, PowerShell antigo, .NET TextReader sem codificação explícita) esperam um BOM UTF-8 (`EF BB BF`) no início para detectar codificação. Ferramentas web modernas e pipelines Unix tratam o BOM como ruído normalmente. Active a alternância para ferramentas Windows conscientes de BOM, desactive para tudo o resto.
Porquê LF vs CRLF?
Ferramentas Windows e formatos Microsoft antigos esperam `\r\n` (CRLF); Unix/Linux/macOS usam `\n` (LF) por padrão. Git geralmente normaliza ambos, mas artefactos que contornam o git (descargas, colagens em Notepad, saídas de build) precisam da escolha explícita. O parser de Auto-detecção ignora fins de linha; este controlo afecta apenas a saída.
Os namespaces sobrevivem à conversão?
Nomes de elemento e atributo com prefixo de namespace round-trip como strings literais (ex. `xmlns:soap` torna-se a chave `@xmlns:soap`). O conversor não resolve namespaces contra URIs — se o seu pipeline a jusante precisar resolução de namespace, faça esse passo à parte. O round-trip para XML preserva os prefixos iniciais.
O que acontece a elementos vazios?
Um elemento XML vazio `<a/>` torna-se `{ "a": null }` em JSON (ou `{ "a": "" }` se era `<a></a>` com texto vazio e CDATA-#text ligado). Indo de JSON para XML, um valor `null` emite um elemento auto-fechado. O round-trip é estável desde que não alterne a definição CDATA-#text entre as duas direcções.
Porque é que a minha saída JSON-para-XML tem chaves ordenadas?
Elementos XML têm ordem definida; objectos JavaScript preservam ordem de inserção para chaves string, então o conversor escreve elementos pela ordem em que as chaves apareceram no JSON. Se o JSON veio de um round-trip JSON.parse, a ordem corresponde à fonte; construído programaticamente, controle a ordem inserindo chaves na sequência desejada.
É seguro converter documentos grandes neste separador?
Documentos de médio megabyte convertem bem abaixo de um segundo. Muito grandes (>10 MB) funcionam mas prendem o thread UI durante o parsing; para essa carga, corra a mesma lógica num Web Worker ou script de build. O serviço de conversão é o mesmo em ambos os contextos.