Pular para o conteúdo principal
ToolsByUs

JSON para TOML

Este conversor emite TOML 1.0 a partir de JSON inteiramente no seu navegador. Chaves escalares são escritas primeiro, depois [tabelas], depois [[matrizes de tabelas]], para que toda definição preceda os cabeçalhos que ela deve preceder. Chaves incompatíveis com TOML são sinalizadas, nulos são recusados com um nome de caminho, e uma matriz de nível superior não pode ser convertida — TOML não tem raiz anônima.

Só local

JSON para TOML: explicação

A direção importa: JSON geralmente nasce dentro de um programa — um payload de API, um documento armazenado, o estado de uma ferramenta de build — enquanto TOML geralmente é lido por uma pessoa configurando algo. Converter JSON para TOML significa reentrar um formato com regras de posicionamento reais, e a maior é invisível até que ela morda: em TOML, a posição de uma chave no arquivo decide a qual tabela ela pertence. Escrever retries = 3 após um cabeçalho [servers] e ela se torna silenciosamente uma chave de servers, não da raiz.

Este conversor emite chaves escalares primeiro, depois [tabelas], depois [[matrizes de tabelas]], para que cada par chave/valor seja escrito sob o cabeçalho a que pertence e cada tabela esteja totalmente definida antes do próximo cabeçalho ser aberto. Objetos JSON se tornam tabelas, matrizes de objetos se tornam matrizes de tabelas, matrizes de escalares permanecem como matrizes inline, e cada valor é emitido como o tipo TOML 1.0 que ele já é — não há etapa de inferência para errar.

Tudo acontece nesta aba do navegador. O JSON que você cola é analisado com o próprio JSON.parse do navegador, o TOML é construído a partir desse documento na memória, e nada cruza a rede — o painel Network do DevTools permanece vazio enquanto você trabalha, e a Content-Security-Policy da página mantém assim.

A travessia inversa é a mais comum — lendo um Cargo.toml em um script — e a converter TOML de volta para JSON página a lida, mantendo datetimes como strings exatamente como esta os recebe.

Se o JSON veio de um script em vez de um formatador, passe-o pelo Validador de JSON primeiro — um documento que falhar em analisar lá também falhará aqui, com a mesma mensagem.

Por que escalares vêm primeiro, depois tabelas, depois matrizes

A regra de posicionamento do TOML é a razão pela qual a saída é ordenada dessa forma. Chaves escritas após um cabeçalho [table] pertencem àquela tabela, e chaves escritas após um cabeçalho [[array of tables]] pertencem à sua entrada mais recente — um emissor que intercalasse escalares e cabeçalhos produziria um arquivo que é analisado com sucesso na estrutura errada. Emitir primeiro os pares chave/valor de um nível, depois suas sub-tabelas, depois suas matrizes de tabelas, é a única ordem que faz o round-trip, e a mesma regra se aplica recursivamente dentro de cada tabela aninhada.

Strings têm uma regra própria: tudo é emitido como uma string básica do TOML em aspas duplas, com backslashes, aspas e caracteres de controle escapados da forma que o TOML 1.0 define. O conversor não alterna para strings literais para economizar pontuação, porque decidir quando um backslash é literal é exatamente o palpite que um conversor não deve fazer. Chaves seguem a mesma disciplina, então uma chave como port: 8080 chega entre aspas e sem ambiguidade.

O mapeamento de JSON para TOML

Cada formato que o conversor lida, e seu destino TOML 1.0:

JSONTOML de saída
ObjetoCabeçalho [table], chaves sob ele
Matriz de objetosEntradas de [[matriz de tabelas]], uma por objeto
Matriz de escalaresMatriz inline: ["fast", "safe"]
StringString básica com escapes padrão
Chave com ponto ou espaçoChave entre aspas: "app.name" = 1
nuloRecusado — TOML 1.0 não tem nulo

Como a saída se parece

O exemplo abaixo é o par exato que o botão “Carregar exemplo” do conversor produz: um objeto raiz com dois escalares e uma matriz de tags inline, um objeto owner aninhado, e uma matriz servers contendo dois objetos. Observe a ordenação — os pares chave/valor simples da raiz, incluindo tags, todos aparecem antes de [owner], e ambas as entradas de servers ficam sob um único cabeçalho [[servers]] em ordem de matriz. Essa ordenação não é cosmética; é o que faz o arquivo ser analisado de volta para a mesma estrutura.

A mesma normalização se aplica como em toda esta família: a saída é gerada a partir do documento analisado, então as peculiaridades de recuo no JSON de origem são preservadas em significado e em ordem de chave, mas reimpressas em um único estilo TOML consistente que um revisor pode comparar.

Casos extremos que este conversor recusa em vez de modificar

Algumas entradas não têm representação fiel em TOML 1.0, e fingir o contrário entregaria a você um arquivo de configuração que mente:

  • Uma matriz ou escalar de nível superior — documentos TOML são sempre uma tabela raiz de pares chave/valor, então um arquivo JSON cujo nível superior não é um objeto é recusado com uma mensagem clara.
  • Qualquer nulo, em qualquer lugar — TOML 1.0 não tem nulo, então o conversor recusa e nomeia o caminho exato, deixando você deletar a chave ou escolher um valor deliberadamente.
  • Chaves que parecem com pontos — uma chave a.b seria analisada como chave pontilhada e iria para uma tabela aninhada, então tais chaves são emitidas como strings básicas entre aspas, e a visualização as sinaliza para que você possa identificar nomes que provavelmente foram destinados a serem de aninhamento.

Perguntas frequentes

Meu JSON é enviado para um servidor durante a conversão?

Não. A conversão é executada inteiramente nesta aba do navegador: JSON.parse e o escritor de TOML são JavaScript local à página, carregado uma vez ao abrir. Não há endpoint de envio, e a Content-Security-Policy proíbe a página de abrir conexões. O DevTools prova isso — observe o painel Network permanecer vazio por qualquer número de conversões.

Por que escalares devem ser escritos antes dos cabeçalhos [table]?

Em TOML, toda chave após um cabeçalho [servers] pertence a servers, então intercalar escalares e cabeçalhos mudaria o significado do arquivo enquanto ele ainda é analisado corretamente. Escrever primeiro os pares chave/valor de um nível, depois suas sub-tabelas e matrizes de tabelas, é a única ordem que é analisada de volta para a estrutura com que você começou — é correção, não estilo.

O que o conversor faz com JSON nulo?

Ele recusa. TOML 1.0 não tem valor nulo — a linguagem não oferece nenhuma forma de escrevê-lo — então nenhuma emissão fiel existe. O conversor reporta o caminho exato da chave ofensora, como owner.middle, e para. Deletar a chave, ou substituir por uma string sentinela, é sua decisão, não um palpite silencioso embutido na saída.

Como matrizes são convertidas?

Por seu conteúdo. Uma cujo elemento é um objeto se torna uma [[matriz de tabelas]], uma entrada por objeto. Uma matriz de escalares ou valores mistos se torna uma matriz inline do TOML em uma linha, e uma matriz vazia é emitida como []. Nada é achatado ou remodelado — o conversor renderiza a estrutura que recebeu, o que torna o resultado previsível.

O que acontece com chaves que têm pontos, espaços ou dois-pontos?

Chaves bare do TOML permitem apenas letras, dígitos, underscores e hífens, então qualquer outra coisa deve ser uma chave entre aspas. Este conversor emite tais chaves como strings básicas — "app.name" = 1 — que o TOML 1.0 define como uma única chave, não um caminho pontilhado. A visualização sinaliza chaves entre aspas para que você possa ver quais nomes provavelmente foram destinados a ser de aninhamento e renomeá-los manualmente.

Posso obter datetimes reais do TOML a partir de uma string JSON?

Não por conversão, e honestamente assim. JSON não tem tipo de data, então o conversor não pode saber se "1979-05-27T07:32:00Z" é um timestamp ou uma frase que acontece se parecer com um; toda string é emitida como uma string básica entre aspas. Se você quer um datetime bare do TOML, remova as aspas na saída manualmente — o texto já é RFC 3339 válido.

Equipe ToolsByUs · Como verificamos nossas ferramentas