JSON, YAML, XML, CSV — round-tripping com um único toolbox

Se você é um developer em 2026, provavelmente abriu 30 abas de navegador este mês com nomes como “json to yaml online” ou “csv to xml converter free”. Todo projeto, todo pipeline de CI, todo data drop entre times precisa de pelo menos um hop formato-para-formato: o time de analytics exporta CSV, o time de plataforma espera YAML, a integração de parceiro roda em XML, e você fica grudando com scripts Python avulsos que funcionam ótimo até o nome de alguém conter uma vírgula e um emoji unicode.

Este guia explica os quatro formatos canônicos de intercâmbio de dados que todo developer backend precisa ler e escrever fluentemente, por que cada um existe e como usar o toolbox de developer do Ai2Done para fazer round-trip entre eles com segurança — incluindo o JSON formatter, XML formatter, YAML formatter e conversores como CSV para Excel, XML para JSON e XML para CSV — todos rodando 100 % no seu navegador.

TL;DR

• JSON é o default moderno — use a menos que tenha razão para não usar.
• YAML é JSON com comentários e menos pontuação — use para arquivos de config que humanos vão ler e editar.
• XML é o formato que suas integrações enterprise ainda exigem — use quando o outro lado não vai ceder.
• CSV é o formato que stakeholders de negócio de fato vão abrir — use para analytics, exports e qualquer coisa destinada ao Excel.
• Round-tripping (JSON → YAML → JSON) é quase sempre sem perdas. CSV ↔ JSON não é sem perdas quando seu JSON tem estruturas aninhadas — achate ou desnormalize deliberadamente.

Por que isso é mais difícil do que parece

Um engenheiro ingênuo pensa “conversão de formato de dados é só JSON.parse e JSON.stringify com sintaxe diferente”. Na prática todo formato tem armadilhas sutis que mordem em uso real de produção:

JSON não tem comentários, sem vírgulas finais, sem undefined, sem tipo Date, sem Map e sem BigInt. Números acima de 2^53 silenciosamente perdem precisão em JavaScript. Strings devem ser UTF-8 (sem quebras de linha \r\n sem escape). Um número surpreendente de arquivos “JSON” escritos por Java ou .NET não são exatamente JSON válido porque vêm como JSON-com-comentários ou JSON-com-vírgulas-finais.

YAML é notoriamente sobre-flexível — a spec tem 80 páginas, o shorthand booleano yes/no/on/off silenciosamente parseia o código de país da Noruega “NO” como false e erros de indentação produzem parses descontroladamente diferentes entre libs. Um documento YAML que carrega corretamente em Ruby pode carregar diferente em Python ou Go por causa de diferenças YAML 1.1 vs. YAML 1.2 vs. estilo custom.

XML é verboso mas inequívoco. Sua real complicação são namespaces (a bobagem do prefixo xmlns:) e atributos vs. elementos filhos — diferentes writers XML representam os mesmos dados lógicos de jeitos completamente diferentes. Há também a escolha de CDATA vs. escape de entidade para caracteres especiais, que pode quebrar consumidores esperando um ou outro.

CSV é o pior de todos porque não há spec real. Ferramentas diferentes usam regras diferentes de quoting, caracteres diferentes de escape e tratamento diferente de quebras de linha dentro de células. Microsoft Excel escreve “CSV” que abre incorretamente no Google Sheets e vice-versa. Mismatches de encoding UTF-8 vs. Windows-1252 transformam “Pokémon” em “Pokémon” em mais ou menos 30 % dos exports CSV do mundo real.

Um bom conversor de formato faz duas coisas não óbvias: (1) tolera entrada não estrita de ferramentas do mundo real e (2) emite saída estrita que ferramentas downstream vão aceitar confiavelmente. A maioria dos conversores online não faz nenhuma das duas.

Método 1: ferramentas de formato do Ai2Done (no navegador)

O hub de formatos do Ai2Done tem ferramentas individuais para cada formato mais vários pares de conversão. O fluxo para qualquer conversão:

1. Abra a ferramenta — ex.: JSON Formatter ou XML para JSON.
2. Cole sua entrada (ou solte um arquivo) no painel esquerdo.
3. A saída aparece instantaneamente no painel direito — formatação e conversão acontecem conforme você digita, localmente no seu navegador.
4. Copie ou baixe o resultado. Para arquivos, a ferramenta produz um único documento de saída ou um ZIP se a entrada continha múltiplos documentos.

Fluxos comuns que nossos usuários encontram:

• JSON → YAML: abra JSON formatter, cole JSON, a saída YAML aparece no painel “Converter para”. Reverta com YAML formatter.
• CSV → JSON: cole CSV, a ferramenta detecta delimitador (vírgula, tab, ponto e vírgula, pipe) e aspas automaticamente. Primeira linha tratada como headers a menos que você desmarque.
• XML → JSON: cole XML, a ferramenta lida com namespaces prefixando chaves com o alias de namespace. Atributos viram chaves @attr, conteúdo de texto vira #text.
• XML → CSV: com a ferramenta XML para CSV, achata elementos repetidos em linhas (você escolhe qual tipo de elemento é o limite de “linha”).
• CSV → Excel: com CSV para Excel, a ferramenta produz um .xlsx real (não um CSV renomeado), respeitando encoding UTF-8 para que chinês, japonês e emoji façam round-trip corretamente.

Tudo roda no seu navegador. Parsing JSON, YAML e XML usa libs testadas em batalha (ajv para validação JSON Schema, js-yaml para YAML, fast-xml-parser para XML) compiladas num único bundle de ~150 KB.

Método 2: jq + yq + xmlstarlet na linha de comando

Para developers que vivem no terminal, a stack canônica é:

# JSON
cat data.json | jq '.'

# YAML
cat data.yaml | yq '.'                   # yq Go do mikefarah
yq -o=json '.' data.yaml > data.json     # YAML → JSON

# XML
xmlstarlet sel -t -c '/' data.xml         # pretty-print

# CSV → JSON
csvkit:  csvjson data.csv > data.json
mlr (Miller): mlr --c2j cat data.csv

As vantagens: scriptável, componível em pipelines, sem aba de navegador necessária. As desvantagens: cada ferramenta tem o próprio DSL para aprender, nenhuma lida com todos os quatro formatos e você acaba escrevendo um pequeno Makefile ou justfile de conversões avulsas por projeto.

Esta é a escolha certa quando você tem conversão repetida e automatizada (um cron job noturno que puxa um CSV de um servidor FTP e empurra JSON para uma API). É overkill para uma tarefa “preciso desse CSV como JSON para colar no Postman” numa terça à tarde.

Método 3: Pandas (quando os dados são o ponto)

Se sua tarefa de conversão é na verdade uma tarefa de transformação de dados disfarçada de conversão de formato — pivotar as linhas, descartar colunas, filtrar, deduplicar, depois sair — pegue pandas:

import pandas as pd
df = pd.read_csv('input.csv')
df = df[df['status'] == 'active']
df = df.drop_duplicates(subset='email')
df.to_json('output.json', orient='records', force_ascii=False)

Pandas lê/escreve CSV, Excel, JSON, Parquet, SQL e dúzia de outros. É a resposta certa quando seu CSV tem 500 K linhas e você precisa fazer algo analítico antes de escrever a saída. Para um arquivo de dados de 50 linhas que você queria convertido em 5 segundos, é massivo overkill — pip install pandas sozinho leva 30 segundos.

Como construímos as ferramentas de formato (deep-dive técnico)

O toolbox de formatos do Ai2Done é construído em torno de uma representação intermediária canônica compartilhada — uma vez que qualquer entrada é parseada (JSON, YAML, XML, CSV), vira uma árvore de objeto JavaScript pura. Todas as conversões então viram “serialize a árvore para o formato X”. Isso significa que só precisamos de N parsers e N serializers, não N² conversores.

Os desafios de engenharia interessantes:

• O problema de atributos vs. filhos do XML. Usamos o prefixo convencional @attr para atributos e #text para conteúdo de texto, depois oferecemos um “modo round-tripping” na UI que preserva isso sem perdas. Você pode converter XML → JSON → XML e ganhar o mesmo XML de volta (módulo espaços em branco).
• Inferência de header CSV. Cheiramos as primeiras 5 linhas: se a linha 1 tem todos valores de texto e a linha 2+ tem valores numéricos, a linha 1 é headers. Se não estiver claro, perguntamos. Isso pega ~95 % dos arquivos CSV reais corretamente sem configuração.
• Segurança YAML. Usamos o safeLoad do js-yaml para evitar o infame exploit YAML 1.1 !!python/object de execução de código que assombrou a lib YAML do Ruby por anos. Nenhum YAML provido pelo usuário pode executar código no seu navegador.
• BigInt e números de alta precisão. Parsers JSON em JavaScript silenciosamente perdem precisão para inteiros acima de Number.MAX_SAFE_INTEGER. Nosso parser detecta esses (inteiros de 15+ dígitos, notação científica além de 17 sig figs) e oferece preservá-los como strings com um marcador "_bigint:..." — opt-in, porque a maioria dos usuários não liga.
• Tratamento de UTF-8 BOM. O “CSV com BOM” exportado por Excel que quebra 30 % dos conversores online funciona bem aqui — detectamos e tiramos o byte-order mark na entrada, opcionalmente re-adicionamos na saída se você ativa “compatibilidade Excel”.

Tudo é compilado num único bundle JS ~400 KB gzipped que carrega na primeira visita. Depois disso, todas as conversões são instantâneas (sub-milissegundo para arquivos abaixo de uns poucos MB).

FAQ

Q: Por que perco dados ao converter JSON aninhado para CSV? A: CSV é fundamentalmente uma tabela 2D. JSON aninhado ({a: {b: {c: 1}}}) não tem representação nativa em CSV. Nossa ferramenta oferece duas estratégias: flatten (produz colunas como a.b.c) ou explode (uma linha por leaf — geralmente não é o que você quer). Escolha deliberadamente; não há resposta “certa”.

Q: Meu CSV tem vírgulas dentro de células. O conversor vai aguentar? A: Sim — seguimos RFC 4180. Células com vírgulas, quebras de linha ou aspas duplas são auto-quotadas com "..." e quaisquer aspas internas são duplicadas para "". Isso casa com Excel, Google Sheets e o módulo csv do Python.

Q: Posso validar JSON contra um JSON Schema no navegador? A: Sim, o JSON Formatter tem uma aba Schema onde você cola um schema e ganha erros de validação inline. Usamos ajv por baixo dos panos (o validador JSON Schema mais rápido em JavaScript).

Q: Meu XML tem namespaces. O JSON convertido vai manter? A: Sim — elementos prefixados por namespace viram chaves JSON como "ns:elementName". As declarações de namespace mudam para uma chave @xmlns na raiz. Reverter a conversão produz XML equivalente (embora potencialmente com formatação diferente).

Q: Qual a diferença entre YAML 1.1 e YAML 1.2 no seu parser? A: Fazemos default para YAML 1.2 (que conserta o problema da Noruega — NO é a string “NO”, não o booleano false). Você pode mudar para modo YAML 1.1 para compatibilidade com configs Ruby ou Symfony antigos que dependem do shorthand booleano legado.

Q: Posso converter em lote 100 arquivos CSV para JSON de uma vez? A: Sim — solte todos os 100 arquivos na ferramenta, clique em Converter, ganhe um ZIP de volta. Cada arquivo é processado no próprio Web Worker para que uma máquina multicore os processe em paralelo.

Experimente agora

Escolha a conversão que você precisa:

• JSON Formatter — valide, embeleze, minifique
• XML para JSON — preserva namespaces e atributos
• XML para CSV — achate elementos repetidos em linhas
• CSV para Excel — produza .xlsx real, não CSV renomeado
• YAML Formatter — valide arquivos de config
• Cron Parser — explique 0 */6 * * 1-5 em português simples

Navegue pelo toolbox de developer completo.

Leituras relacionadas

• Decoder de JSON Web Token que nunca manda seu token — mesma arquitetura, aplicada a JWTs
• Parser de expressão cron explicado para não-DevOps — para a camada de agendamento
• Overview de todas as ferramentas Ai2Done
• Navegue pelo hub de ferramentas de formato ou hub de ferramentas de developer

Última atualização 2026-06-14. Todas as ferramentas de conversão de formato rodam 100 % no seu navegador — seus dados nunca deixam seu dispositivo. Nunca coletamos, logamos ou analisamos o conteúdo que você processa.