JSON a TOML
Este conversor emite TOML 1.0 desde JSON completamente en tu navegador. Las claves escalares se escriben primero, luego [tablas], luego [[arrays de tablas]], para que cada definición preceda a las cabeceras que debe preceder. Las claves incompatibles con TOML se marcan, los nulos se rechazan con una ruta con nombre, y un array de nivel superior no puede convertirse — TOML no tiene raíz anónima.
JSON a TOML: explicación
La dirección importa: JSON suele nacer dentro de un programa — una carga útil de una API, un documento almacenado, el estado de una herramienta de compilación — mientras que TOML suele ser leído por una persona configurando algo. Convertir JSON a TOML significa volver a introducir un formato con reglas de posicionamiento reales, y la más grande es invisible hasta que muerde: en TOML, la posición de una clave en el archivo decide a qué tabla pertenece. Escribe retries = 3 después de una cabecera [servers] y se convierte silenciosamente en una clave de servers, no de la raíz.
Este conversor emite primero las claves escalares, luego [tablas], luego [[arrays de tablas]], para que cada par clave/valor se escriba bajo la cabecera a la que pertenece y cada tabla esté completamente definida antes de que abra la siguiente cabecera. Los objetos JSON se convierten en tablas, los arrays de objetos en arrays de tablas, los arrays de escalares siguen siendo arrays en línea, y cada valor se emite como el tipo TOML 1.0 que ya es — no hay un paso de inferencia que pueda fallar.
Todo ocurre en esta pestaña del navegador. El JSON que pegas se analiza con el JSON.parse del propio navegador, el TOML se construye a partir de ese documento en memoria, y nada cruza la red — el panel de Red en DevTools permanece vacío mientras trabajas, y la Content-Security-Policy de la página mantiene así.
El cruce inverso es el más común — leer un Cargo.toml en un script — y el convertir TOML de vuelta a JSON sitio lo maneja, manteniendo las fechas y horas como cadenas exactamente como este las recibe.
Si el JSON vino de un script en lugar de un formateador, pásalo por el Validador de JSON primero — un documento que no se analiza allí tampoco se hará aquí, con el mismo mensaje.
Por qué los escalares van primero, luego las tablas, luego los arrays
La regla de posicionamiento de TOML es la razón por la que la salida está ordenada de esa manera. Las claves escritas después de una cabecera [tabla] pertenecen a esa tabla, y las claves escritas después de una cabecera [[array de tablas]] pertenecen a su entrada más reciente — por lo que un emisor que intercalara escalares y cabeceras produciría un archivo que se analiza correctamente pero con la estructura errónea. Emitir primero los pares clave/valor de un nivel, luego sus sub-tablas, luego sus arrays de tablas, es el único orden que permite un recorrido de ida y vuelta, y la misma regla se aplica recursivamente dentro de cada tabla anidada.
Las cadenas tienen su propia regla: todo se emite como una cadena básica de TOML entre comillas dobles, con barras invertidas, comillas y caracteres de escape definidos como TOML 1.0 lo especifica. El conversor no cambia a cadenas literales para ahorrar puntuación, porque decidir cuándo una barra invertida es literal es exactamente la suposición que un conversor no debe hacer. Las claves siguen la misma disciplina, por lo que una clave como port: 8080 llega entrecomillada y sin ambigüedad.
La asignación de JSON a TOML
Cada forma que el conversor maneja, y su destino TOML 1.0:
| JSON | TOML resultante |
|---|---|
| Objeto | Cabecera [tabla], claves debajo |
| Array de objetos | Entradas de [[array de tablas]], una por objeto |
| Array de escalares | Array en línea: ["rápido", "seguro"] |
| String | Cadena básica con escapes estándar |
| Clave con punto o espacio | Clave entrecomillada: "app.name" = 1 |
| null | Rechazado — TOML 1.0 no tiene nulo |
Cómo es la salida
El ejemplo a continuación es exactamente el par que produce el botón Cargar muestra del conversor: un objeto raíz con dos escalares y un array de etiquetas en línea, un objeto owner anidado, y un array servers que contiene dos objetos. Fíjate en el ordenamiento — los pares clave/valor simples de la raíz, incluidas las etiquetas, aparecen todas antes de [owner], y ambas entradas de servers quedan bajo una familia de cabeceras [[servers]] en orden de array. Ese ordenamiento no es cosmético; es lo que hace que el archivo se analice de vuelta a la misma estructura.
Se aplica la misma normalización que en todas partes de esta familia: la salida se genera a partir del documento analizado, por lo que las peculiaridades de sangría en el JSON de origen se conservan en significado y orden de claves, pero se reimprimen en un estilo TOML consistente que un revisor puede comparar.
Casos extremos que este conversor rechaza en lugar de alterar
Algunas entradas no tienen representación fiel en TOML 1.0, y hacer como si la tuviera te daría un archivo de configuración que miente:
- Un array o escalar de nivel superior — los documentos TOML siempre son una tabla raíz de pares clave/valor, por lo que un archivo JSON cuyo nivel superior no es un objeto se rechaza con un mensaje claro.
- Cualquier nulo, en cualquier lugar — TOML 1.0 no tiene nulo, por lo que el conversor rechaza y nombra la ruta exacta, dejándote a ti para que elimines la clave o elijas un valor deliberadamente.
- Claves que parecen con puntos — una clave simple a.b se analizaría como clave con puntos y quedaría en una tabla anidada, por lo que tales claves se emiten como cadenas básicas entrecomilladas, y la vista previa las marca para que puedas detectar nombres que probablemente estaban destinados a ser anidados.
Preguntas frecuentes
¿Se envía mi JSON a un servidor durante la conversión?
No. La conversión se ejecuta completamente en esta pestaña del navegador: JSON.parse y el escritor de TOML son JavaScript local de la página cargado una vez al abrir. No hay punto de subida, y la Content-Security-Policy prohíbe que la página abra conexiones. DevTools lo demuestra — observa cómo el panel de Red permanece vacío en cualquier número de conversiones.
¿Por qué los escalares deben escribirse antes de las cabeceras [tabla]?
En TOML, cada clave después de una cabecera [servers] pertenece a servers, por lo que intercalar escalares y cabeceras cambiaría el significado del archivo mientras aún se analiza correctamente. Escribir primero los pares clave/valor de un nivel, luego sus sub-tablas y arrays de tablas, es el único orden que se analiza de vuelta a la estructura con la que empezaste — es corrección, no estilo.
¿Qué hace el conversor con el JSON nulo?
Lo rechaza. TOML 1.0 no tiene valor nulo — el lenguaje no ofrece ninguna forma de escribirlo — por lo que no existe una emisión fiel. El conversor informa la ruta exacta de la clave problemática, como owner.middle, y se detiene. Eliminar la clave o sustituirla por una cadena centinela es tu decisión, no una suposición silenciosa integrada en la salida.
¿Cómo se convierten los arrays?
Por su contenido. Un array cuyo elemento es un objeto se convierte en un [[array de tablas]], una entrada por objeto. Un array de escalares o valores mixtos se convierte en un array en línea de TOML en una sola línea, y un array vacío se emite como []. Nada se aplana o reestructura — el conversor representa la estructura que se le dio, lo que hace que el resultado sea predecible.
¿Qué pasa con las claves que tienen puntos, espacios o dos puntos?
Las claves simples de TOML solo permiten letras, dígitos, guiones bajos y guiones, por lo que cualquier otra cosa debe ser una clave entrecomillada. Este conversor emite tales claves como cadenas básicas — "app.name" = 1 — que TOML 1.0 define como una sola clave, no una ruta con puntos. La vista previa marca las claves entrecomilladas para que puedas ver qué nombres probablemente estaban destinados a ser anidados y renombrarlos manualmente.
¿Puedo obtener fechas y horas reales de TOML a partir de una cadena JSON?
No por conversión, y honestamente así. JSON no tiene tipo de fecha, por lo que el conversor no puede saber si "1979-05-27T07:32:00Z" es una marca de tiempo o una frase que casualmente se parece a una; cada cadena se emite como una cadena básica entrecomillada. Si quieres una fecha y hora de TOML sin comillas, quita las comillas en la salida manualmente — el texto ya es RFC 3339 válido.
¿Qué herramientas relacionadas debería usar después?
- TOML a JSONConvertidor que funciona en tu navegadorAbrir
- Validar JSONValida la sintaxis con línea y columna exactas y repara los erroresAbrir
- Formatear JSONIndenta, ordena claves y quita comentariosAbrir
- Hoja de trucos de sintaxis JSONGuía en lenguaje sencilloAbrir
- JSON vs YAMLComparativa directaAbrir
- Herramientas JSONCompara, formatea, valida y explora documentos JSON.Abrir