Convertidor JSON a YAML: convierta las configuraciones sin el problema de Noruega

La primera vez que YAML me quemó correctamente, era un código de país. Estaba moviendo una configuración local de un proyecto JSON de Laravel a un formato YAML amigable con la implementación, convirtiéndose a mano porque "está cambiando los frenos a sangría". Una de las entradas fue Noruega: "country": "NO". En YAML, sin citar, eso ' no es una cadena; según las reglas de YAML 1.1, PyYAML y muchos otros analizadores todavía se aplican NO es el booleano false. El script de implementación, escrito en Python, evaluó alegremente a los usuarios noruegos como country: false y los enruté al lugar alternativo. Este error tiene un nombre (la comunidad lo llama el problema de Noruega) y pude descubrirlo de manera artesanal, un ticket de soporte confundido a la vez.

La conversión de JSON a mano en YAML parece trivial y en realidad es un campo minado, porque los dos formatos tienen ideas muy diferentes sobre lo que significa una palabra desnuda. En JSON, todo es explícito: las cadenas tienen comillas, los números no, true/false/null son palabras clave, fin de la historia. En YAML, un escalar no citado obtiene interpretado: no se vuelve falso, 3000 se convierte en un entero, 1.10 se convierte en el flotador 1.1 (adiós, cadena de versión), 08 estrangula a algunos analizadores como un octal no válido, y un valor con un espacio de dos puntos perdido se convierte en un mapa anidado cuando menos lo esperas. Cada uno de estos es una corrupción de datos silenciosa: el archivo se analiza bien, los tipos simplemente están equivocados.

un Convertidor JSON a YAML eso entiende que estas reglas le brindan la legibilidad para la que se inventó YAML sin la ruleta tipográfica. El que construí para Toolz.dev detecta todos los escalares ambiguos (parecidos booleanos, parecidos a números, valores heredados de YAML 1.1, cadenas con caracteres especiales) y cita exactamente esos, por lo que lo que era una cadena en su JSON sigue siendo una cadena después de que la siguiente herramienta analiza el YAML. Eso " exactamente esos" importa: citar todo También sería seguro, pero la salida deja de parecerse a YAM idiomática, y el idiomático es el punto entero.

Esta guía cubre cómo la conversión maneja los bordes afilados de YAML, por qué JSON ya es técnicamente YAML (y por qué ese hecho no lo ayuda), y los kubernetes, CI y Docker componen flujos de trabajo donde esta conversión se realiza semanalmente.

TL;Dr: Pegue JSON en el Convertidor de JSON a YAML.dev.dev, elija sangría de 2 o 4 espacios y obtenga YAML estilo bloque limpio con cotizaciones de tipo seguro - "3000" sigue siendo una cuerda, "no" sigue siendo una cuerda, "1.10" sigue siendo una versión. se conserva el pedido de claves, las colecciones vacías salen como [] y {}, y todo se ejecuta en el lado del cliente, por lo que las configuraciones con secretos nunca abandonan su navegador. Vuelta de ida y vuelta con el Validador YAMy formatear la fuente primero con el Formateador JSON.

¿JSON no es ya válido YAML?

Sí, y es 's el más inútil "yes" en la gestión de configuración. YAML 1.2 fue diseñado explícitamente como un superconjunto de JSON: cada documento JSON válido se analiza como YAML válido. Podrías pegar JSON sin procesar en un manifiesto de Kubernetes y kubectl lo aceptaría.

Nadie hace esto, porque la razón por la que YAML existe es ergonomía humana. Manifestaciones de Kubernetes, flujos de trabajo de acciones de GitHub, archivos de composición de Docker, libros de jugadas de Ansible, configuraciones de Home Assistant: estos son YAML porque la gente los lee y edita a mano constantemente, y replicas: 3 bajo un bloque sangrado es mejor que {"replicas":3} anidado entre brackets. Cuando alguien dice "Convertir JSON a YAML" significan de bloque YAML: indentación en lugar de brackets, - guiones en lugar de matrices entre corchetes, no se necesitan comillas donde no se necesitan.

Esa última cláusula es donde vive la dificultad. Pasando de la sintaxis explícita de todo-explicit de JSON a la sintaxis mínima de Yaml Decidiendo, por cada cadena, si puede perder sus comillas de manera segura- y esa decisión requiere conocer las reglas de resolución escalar de YAML' mejor que la mayoría de los humanos de manera confiable a las 5 p.m. de un viernes. Eso' es el trabajo real de un convertidor; la parte de apuntalamiento a sangría es trivial.

¿Qué se rompe silenciosamente cuando te conviertes en la mano?

Los casos de falla se dividen en cuatro familias, y he golpeado a cada uno de ellos en configuraciones reales:

parecidos booleanos. YAML 1.1 resuelve yes, no, on, off, y, n (en varios casquillos) como booleanos, y YAML 1.2 true/false. PyYAML, que sigue siendo la biblioteca YAML predeterminada en la mayoría de las bases de código de Python, implementa 1.1. Entonces "debug": "no" convertido a mano debug: no se convierte en debug: false en su herramienta de implementación de Python. El problema de Noruega (NO → false) y su primo el problema de Ontario (ON → true) son los mayores éxitos de esta familia.

parecidos con números. "port": "3000" convertido a port: 3000 ahora es un número entero. Kubernetes no ' No me importan algunos campos y falla en otros: los valores env var, por ejemplo, deben ser cadenas y kubectl apply rechazará un entero allí con un error que nombra el campo pero no el porque. Las cadenas de versión son peores porque nada falla: version: 1.10 Analiza como el flotador 1.1, y su script de implementación informa felizmente la versión incorrecta para siempre. Ceros iniciales: códigos postales, números de teléfono, identificaciones de aspecto octal como 0755- completa la familia.

caracteres especiales. un dos puntos seguido de un espacio dentro de un valor no citado inicia una asignación (message: error: not found es un error de análisis o un mapa anidado, según el analizador). un # Inicia un comentario valor medio. en tender *, &, ! Choque con el ancla, el alias y la sintaxis de etiquetas de Yaml. Las cadenas con nuevas líneas necesitan escapar o bloquear escalares.

la cadena vacía. Vacío no citado en YAML es null, no "". Cualquier campo JSON que contiene una cadena vacía debe salir citada o cambia de tipo.

los convertidor compara cada cadena con las cuatro familias y cita las que la necesitan, y sólo aquellas. production sale desnudo porque es inequívoco; "3000", "no", "1.10"y "" Salgan citados porque no son. También hay un "cita de "citar todas las cadenas" para cuando estás alimentando a un analizador en el que no confías y quieres que ocurra una resolución escalar cero.

¿Cómo se convierte JSON a YAML con la herramienta?

Paso 1: Pega tu JSON

Cualquier trabajo JSON válido: objetos, matrices, anidamiento profundo, unicode. El botón Cargar muestra le brinda una configuración de servicio realista que ejercita los casos interesantes: un puerto de cadena numérico, un booleano, una matriz vacía, mapas anidados. Si su entrada tiene problemas de sintaxis, el convertidor informa el error exacto del analizador 's en lugar de convertir un documento truncado; para buscar donde El error está en una gran mancha, el Formateador JSON es el mejor microscopio.

Paso 2: Elija sangría

Dos espacios o cuatro. Dos es la convención abrumadora: documentos de Kubernetes, ejemplos de acciones de GitHub, referencias de Docker Compose y yamllint todos los valores predeterminados lo usan, pero algunos equipos estandarizan en cuatro para que sea legible en anidamiento profundo. Elijas lo que elijas, el convertidor es consistente al respecto, incluido el caso sutil de enumerar elementos bajo una clave, donde la sangría manual inconsistente es una fuente clásica de " los valores de mapeo no están permitidos aquí " errores.

Paso 3: Convertir y Revisar

La salida aparece con recuentos de líneas y bytes. Deslícelo una vez, no para corregirlo (eso y el trabajo del convertidor y el trabajo del 39), sino para verificar la cordura de las decisiones de cotización según sus expectativas. Viendo PORT: "3000" Citado mientras NODE_ENV: production No es la herramienta que le dice qué valores eran peligrosos.

Paso 4: Copiar o descargar

Copiar al portapapeles para pegar en un manifiesto existente o descargar como .yaml archivo. La salida utiliza solo espacios: YAML prohíbe la sangría de pestañas, lo cual vale la pena saber cuando luego edita el archivo en un editor configurado para sangría de pestañas.

JSON vs YAML: ¿Cuándo gana cada formato?

El patrón detrás de la tabla: JSON gana donde escribe una máquina y una máquina lee; YAML gana donde una máquina lee pero un humano escribe. La configuración se ubica directamente en la segunda categoría, razón por la cual la dirección JSON a YAML es la común: los datos comienzan su vida en una API o exportación de una base de datos y necesitan convertirse en algo que un equipo de operaciones pueda mantener. El viaje inverso, YAML de regreso a JSON legible por máquina, es lo que Validador YAM identificadores: pegue YAML, obtenga validación más el JSON equivalente.

¿Cuáles son los flujos de trabajo cotidianos para esta conversión?

Manifiestos de Kubernetes desde la salida de API

kubectl get deployment my-app -o json te da JSON; el manifiesto que verifica en Git es YAML. Convertir respuestas API en YAML limpio es la forma más rápida de iniciar un manifiesto desde un recurso en vivo: convertir y eliminar el servidor poblado status y metadata.managedFields bloques, y tienes un punto de partida declarativo. La cotización segura de tipo se gana en la conservación aquí: valores env en Kubernetes moho ser cadenas, y la insistencia del convertidor en citar "3000" es la diferencia entre kubectl apply triunfando y fallando.

Configuración de la canalización CI

Las acciones de GitHub y GitLab CI son solo YAML. Cuando I'm genera pasos de flujo de trabajo mediante programación: una matriz de versiones PHP y Node para probar WP Adminify, digamos, el generador produce naturalmente JSON y el último paso es la conversión. Las cadenas de versiones en las matrices de prueba son exactamente los valores que se alteran mediante una conversión ingenua: una matriz de ["1.9", "1.10", "1.11"] Convertidos a mano sin cotizaciones Pruebas contra PHP 1.1 dos veces los Colección de herramientas de codificación Cubre más de este patrón de generar y luego convertir.

Docker Compose desde la salida de inspección

docker inspect emite JSON; docker-compose.yml quiere YAML. La ingeniería inversa de un archivo Compose de un contenedor en ejecución (puertos, volúmenes, entorno) es un trabajo de conversión y poda. Las matrices y objetos vacíos se convierten a [] y {} Sintaxis de flujo, que Compose acepta y que mantiene la etapa de poda legible.

Hacer que la configuración sea revisable

Este está subestimado: las configuraciones JSON con docenas de claves anidadas son miserables en la revisión de código, en parte porque no pueden llevar comentarios. Convertir a YAML le permite anotar porque rateLimit es 250 justo al lado del valor. Para la revisión en sí, emparejar la conversión con un Diferencia estructural de antes/después de JSON mantiene la pregunta "lo que realmente cambió" honestamente mientras la versión YAML maneja el "por qué".

Documentos de OpenAPI y de esquema

Las especificaciones OpenAPI se escriben comúnmente en YAML, pero se generan y sirven como JSON. Convertir una especificación generada a YAML para edición humana, y luego validar el viaje de ida y vuelta, es un flujo de trabajo estándar del equipo API, y las garantías de fidelidad (orden de claves conservado, tipos citados) significan que la versión YAML permanece diferenciable frente a su ancestro JSON.

¿Por qué importa la preservación de pedidos clave?

Según la especificación JSON, el orden de las claves de objeto no tiene significado {"a":1,"b":2} y {"b":2,"a":1} son el mismo objeto. Entonces, un convertidor podría ordenar las teclas alfabéticamente y ser técnicamente correctos. También sería prácticamente hostil, porque los archivos de configuración son interpretar En orden: una implementación de Kubernetes se lee naturalmente como apiVersion, kind, metadata, spec- ordenarlos alfabéticamente produce un manifiesto que se analiza de manera idéntica y se lee como una nota de rescate.

El convertidor emite claves en orden de origen. Su modelo mental del documento sobrevive a la conversión, el YAML se diferencia limpiamente contra conversiones anteriores de la misma fuente y pedidos convencionales (nombre antes de valor, apiVersion primero) permanecer convencional. si tu escasez ordenamiento canónico con fines de comparación, that's una preocupación de herramienta diferente: el Verificador de diferenciales JSON Se compara por clave independientemente del orden, que es la capa correcta para ese problema.

¿Es seguro convertir las configuraciones que contienen secretos?

La configuración es el texto más secreto que maneja un desarrollador: URL de bases de datos con contraseñas integradas, tokens API en bloques de entorno, nombres de host internos que asignan su infraestructura. It' También es exactamente lo que la gente pega en los convertidores en línea, generalmente a mitad de la implementación, generalmente con prisa.

los Convertidor de Toolz.dev se ejecuta completamente en su navegador: análisis, análisis escalar, serialización: todo es JavaScript del lado del cliente, ninguna solicitud de red transporta sus datos y la herramienta sigue funcionando con su corte de conexión. Eso' es un hecho de arquitectura, no una promesa de política de privacidad. La filosofía de diseño del navegador detrás de toda la caja de herramientas se establece en el Guía del kit de herramientas para desarrolladores webEsta herramienta es esa filosofía aplicada al tipo de documento más sensible de su flujo de trabajo.

La advertencia obvia: la conversión del lado del cliente protege la cambio. Donde pega la salida después es su propia decisión de seguridad.

preguntasrán el

¿Cómo convierto json a yaml en línea?

Pegue su JSON en el Convertidor JSON a YAML, elija sangría de 2 o 4 espacios y haga clic en Convertir. Obtienes YAML estilo bloque con cotización segura para tipos, listo para copiar o descargar como un archivo.yaml. La conversión se ejecuta completamente en su navegador; no se carga nada.

¿JSON ya es válido YAML?

Técnicamente sí, YAML 1.2 es un superconjunto de JSON, por lo que cualquier documento JSON válido se analiza como YAML. Pero la sintaxis JSON anula el propósito de legibilidad de YAML&#39. La conversión produce YAML estilo bloque con sangría en lugar de llaves, que es lo que manifiesta Kubernetes, flujos de trabajo de CI y archivos Compose esperan que los humanos lean y editen.

¿Cuál es el problema de Noruega en YAML?

Según las reglas escalares de YAML 1.1, que analizadores como PyYAML aún aplican, los valores no citados no, sí, activado y desactivado se analizan como booleanos, por lo que el código de país NO se vuelve falso en silencio. El convertidor evita esto citando automáticamente cualquier cadena que un analizador YAML pueda interpretar como booleana, numérica o nula.

¿Se mantendrán cadenas numéricas como "3000" de ser cadenas después de la conversión?

Sí. El convertidor detecta cadenas que parecen números y las cita en la salida, por lo que "3000" sigue siendo una cadena en lugar de convertirse en el entero 3000. Esto importa para los puertos, los números de versión como "1.10" (que de otro modo truncarían al flotador 1.1), códigos postales e ID con ceros iniciales.

¿El convertidor conserva el orden de mis claves JSON?

Sí. Las claves se emiten en el orden en que aparecen en el JSON de origen. La clasificación de claves sería técnicamente válida: el orden de los objetos JSON no tiene significado por RFC 8259- pero el orden de origen mantiene las configuraciones legibles en su estructura convencional y mantiene el YAML diferenciable frente a su fuente JSON.

¿Puedo usar la salida directamente en Kubernetes o Docker Compose?

Sí. La salida es YAML estándar estilo bloque sangrado con espacios (nunca pestañas), que kubectl, Docker Compose, GitHub Actions y GitLab CI aceptan. Los valores que deben ser cadenas, como los valores de Kubernetes env var, salen citados, evitando los errores de tipo que genera kubectl en números no citados.

¿Cómo convierto yaml de nuevo a json?

Usa el Validador YAM en Toolz.dev, analiza su YAML, informa cualquier error de sintaxis y genera el JSON equivalente. Junto con el convertidor JSON a YAML, le brinda un viaje completo de ida y vuelta entre los dos formatos.

¿Es seguro convertir archivos de configuración que contienen secretos?

Sí. La conversión se ejecuta completamente en JavaScript en su navegador: ninguna solicitud de red transporta sus datos, nada se almacena ni registra y la herramienta funciona sin conexión. Las configuraciones con credenciales de bases de datos, tokens API o nombres de host internos nunca salen de su máquina.

La legibilidad de YAML's es real, al igual que sus bordes nítidos: el formato resuelve tipos a partir del contexto, y el contexto es exactamente lo que la conversión manual se equivoca. Un convertidor que conoce las reglas escalares le brinda la configuración legible sin corrupción de tipos silenciosos: Convierte tu JSON, hojear la cita que eligió y enviar un manifiesto donde Noruega todavía es un país.