Cómo corregir JSON antes de convertirlo a YAML

Errores frecuentes

JSON exige claves y cadenas entre comillas dobles. No admite comas finales, comentarios, undefined, NaN ni la sintaxis abreviada de objetos JavaScript.

Comprueba primero la coma, comilla, llave o corchete inmediatamente anterior a la posición indicada.

Trabaja desde el primer error

Un fallo temprano puede producir muchos mensajes secundarios. Corrige solo el primer problema, vuelve a analizar y conserva el texto original hasta confirmar el resultado.

No conviene que una reparación automática adivine valores o elimine contenido.

Confirma la estructura

Cuando el JSON sea válido, revisa que la raíz, los arrays y los tipos coincidan con lo esperado antes de convertir.

El YAML resultante será más legible, pero no corrige errores semánticos del documento.

Flujo de trabajo fiable paso a paso

Trata JSON no válido antes de convertirlo a YAML como una transformación de datos con una entrada, una estructura esperada y un destino definidos. Trabaja sobre una copia, valida antes de cambiar la representación y aísla una muestra mínima. Así se distinguen los fallos de sintaxis de los problemas del modelo de datos o de la aplicación.

Realiza un cambio cada vez y repite la misma validación. En una canalización automática, detén el proceso ante un error del analizador en vez de publicar un resultado parcial o inferido. Conserva la entrada original junto al artefacto generado cuando necesites trazabilidad.

• Corrige primero el primer error informado; una sola comilla ausente puede provocar muchos avisos secundarios.
• Reduce un documento grande al fragmento mínimo que falla sin perder el anidamiento cercano al error.
• Cuando la sintaxis sea válida, comprueba claves obligatorias, tipos, rangos y reglas propias de la aplicación.

Ejemplo práctico y verificación

El ejemplo siguiente es deliberadamente pequeño para poder revisarlo a simple vista. Aplica el mismo método a un documento real: confirma cada clave, tipo escalar, orden de lista y límite de anidamiento antes de aceptar el resultado.

Que la conversión o minificación termine solo demuestra que la entrada pudo analizarse. Compara el valor estructurado antes y después y carga el resultado con la misma biblioteca o plataforma que lo consumirá en producción.

{
  "service": "api",
  "ports": [8080, 8443]
}

Límites y casos especiales

Los casos difíciles de JSON no válido antes de convertirlo a YAML suelen aparecer al confundir validez sintáctica con validez para la aplicación. Un analizador puede aceptar datos incompletos, ambiguos, demasiado grandes o incompatibles con el esquema de destino.

No repares ni normalices a ciegas un documento desconocido. Las claves duplicadas, tipos implícitos, alias, precisión numérica, Unicode, finales de línea y entradas enormes requieren una política explícita. Si el destino impone reglas más estrictas, prevalecen esas reglas.

Lista de comprobación para producción

Antes de publicar, prueba un documento normal, un valor vacío, datos profundamente anidados, texto no ASCII y un ejemplo malformado. Anota la versión de la herramienta o biblioteca si otro sistema debe reproducir exactamente el resultado.

Integra la validación en CI cuando los datos afecten compilaciones, despliegues, API o configuración. Revisa los cambios, conserva una copia de reversión y supervisa el primer consumidor después del despliegue.

• Corrige primero el primer error informado; una sola comilla ausente puede provocar muchos avisos secundarios.
• Reduce un documento grande al fragmento mínimo que falla sin perder el anidamiento cercano al error.
• Cuando la sintaxis sea válida, comprueba claves obligatorias, tipos, rangos y reglas propias de la aplicación.

Preguntas sobre este tema