Convertidor de YAML a JSON gratuito

¿Qué es YAML?

YAML (YAML Ain’t Markup Language) es un formato de serialización de datos fácil de leer para humanos, diseñado para ser sencillo de leer y escribir. Se utiliza ampliamente para archivos de configuración, pipelines CI/CD e intercambio de datos entre lenguajes de programación.

¿Por qué convertir YAML a JSON?

• Compatibilidad universal · JSON es compatible con prácticamente todos los lenguajes de programación y herramientas.
• Gestión de configuración · Muchas herramientas esperan JSON para configuración o intercambio de datos.
• Integración de API · Las API web normalmente requieren formato JSON.
• Procesamiento de datos · Convierte archivos de configuración YAML para usar en flujos de trabajo automatizados.

Preguntas frecuentes

¿Qué características de YAML son compatibles?

El convertidor admite todas las características estándar de YAML 1.2, incluidos mapas, listas, tipos escalares (cadenas, números, booleanos, null), anclas y alias, documentos múltiples y estructuras anidadas.

¿Mi estructura YAML compleja se convertirá correctamente?

Sí. El convertidor maneja estructuras profundamente anidadas, matrices de objetos, referencias de anclas y tipos de datos mixtos. Si tu YAML es válido, producirá un JSON equivalente que conserva todas las relaciones entre los datos.

¿Se conservan los comentarios YAML?

No. JSON no admite comentarios, por lo que se eliminan durante la conversión. Solo los datos estructurados de tu YAML se convierten al formato JSON.

Una breve historia de YAML, una escisión de una lista de correo de 2001

La prehistoria de YAML comienza en la lista de correo sml-dev, una rama de los años 2000 de xml-dev que reunió a personas que pensaban que XML era excesivo para los datos editados por humanos. Convergieron dos vías paralelas: el módulo de Perl Data::Denter de Ingy döt Net, escrito como formato de serialización para el módulo Inline de Perl, y el trabajo conjunto de Oren Ben-Kiki y Clark Evans orientado a simplificar XML. El 11 de mayo de 2001, Clark Evans publicó «YAML Draft 0.1» en sml-dev, y el formato se dio a conocer públicamente por primera vez en un artículo de xmlhack al día siguiente.

El desarrollo inicial de las siglas era irónico: Yet Another Markup Language, una pulla a la proliferación de formatos de marcado en 2001. Entre diciembre de 2001 y abril de 2002, los autores adaptaron el retroacrónimo recursivo YAML Ain't Markup Language: en parte para subrayar que YAML es un formato de serialización de datos y no un formato de marcado de documentos como XML o HTML, y en parte porque la broma había envejecido. El desarrollo recursivo sigue siendo hoy el lema oficial en yaml.org.

Cronología de la especificación

• Borrador 0.1: 11 de mayo de 2001, anuncio en la lista de correo sml-dev.
• YAML 1.0: 29 de enero de 2004, la primera especificación estable, de Ben-Kiki, Evans e Ingy döt Net.
• YAML 1.1: 18 de enero de 2005, la versión que la mayoría de los analizadores «heredados» todavía emulan por defecto. Origen del Problema de Noruega y de la mayoría de las verrugas del tipado implícito.
• YAML 1.2.0: 21 de julio de 2009, la primera revisión con un objetivo explícito de «superconjunto de JSON». Tipado implícito reescrito para alinearse con los tokens de JSON.
• YAML 1.2.1: 1 de octubre de 2009, una actualización de la 1.2.0 solo con erratas.
• YAML 1.2.2: 1 de octubre de 2021, la revisión de correcciones del nuevo Equipo de Desarrollo del Lenguaje YAML formado en 2020.

La especificación 1.2.2 es explícita en que «no hay cambios normativos respecto a la especificación de YAML v1.2»; el trabajo consistió en convertir el origen de DocBook a Markdown, regenerar los diagramas a partir de LaTeX en texto plano y abrir el proceso de desarrollo para que los colaboradores externos pudieran presentar pull requests contra la propia especificación. No se ha publicado ningún lenguaje desde 2009: todo error de conformidad de los analizadores desde entonces es o bien un resto de la 1.1 o una desviación de una especificación que lleva ya más de quince años vigente. El tipo MIME oficial application/yaml se finalizó en 2024; las extensiones de archivo .yaml y .yml están reconocidas ambas desde alrededor de 2006, siendo .yaml la recomendada.

La relación con JSON, «casi un superconjunto»

La especificación de YAML 1.2.2 lo expresa con cuidado: «Por pura coincidencia, JSON era casi un subconjunto completo de YAML». JSON apareció entre YAML 1.0 (2004) y YAML 1.1 (2005); los autores de YAML solo descubrieron el solapamiento de forma retroactiva. El objetivo explícito de la revisión 1.2, en sus propias palabras, era «convertir YAML en un superconjunto estricto de JSON», y esto es casi cierto para los documentos de YAML 1.2 con formato JSON, pero no lo es para YAML 1.1.

En términos prácticos: todo documento JSON es YAML 1.2 válido; la asignación en estilo de flujo {"a": 1, "b": [true, null]} se analiza de forma idéntica en ambos. La mayoría de los documentos JSON no son YAML 1.1 válido por las trampas de los booleanos y de Noruega: un documento JSON que contenga la cadena literal "NO" se volvería a emitir como false si se hace una ida y vuelta a través de un analizador 1.1 con la configuración por defecto. Lo contrario nunca es cierto: YAML puede expresar cosas que JSON no puede, comentarios (que se pierden en la conversión), anclas y alias (que se resuelven en la conversión), etiquetas (que normalmente se descartan), flujos de varios documentos (solo sobrevive el primero o todos como matriz) y claves que no son cadenas en las asignaciones.

El Problema de Noruega

La trampa más citada de YAML. Se llama así por Noruega porque el código de país de dos letras ISO 3166-1 de Noruega es NO, y la expresión regular de booleanos de YAML 1.1 reconoce NO como el booleano falso. Escribe country: NO en YAML 1.1 (o en cualquier analizador 1.2 que todavía use por defecto el comportamiento 1.1, que son la mayoría), analízalo, vuélcalo como JSON y obtienes {"country": false}. El error es silencioso: no hay advertencia ni error de tipo, solo corrupción de datos.

La expresión regular completa de booleanos de YAML 1.1 del esquema oficial yaml.org/type/bool.html es:

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

Son seis lexemas (y/n, yes/no, on/off, true/false) con tres variantes de mayúsculas cada uno, veintidós cadenas que se convierten todas en booleanos sin advertencia. Una lista de respuestas válidas [y, n, maybe] se convierte en [true, false, "maybe"]; un indicador de función dark_mode: on se analiza como dark_mode: true; un ajuste de modo de puerto escrito OFF se convierte en false. YAML 1.2 corrigió esto a nivel de especificación: el esquema básico alineado con JSON solo reconoce true, True, TRUE, false, False, FALSE y no reconoce en absoluto y/n/yes/no/on/off. Pero esta corrección no se ha propagado sobre el terreno: PyYAML y LibYAML siguen usando 1.1 por defecto en todas las versiones que se distribuyen actualmente. Este conversor usa js-yaml v4, que usa por defecto el esquema YAML 1.2 / compatible con JSON; es una de las razones por las que un conversor del lado del navegador es en realidad más seguro que ejecutar yaml.load() en PyYAML y convertir desde ahí.

Otras minas del tipado implícito

Números octales. YAML 1.1 seguía la convención de C: un cero inicial significaba octal. Así, 010 se analizaba como el entero 8, y permissions: 0777 (una forma perfectamente natural de escribir un modo de archivo de Unix) se analizaba como 511. La corrección de YAML 1.2 fue exigir un prefijo explícito 0o, igual que el Python moderno: 0o777 es 511 y 0777 es simplemente 777. Los analizadores anclados en los valores por defecto de 1.1 siguen equivocándose en esto.

Números sexagesimales. YAML 1.1 heredó de formatos de serialización anteriores la convención de que cualquier secuencia de grupos de dígitos decimales separados por dos puntos debía analizarse como un entero o un decimal en base 60 (sexagesimal). El caso de uso anunciado eran las duraciones de tiempo: 1:11:00 se analizaría como el entero 4260 (una hora y once minutos expresados en segundos). Esta regla todavía perjudica a la gente en la práctica cuando escribe marcas de tiempo como 21:00 o números de versión como 2:3:4 y se los encuentra coaccionados a enteros en silencio. El sexagesimal se eliminó en silencio en YAML 1.2, pero PyYAML y otros analizadores con 1.1 por defecto todavía lo aplican.

Coacción automática de fechas y horas. YAML 1.1 también detecta automáticamente las marcas de tiempo ISO 8601 y las analiza como el tipo de fecha/hora nativo del lenguaje anfitrión, lo que es un problema si querías una cadena. Escribe version: 2024-01-15 y obtienes un objeto date de Python, no la cadena "2024-01-15". La lección general, machacada por el ensayo «YAML document from hell» de Ruud van Asseldonk: entrecomilla siempre las cadenas que concebiblemente podrían analizarse como otra cosa. Los códigos de país, los números de versión, los modos de archivo, las marcas de tiempo y cualquier valor extraído de un vocabulario fijo deberían ir entre comillas simples o dobles.

Anclas, alias y la clave de fusión

El sistema de anclas/alias de YAML te permite etiquetar un nodo con &name y reutilizarlo más tarde con *name. El ejemplo clásico:

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

Aquí &defaults ancla la asignación, y <<: *defaults (la clave de fusión, una función del esquema 1.1 conservada por la mayoría de los analizadores) la empalma en el bloque de producción. Cuando esto se convierte a JSON, el alias se resuelve por completo: la salida JSON contiene el contenido repetido literal, no una referencia. Las anclas y los alias desaparecen, y las claves de fusión se aplanan.

El famoso modo de fallo de este sistema es el ataque de los mil millones de risas (billion laughs): como las anclas pueden tener alias varias veces y los destinos de los alias pueden contener a su vez alias, un archivo YAML pequeño puede expandirse hasta una estructura enorme en memoria (10 niveles × anidamiento de 10 = 10¹⁰ elementos de cadena). PyYAML, LibYAML y otros tuvieron que añadir límites de expansión para mitigarlo. Los conversores del lado del navegador tienen límites de memoria naturales (la pestaña agotará la memoria mucho antes de que sufra el anfitrión), pero el riesgo estructural es real.

Flujos de varios documentos y front matter

Un flujo de YAML puede contener más de un documento. Los documentos se separan con una línea que contiene exactamente --- (también usada como marcador de fin de directivas al principio del primer documento, razón por la cual el front matter en Jekyll, Hugo y Eleventy va delimitado por líneas ---). Una línea que contiene ... marca el final de un documento sin iniciar uno nuevo, útil en los protocolos de streaming.

Kubernetes usa --- para agrupar varios manifiestos de recursos en un solo archivo. JSON no tiene equivalente. Un conversor tiene tres opciones cuando se topa con YAML de varios documentos: emitir solo el primer documento, emitir una matriz JSON de documentos, o emitir un documento JSON por cada --- separados por saltos de línea (JSON Lines). La mayoría de los conversores usan por defecto la primera o la segunda opción; loadAll de js-yaml devuelve una matriz.

Cadenas multilínea, plegada frente a literal

YAML tiene dos estilos de escalar de bloque. El estilo literal (|) conserva los saltos de línea exactamente. El estilo plegado (>) sustituye los saltos de línea simples por espacios y conserva las líneas en blanco como separadores de párrafo. Ambos aceptan indicadores de recorte: |- y >- eliminan todos los saltos de línea finales, |+ y >+ los conservan todos, y el | o > sin modificar («recorte») conserva un único salto de línea final. Cuando se convierten a JSON, ambos estilos producen valores de cadena ordinarios: el bloque plegado se convierte en una larga cadena con \n incrustados solo en las líneas en blanco conservadas; el bloque literal tiene \n en cada salto de línea.

Qué se pierde en la conversión

• Las representaciones de nulo se colapsan. YAML acepta como nulo null, Null, NULL, ~ y un valor vacío (key: sin nada después). Los cinco se convierten en el null de JSON, sin posibilidad de distinguirlos.
• Los comentarios desaparecen en silencio. Los comentarios de YAML empiezan por # y la especificación 1.2 es explícita en que son solo de presentación, no forman parte del modelo de datos. JSON no tiene sintaxis de comentarios. Si necesitas conservarlos, guárdalos como datos (por ejemplo, un campo _comment) antes de la conversión.
• Las claves que no son cadenas se coaccionan. Las asignaciones de YAML permiten cualquier nodo como clave, incluidos los enteros (1: foo), los booleanos (true: yes) e incluso las secuencias anidadas. JSON exige claves de tipo cadena. La mayoría de los conversores las convierten en cadena ("1": "foo"); algunos lanzan un error.
• Las etiquetas normalmente se descartan. Las etiquetas personalizadas como !!set, !!omap o las específicas de la aplicación !myapp/Type no tienen equivalente en JSON.
• Las fechas y horas hacen la ida y vuelta como cadenas. Una fecha o marca de tiempo de YAML normalmente se convierte en una cadena ISO 8601 en JSON, ya que JSON no tiene un tipo de fecha nativo.
• Los enteros grandes pierden precisión en JavaScript. Los números JSON son dobles IEEE 754 en JS, así que un entero de YAML como 9007199254740993 se convierte en silencio en 9007199254740992 tras la conversión.
• Las anclas se expanden. Un grafo de YAML que comparte un subárbol en varias posiciones se convierte en un árbol JSON con ese subárbol duplicado. Las referencias cíclicas (que YAML permite) no se pueden representar en JSON en absoluto.

Dónde se usa YAML en la práctica

YAML está en todas partes en la infraestructura moderna: manifiestos de Kubernetes (todo el modelo de objetos es YAML por convención; los archivos de varios documentos separados por --- son lo estándar), Docker Compose (docker-compose.yml para servicios, redes y volúmenes), GitHub Actions (.github/workflows/*.yml: en su mayor parte se respeta el esquema estricto de YAML 1.2, pero el analizador todavía reconoce on: como clave, un casi accidente del Problema de Noruega que GitHub sortea de forma explícita), GitLab CI/CD, playbooks de Ansible, CircleCI / Travis CI / Drone / Bitbucket Pipelines, el front matter de Jekyll / Hugo / Eleventy / Gatsby / Astro, las especificaciones de OpenAPI / Swagger (oficialmente «un objeto JSON que puede representarse tanto en JSON como en YAML»), la configuración de la pila de monitorización Prometheus / Grafana / Loki / Tempo, cloud-init (aprovisionamiento de primer arranque de máquinas virtuales de EC2/GCE/Azure) y AWS CloudFormation / Azure Resource Manager / Google Cloud Deployment Manager. Para la mayoría de estos, la conversión de YAML a JSON es esencial siempre que estés incrustando configuración en protocolos que solo admiten JSON, comparando archivos con jq o alimentando la salida a una herramienta que espera JSON.

Por qué la conversión del lado del navegador es más segura que la del lado del servidor

yaml.load() de PyYAML con la configuración por defecto podía ejecutar código Python arbitrario con cualquier entrada no confiable a través de la etiqueta !!python/object, que deserializa en objetos Python reales con efectos secundarios: CVE-2017-18342, puntuación CVSS v3.1 de 9,8 (crítica), corregido en PyYAML 5.1 (marzo de 2019) al declarar obsoleto el valor por defecto inseguro y convertir safe_load() en el punto de entrada recomendado. El SnakeYAML de Java tenía su propio equivalente (CVE-2022-1471, también CVSS 9,8) en torno a la clase Constructor, que permitía la instanciación arbitraria. El crate serde_yaml, el de facto de Rust, quedó obsoleto en marzo de 2024; el ecosistema todavía está decidiéndose por un sucesor (serde_yml, serde_yaml_ng, serde_norway).

Ejecutar el análisis en el navegador mediante js-yaml v4 evita todo esto: no hay servidor que comprometer, js-yaml no tiene el concepto de ejecución de código arbitrario mediante etiquetas (las etiquetas desconocidas se convierten en escalares simples en lugar de en objetos construidos) y la v4 usa por defecto el esquema 1.2, más seguro. La herramienta de Absolutool se beneficia de esto por defecto.

Más preguntas

¿Cómo gestiona el conversor los archivos YAML de varios documentos?

Los carga con loadAll de js-yaml, que devuelve una matriz de documentos analizados; por tanto, la salida JSON es una matriz JSON con un elemento por cada documento separado por ---. Si solo tienes un único documento, obtendrás una matriz JSON con un elemento; envuelve tu entrada con marcadores ---/... si quieres una semántica explícita de documento único.

¿Se convertirá correctamente mi manifiesto de Kubernetes?

Casi siempre, sí. Kubernetes usa en su mayor parte contenido compatible con YAML 1.2, y js-yaml v4 maneja todas las primitivas estándar (cadenas, enteros, booleanos, nulos, secuencias, asignaciones) más las anclas y los alias. Las dos piezas que no sobreviven son los comentarios (que se eliminan) y cualquier ancla que se expanda a contenido repetido en lugar de a referencias.

¿Por qué mi código de país NO se lee como un booleano?

No debería serlo en este conversor: js-yaml v4 usa por defecto el esquema YAML 1.2 / compatible con JSON, que no reconoce y/n/yes/no/on/off como booleanos. Si te topas con esto en una herramienta distinta (PyYAML, por ejemplo), la solución es envolver el valor entre comillas: country: "NO".

¿Cuál es el límite de tamaño de archivo?

5 MB en el widget de subida, pero el contenido pegado puede ser mayor si tu navegador tiene memoria suficiente. El cuello de botella es la representación en memoria, no la red: no hay ningún servidor en el proceso. Para archivos de más de ~50 MB, considera mejor una cadena de herramientas de YAML de escritorio (por ejemplo, yq en la línea de comandos).

Herramientas relacionadas