Herramientas de desarrollo · Convertidores de sintaxis
¿Es JSON válido YAML? Qué promete YAML 1.2 y dónde se rompe
· Antecedentes
json yaml formatos de datos
YAML 1.2 fue diseñado para que cada documento JSON sea también un documento YAML, razón por la cual la conversión de JSON a YAML parece trivial. Esta publicación explica qué garantiza realmente la especificación y los casos extremos en los que la promesa falla.
Pegar JSON en un archivo YAML y salirse con la suya: por qué funciona y la única vez que no funcionó
Un objeto JSON ordinario se puede pegar en el lado fuente YAML y leerlo bajo el esquema YAML 1.2 JSON de ToolAcre. Las llaves, los corchetes, las claves entrecomilladas, las cadenas, los números, los valores booleanos y nulos se convierten en el mismo valor simple de JavaScript. Eso explica por qué el límite a menudo parece trivial.
La garantía debe seguir siendo específica del analizador. ToolAcre restringe etiquetas, limita los alias y el anidamiento, y aplica un límite de entrada. Un texto puede ser válido bajo un procesador YAML más amplio pero ser rechazado aquí por razones de seguridad o forma no relacionadas con su núcleo de aspecto JSON.
Cargas JSON ordinarias a través de este lector YAML 1.2; Las extensiones no compatibles fallan por distintos motivos.
Los esquemas seleccionados producen valores con forma JSON: cadenas, números, booleanos, nulos, matrices y asignaciones. Esta alineación permite analizar y luego serializar en lugar de reemplazar la puntuación. El código fuente no establece todos los términos o erratas de la especificación YAML, por lo que el artículo informa el comportamiento probado en lugar de afirmar una conformidad exhaustiva.
En modo estricto, la tilde, el valor vacío y `0o755` permanecen como cadenas. Esos son YAML tokens que el propio JSON no contendría. Core los resuelve de manera diferente y al mismo tiempo devuelve una salida en forma de JSON.
Los esquemas enviados se alinean con los datos en forma de JSON sin demostrar todos los límites de las especificaciones.
Las claves de asignación YAML duplicadas mantienen el último valor con una advertencia; una interpretación estricta en otros lugares puede rechazarlos. Los lectores heredados YAML 1.1 pueden escribir palabras como `NO` de manera diferente, mientras que este lector las mantiene como cadenas. Esas diferencias complican las declaraciones generales de portabilidad.
Las tabulaciones utilizadas como sangría producen un error, mientras que las tabulaciones dentro de las cadenas JSON entrecomilladas tienen caracteres de escape. Los valores muy profundos o sobredimensionados pueden afectar los límites de seguridad locales. Una relación lingüística teórica no anula los límites de implementación.
Las claves duplicadas y las diferencias entre los analizadores heredados siguen siendo límites de interoperabilidad
Lo contrario es claramente falso para esta canalización de valores. Los comentarios YAML no tienen representación JSON, los alias se resuelven en datos repetidos, las secuencias de múltiples documentos se convierten en matrices y las etiquetas no admitidas se rechazan. Los bloques escalares se convierten en cadenas pero se pierde su presentación.
Incluso un documento YAML compatible puede, por lo tanto, convertirse a JSON válido y nunca volver al mismo texto YAML. La igualdad de datos puede sobrevivir para los valores ordinarios, mientras que los comentarios, los anclajes, la ortografía y la identidad de la transmisión no.
Qué significa esto para la conversión: JSON a YAML es un cambio de estilo, YAML a JSON es una traducción que puede perder información
JSON-to-YAML suele ser un cambio de estilo y serialización para la entrada con forma de JSON. YAML-to-JSON primero interpreta la sintaxis específica de YAML y luego proyecta el resultado en el modelo de valor más pequeño de JSON. Las direcciones no son simétricas.
ToolAcre prueba documentos JSON-to-YAML-to-JSON ordinarios que contienen valores anidados, Unicode, valores nulos, matrices y cadenas de aspecto ambiguo. Esos dispositivos prueban la clase de datos cubierta, no todos los pares de procesadores JSON o YAML posibles.
Ejemplo resuelto: un documento JSON cargado como YAML: la misma estructura, luego se agregó una característica exclusiva de YAML para mostrar dónde terminan las herramientas JSON
Pegue `{"country":"NO","items":[1,null],"nested":{"ok":true}}` como entrada YAML. El lector estricto devuelve el mismo árbol. Agregue un comentario YAML y el valor seguirá siendo el mismo mientras el comentario desaparece. Reemplace un objeto repetido con un ancla y un alias; el JSON ahora contiene copias en lugar de sintaxis de referencia.
Agregue `---` y un segundo documento; el resultado se convierte en una serie de documentos con una advertencia. Agregar `!!binary`; el lector restringido lo rechaza. Cada paso marca un límite distinto: presentación ignorada, estructura resuelta, convención de flujo y tipo no admitido.
Lo que esto no cubre: compatibilidad a nivel de esquema, donde los tipos YAML como marcas de tiempo no tienen contraparte JSON
La compatibilidad de esquemas no se trata solo de sintaxis superficial. Core puede crear Infinity o NaN, que JSON escribe como nulo con advertencias. Las etiquetas binarias y de marca de tiempo se rechazan según los esquemas restringidos en lugar de convertirse. ToolAcre reduce deliberadamente YAML a datos seguros en forma de JSON.
Otra implementación YAML puede admitir tipos adicionales. Eso lo hace menos compatible con valores JSON simples en esos puntos, no automáticamente mejores o peores. Elija según el contrato de destino y los requisitos de seguridad.
La compatibilidad a nivel de esquema incluye valores no finitos y etiquetas temporales que este lector restringido limita o rechaza.
Los datos ordinarios en forma de JSON pasan limpiamente a través de este lector y escritor YAML 1.2. Las afirmaciones más amplias sobre todos los documentos o analizadores requieren accesorios que cubran claves duplicadas, versiones de esquemas, etiquetas y límites de recursos.
Utilice convertidores de sintaxis para probar el texto real y leer sus advertencias. Trate "JSON es YAML" como una abreviatura útil sólo después de nombrar el analizador, el esquema y las características no compatibles que hacen que el límite real sea preciso.
Para una prueba de portabilidad, mantenga un dispositivo completamente dentro del modelo de valor de JSON y otro que agregue una característica exclusiva de YAML a la vez. Ejecute ambos a través de cada consumidor previsto. El primero mide la afirmación del subconjunto práctico; el segundo identifica exactamente dónde divergen los comentarios, alias, secuencias, etiquetas o reglas escalares. Este método por etapas es más informativo que preguntar si dos lenguajes son subconjuntos en abstracto, porque produce fallas relacionadas con los analizadores que su sistema realmente usa.