Português (Brasil)

Ferramentas de desenvolvedor · Conversores de sintaxe

Como funciona a conversão de JSON para YAML: cotação, recuo e estilo de fluxo

· Como funciona

JSON yaml fluxo de trabalho do desenvolvedor

Um objeto JSON aninhado mudando para uma definição de serviço YAML recuada
Ilustração vetorial original ToolAcre

JSON para YAML parece uma questão de exclusão de colchetes, mas um conversor toma decisões reais sobre quais strings precisam de aspas e quando usar o estilo de bloco versus fluxo. Esta postagem aborda essas decisões.

Os colchetes desaparecem, mas para onde vão as aspas? — uma carga útil JSON convertida em YAML e a mistura de strings entre aspas e vazias no resultado

A remoção de colchetes e aspas não transforma um objeto JSON em um arquivo YAML confiável. O conversor deve decidir como um mapeamento aninhado, matriz, string e nova linha são representados e se um valor que se parece com um número ou booleano permanece como texto. Um engenheiro de DevOps que move uma definição de serviço API para o Compose precisa que essas decisões sejam previsíveis antes de copiar o resultado em um diretório de implantação. A conversão altera a sintaxe, não a configuração real do serviço.

JSON (quase) já é YAML — por que a entrada é válida no estilo de fluxo YAML 1.2 antes mesmo de a conversão começar

YAML 1.2 trata a sintaxe JSON como um subconjunto de estilo de fluxo permitido para dados comuns em formato JSON, o que explica por que um objeto JSON já está próximo de YAML. Mas uma conversão útil normalmente muda para um recuo em estilo de bloco legível por humanos. A entrada é analisada como JSON primeiro; comandos shell arbitrários nunca são executados. ToolAcre carrega YAML por meio de um esquema restrito no caminho reverso, rejeita tags inseguras e limita a expansão de alias, portanto, um conversor não pode ser usado para instanciar objetos arbitrários de uma tag !!js/function não confiável.

Estilo de bloco versus estilo de fluxo — como um conversor escolhe mapeamentos e sequências baseados em indentação em vez de colchetes e colchetes, e o que significa a profundidade de indentação

O estilo de bloco usa pares key/value recuados e linhas começando com um traço para itens da matriz: uma string de imagem em services.web é recuada abaixo da web, enquanto as portas se tornam uma sequência. O estilo de fluxo mantém colchetes e colchetes semelhantes a JSON. ToolAcre usa dump js-yaml com recuo de dois espaços por padrão, sem referências e uma configuração de largura de linha ilimitada, em vez de apenas substituir a pontuação por uma expressão regular. Alterar a largura do recuo afeta a legibilidade, não as chaves reais ou a ordem da matriz.

Quais strings devem permanecer entre aspas — valores que de outra forma se tornariam booleanos, números, nulos ou datas, e strings com dois pontos, hashes ou espaços iniciais

Algumas strings devem ser citadas para sobreviver a outro analisador: "false" deve permanecer como texto em vez de booleano falso, "2026-09-28" não deve se tornar silenciosamente uma data em um consumidor YAML 1.1, e dois pontos seguidos de espaço podem ser confundidos com sintaxe de mapeamento. O dumper de ToolAcre escolhe cotações de proteção, incluindo opções de compatibilidade para leitores YAML mais antigos. Nem sempre é necessário citar uma referência de imagem comum com dois pontos, e remover gratuitamente as aspas presentes pode interromper o processo de ida e volta. Verifique os tipos, bem como a aparência visual.

Strings multilinhas — como uma nova linha dentro de uma string JSON pode se tornar um bloco escalar literal (|) ou dobrado (>)

Uma string JSON contendo uma nova linha real pode ser renderizada como um escalar de bloco YAML com |. O |- formulário remove a nova linha final, enquanto | preserva; > dobraria algumas quebras de linha em espaços. Esses indicadores descrevem dados, não enfeites de formatação. O dumper de ToolAcre escolhe uma representação que pode ler a string original em vez de sempre forçar um estilo. Após a conversão, inspecione cuidadosamente um valor de ambiente multilinha ou certificado: erros de indentação aqui podem alterar o que o aplicativo recebe.

Exemplo resolvido: convertendo uma definição de serviço - um objeto JSON aninhado em YAML, com cada decisão de cotação e estilo anotada

Para um objeto JSON concreto, use services.web com imagem "example/web:1", portas ["8080:80"] e chaves de ambiente DEBUG="false", RELEASE="2026-09-28" e MESSAGE="line uma\nlinha dois". ToolAcre emite imagem: exemplo/web:1 e uma lista de portas; DEBUG fica entre aspas 'false', RELEASE entre aspas '2026-09-28' e MESSAGE usa um bloco |- com duas linhas recuadas. Cada escolha protege os tipos originais. Execute a verificação completa do painel antes de salvar como compose.yaml; o conversor não pode dizer se a imagem existe ou se o serviço será iniciado.

O que isso não cobre — adição de comentários, âncoras ou uma ordem de chave personalizada, nenhum dos quais existe na fonte JSON a ser transportada

JSON não possui comentários, âncoras ou aliases para preservar: um conversor não pode recuperá-los de uma entrada que nunca os continha. Ele também não pode inferir o gerenciamento de segredos específicos do Compose, um pedido de chave personalizado ou a validade da versão API do Kubernetes. Dois arquivos YAML podem serializar os mesmos dados, mas usar espaços em branco e estilos de cotação diferentes. Revise o resultado no programa de destino e evite colar tokens API reais em serviços de conversão externos.

Conclusão: a conversão é uma re-serialização com regras — e como o painel de conversores de sintaxe produz o YAML no seu navegador

A conversão é analisada e serializada novamente sob um conjunto de regras, não uma exclusão de pontuação. Os conversores de sintaxe executam essas operações em seu navegador; inspecione uma configuração confidencial localmente e execute uma viagem de ida e volta em um pequeno objeto de teste antes de aplicar o método a um arquivo maior. Se um valor cotado mudar de tipo no caminho de volta, a formatação não será meramente cosmética e precisará de investigação.