Guía de Conversión CSV a JSON

El mes pasado corrupté una lista de 40,000 contactos de un cliente porque el conversor que usé no manejaba comas dentro de campos entre comillas. La fila 847 tenía nombre de empresa: "López, Gutiérrez y Asociados." El conversor dividió eso en dos columnas y cada fila posterior se desplazó una columna a la derecha. Direcciones terminaron en columnas de teléfono. Nombres se fusionaron con emails. Pasé 4 horas arreglándolo manualmente. La herramienta a la que cambié maneja ese caso correctamente. Esto aprendí sobre conversión de datos de la manera difícil.

Cuándo Necesitas Convertir CSV a JSON (Y Viceversa)

La conversión CSV a JSON aparece constantemente en desarrollo web. Tu cliente exporta datos de clientes desde su CRM como CSV. Tu API acepta JSON. Esa conversión tiene que pasar limpiamente o pierdes datos, corrompes campos, o inyectas errores que nadie detecta hasta producción.

La dirección inversa (JSON a CSV) pasa cuando los analistas necesitan datos de tu aplicación en una hoja de cálculo. Tu base de datos almacena objetos JSON anidados. El analista quiere filas planas en Excel. Necesitas aplanar la estructura, decidir cómo manejar arrays, y producir algo que Excel parsee sin destrozar fechas o números.

Las migraciones de base de datos frecuentemente requieren ambas direcciones. Exportar de un sistema como CSV, transformar la estructura, importar en otro como JSON. Cada paso introduce corrupción potencial si tus herramientas no respetan las especificaciones del formato.

Cómo Difieren los Formatos

Estructura CSV

CSV (Comma-Separated Values) es plano. Una fila de cabecera define columnas, cada fila subsiguiente son datos. Sin anidamiento, sin tipado, sin metadata. Un campo es texto, siempre. Si parece un número, una fecha o un booleano es decisión de la aplicación que lo consume.

La especificación RFC 4180 define reglas que la mayoría ignora: campos que contienen comas, comillas o saltos de línea deben estar encerrados en comillas dobles. Una comilla doble dentro de un campo se escapa duplicándola (""). En la práctica, encontrarás CSVs que violan cada una de estas reglas.

Estructura JSON

JSON soporta tipos (string, number, boolean, null, array, object) y anidamiento. Un registro de cliente en JSON puede tener un objeto dirección con campos anidados. En CSV, o aplanas eso a "direccion_calle, direccion_ciudad, direccion_cp" o pierdes la estructura.

Los arrays de JSON no tienen equivalente en CSV. Un cliente con 3 números de teléfono los guarda como array en JSON. En CSV, o creas columnas "telefono_1, telefono_2, telefono_3" (limitando el máximo) o serializas el array como string dentro de una celda, lo que rompe la mayoría del software de hojas de cálculo.

Los 4 Bugs de Conversión Que Rompen Todo

Bug 1: Comas dentro de campos entre comillas. El ejemplo de mi intro. "López, Gutiérrez y Asociados" es un campo, pero un parser naive divide en cada coma sin importar las comillas. Cualquier herramienta que use un simple string.split(",") en vez de un parser CSV apropiado falla en esto. Cerca del 15% de datasets empresariales tienen comas en campos de texto.

Bug 2: Conversión número-string. Código postal 01000 se convierte en 1000 cuando el conversor lo interpreta como número. Número de teléfono +52-55-1234-5678 se convierte en una expresión matemática. Números de tarjeta de crédito pierden precisión porque JavaScript no puede manejar enteros de 16 dígitos sin BigInt. La solución: tratar todo como string durante la conversión y dejar que la aplicación receptora haga el type-casting explícitamente.

Bug 3: Confusión de formato de fecha. Es 01/02/2026 el 1 de febrero o el 2 de enero? Depende del locale. CSV no tiene tipo fecha, así que los strings de fecha se convierten a lo que el parser asume. He visto datasets donde la mitad de las fechas eran DD/MM/AAAA (de fuentes europeas/latinas) y la otra mitad MM/DD/AAAA (de fuentes estadounidenses) en el mismo archivo. El único enfoque seguro: convertir fechas a ISO 8601 (2026-01-02) durante el proceso y verificar una muestra.

Bug 4: Marcadores BOM. Excel agrega un Byte Order Mark (tres bytes invisibles: EF BB BF) al inicio de archivos CSV guardados como UTF-8. La mayoría de parsers JSON incluyen esos bytes en el primer nombre de campo, convirtiendo "id" en "\ufeffid". Tu código no puede encontrar el campo "id" porque en realidad es "\ufeffid" con un prefijo invisible. Elimina marcadores BOM antes de parsear. Toda herramienta CSV robusta hace esto. Los conversores simples no.

Por Qué Ganan los Conversores en el Navegador

Cuando corrupté ese archivo del cliente, usaba un conversor online que subía el CSV a su servidor, lo procesaba y devolvía JSON. Tres problemas: los datos de mi cliente (40,000 contactos con emails y teléfonos) estuvieron momentáneamente en el servidor de alguien más, la conversión tomó 8 segundos de upload/download para un archivo de 2MB, y no tenía forma de verificar qué hizo su parser con edge cases.

Las herramientas en navegador usando File API leen el archivo localmente. JavaScript lo procesa en tu pestaña del navegador. Nada sale de tu máquina. Puedes verificarlo abriendo la pestaña Network en DevTools y observando que cero bytes se transmiten durante la conversión. Para datos sensibles de negocio, esto no es un nice-to-have. Es un requisito.

El rendimiento es bueno para la mayoría de casos. Un CSV de 10MB (aproximadamente 100,000 filas) se convierte a JSON en 2-3 segundos en un navegador moderno. Nuestro conversor CSV a JSON maneja edge cases RFC 4180, elimina marcadores BOM, preserva tipado string, y procesa archivos hasta 50MB. Corre completamente en tu navegador y funciona offline si cargaste la página previamente.

Manejo de Archivos Grandes (10MB+)

Las herramientas en navegador chocan contra límites de memoria alrededor de 50-100MB dependiendo del RAM del dispositivo. Un CSV de 50MB cargado en memoria, parseado y convertido a JSON (que típicamente es 20-40% más grande por repetición de keys) puede consumir 200MB de memoria del navegador. En un teléfono con 4GB de RAM, eso crashea la pestaña.

Para archivos mayores a 50MB, pasa a herramientas de línea de comando. El paquete csvtojson para Node.js hace stream de datos fila por fila, sin cargar el archivo completo en memoria. Maneja archivos de 500MB+ sin problemas en una máquina con 8GB de RAM. Instalas con npm, pipeas tu archivo, listo.

Mi regla: menos de 50MB, usa la herramienta del navegador (instantánea, privada, sin setup). Más de 50MB, baja a la terminal. Más de 1GB, usa un enfoque de streaming en el lenguaje en el que ya está escrito tu pipeline.

Mi Workflow de Conversión para Datos de Clientes

Paso uno: abre el CSV en un editor de texto plano, no Excel. Mira las primeras 5 filas crudas. Verifica el delimitador (coma, punto y coma, tab). Busca marcadores BOM (caracteres invisibles antes del primer header). Verifica si algún campo contiene el carácter delimitador dentro de comillas.

Paso dos: convierte una muestra primero. Toma las primeras 100 filas y conviértelas. Inspecciona el JSON resultante. Verifica que los nombres de campo coincidan exactamente con los headers. Verifica que los números que deberían ser strings (códigos postales, teléfonos, IDs) se mantuvieron como strings.

Paso tres: convierte el archivo completo. Después de que la muestra valide, corre el dataset completo. Compara conteo de filas: las filas del CSV de entrada deben igualar la longitud del array JSON de salida. Si no coinciden, un error de parseo silenciosamente fusionó o descartó filas.

Paso cuatro: verifica spot-check filas con edge cases conocidos. Encuentra una fila con coma en un campo. Encuentra una con comilla. Encuentra una con campo vacío. Verifica que cada una se convirtió correctamente. Esto toma 5 minutos y atrapa los bugs que aparecen en producción como "por qué la dirección de este cliente está en su campo de teléfono?"

Este workflow agrega 10 minutos a lo que podría ser una operación de 30 segundos de arrastrar y soltar. Esos 10 minutos me han ahorrado horas de depurar datos corruptos downstream. Después del incidente con 40,000 contactos, no me salto pasos.