Conversor CSV / TSV ↔ JSON

Funciones

• Tres direcciones: CSV → JSON, JSON → CSV y CSV → SQL (sentencias INSERT, con CREATE TABLE opcional)
• ⚠️ Los nombres de tabla y columna de la salida SQL pasan por una lista blanca antes de escribirse: lo demás se entrecomilla con comillas dobles, las comillas simples de los valores se duplican y no se abre ninguna vía de inyección
• ⚠️ La deducción de tipos del SQL es solo una conjetura, y comparte reglas con CSV → JSON (`true` es cadena en ambos)
• Detección del delimitador entre coma, punto y coma, tabulador y barra vertical, guiada por «que todas las filas tengan el mismo ancho», no por la frecuencia
• Las comillas, los saltos dentro de un campo y el escape `""` siguen la RFC 4180, así que el CSV de salida no se descuadra en Excel
• Quita el BOM que escribe Excel: si no, la primera clave esconde un carácter invisible
• Los números solo pasan a número cuando no se pierde nada al ir y volver: `007`, `1.50`, `1e5` y los ID muy largos se quedan como cadenas
• Una tabla sin encabezado se convierte en un array de arrays, en vez de inventar claves como `"0"` y `"1"` que parecen nombres de campo reales
• Los encabezados repetidos reciben un sufijo (`id`, `id_2`), así que una columna no sobrescribe en silencio a la anterior
• Las filas más largas que el encabezado conservan sus columnas de más; las más cortas se rellenan con cadenas vacías
• En JSON → CSV, los nombres de columna son la unión de todas las claves, así que un campo que aparece por primera vez en una fila posterior no se pierde
• Los objetos y arrays anidados se aplanan al texto JSON dentro de la celda
• La salida va con resaltado, y el sangrado del JSON admite 2 / 4 espacios o tabulador

Cómo se usa

1. Pega CSV / TSV o JSON: lo que se pueda analizar como JSON se trata como JSON y el resto como CSV
2. La dirección, el delimitador y si hay encabezado se pueden fijar a mano
3. El resultado es inmediato; si el delimitador se detectó mal, elige uno a mano y vuelve a mirar
4. Haz clic en Copiar para llevarte el resultado

Preguntas frecuentes

¿El tipo del CSV → SQL es una conjetura?

Sí, y la página lo dice. Solo mira cómo son los valores de la columna: si todos son enteros, propone `INTEGER` (si superan los 32 bits, `BIGINT`); si todos son decimales, `NUMERIC`; y en los demás casos, `TEXT`. No sabe qué debería ser esa columna en tu base de datos: una columna con números de teléfono es toda numérica, pero el tipo correcto es `TEXT` (los ceros iniciales, el `+` del código de país). Toma el `CREATE TABLE` como punto de partida y no como conclusión, y ajústalo a tu semántica antes de usarlo.

¿Es seguro ejecutar el SQL generado?

La parte que se compone está escrita contra la inyección: los nombres de tabla y columna pasan primero por una lista blanca (deben empezar por letra o guion bajo, seguir con letras, dígitos o guiones bajos y no ser palabra reservada) y, si no la cumplen, se entrecomillan con comillas dobles; las comillas simples de los valores se duplican siempre. Ambas cosas son necesarias: el contenido del CSV viene de otro sitio, y una sola comilla sin escapar cerraría el valor antes de tiempo y convertiría el resto en parte del SQL. Dicho esto, que la sentencia sea válida es otra cosa: el tipo es una conjetura y los nombres de columna vienen del encabezado, así que revísala antes de ejecutarla.

¿Por qué algunos números se volvieron cadenas y otros no?

Porque el criterio predeterminado es que el viaje de ida y vuelta no pierda nada: solo se convierte cuando pasar el texto a número y volver a texto devuelve la cadena original. `30` pasa a 30 y vuelve a `30`, así que se convierte; `007` pasa a 7 y vuelve como `7`, distinto del original, así que se queda `"007"`; `1.50` se comporta igual; y un entero por encima de 2^53 (como un número de pedido de 20 dígitos) perdería dígitos, así que también se queda como cadena. Así obtienes el tipo numérico sin alterar los datos de forma irreversible. Para leerlo todo como texto, elige «Todo como texto».

¿Cómo se decide el delimitador?

Entre la coma, el punto y coma, el tabulador y la barra vertical se elige el que haga que todas las filas tengan el mismo número de campos. No se usa «el que más aparece» porque el contenido puede engañarlo: en una tabla separada por puntos y coma, si la columna de notas contiene varias comas, el total de comas puede superar al de puntos y coma, y contar llevaría a descuadrar la tabla entera. Si ninguno lo cumple (por ejemplo, porque las filas ya tienen anchos distintos), se vuelve a la coma. Si se detecta mal, elige uno a mano: la opción está encima del resultado.

¿Por qué desaparecen las filas en blanco?

Las filas vacías se saltan. Son habituales en un CSV editado a mano, y ni Excel ni otras herramientas producen una fila de datos al leerlas; si se conservaran, el JSON ganaría un registro vacío del estilo `{"id":"","name":""}`. El precio es que una fila de un CSV de una sola columna cuyo valor sea justo vacío también se descarta; para una tabla de una sola columna con valores vacíos, añade una columna de relleno antes de convertir.

¿Qué pasa con los objetos (arrays) anidados?

Se aplanan al texto JSON dentro de la celda: `{"a":{"x":1}}` se convierte en una celda que contiene `{"x":1}`. El CSV solo tiene filas y columnas, no un sitio para el anidamiento; la otra vía sería desplegarlo en varias columnas (`a.x`), pero eso exige permitir puntos en los nombres de columna y no es reversible. Si de verdad necesitas conservar la estructura, déjala en JSON y no la pases a CSV.

¿Habrá problemas al abrir la salida en Excel?

No. La salida de JSON → CSV usa CRLF, que es lo que fija la RFC 4180 y el único fin de línea que Excel acepta sin condiciones; los campos con comas o saltos van entrecomillados, así que no se descuadran. En la otra dirección (pegar un CSV exportado por Excel) también se trata el BOM que Excel escribe al principio: sin quitarlo, la primera clave llevaría un carácter invisible (U+FEFF) que al imprimirse parece idéntico a `id` pero que `obj.id` nunca encuentra.