Convertir YAML a JSON

YAML 1.2 es deliberadamente un superconjunto de JSON, así que todo documento JSON ya es YAML válido y esta conversión consiste en escribir los mismos datos sin ninguna de las abreviaturas. Por eso sirve para depurar: el JSON te enseña los valores que produjo el analizador, no los caracteres que tú tecleaste.

Casi todas las sorpresas de un fichero YAML son sorpresas de resolución: una versión que se volvió número, una palabra que se volvió booleano, un alias que arrastró más de lo que esperabas. Ninguna se ve en el YAML y todas se ven en el JSON. El resto de esta página es la lista de esas resoluciones, en el orden en que suelen costar tiempo.

Un YAML puede contener varios documentos en un mismo flujo, separados por líneas de tres guiones, y hay ecosistemas enteros donde ésa es la forma normal de un fichero. JSON no tiene equivalente: un fichero JSON es un solo valor. Así que el analizador se niega en lugar de elegir en silencio, y el mensaje dice que el origen contiene varios documentos e indica la línea y la columna donde empieza el segundo.

La salida es mecánica. Parte el fichero por los separadores y convierte cada documento por separado, o envuelve tú las partes en una única lista de nivel superior antes de convertir. Un guion triple suelto al principio del fichero no molesta, y un cierre con tres puntos tampoco: sólo detiene la conversión un segundo documento de verdad.

Un ancla y sus alias se convierten en copias. Un fichero que define un bloque una vez y lo referencia desde seis sitios produce un JSON con seis copias completas de ese bloque, porque JSON no sabe referirse a un valor definido en otro lugar. La salida es más grande que la entrada y dice lo mismo.

La clave de fusión es la parte que pilla a la gente. Una línea con dos signos de menor seguidos y un alias detrás es una convención de YAML 1.1 para fundir un mapa dentro del actual, y no forma parte del esquema básico de 1.2. Sale como una clave normal, llamada literalmente así, cuyo valor es el mapa referenciado. Las claves que esperabas fundidas están un nivel más abajo, colgando de ella, y lo que consuma el JSON tendrá que aplanarlo por su cuenta.

Hay dialectos que cuelgan significado de etiquetas propias: referencias a recursos en plantillas de infraestructura, inclusiones de otros ficheros, llamadas a funciones del sistema que lo lee. El analizador no conoce esas etiquetas, así que resuelve cada una a su valor desnudo y sigue: una referencia con su nombre detrás se convierte en la cadena con ese nombre, y una etiqueta con una lista detrás se convierte en la lista sola.

Es la conversión más peligrosa de la página, porque el JSON resultante es válido, verosímil y equivocado. No queda ninguna marca que diga que había una etiqueta ahí. Si tu YAML pertenece a un dialecto con etiquetas propias, este conversor va a producir un documento que ya no describe lo que querías decir, y la única defensa es saber de antemano que tu fichero las usa.

YAML 1.1 trataba como booleanos varias palabras además de las dos obvias, que es el origen del problema famoso en el que un código de país de dos letras se convierte en falso. El analizador de esta página implementa YAML 1.2, cuyo esquema básico reconoce solamente true y false, así que esas otras palabras sobreviven como texto.

Eso es un valor por omisión y no una garantía. Un fichero cuya primera línea es una directiva declarando la versión 1.1 se lee como 1.1, y entonces sí se convierten. Y sobre todo: eso sólo es cierto de este conversor. La biblioteca que lea tu YAML en producción puede ser una implementación de 1.1, y entonces el fichero significa dos cosas distintas según quién lo abra. El JSON de aquí te dice qué ve un analizador de 1.2, que es útil precisamente porque puede diferir de lo que ve tu servidor.

Un valor escrito 1.0 se resuelve al número 1, así que una versión fijada se convierte en un entero y se imprime sin su decimal. Uno escrito 0755 se resuelve a 755. Entrecomillar cualquiera de los dos en el origen lo mantiene como texto, y el JSON de salida lo enseña con comillas: eso convierte esta conversión en una manera rápida de auditar qué valores del fichero necesitan comillas.

Un valor con dos puntos, como un número de versión de tres partes, no puede ser un número y sigue siendo texto sin que hagas nada. La regla práctica es que cualquier cosa que fuera un identificador y esté hecha de dígitos merece una revisión: en un fichero de configuración esos son casi siempre los valores que rompen algo mucho después de haberse escrito.

YAML no pone límite al tamaño de un entero y los números de JSON son de coma flotante de doble precisión. Un identificador de 64 bits escrito con sus diecinueve cifras vuelve con las últimas cambiadas y ceros al final, y nada avisa. La conversión ha sido correcta según la especificación y el dato ya no sirve.

Cualquier YAML que guarde identificadores de esa magnitud los quiere entrecomillados como texto antes de convertir, no después: una vez que el número pasó por el analizador, las cifras originales no están en ninguna parte. Es la única pérdida de esta página que no se puede detectar mirando la salida, porque el número resultante tiene el mismo aspecto que uno correcto.

JSON tiene seis tipos y YAML tiene un sistema de etiquetas, así que donde los dos discrepan algo se aplana. Una fecha escrita sin comillas y sin etiqueta es lo más sencillo: bajo el esquema básico de 1.2 es una cadena y llega al JSON como cadena, que casi siempre es lo que quieres.

Con etiqueta cambia. Un valor marcado explícitamente como marca de tiempo se convierte en una fecha y después en una cadena normalizada a UTC, de modo que si venía con un desfase horario, ese desfase ya no está y la hora se ha desplazado. Y un valor marcado como binario se descodifica a bytes y se serializa como un objeto con las posiciones por clave, que es técnicamente completo y no lo va a reconocer ningún consumidor: si necesitas ese campo, vuelve a codificarlo como texto en el YAML antes de convertir.

Las claves duplicadas dentro de un mismo mapa se rechazan, con un mensaje que dice que las claves deben ser únicas y la línea donde está la segunda. Es más estricto que algunas herramientas de YAML y es lo correcto: una clave duplicada significa que uno de los dos ajustes lleva siendo ignorado desde que se añadió, probablemente sin que nadie lo supiera.

El segundo es un tabulador usado para sangrar. YAML lo prohíbe, y el analizador lo dice con línea y columna. Los dos errores son el conversor haciéndote un favor: un fichero con cualquiera de los dos problemas es un fichero cuyo comportamiento ya depende de qué biblioteca lo lea, que es exactamente lo que un fichero de configuración no debe hacer.

La salida va sangrada con dos espacios y termina con un salto de línea. No se ordenan las claves, así que el orden es el del documento original y dos conversiones del mismo fichero se comparan limpiamente. Es la forma que una herramienta de línea de órdenes, un validador de esquema o un cliente de API leen sin más trámite.

Validar es el motivo más fuerte para hacer este viaje. Los esquemas de JSON son maduros y están implementados en todas partes, y pasar una copia generada de una configuración por un esquema detecta claves mal escritas que un revisor de YAML —que sólo comprueba sintaxis— deja pasar sin comentarios.

Para inspeccionar, para validar y para pasarlo por herramientas que sólo hablan JSON. Lo que no es es un sustituto del YAML: los comentarios se han ido, las anclas se han convertido en duplicación y cualquier etiqueta propia se ha evaporado en silencio. Convertirlo de vuelta te daría un fichero que funciona y que ya no parece escrito por una persona.

La disciplina que evita el problema es tratar el YAML como fuente y el JSON como vista. Genera el JSON cuando necesites mirarlo, míralo, y bórralo. En cuanto una copia generada empieza a editarse, tienes dos versiones de la verdad y la que se va a quedar desactualizada es siempre la que nadie recuerda haber creado.

El análisis y la serialización ocurren los dos dentro de esta página, en JavaScript. Un fichero con nombres de máquinas internas, registros privados de imágenes, cadenas de conexión o secretos se queda en tu equipo, y la comprobación es de diez segundos: desconecta la red y convierte igualmente.

El tope de la capa gratuita son 100 MB por fichero y hasta cien ficheros por tanda, muy por encima de cualquier configuración real. Si lo que tienes es un directorio de manifiestos y quieres verlos todos como datos, cabe en una sola pasada y vuelve en un ZIP.