CSV y JSON son los dos formatos de datos tabulares más comunes en el software moderno, y moverse entre ellos de forma confiable es una de las tareas de ingeniería de datos más frecuentes en cualquier proyecto. CSV es la lengua franca de las hojas de cálculo, las exportaciones analíticas y los sistemas heredados; JSON es el estándar para las APIs web, las canalizaciones de datos modernas y las bases de datos de documentos. Las secciones a continuación explican los casos límite sutiles que confunden a los conversores ingenuos, cuándo elegir cada formato y cómo interpretar la salida del Inspector de Datos para detectar problemas de calidad antes de que lleguen a producción.
Casos Límite Que Confunden a los Conversores Ingenuos
Un analizador CSV ingenuo divide cada línea por el carácter delimitador y lo da por terminado, pero los archivos CSV del mundo real contienen varios casos límite que rompen ese enfoque. Los campos entrecomillados son el más común: una celda como `"Smith, John"` contiene una coma que es parte del valor y no un separador de campos, y el analizador debe rastrear el estado de las comillas mientras recorre la línea. Los saltos de línea incrustados dentro de campos entrecomillados son legales según la RFC 4180 pero con frecuencia se analizan mal — una fila CSV puede abarcar múltiples líneas físicas cuando una celda entrecomillada se envuelve. Las comillas dobles escapadas dentro de campos entrecomillados se representan como dos comillas dobles consecutivas (`"He said ""hello"""`), que deben colapsarse a una sola comilla en la salida. Las marcas de orden de bytes (BOM) Unicode aparecen al inicio de archivos guardados por Excel en Windows y crean bytes basura invisibles en el primer nombre de campo a menos que se eliminen. Distintos sistemas usan distintos finales de línea (LF en Unix, CRLF en Windows, ocasionalmente CR solo en archivos Mac antiguos), y el analizador debe manejar los tres para evitar filas vacías al final. Este conversor maneja correctamente cada uno de estos casos, pero si escribes tu propio conversor, no improvises tu propio analizador — usa una biblioteca bien probada como Papa Parse en JavaScript, el módulo csv en Python o equivalente.
Cuándo Elegir CSV o JSON
La elección de formato depende del consumidor y la forma de los datos más que del origen. Elige CSV cuando los datos son fundamentalmente tabulares (filas de registros homogéneos), cuando el consumidor es una herramienta de hoja de cálculo (Excel, Google Sheets, Numbers), una canalización ETL heredada, o cualquier analista que abrirá el archivo para revisarlo a simple vista. CSV tiene cero sobrecarga estructural — la representación más pequeña posible de datos tabulares — lo que importa cuando los archivos alcanzan gigabytes. Las desventajas: CSV no tiene sistema de tipos (todo es una cadena), no soporta estructuras anidadas (los datos jerárquicos deben aplanarse) y no tiene una forma formal de representar nulos (usualmente cadena vacía o un centinela como `NULL`). Elige JSON cuando los registros son heterogéneos (forma distinta por registro), cuando los datos tienen anidamiento natural (pedidos con líneas de detalle, usuarios con direcciones), o cuando el consumidor es una API moderna, una aplicación JavaScript o una base de datos de documentos. JSON preserva los tipos y la estructura nativos. Las desventajas son el tamaño (JSON con claves repetidas es de 2 a 5 veces más grande que el CSV equivalente) y el costo de análisis (JSON requiere un analizador completo mientras que CSV puede transmitirse). JSONL resuelve el dilema para conjuntos de datos muy grandes que son naturalmente jerárquicos — cada línea es analizable de forma independiente, lo que permite verdadera transmisión sin retener el archivo entero en memoria.
Usar el Inspector de Datos para Detectar Problemas
La pestaña Inspector de Datos saca a la luz problemas de calidad de datos que de otro modo solo aparecerían aguas abajo cuando algo se rompe. La señal más importante es la tasa de llenado por columna — el porcentaje de filas que tienen un valor no nulo en cada columna. Una columna al 100% de llenado está completamente poblada; una columna al 50% de llenado tiene la mitad de sus filas vacías, lo cual puede ser correcto (campos opcionales) o puede indicar corrupción de datos en el origen. Revisa manualmente las columnas con menos del 80% de llenado antes de enviar los datos a cualquier lugar importante. La inferencia de tipos informa si una columna es consistentemente numérica, consistentemente de texto, o mixta. Las columnas de tipo mixto suelen ser un error en el origen — típicamente una columna numérica con algunas entradas de texto extraviadas que causarán errores de tipo en un consumidor de tipado estricto aguas abajo. El conteo de valores únicos detecta claves duplicadas: si tu supuesta columna de clave primaria tiene menos valores únicos que el total de filas, los datos de origen tienen duplicados que deben deduplicarse antes de la importación. Los valores de muestra te dan una verificación rápida de que los primeros valores de cada columna se ven razonables — fechas que se analizaron como cadenas, números con símbolos de moneda aún adheridos, o espacios al final que harán fallar las coincidencias de texto. En conjunto, estos diagnósticos detectan aproximadamente el 90% de los problemas reales de calidad de datos CSV/JSON antes de que salgan de esta herramienta.