Convertidor YAML-JSON

Acerca del Convertidor YAML-JSON

El Convertidor YAML-JSON es una herramienta en línea gratuita para convertir entre formatos YAML (YAML Ain't Markup Language) y JSON (JavaScript Object Notation). Sube archivos o pega datos, personaliza las opciones de formato y descarga archivos convertidos, todo procesado localmente en tu navegador para total privacidad.

¿Debo usar JSON o YAML para mi proyecto?

Usa JSON para comunicación máquina-a-máquina y YAML para configuración editada por humanos. JSON es estricto, rápido de analizar y tiene una sola escritura válida para cualquier documento, lo que lo hace ideal para APIs, archivos de log y estado serializado. YAML es un superconjunto estricto de JSON 1.2 (según la especificación YAML 1.2) que añade comentarios, cadenas multilínea sin escape, anclas y alias para evitar repetición, y una sintaxis basada en indentación mucho más concisa — todo genial para manifiestos Kubernetes, flujos de GitHub Actions y playbooks Ansible donde un humano es el autor principal. Evita YAML donde importe la seguridad con entrada no confiable (los ataques históricos "Billion Laughs" y de ejecución por tag viven ahí) y evita JSON donde quieras comentarios. El tipo MIME oficial de YAML registrado en RFC 9512 es application/yaml; JSON usa application/json de RFC 8259.

¿Por qué mi valor YAML "1.23" se vuelve un número cuando quiero una cadena?

Este es el escollo YAML más notorio y muerde a cada operador Kubernetes al menos una vez. YAML 1.1 autodetecta tipos escalares desde su sintaxis: 1.23 es un flotante, 42 es un entero, true / yes / on son booleanos, null y ~ son nulos. Así un campo version: 1.10 silenciosamente pierde el cero final y se vuelve 1.1; un campo country con NO se vuelve el booleano false; y un número de serie 0123 se vuelve el entero octal 83. Para forzar una cadena, entrecomilla el valor (version: "1.10") o usa la etiqueta de tipo explícita (version: !!str 1.10). YAML 1.2 reduce el conjunto booleano implícito solo a true y false, pero la mayoría de analizadores del mundo real (PyYAML, JS yaml sin opciones, Kubernetes) aún por defecto al comportamiento 1.1. Siempre entrecomilla valores cadena que podrían parecer numéricos, booleanos o null.

¿Cómo funcionan las anclas y alias en YAML — y JSON tiene un equivalente?

Las anclas YAML (&nombre) capturan un nodo y los alias (*nombre) lo reutilizan, dejándote escribir un valor una vez y referenciarlo en otro lugar del mismo documento. La clave de fusión << también permite mezclar un mapeo. JSON no tiene equivalente — cada valor debe escribirse completo — así cuando este convertidor va de YAML a JSON debe materializar (expandir) cada alias en una copia separada de los datos, lo que puede inflar el tamaño de documentos que confiaban mucho en aliasing. Yendo al revés, de JSON a YAML, este convertidor opcionalmente reintroduce anclas para nodos que aparecen idénticamente múltiples veces si habilitas la opción "compactar subárboles idénticos". Las anclas son también el vector del infame ataque YAML "Billion Laughs", así que la mayoría de bibliotecas YAML modernas limitan profundidad de alias y tamaño de expansión por defecto.

¿Cuál es la diferencia entre YAML 1.1, YAML 1.2 y YAML 1.2.2?

YAML 1.1 (2005) es la versión que la mayoría de analizadores legados aún implementan por defecto — incluyendo PyYAML, snakeyaml y la stdlib de Ruby. Permite los booleanos yes/no/on/off/true/false en cualquier mayúscula, acepta números octales vía cero inicial (0123 = 83) y parsea notación científica agresivamente. YAML 1.2 (2009) realineó la especificación para ser un superconjunto estricto de JSON, redujo booleanos solo a true/false, eliminó la regla de octal con cero inicial (usa 0o123 como JSON5) y endureció muchos casos límite. YAML 1.2.2 (2021) es una revisión aclaratoria de 1.2 sin cambios incompatibles — la mayoría de bibliotecas YAML JavaScript son compatibles 1.2.2. Este convertidor apunta a YAML 1.2 por defecto. Si mantienes playbooks Ansible, manifiestos Kubernetes o cualquier cosa generada por una herramienta Python, espera rarezas 1.1 en el campo y entrecomilla escalares ambiguos defensivamente.

¿Puedo incluir comentarios al convertir YAML a JSON?

Estrictamente no. La RFC 8259 prohíbe comentarios en JSON, y cualquier analizador JSON que valga la pena los rechazará como error de sintaxis. Los comentarios YAML (# lo que sea) se eliminan durante la conversión y desaparecen por completo del JSON de salida. Si preservar comentarios es crítico — por ejemplo, generas JSON desde una config YAML editada a mano y quieres que el JSON siga siendo revisable — escribe los comentarios a un archivo separado, o cambia el formato de salida a JSON5 (que permite ambos // y /* */ comentarios) o JSONC (JSON con comentarios, ampliamente usado por archivos de configuración VS Code). Yendo al revés (JSON a YAML), este convertidor no tiene comentarios que añadir porque la fuente no contiene ninguno, pero puedes pegar el YAML resultante en tu editor y añadir comentarios de documentación libremente.

¿Cómo funcionan las cadenas multilínea y qué estilo YAML debería elegir?

YAML ofrece dos estilos de escalar de bloque para texto multilínea. El bloque literal | preserva cada salto de línea exactamente — elígelo para fragmentos de código, arte ASCII o cualquier cosa donde los saltos de línea sean semánticos. El bloque plegado > colapsa cada salto de línea individual a un espacio (tratando líneas sucesivas como un párrafo) pero preserva separadores de línea en blanco — elígelo para prosa. Ambos estilos soportan indicadores de chomping: |+ mantiene todos los saltos finales, |- elimina todos los saltos finales y | (sin indicador) mantiene exactamente un salto final. JSON no tiene sintaxis multilínea — cada salto de línea en un valor debe codificarse como \n — así este convertidor expande un bloque literal YAML de tres líneas en una sola cadena JSON con dos caracteres \n. Cuida la indentación: la indentación del contenido de bloque se elimina de cada línea, así que líneas mal alineadas producen salida irregular.

¿Cómo convierto por streaming un archivo YAML multi-documento o un JSON enorme?

Un archivo YAML puede contener múltiples documentos separados por marcadores --- (usado a menudo en manifiestos Kubernetes que empaquetan varios recursos). Este convertidor los carga todos y produce un arreglo JSON de documentos en la salida; el inverso convierte un arreglo JSON de vuelta en un flujo YAML multi-documento. Para archivos más grandes que el navegador pueda manejar cómodamente (por encima de ~50 MB), usa herramientas de línea de comandos: yq (jq para YAML) maneja ambas direcciones con yq -o=json input.yaml > out.json y yq -P input.json > out.yaml, mientras documentos JSON grandes hacen streaming a través de jq, ijson (Python) o JSONStream (Node). El tipo MIME oficial YAML según RFC 9512 es application/yaml y la sintaxis multi-documento es parte de la especificación YAML 1.2, así que la mayoría de analizadores modernos manejan la forma streaming nativamente sin ninguna bandera especial.

¿Son equivalentes el estilo de flujo de YAML ({key: value, list: [1, 2]}) y el estilo de bloque?

Sí, semánticamente idénticos, pero estilísticamente muy diferentes. El estilo de flujo usa llaves y corchetes tipo JSON y cabe en una línea — útil para objetos cortos dentro de documentos más grandes. El estilo de bloque solo usa indentación y es la forma YAML canónica para todo multilínea. La mayoría de herramientas (Helm, Kustomize, Ansible, GitHub Actions) prefieren estilo de bloque para legibilidad y para mantener diffs mínimos. Este convertidor te deja elegir: en salida JSON-a-YAML, elige "preferir bloque" (predeterminado) o "preferir flujo" o "flujo solo para primitivos". Una sutileza: en estilo de flujo, cadenas que contienen comas, dos puntos, corchetes o llaves deben entrecomillarse porque esos caracteres son estructurales; el estilo de bloque es más tolerante. Ante la duda, pasa el YAML por yamllint para atrapar escalares ambiguos no entrecomillados antes de que te muerdan en producción.