Comparación de configuraciones JSON/YAML/TOML: Guía de selección para desarrolladores

Originario de JavaScript, JSON fue diseñado como un formato de intercambio de datos multiplataforma ligero. Sus reglas de sintaxis se basan en el estándar ECMAScript, y prioriza la fiabilidad para el análisis por máquina. RFC 8259 define explícitamente su propósito central como la transmisión de datos estructurados entre sistemas.

YAML, cuyo nombre completo es YAML Ain't Markup Language, se posiciona como dato de configuración legible por humanos. Prioriza la reducción de la barrera para la edición manual, simplifica la escritura jerárquica mediante una estructura basada en sangría y es adecuado para escenarios en los que personal no técnico necesita editar configuraciones.

TOML, cuyo nombre completo es Tom's Obvious, Minimal Language, se diseña como un formato de configuración con semántica clara. Aboga porque la semántica de la configuración se pueda analizar sin ambigüedad y evita interpretaciones ambiguas mediante la seccionamiento explícito y la estructura de clave-valor.

Las diferencias en las características comunes entre los tres formatos afectan directamente la experiencia de escritura de configuraciones. JSON no reserva espacio para comentarios, y la mayoría de los analizadores no admiten la sintaxis de comentarios. Tanto YAML como TOML admiten de forma nativa comentarios de una sola línea y de varias líneas, lo que facilita la escritura de descripciones de configuración.

Las diferencias en cadenas multilínea y tipos de fecha corresponden a los requisitos de diferentes escenarios: YAML es adecuado para escribir descripciones multilínea o contenido de plantilla, mientras que JSON requiere procesamiento de escape para saltos de línea, lo que tiene una compatibilidad constante pero es complicado de escribir.

El problema más conocido de JSON es la falta de soporte oficial para comentarios. Si algunos desarrolladores añaden comentarios a JSON, al cambiar a un analizador estándar se activará directamente un fallo de análisis, lo que provocará que no se pueda cargar la configuración. Algunas soluciones derivadas como JSONC añaden soporte para comentarios, pero no se han incorporado al estándar oficial.

YAML tiene el conocido problema de Noruega: cuando una cadena tiene el formato 20:03, algunos analizadores la convertirán automáticamente a un tipo de tiempo Base60, lo que da como resultado el valor 1203, que no coincide con el valor de cadena esperado. Este problema se origina en las reglas de conversión de tipos implícitas de YAML.

TOML no tiene conversión de tipos implícita. Todos los tipos de valor están marcados explícitamente por la sintaxis, y no se infiere ningún tipo automáticamente. Por lo tanto, no tiene problemas de ambigüedad similares, y el resultado de tipo coincide con la expectativa del escritor.

Existe una estratificación clara en el nivel de adopción de los tres formatos en diferentes pilas tecnológicas. La siguiente tabla resume el estado general de cada formato por escenario de aplicación, así como la madurez de los analizadores en el ecosistema correspondiente.

Al realizar la conversión entre diferentes formatos, existen límites fijos para la pérdida de información. La herramienta de conversión de formatos OKfmt retiene la información válida según el soporte de sintaxis y descarta el contenido incompatible. Al convertir JSON a YAML o TOML, no se pierde información nativa, y todas las estructuras se pueden mapear completamente.

Al convertir YAML a JSON, los comentarios de YAML y la información del tipo de fecha nativo se pierden, ya que JSON no admite estas dos características. Al convertir TOML a JSON, solo se pierden los comentarios, y todos los tipos de estructura se pueden mapear completamente. Al convertir YAML a TOML, los tipos de fecha nativos se convierten a cadenas en el formato correspondiente, y los comentarios se pueden retener completamente.