Conversor de YAML para JSON

YAML e JSON descrevem os mesmos dados, mas com filosofias diferentes. O YAML aposta na legibilidade humana e usa indentação para representar a hierarquia, dispensando chaves e a maioria das aspas. Já o JSON é mais rígido e explícito, com {} para objetos, [] para listas e aspas obrigatórias em todas as chaves de texto.

Na prática, você escreve a configuração em YAML porque é confortável de ler e editar, mas a aplicação, a API ou a linguagem de programação muitas vezes esperam JSON. É aí que a conversão entra. Ela pega a estrutura baseada em recuo do YAML e a reescreve no formato pontuado do JSON, preservando objetos, listas, números, booleanos e valores nulos.

Algumas diferenças moldam o resultado:

• O YAML aceita comentários com #; o JSON não tem comentários, então eles são descartados.
• O YAML permite âncoras e aliases para reaproveitar trechos; na conversão eles são expandidos.
• Strings de várias linhas do YAML viram um único valor com quebras codificadas.

Entender essas distinções ajuda a prever exatamente o que sai do conversor.

O processo acontece em três etapas claras. Primeiro vem a análise do YAML: o texto colado é lido linha a linha, e a profundidade de cada nível é determinada pela indentação. Nesse momento o conversor monta uma árvore de dados em memória, identificando o que é objeto, lista, número, texto ou valor booleano.

Depois vem o mapeamento para a estrutura JSON. Cada nó da árvore ganha sua representação equivalente: um mapa YAML vira um objeto entre chaves, uma sequência vira um array entre colchetes e os valores recebem aspas quando são texto. Recursos como âncoras (&) e aliases (*) são resolvidos, ou seja, o conteúdo referenciado é copiado para onde foi reutilizado.

Por fim, o conversor trata os casos de borda. Datas, valores especiais e strings que parecem números recebem atenção para não mudar de tipo sem querer. Chaves duplicadas, indentação inconsistente e tabulações no lugar de espaços costumam gerar erro, e o conversor sinaliza a linha problemática.

Todo o trabalho ocorre no seu navegador, sem enviar os dados para nenhum servidor.

Nada explica melhor do que um exemplo lado a lado. Imagine um trecho de configuração de servidor escrito em YAML:

`` servidor: host: localhost porta: 8080 ativo: true hosts_permitidos: - api.exemplo.com - app.exemplo.com ``

O mesmo conteúdo, depois da conversão, fica assim em JSON:

`` { "servidor": { "host": "localhost", "porta": 8080, "ativo": true, "hosts_permitidos": ["api.exemplo.com", "app.exemplo.com"] } } ``

Repare em alguns pontos importantes:

• A indentação do YAML virou chaves e colchetes explícitos.
• O número 8080 permanece sem aspas, porque é um valor numérico.
• O booleano true foi preservado como tipo, não como texto.
• A lista com hífens virou um array entre colchetes.

Esse mapeamento previsível é o que torna a conversão confiável para uso programático. Se quiser percorrer o caminho inverso, o conversor de JSON para YAML faz exatamente o oposto.

A conversão de YAML para JSON aparece em vários momentos do fluxo de trabalho de quem desenvolve ou cuida de dados. Os cenários mais comuns são:

1. Preparar dados para APIs REST. A maioria dos endpoints aceita JSON no corpo das requisições. Se a sua fonte de verdade está em YAML, converter antes de enviar evita erros.
2. Migrar arquivos de configuração. Ao trocar de ferramenta, um projeto pode exigir que os arquivos .yaml sejam reescritos em .json. A conversão automatiza esse passo.
3. Depurar YAML. Quando a indentação confunde, ver o equivalente em JSON deixa a estrutura real evidente e revela onde um nível foi aninhado errado.
4. Integrar sistemas distintos. Um serviço produz YAML, outro consome JSON; a conversão funciona como ponte entre eles.

Depois de gerar o JSON, costuma valer a pena passar o resultado por um formatador de JSON para deixar a indentação consistente. E se o seu ponto de partida for outro formato, o conversor de TOML para JSON cobre um caminho parecido.

A conversão de YAML para JSON é confiável, mas não é totalmente reversível em todos os casos, e vale conhecer os limites antes de depender dela cegamente.

O ponto principal é que alguns recursos do YAML não existem no JSON. Comentários iniciados com # desaparecem, porque o JSON não tem onde guardá-los. Âncoras e aliases são expandidos, então a economia de espaço que o YAML oferecia se perde, embora o conteúdo final fique idêntico. Tags personalizadas do YAML também não têm equivalente direto.

Outro cuidado é com tipos ambíguos. No YAML, um valor como sim ou um CEP com zero à esquerda pode ser interpretado como booleano ou número quando você queria texto. Coloque o valor entre aspas no YAML para garantir que ele chegue ao JSON como string.

Por isso, considere a conversão como lossless no conteúdo, mas não na apresentação. Os dados continuam fiéis; o que muda são comentários, formatação e a forma de reaproveitar trechos. Para configurações críticas, revise o JSON gerado antes de colocá-lo em produção.