Qual o formato mais usado hoje?

JSON na web, sem dúvidas, é o formato dominante em APIs REST e em configuração frontend. YAML domina em DevOps e infraestrutura, sobretudo em pipelines de CI e definições de containers. XML mantém-se em ambientes empresariais e em formatos com estrutura documental complexa. TOML cresceu muito no ecossistema de ferramentas de desenvolvimento. CSV continua a ser o padrão para dados tabulares.

Posso converter entre formatos?

Sim, na maior parte dos casos. JSON, YAML e TOML têm modelos de dados próximos e a conversão entre eles é quase directa. XML é mais complexo por causa de atributos e conteúdo misto, mas há mapeamentos comuns. CSV só representa tabelas, portanto a conversão para hierárquico ou de hierárquico para CSV exige decisões sobre como aplanar a estrutura.

Porque é que YAML é tão problemático?

Tem uma especificação maior do que aparenta. Algumas palavras-chave ("yes", "no", "on", "off") são interpretadas como booleanos, números com zeros à esquerda podem ser lidos como octal, e a indentação por espaços ou tabs causa erros silenciosos. As versões mais recentes (YAML 1.2) resolveram alguns destes pontos, mas é preciso estar atento ao modo estrito do parser.

JSON5 e JSONC resolvem a falta de comentários do JSON?

Sim, são variantes do JSON que adicionam comentários e alguma flexibilidade extra (vírgulas pendentes, chaves sem aspas). Não são standards universais, mas são suportados em ambientes específicos como editores de código. Para troca entre sistemas, mantém JSON puro para garantir compatibilidade.

Quando devo escolher TOML em vez de YAML?

TOML é melhor quando queres uma sintaxe limpa para configuração mas sem as armadilhas da indentação significativa. Para ficheiros de configuração de projecto com estrutura média, TOML costuma ser menos propenso a erros. YAML é melhor para estruturas muito profundas ou quando precisas de referências internas e funcionalidades avançadas.

Comparação de Formatos de Dados. JSON, YAML, XML, TOML, INI, CSV

Tabela comparativa

Formato	Comentários	Verbosidade	Tipos	Leitura humana	Caso típico
JSON .json	Não	Média	Básicos	Média	APIs web, configuração frontend
YAML .yaml / .yml	Sim	Baixa	Básicos	Alta	Configuração de CI/CD, infraestrutura como código
XML .xml	Sim	Alta	Só texto	Baixa	Sistemas empresariais, documentos, SOAP
TOML .toml	Sim	Média	Rico	Alta	Configuração de aplicações, ferramentas de desenvolvimento
INI .ini / .conf	Sim	Baixa	Só texto	Alta	Configuração simples, ficheiros legados
CSV .csv	Não	Baixa	Tabular	Média	Folhas de cálculo, exportação de dados tabulares

Detalhes por formato

JSON.json

JavaScript Object Notation

Formato derivado da sintaxe de objectos JavaScript. Tornou-se a língua franca de troca de dados na web pela simplicidade e por ser nativamente compreendido por qualquer linguagem moderna.

Exemplo

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": false,
    "tags": ["web", "api"]
  }
}

Prós

+Suportado nativamente por praticamente todas as linguagens
+Sintaxe simples e previsível
+Parse rápido e barato
+Estrutura hierárquica clara

Contras

−Não permite comentários, o que limita a sua utilidade em ficheiros de configuração editados à mão
−Pouco tolerante a erros de sintaxe (vírgula a mais e o parse falha)
−Verboso para configuração longa devido a aspas e chavetas obrigatórias

Quando usar

Respostas e pedidos de APIs REST, armazenamento de dados estruturados, comunicação entre serviços. Sempre que a leitura humana é secundária à interoperabilidade.

YAML.yaml / .yml

YAML Ain't Markup Language

Formato pensado para legibilidade humana, com sintaxe baseada em indentação em vez de chavetas. É um superconjunto do JSON.

Exemplo

server:
  host: localhost
  port: 8080
  debug: false
  tags:
    - web
    - api

Prós

+Muito legível, sem ruído visual de chavetas e aspas
+Suporta comentários e referências internas
+Excelente para ficheiros editados manualmente
+Estruturas complexas com pouca sintaxe

Contras

−Indentação significativa é fonte comum de bugs (tabs vs espaços)
−Especificação grande, com casos extremos surpreendentes ("yes" e "no" interpretados como booleanos)
−Parsing mais lento e dependente de bibliotecas externas em algumas linguagens

Quando usar

Pipelines de CI/CD, definições de containers, configuração de orquestradores e qualquer ficheiro de configuração extenso que beneficie de comentários e estrutura clara.

XML.xml

Extensible Markup Language

Formato baseado em tags com raízes em SGML. Foi durante anos o padrão para troca de dados estruturados antes de o JSON se popularizar.

Exemplo

<server>
  <host>localhost</host>
  <port>8080</port>
  <debug>false</debug>
  <tags>
    <tag>web</tag>
    <tag>api</tag>
  </tags>
</server>

Prós

+Esquemas formais maduros (XSD, DTD) para validação rigorosa
+Suporte robusto a metadados via atributos e namespaces
+Ecossistema poderoso de transformações com XSLT e consultas com XPath
+Ideal para documentos com conteúdo misto (texto e estrutura)

Contras

−Muito verboso, tags de abertura e fecho duplicam o volume
−Distinção entre atributos e elementos é arbitrária e divide opiniões
−Mais difícil de ler e escrever à mão do que alternativas modernas

Quando usar

Integrações com sistemas legados ou empresariais, documentos com estrutura complexa, formatos onde a validação rigorosa por esquema é obrigatória (facturação electrónica, ficheiros de escritório).

TOML.toml

Tom's Obvious Minimal Language

Formato relativamente recente, desenhado para ser óbvio e inequívoco. Combina secções no estilo INI com tipos de dados ricos e suporte a estruturas aninhadas.

Exemplo

[server]
host = "localhost"
port = 8080
debug = false
tags = ["web", "api"]

Prós

+Especificação curta e sem casos ambíguos
+Tipos nativos para datas, números e arrays
+Suporta comentários e secções nomeadas
+Equilíbrio entre legibilidade humana e parsing fiável

Contras

−Menos universal, fora dos ecossistemas que o adoptaram pode ser exótico
−Estruturas profundamente aninhadas ficam mais verbosas que em YAML
−Comunidade ainda em crescimento, menos ferramentas auxiliares

Quando usar

Ficheiros de configuração de projectos modernos, manifestos de pacotes, qualquer caso onde queres uma sintaxe limpa sem as armadilhas de indentação do YAML.

INI.ini / .conf

Initialization File

Um dos formatos mais antigos ainda em uso. Estrutura por secções entre parêntesis rectos e pares chave-valor. Não há especificação formal única, o que gera variantes incompatíveis.

Exemplo

[server]
host = localhost
port = 8080
debug = false
tags = web,api

Prós

+Extremamente simples de ler e escrever
+Trivial de parsear, mesmo com código próprio
+Suportado por muitos sistemas operativos e ferramentas
+Aceita comentários e secções

Contras

−Sem standard formal, cada implementação tem variações
−Não suporta hierarquias profundas além de uma secção
−Todos os valores são strings, conversão de tipos fica a cargo da aplicação
−Sem suporte nativo a listas estruturadas

Quando usar

Configuração plana de ferramentas pequenas, ficheiros de utilizador em sistemas Windows e Linux, casos onde a simplicidade vale mais que as funcionalidades.

CSV.csv

Comma-Separated Values

Formato para dados tabulares: uma linha por registo, valores separados por vírgulas. Existe há décadas e continua a ser o pão e a manteiga do intercâmbio entre folhas de cálculo, bases de dados e ferramentas de análise.

Exemplo

host,port,debug,tags
localhost,8080,false,"web,api"
example.com,443,true,"web"

Prós

+Universal entre folhas de cálculo, bases de dados e ferramentas estatísticas
+Compacto para dados puramente tabulares
+Streaming linha a linha permite ficheiros enormes
+Editável em qualquer ferramenta, da Excel ao Vim

Contras

−Sem hierarquias, é só uma tabela plana
−Sem tipos, tudo são strings sem distinção entre número e texto
−Tratamento de aspas, vírgulas dentro de valores e quebras de linha é fonte clássica de bugs
−Variações regionais (vírgula vs ponto e vírgula como separador)

Quando usar

Exportação de relatórios, importação em folhas de cálculo, datasets para análise estatística, qualquer cenário onde os dados são genuinamente tabulares.

Sobre esta ferramenta

Comparação directa entre seis formatos de serialização de dados muito usados: JSON, YAML, XML, TOML, INI e CSV. Para cada um vês sintaxe lado a lado, pontos fortes, pontos fracos e em que contexto faz sentido escolhê-lo. Útil para decidir o formato de configuração de uma aplicação nova, para perceber rapidamente um formato com que não estás familiarizado, ou para sustentar uma decisão técnica com argumentos concretos.

Como usar

Lê a tabela comparativa para teres uma visão geral das características de cada formato.
Compara os exemplos lado a lado, todos representam o mesmo objecto para facilitar a comparação.
Decide com base no contexto, há formatos melhores para configuração editada à mão e outros melhores para troca entre sistemas.

Perguntas frequentes

Qual o formato mais usado hoje?: JSON na web, sem dúvidas, é o formato dominante em APIs REST e em configuração frontend. YAML domina em DevOps e infraestrutura, sobretudo em pipelines de CI e definições de containers. XML mantém-se em ambientes empresariais e em formatos com estrutura documental complexa. TOML cresceu muito no ecossistema de ferramentas de desenvolvimento. CSV continua a ser o padrão para dados tabulares.
Posso converter entre formatos?: Sim, na maior parte dos casos. JSON, YAML e TOML têm modelos de dados próximos e a conversão entre eles é quase directa. XML é mais complexo por causa de atributos e conteúdo misto, mas há mapeamentos comuns. CSV só representa tabelas, portanto a conversão para hierárquico ou de hierárquico para CSV exige decisões sobre como aplanar a estrutura.
Porque é que YAML é tão problemático?: Tem uma especificação maior do que aparenta. Algumas palavras-chave ("yes", "no", "on", "off") são interpretadas como booleanos, números com zeros à esquerda podem ser lidos como octal, e a indentação por espaços ou tabs causa erros silenciosos. As versões mais recentes (YAML 1.2) resolveram alguns destes pontos, mas é preciso estar atento ao modo estrito do parser.
JSON5 e JSONC resolvem a falta de comentários do JSON?: Sim, são variantes do JSON que adicionam comentários e alguma flexibilidade extra (vírgulas pendentes, chaves sem aspas). Não são standards universais, mas são suportados em ambientes específicos como editores de código. Para troca entre sistemas, mantém JSON puro para garantir compatibilidade.
Quando devo escolher TOML em vez de YAML?: TOML é melhor quando queres uma sintaxe limpa para configuração mas sem as armadilhas da indentação significativa. Para ficheiros de configuração de projecto com estrutura média, TOML costuma ser menos propenso a erros. YAML é melhor para estruturas muito profundas ou quando precisas de referências internas e funcionalidades avançadas.

JSON vs YAML vs XML vs TOML vs INI vs CSV

Sobre esta ferramenta

Como usar

Perguntas frequentes

Ferramentas relacionadas