Conversor de JSON para TOML

Converte um objeto JSON em documento conforme TOML 1.0 via @iarna/toml. Objetos aninhados viram cabeçalhos `[section]`; arrays de objetos viram blocos array-of-tables `[[items]]`; strings, números, booleanos e strings de data-hora ISO 8601 mapeiam para primitivos TOML. A saída é ordenada para uma ordem canônica — chaves aparecem antes de sub-tabelas para compatibilidade com parsers TOML estritos.

Exemplo

Entrada JSON:

{
  "name": "Ada",
  "active": true,
  "address": {
    "city": "London"
  }
}

Saída TOML:

name = "Ada"
active = true

[address]
city = "London"

Armadilhas comuns de JSON para TOML

TOML tem regras de nível superior mais estritas que JSON. Os padrões abaixo explicam por que um valor JSON que "deveria funcionar" pode falhar.

• Array de nível superior. TOML não pode representar um array JSON de nível superior. Envolva-o: `{"items": [...]}`. O resultado vira um array-of-tables TOML sob `[[items]]`.
• Escalar de nível superior. Um documento JSON nu `42` ou `"hello"` não tem chave para se ligar em TOML. Envolva em um objeto: `{"value": 42}`.
• Valores null. TOML não tem tipo null. O serializador omite por completo as chaves cujo valor JSON é null. Se precisa representar "explicitamente nada", use string vazia `""` ou um valor sentinela, dependendo do código a jusante.
• Arrays de tipos mistos. TOML 1.0 permite `[1, "two"]`, mas parsers legados 0.5 não. Se seu TOML precisa round-trip por tooling 0.5, mantenha arrays homogêneos no JSON antes de converter.
• Chaves com pontos na saída TOML. Uma chave JSON como `"my.key"` vira um caminho de "chave pontilhada" TOML, que parsers TOML interpretarão como aninhado. Para preservar um ponto literal no nome da chave, o serializador a aspas: `"my.key" = ...` — mas os consumidores ainda podem parseá-la como caminho.
• NaN / Infinity. TOML 1.0 suporta literais `nan`, `inf`, `-inf`. JSON não representa estes — geralmente chegam como strings `"NaN"`, `"Infinity"` etc. Converta manualmente se precisar de especiais reais de float TOML.

Como datas são representadas?

Datas JSON são strings ISO 8601, p. ex. `"2026-04-26T12:00:00Z"`. O serializador as mantém como strings em TOML — não como tipos data-hora nativos. Para obter um data-hora TOML nativo, você precisaria pré-processar e emitir o valor com o marcador de tipo correto no lado JavaScript.

Objetos profundamente aninhados são achatados?

Não — viram cabeçalhos aninhados `[a.b.c]`. Cada nível de aninhamento vira um caminho de cabeçalho unido por pontos. Para estruturas muito profundas, a saída pode ter linhas de cabeçalho longas; é apenas como TOML expressa profundidade.

A ordem das chaves é preservada?

Mais ou menos. O serializador canonicaliza a ordem para que primitivos venham antes de sub-tabelas (regra TOML). Dentro de cada nível, a ordem de inserção JSON é preservada.

Como obtenho uma tabela inline TOML na saída?

Você não pode — o serializador sempre usa cabeçalhos de bloco `[section]`, nunca tabelas inline. Se precisa de saída inline, pós-processe o resultado. Tabelas inline são uma característica de legibilidade TOML, não uma forma de dados diferente.

Meu JSON é enviado para algum lugar?

Não. Tudo roda no seu navegador — sua entrada é parseada e serializada por JavaScript nesta página e nunca enviada a servidor.

Posso fazer round-trip JSON → TOML → JSON?

Para tipos suportados (string, número, booleano, objeto aninhado, array de objetos), sim. Round-trips perdem valores null (TOML não tem null) e podem normalizar a ordem das chaves.