Conversor de JSON para TOML

Exemplo

Entrada:

{
  "project": { "name": "my-app", "version": "1.0.0" },
  "dependencies": { "django": "4.2", "redis": "^5.0" },
  "servers": [
    { "host": "h1.example.com", "port": 443 },
    { "host": "h2.example.com", "port": 443 }
  ]
}

Saída:

[project]
name = "my-app"
version = "1.0.0"

[dependencies]
django = "4.2"
redis = "^5.0"

[[servers]]
host = "h1.example.com"
port = 443

[[servers]]
host = "h2.example.com"
port = 443

Mapeamento de tipos

Convenções específicas do TOML

• As tabelas não devem conflitar: uma chave não pode ser tanto um valor quanto um cabeçalho de tabela no mesmo documento.
• Array de tabelas usa colchetes duplos: [[servers]] significa “iniciar um novo elemento do array servers”.
• Chaves pontuadas permitem que você escreva project.author.name = "..." sem criar um cabeçalho de tabela.
• Comentários começam com # e são apenas de linha.

Tratamento de null

TOML não tem null. Opções:

• Omitir a chave, mais semântico, se “ausente” for equivalente a “null”.
• Substituir por uma string vazia, bom se a string vazia nunca for um valor válido.
• Usar um valor sentinela, "__null__" ou similar, interpretado pelo seu código.

O conversor omite chaves nulas por padrão e avisa ao fazê-lo.

Erros comuns

• Array JSON no nível superior. [1, 2, 3] na raiz do JSON não pode se tornar um documento TOML válido, envolva-o em um objeto como { "items": [1, 2, 3] }.
• Misturando cabeçalhos de tabela com atribuições inline. Uma vez que você escreve [project], cada chave subsequente nessa seção pertence a project até o próximo cabeçalho.
• Chaves com caracteres especiais. "api-key" está bom (entre aspas), mas api-key sem aspas é um erro de análise TOML.
• Assumindo que a ordem é preservada. Os analisadores TOML geralmente preservam a ordem dos cabeçalhos dentro das tabelas, mas a ordem das chaves dentro de uma tabela não é garantida em todas as implementações.