Pular para o conteúdo principal

TOML para JSON

Nada é enviado: este conversor analisa TOML 1.0 no seu navegador e emite JSON. Tabelas se tornam objetos, entradas de [[array de tabelas]] se tornam arrays de objetos, datetimes RFC 3339 são mantidas como strings e chaves duplicadas falham com um erro numerado por linha em vez de serem mescladas silenciosamente. O JSON segue o RFC 8259.

Só local

TOML para JSON: explicação

TOML ocupa um nicho específico: é o formato de configuração do Cargo.toml, pyproject.toml e de centenas de gerenciadores de pacotes, escolhido porque um ser humano pode editá-lo sem quebrar. JSON ocupa outro diferente — é o que os programas trocam entre si. Mais cedo ou mais tarde, um script, um fixture de teste ou uma API quer seu TOML como JSON, e essa conversão tem exatamente duas perguntas mecânicas: como um cabeçalho [table] se torna um objeto JSON, e como um cabeçalho [[array de tabelas]] se torna um array JSON?

O mapeamento é determinístico. Um [table] e suas chaves se tornam um objeto aninhado; chaves pontilhadas como database.port também se tornam objetos aninhados; um [[array de tabelas]] se torna um array com um objeto por cabeçalho. Os escalares do TOML mapeiam diretamente — booleanos permanecem booleanos, inteiros e floats permanecem números, e os underscores que o TOML permite para legibilidade desaparecem, porque 1_000_000 e 1000000 são o mesmo número. Datetimes RFC 3339 não têm tipo em JSON, então chegam como strings com seu texto preservado exatamente.

Tudo é executado nesta aba do navegador. O texto TOML que você cola é analisado por um motor na página, o JSON é serializado a partir do documento analisado, e nenhum dos dois toca a rede — abra o DevTools e veja o painel de Rede permanecer silencioso enquanto você converte. A Content-Security-Policy da página proíbe conexões de saída, então a afirmação sobre privacidade é verificável em vez de ser decorativa.

O ciclo de ida e volta é o fluxo de trabalho comum — extrair a configuração de um payload, editá-la, colocá-la de volta — e a converter JSON de volta para TOML página executa este mapeamento em sentido inverso, escalares primeiro.

O JSON que esta ferramenta emite é compacto por padrão, então se você quiser com recuo para leitura, o Formatador de JSON o reimprimirá com a espaçagem da sua escolha.

Como a conversão realmente funciona

O motor analisa seu TOML em uma árvore de documentos primeiro, porque toda decisão de JSON segue das regras de escopo do TOML: um cabeçalho [table] abre um objeto nomeado, um cabeçalho [[array de tabelas]] anexa um novo objeto a um array nomeado, e chaves acima de qualquer cabeçalho pertencem ao objeto raiz. Uma vez que a árvore existe, emitir JSON é uma serialização direta — os únicos pontos de julgamento são os locais onde TOML e JSON discordam, e cada um é decidido da mesma maneira toda vez:

  • Tabelas: [owner] com uma chave name produz um objeto owner — os cabeçalhos do TOML e as chaves do JSON codificam a mesma aninhamento.
  • Arrays de tabelas: cada cabeçalho [[servers]] anexa um objeto a um array servers, na ordem do arquivo.
  • Chaves pontilhadas: database.port = 5432 aninha-se sob database, exatamente como o TOML 1.0 define que chaves pontilhadas devem se comportar.
  • Datetimes: 1979-05-27T07:32:00Z não tem tipo em JSON, então é emitido como a string "1979-05-27T07:32:00Z", byte por byte.
  • Números: underscores são pontuação do TOML, não dados — 1_000_000 é emitido como 1000000 — e os inf e nan do TOML se tornam null, porque JSON não tem literais para nenhum dos dois.

Como a saída se parece

O exemplo abaixo é o par exato que o botão “Carregar exemplo” do conversor produz: um raiz com três chaves escalares (uma delas com underscore), uma tabela [issuer] e duas entradas [[items]]. Veja cada forma cruzar — os underscores desaparecem dentro do número, a tabela issuer aninha-se como objeto e o array items coleta seus objetos na ordem do arquivo. As chaves permanecem na ordem que o TOML declarou, porque a ordem do documento é a única ordem que um conversor pode manter honestamente.

Como o JSON é emitido a partir da árvore analisada e não por emenda textual, a formatação também é normalizada: dois estilos de espaçamento no TOML produzem um JSON consistente e uma linha em branco solta não muda nada. O que sobrevive é estrutura e valores — que é exatamente o que um conversor deve prometer.

Chaves duplicadas e outras falhas honestas

Um conversor honesto recusa entradas que não pode representar fielmente, e o TOML 1.0 é suficientemente estrito para que essas recusas sejam raras e inequívocas. Três entradas são rejeitadas com uma mensagem específica, numerada por linha, em vez de serem reformatadas silenciosamente:

  • Chaves duplicadas — TOML 1.0 proíbe definir uma chave mais de uma vez, então o parser para na linha ofensiva em vez de deixar o último-vencer reescrever silenciosamente sua configuração.
  • Strings multilinha — o suporte deste parser cobre strings básicas e literais de linha única; um bloco """ é recusado com uma mensagem que diz exatamente isso, em vez de uma suposição distorcida.
  • Construtos não fechados — um cabeçalho [table] ou string entre aspas que nunca termina relata a linha onde o parser desistiu, não um erro de sintaxe genérico.

O mapeamento de relance

Todo constructo que este conversor suporta, e para onde ele vai no JSON:

TOML 1.0JSON de saída
[owner] tableObjeto "owner" aninhado
cabeçalho [[items]]Array "items" de objetos
chave pontilhada database.portObjeto "database" aninhado
1979-05-27T07:32:00ZString, texto RFC 3339 preservado
1_000_000Número 1000000
'literal string'String, backslashes intactos

Perguntas frequentes

Converter TOML para JSON envia meu arquivo para algum lugar?

Não. A análise e a serialização são executadas dentro desta aba do navegador com JavaScript que carregou quando a página abriu. Não há rota de API para enviar dados, e a Content-Security-Policy bloqueia conexões de saída. Você pode verificar ambas as afirmações em segundos: abra o DevTools, veja o painel de Rede enquanto converte e veja que nenhuma requisição é disparada.

O que acontece com os datetimes TOML na saída JSON?

Eles se tornam strings. JSON (RFC 8259) não tem tipo de data ou datetime — apenas string, número, booleano, null, objeto e array — então 1979-05-27T07:32:00Z é emitido como a string exata "1979-05-27T07:32:00Z". Nada é reformatado ou deslocado de fuso horário; o texto sobrevive byte por byte, e seu código downstream o analisa quando precisa de uma data real.

Como [[array de tabelas]] difere de [table]?

Colchetes duplos anexam, colchetes simples definem. [servers] cria um objeto chamado servers; um segundo cabeçalho [servers] seria um erro de chave duplicada. [[servers]] cria um array e anexa um objeto por cabeçalho, então três blocos [[servers]] se tornam um array de três elementos. A distinção simples versus duplo é toda a diferença, por isso este conversor também preserva na direção inversa.

Por que uma chave duplicada é um erro em vez de uma substituição?

Porque o TOML 1.0 declara que definir uma chave várias vezes é inválido, e um conversor que resolvesse o conflito certificaria um arquivo cuja própria especificação rejeita. O erro cita o número da linha da segunda definição, que geralmente é o erro de digitação ou a mesclagem ruim que você precisava encontrar de qualquer maneira.

Meu TOML usa strings multilinha entre aspas triplas — por que o erro?

Este parser suporta um subconjunto documentado do TOML 1.0: strings básicas de linha única, strings literais de linha única, inteiros, floats, booleanos, datetimes, tabelas, arrays de tabelas e chaves pontilhadas. Strings multilinha estão fora do subconjunto e são recusadas com uma mensagem clara nomeada em vez de serem parcialmente analisadas. Divida o valor em uma string de linha única com escapes \n e ele converte limpo.

O que aconteceu com meus valores inf e nan?

TOML permite inf e nan de ponto flutuante, mas JSON não tem literais para nenhum dos dois — JSON.parse não pode produzi-los e JSON.stringify escreve null. O conversor emite null para esses dois valores e os sinaliza na visualização, porque transformar silenciosamente o infinito em um número finito é o tipo de mentira que custa horas para rastrear.