Conversor de YAML para JSON gratuito

O que é YAML?

YAML (YAML Ain’t Markup Language) é um formato de serialização de dados amigável para humanos, projetado para ser fácil de ler e escrever. É amplamente usado para arquivos de configuração, pipelines de CI/CD e troca de dados entre linguagens de programação.

Por que converter YAML para JSON?

• Compatibilidade universal · JSON é suportado por praticamente todas as linguagens de programação e ferramentas.
• Gerenciamento de configuração · Muitas ferramentas esperam JSON para configuração ou troca de dados.
• Integração de API · APIs web normalmente exigem o formato JSON.
• Processamento de dados · Converta arquivos de configuração YAML para uso em fluxos de trabalho automatizados.

Perguntas frequentes

Quais recursos do YAML são suportados?

O conversor suporta todos os recursos padrão do YAML 1.2, incluindo mapas, listas, tipos escalares (strings, números, booleanos, null), âncoras e aliases, documentos múltiplos e estruturas aninhadas.

Minha estrutura YAML complexa será convertida corretamente?

Sim. O conversor lida com estruturas profundamente aninhadas, arrays de objetos, referências de âncoras e tipos de dados mistos. Se o seu YAML for válido, ele produzirá um JSON equivalente preservando todas as relações entre os dados.

Os comentários YAML são preservados?

Não. JSON não suporta comentários, portanto eles são removidos durante a conversão. Apenas os dados estruturados do seu YAML são convertidos para o formato JSON.

Uma breve história do YAML, uma ramificação de uma lista de discussão de 2001

A pré-história do YAML começa na lista de discussão sml-dev, uma ramificação dos anos 2000 da xml-dev que reuniu pessoas que achavam o XML exagerado para dados editados por humanos. Duas frentes paralelas convergiram: o módulo Perl Data::Denter de Ingy döt Net, escrito como um formato de serialização para o módulo Inline do Perl, e o trabalho conjunto de Oren Ben-Kiki e Clark Evans voltado a simplificar o XML. Em 11 de maio de 2001, Clark Evans publicou o «YAML Draft 0.1» na sml-dev, e o formato foi divulgado pela primeira vez em um artigo da xmlhack no dia seguinte.

O significado inicial da sigla era irônico: Yet Another Markup Language (mais uma linguagem de marcação), uma alfinetada na proliferação de formatos de marcação em 2001. Entre dezembro de 2001 e abril de 2002, os autores adaptaram o acrônimo recursivo YAML Ain't Markup Language (YAML não é linguagem de marcação): em parte para destacar que o YAML é um formato de serialização de dados, e não um formato de marcação de documentos como o XML ou o HTML, e em parte porque a piada já tinha envelhecido. O significado recursivo continua sendo o slogan oficial no yaml.org até hoje.

Linha do tempo da especificação

• Draft 0.1: 11 de maio de 2001, anúncio na lista de discussão sml-dev.
• YAML 1.0: 29 de janeiro de 2004, a primeira especificação estável, por Ben-Kiki, Evans e Ingy döt Net.
• YAML 1.1: 18 de janeiro de 2005, a versão que a maioria dos parsers «legados» ainda emula por padrão. Origem do Problema da Noruega e da maioria das verrugas de tipagem implícita.
• YAML 1.2.0: 21 de julho de 2009, a primeira revisão com a meta explícita de ser um «superconjunto do JSON». Tipagem implícita reescrita para se alinhar aos tokens do JSON.
• YAML 1.2.1: 1 de outubro de 2009, uma atualização apenas de errata da 1.2.0.
• YAML 1.2.2: 1 de outubro de 2021, a revisão de corrigenda feita pela nova YAML Language Development Team, formada em 2020.

A especificação 1.2.2 é explícita ao dizer que «não há mudanças normativas em relação à especificação YAML v1.2»; o trabalho consistiu em converter o código-fonte de DocBook para Markdown, regenerar os diagramas a partir de LaTeX em texto simples e abrir o processo de desenvolvimento para que contribuidores externos pudessem enviar pull requests contra a própria especificação. Nenhuma versão da linguagem foi lançada desde 2009: todo bug de conformidade de parser desde então é ou um resquício da 1.1 ou um desvio de uma especificação que já se mantém há mais de quinze anos. O tipo MIME oficial application/yaml foi finalizado em 2024; as extensões de arquivo .yaml e .yml são reconhecidas desde por volta de 2006, sendo a .yaml a recomendada.

O «quase superconjunto»: a relação com o JSON

A especificação YAML 1.2.2 coloca a questão com cuidado: «Por pura coincidência, o JSON era quase um subconjunto completo do YAML». O JSON surgiu entre o YAML 1.0 (2004) e o YAML 1.1 (2005); os autores do YAML só descobriram a sobreposição retroativamente. A meta explícita da revisão 1.2, em suas próprias palavras, era «tornar o YAML um superconjunto estrito do JSON», e isso é quase verdadeiro para documentos YAML 1.2 formatados como JSON, mas não é verdadeiro para o YAML 1.1.

Em termos práticos: todo documento JSON é YAML 1.2 válido, e o mapeamento em estilo de fluxo {"a": 1, "b": [true, null]} é interpretado de forma idêntica nos dois. A maioria dos documentos JSON não é YAML 1.1 válido por causa das pegadinhas de booleanos e da Noruega: um documento JSON contendo a string literal "NO" seria reemitido como false se passasse por um ciclo de ida e volta em um parser 1.1 com as configurações padrão. O contrário nunca é verdadeiro: o YAML consegue expressar coisas que o JSON não consegue, como comentários (perdidos na conversão), âncoras e aliases (resolvidos na conversão), tags (geralmente descartadas), fluxos de múltiplos documentos (só o primeiro ou todos como array sobrevivem) e chaves não textuais em mapeamentos.

O Problema da Noruega

A pegadinha mais citada do YAML. Recebe o nome da Noruega porque o código de país de duas letras ISO 3166-1 para a Noruega é NO, e a regex de booleanos do YAML 1.1 reconhece NO como o booleano falso. Escreva country: NO no YAML 1.1 (ou em qualquer parser 1.2 que ainda use o comportamento 1.1 por padrão, o que vale para a maioria deles), interprete-o, gere-o como JSON e você obtém {"country": false}. O bug é silencioso: não há aviso, não há erro de tipo, apenas corrupção de dados.

A regex completa de booleanos do YAML 1.1, do schema oficial yaml.org/type/bool.html, é:

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

São seis lexemas (y/n, yes/no, on/off, true/false) com três variantes de caixa cada, vinte e duas strings que viram booleanos sem aviso. Uma lista de respostas válidas [y, n, maybe] vira [true, false, "maybe"]; uma feature flag dark_mode: on é interpretada como dark_mode: true; uma configuração de modo de porta escrita OFF vira false. O YAML 1.2 corrigiu isso no nível da especificação: o core schema alinhado ao JSON só reconhece true, True, TRUE, false, False, FALSE e não reconhece y/n/yes/no/on/off de forma alguma. Mas essa correção não se propagou pela prática: PyYAML e LibYAML ainda usam o 1.1 por padrão em todas as versões atualmente distribuídas. Este conversor usa o js-yaml v4, que adota por padrão o schema YAML 1.2 / compatível com JSON; é uma das razões pelas quais um conversor no lado do navegador é, na verdade, mais seguro do que rodar yaml.load() no PyYAML e converter a partir daí.

Outras armadilhas de tipagem implícita

Números octais. O YAML 1.1 seguia a convenção da linguagem C: um zero à esquerda significava octal. Então 010 era interpretado como o inteiro 8, e permissions: 0777 (uma forma perfeitamente natural de escrever um modo de arquivo Unix) era interpretado como 511. A correção do YAML 1.2 foi exigir um prefixo explícito 0o, igual ao do Python moderno: 0o777 é 511, e 0777 é apenas 777. Parsers presos nos padrões da 1.1 ainda erram isso.

Números sexagesimais. O YAML 1.1 herdou de formatos de serialização anteriores a convenção de que qualquer sequência de grupos de dígitos decimais separados por dois-pontos deveria ser interpretada como um inteiro ou número de ponto flutuante de base 60 (sexagesimal). O caso de uso anunciado eram durações de tempo: 1:11:00 seria interpretado como o inteiro 4260 (uma hora e onze minutos, em segundos). Essa regra ainda incomoda na prática quando se escrevem timestamps como 21:00 ou números de versão como 2:3:4 e eles são silenciosamente convertidos em inteiros. O sexagesimal foi removido silenciosamente no YAML 1.2, mas PyYAML e outros parsers com padrão 1.1 ainda o aplicam.

Coerção automática de data e hora. O YAML 1.1 também detecta automaticamente timestamps ISO 8601 e os interpreta como o tipo nativo de data/hora da linguagem hospedeira, o que é um problema se você queria uma string. Escreva version: 2024-01-15 e você obtém um objeto date do Python, não a string "2024-01-15". A lição geral, martelada pelo ensaio «YAML document from hell» de Ruud van Asseldonk: sempre coloque entre aspas as strings que possam, por algum motivo, ser interpretadas como outra coisa. Códigos de país, números de versão, modos de arquivo, timestamps e qualquer valor extraído de um vocabulário fixo devem ser envolvidos em aspas simples ou duplas.

Âncoras, aliases e a chave de merge

O sistema de âncoras/aliases do YAML permite rotular um nó com &name e reutilizá-lo mais tarde com *name. O exemplo clássico:

defaults: &defaults
  timeout: 30
  retries: 3
production:
  <<: *defaults
  host: prod.example.com

Aqui, &defaults ancora o mapeamento, e <<: *defaults (a chave de merge, um recurso do schema 1.1 mantido pela maioria dos parsers) insere-o no bloco de produção. Quando isso é convertido para JSON, o alias é totalmente resolvido: a saída JSON contém o conteúdo repetido literalmente, não uma referência. As âncoras e os aliases desaparecem, e quaisquer chaves de merge são achatadas.

O famoso modo de falha desse sistema é o ataque billion laughs: como as âncoras podem ser referenciadas por aliases várias vezes e os alvos de alias podem, eles próprios, conter aliases, um pequeno arquivo YAML pode se expandir em uma estrutura enorme na memória (10 níveis × aninhamento de 10 vezes = 10¹⁰ elementos de string). PyYAML, LibYAML e outros tiveram de adicionar limites de expansão para mitigar isso. Conversores no lado do navegador têm limites naturais de memória (a aba estoura a memória muito antes de o sistema sofrer), mas o risco estrutural é real.

Fluxos de múltiplos documentos e front matter

Um fluxo YAML pode conter mais de um documento. Os documentos são separados por uma linha contendo exatamente --- (também usada como marcador de fim de diretivas no início do primeiro documento, e é por isso que o front matter em Jekyll, Hugo e Eleventy fica delimitado por linhas ---). Uma linha contendo ... marca o fim de um documento sem iniciar um novo, útil em protocolos de streaming.

O Kubernetes usa --- para agrupar vários manifestos de recursos em um único arquivo. O JSON não tem equivalente. Um conversor tem três opções ao encontrar YAML de múltiplos documentos: emitir apenas o primeiro documento, emitir um array JSON de documentos ou emitir um documento JSON por --- separado por quebras de linha (JSON Lines). A maioria dos conversores usa por padrão a primeira ou a segunda opção; o loadAll do js-yaml retorna um array.

Strings de múltiplas linhas: dobrado vs. literal

O YAML tem dois estilos de escalar em bloco. O estilo literal (|) preserva as quebras de linha exatamente. O estilo dobrado (>) substitui quebras de linha simples por espaços e preserva linhas em branco como separadores de parágrafo. Ambos aceitam indicadores de corte (chomping): |- e >- removem todas as quebras de linha finais, |+ e >+ mantêm todas elas, e o | ou > sem modificação («clip») preserva uma única quebra de linha final. Quando convertidos para JSON, os dois estilos produzem valores de string comuns: o bloco dobrado vira uma única string longa com \n embutido apenas nas linhas em branco preservadas; o bloco literal tem \n em cada quebra de linha.

O que se perde na conversão

• As representações de nulo se fundem. O YAML aceita null, Null, NULL, ~ e um valor vazio (key: sem nada depois) como nulo. Todos os cinco viram null no JSON, de forma indistinguível.
• Os comentários desaparecem silenciosamente. Os comentários YAML começam com # e a especificação 1.2 é explícita ao dizer que eles são apenas de apresentação, não fazem parte do modelo de dados. O JSON não tem sintaxe de comentário. Se você precisar preservá-los, armazene-os como dados (por exemplo, em um campo _comment) antes da conversão.
• Chaves não textuais são convertidas. Os mapeamentos YAML permitem qualquer nó como chave, incluindo inteiros (1: foo), booleanos (true: yes) e até sequências aninhadas. O JSON exige chaves de string. A maioria dos conversores transforma em string ("1": "foo"); alguns lançam erro.
• As tags geralmente são descartadas. Tags personalizadas como !!set, !!omap ou !myapp/Type, específicas de uma aplicação, não têm equivalente em JSON.
• Datas e horas fazem a ida e volta como strings. Uma data ou timestamp YAML geralmente vira uma string ISO 8601 no JSON, já que o JSON não tem tipo de data nativo.
• Inteiros grandes perdem precisão em JavaScript. Os números JSON são doubles IEEE 754 em JS, então um inteiro YAML como 9007199254740993 vira silenciosamente 9007199254740992 depois da conversão.
• As âncoras são expandidas. Um grafo YAML que compartilha uma subárvore em várias posições vira uma árvore JSON com essa subárvore duplicada. Referências cíclicas (que o YAML permite) não são representáveis em JSON de forma alguma.

Onde o YAML é realmente usado

O YAML está em toda parte na infraestrutura moderna: manifestos do Kubernetes (todo o modelo de objetos é YAML por convenção; arquivos de múltiplos documentos separados por --- são o padrão), Docker Compose (docker-compose.yml para serviços, redes, volumes), GitHub Actions (.github/workflows/*.yml: o schema estrito do YAML 1.2 é, em grande parte, seguido, mas o parser ainda reconhece on: como uma chave, um quase-acidente do Problema da Noruega que o GitHub contorna explicitamente), GitLab CI/CD, playbooks do Ansible, CircleCI / Travis CI / Drone / Bitbucket Pipelines, front matter de Jekyll / Hugo / Eleventy / Gatsby / Astro, especificações OpenAPI / Swagger (oficialmente «um objeto JSON que pode ser representado tanto em JSON quanto em YAML»), configuração da pilha de monitoramento Prometheus / Grafana / Loki / Tempo, cloud-init (provisionamento de primeiro boot de VMs EC2/GCE/Azure) e AWS CloudFormation / Azure Resource Manager / Google Cloud Deployment Manager. Para a maioria deles, a conversão de YAML para JSON é essencial sempre que você está embutindo configuração em protocolos que só aceitam JSON, comparando arquivos com jq ou alimentando a saída para uma ferramenta que espera JSON.

Por que a conversão no lado do navegador é mais segura que no lado do servidor

O yaml.load() do PyYAML, com as configurações padrão, podia executar código Python arbitrário a partir de qualquer entrada não confiável por meio da tag !!python/object, que desserializa em objetos Python reais com efeitos colaterais, a CVE-2017-18342, com nota CVSS v3.1 de 9,8 (Crítica), corrigida no PyYAML 5.1 (março de 2019) ao tornar obsoleto o padrão inseguro e fazer do safe_load() o ponto de entrada recomendado. O SnakeYAML do Java teve seu próprio equivalente (a CVE-2022-1471, também CVSS 9,8) em torno da classe Constructor, que permitia instanciação arbitrária. O crate serde_yaml, de fato o padrão do Rust, foi descontinuado em março de 2024; o ecossistema ainda está se acomodando em torno de um sucessor (serde_yml, serde_yaml_ng, serde_norway).

Rodar a interpretação no navegador via js-yaml v4 contorna tudo isso: não há servidor a ser comprometido, o js-yaml não tem o conceito de execução de código arbitrário por meio de tags (tags desconhecidas viram escalares simples, em vez de objetos construídos) e o v4 adota por padrão o schema 1.2, mais seguro. A ferramenta da Absolutool se beneficia disso por padrão.

Mais perguntas

Como o conversor lida com arquivos YAML de múltiplos documentos?

Ele os carrega com o loadAll do js-yaml, que retorna um array de documentos interpretados; a saída JSON é, portanto, um array JSON com um elemento por documento separado por ---. Se você tiver apenas um único documento, obterá um array JSON com um elemento; envolva sua entrada em marcadores ---/... se quiser semântica explícita de documento único.

Meu manifesto do Kubernetes será convertido corretamente?

Quase sempre sim. O Kubernetes usa, em grande parte, conteúdo compatível com YAML 1.2, e o js-yaml v4 lida com todos os primitivos padrão (strings, inteiros, booleanos, nulos, sequências, mapeamentos), além de âncoras e aliases. As duas partes que não sobrevivem são os comentários (removidos) e quaisquer âncoras que sejam expandidas em conteúdo repetido, em vez de referências.

Por que meu código de país NO está sendo lido como um booleano?

Não deveria estar, neste conversor: o js-yaml v4 adota por padrão o schema YAML 1.2 / compatível com JSON, que não reconhece y/n/yes/no/on/off como booleanos. Se você estiver enfrentando isso em outra ferramenta (o PyYAML, por exemplo), a correção é envolver o valor em aspas: country: "NO".

Qual é o limite de tamanho de arquivo?

5 MB no widget de upload, mas o conteúdo colado pode ser maior se o seu navegador tiver memória. O gargalo é a representação na memória, não a rede; não há servidor no caminho. Para arquivos maiores que ~50 MB, considere usar um conjunto de ferramentas YAML de desktop (o yq na linha de comando, por exemplo).

Ferramentas relacionadas