Convertidor JSON / CSV / YAML / SQL / XML

No. Los datos se analizan y se convierten en tu navegador con JavaScript, y la herramienta no los sube a LeedyBox ni los guarda. Al abrirse, la página carga dos bibliotecas de código abierto desde el propio leedybox.com, js-yaml para YAML y PapaParse para CSV; se ejecutan dentro de la página, y tus datos no se envían a ningún sitio.

Una entrada que empieza por { o [ se lee como JSON; una que empieza por <, como XML, y una que empieza por una palabra clave SQL como INSERT, CREATE, SET, START, UPDATE o WITH seguida de un espacio, o por un comentario -- o /*, como SQL. Todo lo demás se prueba como CSV si su primera línea contiene una coma, una tabulación o un punto y coma, y después como YAML. Elige tú el formato en el menú «Entrada» en estos casos: cuando un CSV o un YAML empieza por una palabra que también es una palabra clave SQL, por ejemplo una fila de encabezado CSV que empieza por Start date o Update time, porque entonces se lee como SQL y falla; cuando todas las líneas de una entrada YAML tienen el mismo número de comas, como title: Hello, world seguido de tags: news, tech, porque entonces puede leerse como CSV; con un CSV delimitado por barras verticales o de una sola columna, que la detección automática no reconoce, y cuando falla una entrada YAML o CSV, porque entonces la detección automática solo indica que no se reconoció el formato, mientras que con un formato elegido se muestra el error del propio analizador y, en la mayoría de los casos, dónde se produjo.

Con el menú «Entrada» en JSON, solo se acepta JSON válido, así que usa ese ajuste con «Validar sintaxis» para comprobar que el texto es JSON válido. Con «Detección automática», una entrada que empieza por { o [ pero no es JSON válido se lee como sintaxis de flujo YAML cuando es posible, y una nota lo indica: en ese caso, las comas finales, las comillas simples y las claves sin comillas funcionan, pero una clave sin comillas necesita un espacio después de los dos puntos, porque {a:1} se lee como una clave llamada a:1 con valor nulo. Los comentarios // y /* */ no son comentarios en YAML; pueden acabar dentro de claves o valores, o impedir que se lea la entrada, así que quítalos antes. JSON Lines (NDJSON) se ofrece como formato de salida, pero no se lee como entrada cuando tiene más de una línea; pon las líneas entre [ y ] con una coma después de cada línea excepto la última.

Los valores YAML sin comillas que parecen números se leen como números, así que una versión como 1.10 pasa a ser 1.1, un código postal como 01234 pasa a ser 1234 y 0x1F pasa a ser 31; pon esos valores entre comillas en el YAML para conservarlos como texto. El convertidor lee el YAML con el esquema core de js-yaml, que sigue YAML 1.2 en los booleanos y las fechas, así que yes, no, on, off y las fechas como 2026-10-02 se quedan como texto, y solo las formas de true y false, como True o FALSE, pasan a ser booleanos. Al convertir JSON a YAML, las cadenas que podrían malinterpretarse, como "01234", "1.10" o "yes", se escriben entre comillas.

Los elementos hijos que se repiten bajo el mismo padre se convierten en una matriz, pero uno solo se convierte en un valor simple o en un objeto, así que <items> con un <item> da una estructura distinta de <items> con dos. Todos los valores XML se leen como texto, así que <id>1</id> pasa a ser "1" y 007 conserva sus ceros, mientras que los comentarios y las instrucciones de procesamiento se descartan. Para la salida CSV y SQL, las filas se toman de una matriz dentro de envoltorios de una sola clave como <items>, así que con un único <item> todo el elemento acaba como texto JSON en una sola columna; para CSV, «Aplanar (columnas a.b.c)» lo divide en columnas.

Sí, si las filas están en sentencias INSERT INTO ... VALUES. Las sentencias de preparación como CREATE TABLE, SET o LOCK se omiten, otras sentencias como DROP TABLE se ignoran y se indican en una nota, y las filas de varias tablas se combinan en una sola lista, así que pega las tablas de una en una si sus columnas son distintas. De forma predeterminada, mysqldump omite los nombres de columna, así que las columnas se llaman column1, column2, etc., salvo que hagas el volcado con --complete-insert. Por su parte, pg_dump escribe las filas como bloques COPY de forma predeterminada, y la herramienta no los lee, así que haz el volcado con --column-inserts. Si el volcado también contiene funciones o procedimientos almacenados, pega solo las sentencias INSERT: la herramienta divide la entrada por los puntos y coma, así que un INSERT dentro del cuerpo de una función puede leerse como datos o detener la conversión.

Todos los valores CSV se tratan como texto, lo que conserva los ceros iniciales de valores como 01234, pero convierte 42 en "42" en JSON y en '42' en SQL, y una celda vacía pasa a ser una cadena vacía en lugar de null o NULL. El tipo de cada columna se elige a partir de los valores de esa columna, así que una tabla creada a partir de CSV tiene columnas de texto: VARCHAR(255), o TEXT cuando un valor tiene más de 255 caracteres (NVARCHAR(255) o NVARCHAR(MAX) en SQL Server, TEXT en SQLite). Cuando la entrada es JSON o YAML y todos los valores de una columna son números sin comillas, o todos son true o false, la columna recibe en cambio un tipo numérico o booleano: un tipo entero (INT, INTEGER o BIGINT, según la base de datos y el tamaño de los números), un tipo de coma flotante para los decimales, o BOOLEAN (BIT en SQL Server, INTEGER en SQLite). La sentencia no incluye clave primaria, índices ni restricciones NOT NULL, así que añádelos antes de ejecutarla si tu tabla los necesita.