Cookies para estatística e publicidade
Usamos cookies de estatística e de publicidade, ambos enviados ao Google. Recusar não muda nada do que você vê.Ler a página de privacidade
Aqui você converte TOML para JSON de graça e sem conta: solte o arquivo acima e em poucos segundos o resultado está pronto para baixar. A conversão acontece dentro do seu próprio navegador, então o arquivo nunca é enviado. Funciona igual no Windows, no macOS e no Linux e também no iPhone e no Android, e continua funcionando mesmo se você cortar a conexão.
Até 100 arquivos de uma vez. Formatos misturados não são problema.
Eles são convertidos um após o outro e baixados juntos em um ZIP.
TOML para JSON
TOML é o padrão de empacotamento Python e Rust há anos, e as ferramentas em volta de um repositório muitas vezes não acompanharam. Um passo de CI com jq disponível e nada mais, um script Node que precisa ler a versão de um Cargo.toml, um painel contando dependências em duzentos repositórios — todos leem JSON e nenhum lê TOML sem uma dependência nova.
É esse o caso que esta conversão serve, e funciona de forma limpa porque os dois modelos de dado se sobrepõem quase por completo. TOML é uma tabela de pares chave-valor com aninhamento e arrays — o que é um objeto JSON com aninhamento e arrays.
Um cabeçalho entre colchetes vira um objeto aninhado, e um cabeçalho pontuado vira aninhamento em vários níveis — um cabeçalho escrito para uma ferramenta e depois um linter embaixo dele produz um objeto dentro de outro, então o caminho JSON bate exatamente com o cabeçalho.
Um cabeçalho de colchete duplo é o array de tabelas, e vira um array JSON de objetos com uma entrada por ocorrência. É o que guarda os autores de um pacote Python, os binários de um crate Rust e os alvos de um build.
TOML é o único formato desta família com tipos temporais de verdade: data-hora com fuso, data-hora local, data local e hora local estão na especificação, e um leitor devolve tudo isso como data. JSON não tem tipo de data algum, então cada um vira string.
Os valores sobrevivem com uma ressalva: uma data-hora com fuso mantém o próprio fuso em vez de ser normalizada para UTC. Uma hora local ganha um componente de milissegundo que não tinha — uma hora escrita como oito da manhã chega com uma parte fracionária anexada.
TOML 1.0 exige que a implementação lide com inteiros de 64 bits assinados. Números JSON são doubles IEEE e são exatos só até cerca de nove quatrilhões. Um arquivo TOML com um inteiro acima dessa faixa é totalmente legal, e o leitor aqui para com um erro dizendo que o inteiro não pode ser representado sem perda em vez de produzir JSON com um número errado.
Recusar é a decisão certa: um identificador arredondado em silêncio é um bug que aparece semanas depois numa junção que não bate com nada. Se seu TOML tem um valor desse tamanho, coloque-o entre aspas como string na origem.
Floats TOML incluem inf e nan como valores literais. JSON não tem nenhum dos dois, e o serializador escreve null para ambos. Isso é comportamento padrão do JavaScript e é lossy de um jeito que nada avisa — um limite superior configurado como infinito e um limite não definido viram a mesma coisa no JSON.
A perda mais sutil é de tipo. TOML distingue um inteiro de um float, então 1 e 1.0 são valores diferentes com tipos diferentes. JSON tem um tipo de número só, e 1.0 é serializado como 1.
Tabelas e chaves saem na ordem em que o TOML as declarou, mantendo um arquivo convertido legível. A exceção são chaves numéricas: uma chave TOML entre aspas que é um número é reordenada antes de qualquer outra chave no seu objeto e ordenada crescente, porque é assim que objetos JavaScript ordenam chaves com cara de inteiro.
A saída é JSON comum, então jq lê sem nenhuma flag: puxar uma versão de projeto, listar nomes de dependência ou checar se uma seção de ferramenta existe são expressões de uma linha só. Costuma ser o motivo inteiro da viagem, e transforma um script de shell que ia fazer grep num TOML num que consulta de verdade.
Isso também abre validação. JSON Schema é maduro e amplamente implementado, e TOML não tem linguagem de esquema própria na especificação, então converter e depois validar é um jeito genuíno de aplicar regras internas em muitos repositórios.
TOML suporta comentário e usa bastante: o motivo de uma dependência estar fixada, o número do chamado ao lado de uma solução alternativa. JSON não tem sintaxe de comentário sob a RFC 8259, então nada disso chega.
Isso resolve a direção da relação. O TOML é o arquivo que as pessoas editam e revisam, e o JSON é gerado dele sempre que algo precisa lê-lo. Comitar o JSON junto com o TOML cria duas versões da verdade que vão divergir; gerá-lo no passo de build não.
Se a leitura acontece dentro de uma aplicação em vez de num passo de build, use um leitor de verdade. Toda linguagem grande tem um — Python tem tomllib na biblioteca padrão há várias versões, e Rust, Go e JavaScript têm opções bem mantidas. Ler o arquivo diretamente mantém os tipos temporais e a distinção inteiro-float que esta conversão achata.
O conversor ganha seu lugar na fronteira: uma inspeção pontual, um passo de CI onde adicionar uma dependência não vale a pena, ou um pipeline cuja próxima etapa só fala JSON. Tudo roda no seu navegador, então uma configuração privada com credencial dentro é segura de soltar aqui.
| TOML | JSON | |
|---|---|---|
| Nome completo | Tom's Obvious Minimal Language | JavaScript Object Notation |
| Extensão do arquivo | .toml | .json |
| Tipo de mídia | application/toml | application/json |
| Publicado pela primeira vez | 2013 | 2001 |
| Especificação | TOML 1.0 | RFC 8259 |
| Licença | Padrão aberto | Padrão aberto |
| Situação hoje | Atual | Atual |
| Abre no navegador | Nenhum navegador | Todos os navegadores |
| Considerado no lugar | YAML, INI | XML, YAML, NDJSON |
Os comentários não sobrevivem. TOML permite anotar um arquivo e JSON não tem sintaxe para isso, então cada linha de explicação se perde — e isso atinge justamente os arquivos que se comentam: configuração que outra pessoa vai manter.
Nada é descartado. TOML e JSON guardam o conteúdo sem perda, então a conversão troca a embalagem e não a qualidade — e pode ser repetida sem que o estrago se acumule.
JSON abre em qualquer navegador atual. TOML alcança ainda menos navegadores. Se o arquivo vai para uma página web ou um formulário, esse costuma ser todo o motivo da conversão.
Visual Studio Code lê tanto TOML quanto JSON, então dá para comparar o resultado com o original sem um segundo programa.
Os dois miram trabalhos diferentes: TOML em a edição, JSON em mover dados entre programas e a web. Vale pesar isso antes, porque o motivo de um existir costuma ser o motivo de o outro ser incômodo.
TOML foi publicado em 2013. Está descrito em TOML 1.0, e vale conhecer se o arquivo precisa sobreviver à ferramenta que o escreveu.
JSON e de 2001, descrito em RFC 8259. Visual Studio Code, jq e Postman leem o formato.
Não. Esta conversão acontece inteiramente no seu navegador, então o arquivo não sai do seu aparelho. Você mesmo pode conferir: abra a aba de rede das ferramentas de desenvolvedor e converta alguma coisa. Você verá a própria página e as requisições de estatística e de publicidade com que este serviço é pago, e nenhuma que leve o seu arquivo.
É. Sem conta, sem marca d’água e sem cota diária para gastar: roda no seu próprio aparelho, então você pode voltar quantas vezes quiser. O navegador processa arquivos de até 100 MB, 100 por vez.
Não. JSON guarda o mesmo conteúdo sem jogar nada fora: o resultado é idêntico em qualidade ao original.
Nada é descartado. TOML e JSON guardam o conteúdo sem perda, então a conversão troca a embalagem e não a qualidade — e pode ser repetida sem que o estrago se acumule.
Os comentários não sobrevivem. TOML permite anotar um arquivo e JSON não tem sintaxe para isso, então cada linha de explicação se perde — e isso atinge justamente os arquivos que se comentam: configuração que outra pessoa vai manter.