Convertir YAML a JSON

¿Qué hace el convertidor YAML a JSON?

El convertidor lee YAML 1.2-strict y emite JSON — bidireccional, con soporte multi-documento e indicaciones específicas de perfil para los ámbitos de uso YAML más importantes de 2026: Kubernetes, Docker Compose, GitHub Actions, Helm.

Puro cliente. Cada entrada permanece en su navegador. Sin registro, sin subida al servidor, sin seguimiento — puede comprobarlo usted mismo con las herramientas dev del navegador en la pestaña Red.

Cinco propiedades lo distinguen de convertidores estándar:

• YAML-1.2-strict con Norway-Lint. El parseador corre en modo 1.2-strict — NO, yes, off permanecen como cadenas. El Norway-Lint advierte de todos modos, porque muchos parseadores aguas abajo aún corren en modo 1.1.
• Visualizador de anchors y aliases. Lista de aristas con línea de definición y todos los usos (*alias y merge << distinguidos) — antes de que ocurra la resolución.
• Perfiles de workflow. Validadores Kubernetes, Compose, GHA y Helm comprueban los campos obligatorios de la herramienta respectiva, sin convertir el convertidor en un linter estricto.
• Preservación de comentarios en el camino de vuelta. JSON → YAML puede opcionalmente preservar comentarios de un YAML original en su posición.
• Tabla de fidelidad de tipos. Datetime, binary, tags personalizados se muestran bajo la salida JSON como lista, para que la pérdida de tipo no ocurra de forma oculta.

El convertidor no es un editor en vivo, sino un puente de formato dirigido entre YAML y JSON. La escritura del archivo YAML en sí ocurre en su editor — VS Code, Vim, Cursor — con validación de esquema y autocompletado. Aquí llega el archivo cuando está estructuralmente listo y solo debe traducirse a otra representación.

¿Qué es el Norway-bug y cómo lo trata la herramienta?

El Norway-bug es la trampa YAML más citada: bajo YAML 1.1, NO parsea como booleano false, porque el token pertenece a la familia booleana 1.1 (yes/no/on/off, cada variante de mayúsculas/minúsculas). Una lista ingenua de países como allowed: [DE, FR, NO, ES] se convierte en ['DE', 'FR', false, 'ES'] — Noruega desaparece, sin que el parseador emita un error.

YAML 1.2 ha eliminado este comportamiento; solo true y false son ahí aún booleanos. Pero: muchos parseadores en libertad corren hasta hoy por defecto en 1.1, porque la actualización tenía carácter de breaking change. PyYAML de Python es por defecto 1.1 hasta la versión 6, Psych de Ruby también. Herramientas como Norway-Land documentan la historia en detalle.

El lint de este convertidor escanea la fuente buscando exactamente estos tokens: NO, Yes, off, enteros octales con 0 inicial (0755), valores sexagesimales (22:22). Si encuentra un acierto, muestra la línea, el token y una propuesta concreta ("NO" citado, 0o755 como marcador octal explícito). La herramienta no bloquea la conversión — solo muestra dónde pasa la fractura 1.1/1.2 por su código.

¿Para qué son los perfiles de workflow?

Los convertidores YAML a JSON genéricos son convertidores de formato sin conocimiento de dominio. No saben que un manifiesto Kubernetes sin apiVersion y kind es rechazado por el servidor API, o que GitHub Actions no resuelve anchors YAML.

Los perfiles en este convertidor llenan exactamente esta brecha:

• Kubernetes — comprueba los tres campos obligatorios del servidor API apiVersion, kind, metadata.name y emite una indicación info-level si un kind namespaced (Deployment, Service, …) llega sin metadata.namespace. Multi-documento: cada recurso se comprueba individualmente.
• Docker Compose — comprueba la existencia de services: (obligatorio), marca el campo version: superado en Compose v2 como info, acepta extensiones con prefijo x- y marca claves de nivel superior desconocidas.
• GitHub Actions — comprueba on: y jobs: (obligatorios), emite una nota info por name: faltante, y advierte ante anchors YAML detectados, porque Actions no los honra.
• Helm — comprueba la convención de Chart.yaml: apiVersion: v2, name, version, type.

Todas las indicaciones son no bloqueantes. Complementan la salida JSON con contexto, pero nunca la bloquean. Quien necesite validación estricta usa kubeval, kustomize, docker compose config, helm lint en local.

¿Cómo funciona el visualizador de anchors y aliases?

Los anchors YAML (&name) y aliases (*name) son el mecanismo DRY del lenguaje. Se define una pieza de configuración una vez y se referencia varias veces. << es el merge-key: fusiona los campos del mapa referenciado en el mapa actual, con posibilidad de override.

El problema en la práctica: en cuanto un archivo tiene dos o tres anchors, se pierde rápidamente la visión general de dónde está definido qué y qué override prevalece. El visualizador resuelve eso con una lista compacta de aristas:

• Cada anchor aparece una vez con &name y línea de definición.
• Debajo está la lista de todos los usos con número de línea y badge de tipo (merge para <<, alias para plain *name).
• En una entrada como defaults: &d y <<: *d en dos configuraciones, se ve de un vistazo que d sirve dos veces como fuente de merge.

El visualizador escanea la fuente textualmente — rápido, sin análisis completo de parseador. Límite: anchors en secuencias estilo flow ([a: &x 1]) sobre varias líneas no se capturan, pero eso es extremadamente raro en configuraciones DevOps.

¿Cómo funciona la preservación de comentarios?

JSON no tiene comentarios según la spec. Quien va YAML → JSON → YAML hacia atrás pierde en el primer tramo todos los comentarios — y no vuelven, porque el JSON no sabe nada de ellos.

El conmutador de preservación de comentarios (visible solo en el camino de vuelta JSON → YAML) resuelve eso con una segunda entrada: el YAML original. Una vez activado:

1. El convertidor parsea el YAML original a un AST con propiedades de comentario en cada nodo.
2. Del JSON se emite un YAML fresco.
3. El convertidor recorre ambos árboles AST en paralelo y transfiere los comentarios por match de ruta al YAML fresco.

Los comentarios de encabezado permanecen como encabezado, los comentarios iniciales permanecen iniciales, los comentarios de cola se cuelgan de nuevo tras el valor correcto. En mappings se hace match por clave, en secuencias por índice.

Límite: si se renombran claves en el JSON, se desplazan campos o se cambian estructuras, el comentario cae en ese lugar — el match de ruta no encuentra nada. Quien quiera conservar comentarios sin falta modifica los datos de modo que la estructura original siga reconocible.

¿Qué no se construye a propósito?

• Sin editor YAML en vivo. El convertidor parsea al teclear, pero no ofrece autocompletado de sintaxis ni autocompletado consciente del esquema. Quien lo necesite usa VS Code con la extensión YAML.
• Sin extensión de tags personalizados. !Ref, !GetAtt, !Sub de CloudFormation o tags específicos de Ansible se parsean con tolerancia, pero no se evalúan. Herramientas como aws cloudformation validate-template son la dirección correcta.
• Sin renderizado de plantillas Helm. Los Helm-Charts con placeholders {{ .Values.x }} exigen el binario Helm. Renderizamos Chart.yaml directamente; values.yaml se trata como YAML genérico.
• Sin validación completa de esquema K8s. Las indicaciones K8s son heurísticas. Quien necesite validación completa contra el esquema actual usa kubeval o kustomize build | kubectl --dry-run=server apply.

¿Dónde encuentro más detalles?

• YAML 1.2 Spec — la especificación oficial
• YAML en Wikipedia — historia y propiedades
• Explicación del Norway-Problem — por qué 1.2 eliminó los tipos implícitos
• Convención Workflow Kubernetes — apiVersion, kind, metadata
• Docker Compose Reference — esquema Compose
• GitHub Actions Workflow Syntax — referencia de workflow