Converter YAML para JSON

O YAML 1.2 é deliberadamente um superconjunto do JSON, o que significa que todo documento JSON já é YAML válido, e esta conversão é uma questão de escrever o mesmo dado sem nenhum atalho. É exatamente por isso que é útil para depuração: o JSON mostra os valores que o interpretador produziu, não os caracteres que você digitou.

A maioria das surpresas num arquivo YAML são surpresas de resolução — uma versão que virou número, uma palavra que virou booleano, um apelido que trouxe mais do que você esperava. Nenhuma delas é visível no YAML e todas são visíveis no JSON. O resto desta página é a lista dessas resoluções.

Arquivos YAML podem guardar vários documentos num fluxo só, separados por linhas de três traços. Manifestos Kubernetes usam isso o tempo todo. O JSON não tem equivalente — um arquivo JSON é um valor só — então o interpretador recusa em vez de escolher um documento silenciosamente, e a conversão falha com uma mensagem nomeando a linha onde o segundo documento começa.

A saída é mecânica. Divida o arquivo nos marcadores e converta cada documento separadamente, ou envolva as partes numa lista única de nível superior você mesmo antes de converter. Um marcador de abertura sozinho no topo do arquivo está bem; só um segundo documento para a conversão.

Uma âncora e seus apelidos colapsam em cópias. Um arquivo de CI que define um bloco padrão uma vez e o referencia em seis tarefas produz JSON com seis cópias completas desse bloco, porque o JSON não tem como referenciar um valor definido em outro lugar. A saída é maior que a entrada e diz a mesma coisa.

A chave de mesclagem é a parte que pega as pessoas. Uma linha escrita com dois sinais de menor seguidos de um apelido é uma convenção do YAML 1.1 para mesclar um mapa no atual, e não faz parte do esquema núcleo do YAML 1.2, então atravessa como uma chave comum chamada literalmente "<<" cujo valor é o mapa referenciado. As chaves que você esperava serem mescladas na tarefa ficam um nível abaixo, dentro dessa chave.

Formas curtas de CloudFormation, inclusões do Home Assistant e uma dúzia de outros dialetos dependem de significado pendurado em tags personalizadas. O interpretador não conhece essas tags, então resolve cada uma para seu valor puro e segue em frente — a tag desaparece e só sobra o valor de dentro.

Esta é a conversão mais perigosa da página, porque o JSON sai válido, plausível e errado. Não sobra marcador nenhum dizendo que uma tag estava ali. Se o seu YAML pertence a um dialeto com tags personalizadas, este conversor vai produzir um documento que não descreve mais o que você quis dizer, e a única defesa é saber de antemão que seu arquivo usa isso.

O YAML 1.1 tratava várias palavras como "sim" e "não" como booleanos, a origem do problema conhecido em que um código de país escrito como "no" vira falso. O interpretador aqui implementa o YAML 1.2, cujo esquema núcleo reconhece só `true` e `false`, então essas palavras sobrevivem como string e o código de país fica seguro.

Isso é um padrão, não uma garantia. Um arquivo cuja primeira linha é uma diretiva de versão 1.1 é lido como 1.1, e então essas palavras genuinamente viram booleano no JSON. Também vale só para este conversor — a ferramenta que lê seu YAML em produção pode muito bem ser uma implementação 1.1. O JSON aqui mostra o que um interpretador 1.2 vê, útil justamente porque pode diferir do que seu ambiente de execução vê.

Um valor escrito `1.0` resolve para o número `1`, então uma versão fixada vira um inteiro e imprime sem sua casa decimal. Um valor escrito `0755` resolve para `755`. Colocar aspas em qualquer um dos dois na origem mantém isso como string, e a saída JSON vai mostrar aspas ao redor, o que torna esta conversão um jeito rápido de auditar um arquivo em busca de valores que precisam de aspas.

Inteiros grandes perdem precisão silenciosamente. O YAML não tem limite de tamanho para um inteiro, números JSON são de ponto flutuante de precisão dupla, e um identificador de 64 bits sai arredondado. Nada reporta isso. Qualquer YAML guardando IDs dessa magnitude quer eles entre aspas como string antes da conversão, não depois.

O JSON tem seis tipos e o YAML tem um sistema de tags. Onde os dois discordam, algo é achatado. Um valor carregando a tag explícita de data vira uma data e depois uma string ISO 8601 no JSON, normalizada para UTC — então uma data escrita com um deslocamento de fuso sai deslocada e marcada com Z, e o deslocamento original desaparece.

Um valor binário é decodificado em bytes e depois serializado como um objeto indexado por posição. O dado todo está lá e nenhum consumidor vai reconhecer isso; recodificar o campo para texto base64 no YAML antes de converter é o caminho mais curto. Data sem tag e sem aspas é mais simples: sob o esquema núcleo 1.2 elas são strings comuns, então uma data escrita continua a mesma string, o que geralmente é o que você quer.

Dois erros param a conversão de imediato e ambos valem reconhecer. Chaves duplicadas no mesmo mapeamento são rejeitadas — a mensagem diz que chaves de mapa devem ser únicas, com o número da linha — mais rígido que algumas ferramentas YAML e geralmente o comportamento correto, já que uma chave duplicada significa que uma das duas configurações foi ignorada desde que foi adicionada.

O segundo é uma tabulação usada para indentação. O YAML proíbe tabulação ali, e o interpretador diz isso com uma linha e coluna. Os dois erros são o conversor te fazendo um favor: um arquivo com qualquer um dos dois problemas é um arquivo cujo comportamento já depende de qual interpretador o lê.

A saída é indentada com dois espaços e termina com uma quebra de linha, então uma ferramenta de linha de comando, um validador de esquema JSON e qualquer cliente HTTP leem direto. Validação é o motivo mais forte para fazer essa viagem: JSON Schema é maduro e amplamente implementado, e rodar uma cópia JSON gerada de uma configuração contra um esquema pega chave grafada errado que um verificador de sintaxe YAML deixaria passar.

Não é um substituto para o YAML. Comentários se foram, âncoras foram expandidas em duplicação, e qualquer tag personalizada evaporou silenciosamente, então converter de volta te daria um arquivo que funciona e não parece mais algo que uma pessoa escreveu. Guarde o YAML como a fonte e trate o JSON como a visão.