Conversor de JSON para YAML

1. 1

   Colar ou carregar JSON

   Cole JSON no editor ou solte um arquivo .json, .ndjson ou .jsonl na página. Nada é enviado — o arquivo é lido no seu dispositivo.

2. 2

   Escolher o analisador de destino

   Portável é o padrão e coloca entre aspas todo valor que um analisador YAML 1.1 ou com resolução de timestamps leria como outro tipo. Escolha YAML 1.2 para o mínimo de aspas, ou tudo entre aspas quando você não souber quem vai ler.

3. 3

   Definir a apresentação

   Escolha a indentação, como null é escrito e se o documento começa com ---. A pré-visualização se atualiza a cada alteração.

4. 4

   Converter e conferir o resultado

   Clique em Converter para YAML. O resultado é relido com um analisador independente e comparado com o seu JSON original, e o selo diz se todos os valores sobreviveram.

5. 5

   Baixar ou copiar

   Baixe o arquivo .yaml ou copie-o. Para o sentido inverso existe a ferramenta YAML para JSON.

Este conversor gratuito transforma JSON em YAML no seu dispositivo. Cole ou carregue JSON, escolha o analisador para o qual o seu YAML é escrito, e o conversor põe entre aspas exatamente os valores que de outro modo mudariam de tipo pelo caminho. Cada resultado é relido com um analisador independente e comparado com o seu JSON original antes de ser oferecido a você. JSON inválido é localizado ao caractere, com cursor e uma saída.

• Aspas para um analisador nomeado — Escolha YAML 1.2, portável ou tudo entre aspas. Portável é o padrão e é seguro com PyYAML, js-yaml, Psych do Ruby e Go.
• Verificação de ida e volta — O YAML é relido com um analisador independente e comparado valor a valor com o seu JSON. O selo nomeia o primeiro caminho divergente, se existir.
• Strings multilinha legíveis — Uma string com quebras de linha é escrita como literal de bloco, para que scripts, certificados e SQL continuem legíveis em vez de colapsarem em escapes.
• NDJSON na entrada, YAML multidocumento na saída — Um valor JSON por linha passa a um documento YAML por linha de entrada, separados por ---. As linhas em branco são ignoradas.
• Erros localizados no seu dispositivo — Mensagem, linha, coluna, um cursor sob o caractere exato e o que ali era esperado — idênticos em todos os navegadores, em vez do que reporta o analisador do navegador.
• No seu dispositivo, não nos nossos servidores — O arquivo é lido, analisado, convertido e verificado localmente. Não há passo de envio, portanto não há nada a que recusar.

Esta é a configuração que decide se a conversão está correta e é a razão de ser desta ferramenta. O YAML não tem uma forma única e acordada de ler uma palavra sem aspas: o mesmo arquivo significa coisas diferentes para analisadores diferentes, e um conversor que usa o mínimo de aspas está apostando em qual deles você vai usar.

• Portável (padrão) — Põe entre aspas a união de tudo o que um analisador YAML 1.2 base, um YAML 1.1 e um com resolução de timestamps retipariam. Um pouco mais de aspas; os mesmos valores em toda parte.
• YAML 1.2 — Aspas mínimas, seguindo o esquema base do YAML 1.2. Correto se — e só se — quem lê o arquivo for um analisador 1.2 sem resolução de timestamps. A ferramenta continua contando e reportando os valores que um leitor 1.1 mudaria.
• Tudo entre aspas — Todas as strings vão entre aspas. Verboso, inequívoco e a resposta certa quando você não faz ideia do que vai ler o arquivo.
• Quem lê YAML 1.1 — O PyYAML e, portanto, o Ansible e o SaltStack, o Psych do Ruby e uma longa cauda de ferramentas construídas sobre eles. Não é um canto legado: é boa parte do mundo da infraestrutura.

Não são strings exóticas. São as que as pessoas realmente guardam em arquivos de configuração, e cada uma volta de um analisador não avisado como um tipo diferente. O modo portável põe todas entre aspas; o modo YAML 1.2 só trata a primeira linha e informa quantas das restantes ficaram sem aspas.

• true, false, null, 12, 1.5, 0x1F — Retipados por todos os analisadores, incluindo o YAML 1.2. Sempre entre aspas, em todos os modos.
• yes, no, on, off, y, n — Strings em YAML 1.2. Booleanos em YAML 1.1 — um valor de configuração «no» passa a false no Ansible.
• 0755, 0644 — Uma permissão de arquivo e, para um analisador YAML 1.1, um inteiro octal com zero inicial: 0755 passa a 493.
• 1:30, 12:30:45 — Para você, uma duração ou uma hora; para um analisador YAML 1.1, inteiros de base 60, que lê 1:30 como 90.
• 2024-01-01 — Um objeto de data para tudo o que resolve timestamps, incluindo o esquema padrão do js-yaml, o PyYAML e o yaml.v3 do Go.
• 1_000, 0b1010 — Strings pela letra da especificação 1.2, inteiros para o js-yaml. Postos entre aspas mesmo assim, porque o que conta é o leitor e não a especificação.

O mapeamento é direto e a estrutura do seu documento é preservada exatamente. Nada é reordenado, nada se perde e nenhuma chave é renomeada.

• Objetos — Blocos indentados de chave e valor. A ordem das chaves é preservada, a menos que você peça chaves ordenadas.
• Arrays — Listas com travessão. Uma lista dentro de um mapa pode ficar indentada ou alinhada com a coluna da chave.
• Objeto e array vazios — São escritos {} e [] em vez de ficarem em branco, porque um valor em branco seria relido como null e mudaria a forma em silêncio.
• null — Escrito null por padrão, ou como til, ou vazio. A forma vazia é usada apenas para valores de mapa — veja a nota sobre apresentação mais abaixo.
• Strings com quebras de linha — Literais de bloco, com o indicador de corte escolhido a partir das quebras finais para que a string volte exatamente igual.
• Chaves — Entre aspas pelas mesmas regras dos valores. Uma chave «n» ou «yes» leva aspas, porque sem elas se torna uma chave booleana num leitor YAML 1.1.

Um script de shell dentro de um ConfigMap, um certificado PEM, uma instrução SQL: são os valores que mais se quer manter legíveis e os que um conversor ingênuo esmaga numa única linha de escapes.

• Literais de bloco — Uma string multilinha é escrita depois de um | para que as linhas continuem linhas. O indicador de corte vem das quebras finais, de modo que nenhuma se ganha nem se perde.
• Quando não se pode usar um bloco — Uma string cuja primeira linha está em branco ou indentada, ou que contém um retorno de carro ou um caractere de controle, leva aspas em vez disso. Esses casos precisam de um indicador de indentação explícito, e errá-lo é corrupção silenciosa.
• Quebrar linhas longas (Pro) — Uma coluna de quebra dobra valores longos com uma quebra de linha escapada, a única forma de quebra em YAML que é exatamente reversível. Escalares simples e de bloco dobrados não o são, por isso um valor a quebrar é primeiro posto entre aspas.
• Sem dobras acidentais — Com a quebra desligada — o padrão — as strings longas ficam numa única linha, por isso nada é reformatado na saída.

NDJSON — também chamado JSON Lines — é um valor JSON por linha e é o que produzem os pipelines de registros, as exportações de bancos de dados e o jq -c. Como arquivo completo não é JSON válido, por isso a maioria dos conversores o rejeita.

• Detectado de duas formas — Pela extensão .ndjson ou .jsonl e pelo conteúdo: um arquivo que não é um único documento JSON válido mas cujas linhas não vazias analisam cada uma por si.
• Um documento por registro — Cada valor passa a documento YAML próprio, separado por ---, que é como qualquer analisador lê um fluxo YAML.
• Um array numa linha não é NDJSON — [1,2] é um documento JSON válido, por isso é convertido como um só. É exatamente por isso que a leitura de documento único é tentada primeiro.
• Uma linha inválida para a conversão — É reportado o número da linha, em vez de produzir um fluxo meio convertido com registros descartados em silêncio.

Nenhuma destas muda o significado do documento. Todas mudam como ele se lê, e a pré-visualização se atualiza à medida que você as ajusta.

• Indentação — De 1 a 8 espaços por nível. Dois é o padrão e o que a maioria das ferramentas YAML espera.
• Estilo de null — null, um til ou vazio. A forma vazia é usada apenas para valores de mapa: uma entrada de lista vazia no fim de uma lista aninhada é lida de forma diferente por analisadores diferentes, por isso aí é escrita como til.
• Marcador de documento — Começar o arquivo com ---. Entre documentos de um fluxo é sempre emitido, independentemente desta configuração.
• Ordenar chaves (Pro) — Chaves alfabéticas, para diffs que não se mexem quando um produtor reordena a sua saída.
• Estilo de aspas (Pro) — Aspas simples ou duplas onde forem precisas. As simples recuam para as duplas em qualquer string que não consigam representar.
• Indentação de listas (Pro) — Indentar uma lista sob a sua chave ou alinhá-la com a coluna da chave — o estilo dos manifestos Kubernetes e menos quatro colunas em cada lista.
• Estilo multilinha (Pro) — Literais de bloco legíveis ou uma única linha entre aspas duplas com escapes.

Todos os outros conversores desta categoria entregam YAML e deixam você descobrir mais tarde se ainda significa o que o seu JSON significava. Este confere antes de você baixar qualquer coisa.

• Um leitor independente — O resultado é analisado por uma implementação diferente daquela que o escreveu. Um escritor conferido pelo seu próprio leitor nada prova: ambos compartilhariam qualquer mal-entendido.
• Comparado valor a valor — Contra o seu JSON original, não contra uma cópia reserializada. Os tipos também são comparados, por isso uma string que volta como data falha.
• A primeira diferença é nomeada — Por caminho — /servers/3/started — com ambos os tipos e ambos os valores, em vez de um seco «verificação falhou» num arquivo de 40 000 linhas.
• Lido contra o analisador que você escolheu — A verificação usa o esquema do seu destino, por isso verificado significa sempre verificado para o leitor para o qual você disse estar escrevendo.
• Pode ser desligada — Custa uma segunda leitura do documento. Num arquivo grande de forma conhecida talvez você não a queira; a configuração é sua, e o resultado fica marcado como desatualizado se você a mudar.

Impulsionado por algoritmos de processamento otimizados.

O YAML é o formato de configuração do mundo da infraestrutura e o JSON é o que quase tudo produz. Converter entre os dois é como os dados de uma API, de um banco de dados ou de um aplicativo acabam num manifesto Kubernetes, num arquivo Compose, num fluxo do GitHub Actions ou num playbook do Ansible.

• Fluxos de configuração — Reutilizar dados em forma de JSON no Kubernetes, no Docker Compose, no GitHub Actions, no Ansible e em tudo o mais que leia YAML.
• Legibilidade — O YAML dispensa chaves e aspas, por isso um documento aninhado é mais fácil de ler e de rever num pull request.
• Comentários — O YAML aceita comentários e o JSON não, por isso converter é muitas vezes o primeiro passo para transformar dados gerados em algo que uma pessoa vai manter.
• Aqui a correção pesa mais — Um arquivo de configuração é executado. Uma string de versão que vira número, ou uma permissão que vira octal, não falha em alto e bom som: é implantada.
• Privacidade — Nada é enviado, por isso uma resposta de API com credenciais ou dados de clientes nunca sai da máquina onde foi aberta.

• YAML para JSON
• Formatador JSON
• Validador JSON
• Minificador JSON
• JSON para XML
• Visualizador JSON