Por qué las exportaciones CSV de hojas de cálculo se rompen al convertirlas
Una exportación CSV parece datos simples, obviamente estructurados. En cuanto aparece una dirección real, un cero a la izquierda o un salto de línea incrustado, esa simplicidad resulta ser una ilusión.
· 4 min de lectura
Por qué CSV parece trivial y no lo es
Un archivo CSV parece casi tan simple como puede serlo un formato de datos — dividir cada línea por comas, tratar la primera línea como encabezados de columna, listo — y esa aparente simplicidad es exactamente lo que hace que el formato sea tan fácil de manejar mal en cuanto aparecen datos del mundo real. El enfoque ingenuo de dividir por comas funciona perfectamente en un ejemplo de juguete y se rompe en la primera fila donde un valor de dato real resulta contener una coma propia, lo cual es algo rutinario en lugar de un caso extremo: una dirección como "Calle Mayor 123, 4º" o el nombre de una empresa como "García, López y Cía." son valores completamente ordinarios que legítimamente contienen exactamente el carácter que un analizador simple usa como separador de campos.
Cómo maneja CSV realmente las comas dentro de un valor real — y cómo se equivocan las herramientas ingenuas
La especificación de CSV resuelve el problema de la coma incrustada permitiendo que un campo se envuelva entre comillas dobles, dentro de las cuales las comas, e incluso los saltos de línea, son simplemente datos literales y no estructura — un campo correctamente entrecomillado como `"García, López y Cía."` se entiende como un único valor que contiene una coma, no dos valores separados por esa coma. Un analizador que divide ingenuamente por cada coma sin rastrear si actualmente está dentro de un campo entrecomillado no tiene forma de hacer esa distinción, y divide silenciosamente ese único nombre de empresa en dos columnas espurias — normalmente sin lanzar ningún error, que es precisamente lo que hace peligrosa a esta clase de error: la conversión parece exitosa, y la corrupción solo se descubre después, a menudo mucho después de que esos datos malformados ya se hayan usado para algo.
Saltos de línea incrustados dentro de una sola celda
Una celda de hoja de cálculo que contiene una nota o dirección de varias líneas es completamente normal, y cuando esa celda se exporta a CSV, la especificación la maneja igual que maneja una coma incrustada: todo el campo se envuelve entre comillas, y el salto de línea dentro de él es genuinamente parte de los datos del campo, no una señal de que ha empezado una nueva fila. Un analizador que asume que cada salto de línea en el archivo marca el inicio de un nuevo registro, sin rastrear si actualmente está dentro de un campo entrecomillado abierto, divide esa única celda de varias líneas en lo que parecen varias filas separadas — corrompiendo silenciosamente la estructura de filas de todo lo que sigue en el archivo, ya que cada fila posterior queda ahora desplazada por la cantidad de filas espurias adicionales que introdujo la celda rota.
Ambigüedad de tipos: ceros a la izquierda, números de teléfono, y números que en realidad no lo son
Cada valor individual en un archivo CSV crudo se almacena como texto plano, sin ninguna forma integrada de indicar si un valor dado es "realmente" un número, un booleano, o simplemente una cadena que resulta parecer numérica — lo cual se convierte en un problema real en cuanto un conversor intenta ser útil infiriendo tipos automáticamente. Un código postal como "007" o un identificador como "042" tiene un cero a la izquierda que es semánticamente significativo — es un identificador de ancho fijo, y "7" y "007" son identificadores distintos aunque representen el mismo número — pero un conversor que analiza con entusiasmo cadenas de apariencia numérica como números reales elimina silenciosamente ese cero a la izquierda, ya que el número 7 no tiene ningún concepto de cuántos ceros lo precedían antes. Un número de teléfono como "+34 600 000 000" parece parcialmente numérico pero no son datos aritméticos en absoluto, y convertirlo en un número produce algo genuinamente sin sentido. La opción segura y correcta por defecto es dejar los valores ambiguos como texto a menos que un valor sea inequívoca y seguramente numérico, ya que adivinar mal aquí corrompe los datos en silencio en lugar de lanzar un error visible y detectable.
Por qué Excel en concreto añade una segunda capa de problemas sin relación
Más allá de los casos extremos genuinos del propio formato CSV, Microsoft Excel introduce fricción adicional que no tiene nada que ver con la especificación CSV en sí: muchas configuraciones regionales europeas y de otras regiones de Excel usan por defecto el punto y coma en lugar de la coma como separador de campos, ya que la coma ya se usa como separador decimal en esas configuraciones regionales, lo que significa que un archivo CSV exportado desde una de esas configuraciones de Excel no se analizará correctamente con un analizador delimitado por comas. Excel también tiene la conocida costumbre de reformatear automáticamente valores que cree reconocer cuando se abre un archivo CSV para verlo — convirtiendo un identificador numérico largo en notación científica, por ejemplo — que es una mala interpretación al mostrarlo por parte de Excel, no un defecto del propio archivo CSV subyacente, pero que rutinariamente se confunde con corrupción de datos real en la exportación misma.