Herramientas de desarrollo · Convertidores de sintaxis
Cuatro modelos de datos comparados: por qué JSON, YAML, TOML y XML nunca asignan 1:1
· Antecedentes
formatos de datos json yaml
Cada conversión entre estos formatos tiene pérdidas en alguna parte, porque cada uno fue diseñado en torno a un modelo de datos diferente. Esta publicación compara sus sistemas y estructuras de tipos para que pueda predecir qué mantendrá una conversión y qué eliminará.
La configuración que no sería de ida y vuelta: un archivo convertido a través de tres formatos y los campos que resultaron diferentes
Un objeto ordinario que contiene números seguros, cadenas, valores booleanos, matrices y objetos anidados puede sobrevivir a las pruebas JSON-to-YAML-to-JSON y JSON-to-TOML-to-JSON. Agregue un valor nulo antes de TOML, una fecha y hora de TOML, contenido mixto de XML o un comentario de YAML y algunos cambios de información de fuente o valor.
La pregunta útil no es si la conversión genera pérdidas universalmente. Es qué clase de entrada y qué dirección conservan las propiedades que necesita. Las advertencias y rechazos de ToolAcre hacen que esa matriz sea observable en lugar de reducir cada par a una sola promesa de marketing.
Una configuración representativa puede recorrer algunos pares, pero no todas las formas admitidas.
JSON proporciona valores nulos, booleanos, números, cadenas, matrices y objetos en este analizador. No tiene comentarios, tipo de fecha y hora ni sintaxis de referencia compartida. JavaScript analiza números a medida que IEEE-754 se duplica, por lo que un número entero sin comillas más allá del rango seguro puede perder precisión antes de que otro escritor lo vea.
Las claves de objeto son cadenas y la clasificación opcional cambia su presentación. Las matrices permanecen ordenadas. El análisis estricto rechaza comentarios, comas finales y tokens numéricos no finitos, estableciendo una línea de base compacta para los demás lectores.
JSON modelo de valor tal como lo utiliza esta implementación de JavaScript
ToolAcre acepta YAML a través de esquemas restringidos JSON o Core. Los anclajes y alias se resuelven, los comentarios desaparecen, las secuencias se convierten en matrices, las claves duplicadas mantienen el último valor con una advertencia y se rechazan los alias recursivos o explosivos.
Se rechazan las etiquetas personalizadas, los constructores binarios, de marca de tiempo, de conjuntos y de objetos de lenguaje. Core Infinity y NaN se vuelven nulos en los formatos de destino con advertencias. Este es intencionalmente un subconjunto del sistema de etiquetas más amplio de YAML, no una afirmación de soporte completo de objetos YAML.
El modelo restringido YAML ToolAcre acepta
TOML comienza con una tabla y admite cadenas, enteros con signo, flotantes, booleanos, matrices, tablas y cuatro tipos temporales. No tiene nulo. ToolAcre convierte fechas y horas en cadenas orientadas al código fuente y números enteros anchos en cadenas decimales en lugar de perder dígitos.
Al escribir TOML, las claves de objetos nulos se omiten y las entradas de matriz nulas se convierten en cadenas vacías. Se rechazan las matrices de raíces y los escalares. Los comentarios y la elección del autor entre encabezados, claves de puntos y tablas en línea no regresan a través de un valor simple.
Tabla raíz de TOML, valores temporales y límite nulo
XML se proyecta como un árbol con atributos `@`, claves secundarias ordinarias, `#text`, `#cdata`, matrices de hermanos repetidos y prefijos de espacios de nombres literales. Se eliminan los comentarios, declaraciones e instrucciones de procesamiento. La posición del texto mixto se pierde y no se puede saber uno versus muchos antes de que aparezcan las repeticiones.
Los valores se leen como cadenas a menos que se seleccione la inferencia. Un valor nulo escrito desde JSON se convierte en un elemento vacío y no se puede distinguir de una cadena vacía al regresar. Se rechaza cada DOCTYPE y los nombres no válidos detienen la serialización en lugar de reescribirse.
Proyección XML de ToolAcre: elementos, atributos, texto y prefijos literales
Envío en nueve direcciones: JSON a YAML, XML, TOML y CSV; YAML a JSON y TOML; TOML a JSON y YAML; XML a JSON. Los valores ordinarios en forma de JSON obtienen mejores resultados entre JSON y YAML. TOML introduce fecha y límites nulos. XML requiere convenciones de nomenclatura y categoría de nodos.
CSV es un valor atípico plano y solo salida. Las matrices u objetos seleccionados se convierten en filas, los caminos anidados se aplanan en columnas de puntos, las fusiones nulas con texto vacío y las cadenas tipo fórmula se neutralizan. CSV-to-JSON, XML-to-TOML y otros pares ausentes se rechazan en lugar de inferirse.
Matriz de compatibilidad para las nueve direcciones enviadas, con CSV solo como salida
Los formatos binarios y los lenguajes de esquema están fuera del alcance. Un esquema puede restaurar la cardinalidad de la lista o validar formas comerciales, mientras que las codificaciones binarias introducen tipos a nivel de bytes y marcos que no se representan aquí. El convertidor nunca reclama esas capacidades.
La conversión de sintaxis tampoco prueba la validez de la aplicación. Un mensaje de pedido YAML, XML limpio en forma de Kubernetes o un archivo de proyecto TOML aún puede violar el contrato de destino. Utilice el validador de dominio después de inspeccionar la asignación de sintaxis.
Conclusión: elija el modelo, luego la sintaxis y cómo el panel de convertidores de sintaxis le permite probar una conversión antes de comprometerse con ella.
Elija el modelo de datos antes de elegir su puntuación. Si los comentarios y alias son importantes, un salto JSON no puede conservarlos. Si nulo importa, la salida TOML lo cambia. Si el contenido mixto ordenado es importante, una proyección JSON simple es insuficiente. Si el destino es una tabla, el JSON anidado requiere una convención de aplanamiento explícita.
Utilice ToolAcre para probar un documento representativo y leer todas las advertencias. El resultado es evidencia sobre un par y una entrada concretos, no un permiso para llamar a todas las conversiones sin pérdidas o a todos los analizadores admitidos completos.
Cree el documento representativo a partir de los límites que son importantes para su servicio: texto nulo y vacío, un identificador grande, una cadena similar a una fecha, un registro repetido, un comentario o alias si YAML está involucrado y texto mixto si XML está involucrado. Compare los valores normalizados después de cada salto admitido y conserve las advertencias con el resultado. Esa matriz se convierte en un artefacto de decisión para el modelo elegido en lugar de una vaga preferencia por una sintaxis familiar.