Trabajar con archivos CSV sin romperlos
El CSV parece el formato más simple de la informática: valores, comas, saltos de línea. En la práctica es el formato que más datos estropea en silencio, porque no hay una especificación única y cada generador toma decisiones ligeramente distintas. Casi todos los problemas de CSV vienen de un puñado de ambigüedades, y en cuanto sabes nombrarlas las soluciones son evidentes.
Comas dentro de los valores y cómo funcionan las comillas
En cuanto un valor contiene el delimitador, el formato necesita un escape, y la convención es envolver el campo entre comillas dobles. Una comilla dentro de un campo entrecomillado se escribe entonces dos veces. Por eso un campo de nombre que contiene Smith, John aparece como "Smith, John" y por eso un valor con comillas las duplica: no es una errata, es la regla de escape.
Partir una línea CSV por las comas, por tanto, no funciona, por tentador que resulte. Un analizador correcto lleva la cuenta de si está dentro de un campo entrecomillado, y esos campos pueden contener legalmente comas, comillas e incluso saltos de línea. Si un archivo gana columnas de repente a mitad de camino, la causa casi siempre es un delimitador sin escapar dentro de un valor.
El delimitador no siempre es una coma
En las configuraciones regionales donde la coma es el separador decimal, las hojas de cálculo suelen escribir CSV con punto y coma, de modo que un archivo que se abre perfectamente en una máquina cae en una sola columna en otra. Los tabuladores también son habituales y resultan más seguros precisamente porque rara vez aparecen dentro de los valores.
Como el delimitador no se declara en ninguna parte del archivo, las herramientas tienen que adivinarlo, normalmente probando candidatos y viendo cuál produce un número de columnas coherente. Cuando una importación sale mal, comprobar el delimitador es lo más rápido de descartar; y cuando controlas la salida, los datos separados por tabuladores evitan toda esta clase de problemas.
La codificación y la hoja de cálculo que quiere un BOM
Un texto que se ve como é donde debería haber é es un archivo UTF-8 leído con una codificación antigua de un solo byte. El CSV no lleva declaración de codificación, así que al lector hay que indicársela o tiene que adivinarla, y adivinar mal destroza todos los caracteres no ASCII dejando la estructura intacta, que es por lo que el daño suele llegar hasta la base de datos.
El culpable habitual es Excel: en muchos sistemas asume una página de códigos antigua salvo que el archivo empiece con una marca de orden de bytes UTF-8. Escribir el BOM hace que los acentos se abran correctamente allí, a cambio de unos bytes invisibles al principio que algunos analizadores estrictos te devolverán como parte del nombre de la primera columna. Saberlo de antemano ahorra media hora de desconcierto.
Valores que una hoja de cálculo reescribirá en silencio
El CSV no tiene tipos —todo es texto—, así que el lector decide qué significan las cosas, y las hojas de cálculo son agresivas al respecto. Los ceros a la izquierda desaparecen cuando un código postal o un código de producto se lee como número. Los identificadores largos se convierten en notación científica. Las cadenas que parecen fechas se reformatean según la configuración regional de la máquina, y así el mismo archivo produce resultados distintos en dos oficinas.
Lo seguro es dejar esas columnas como texto en el momento de importar, no arreglarlas después, porque los dígitos originales ya se han perdido una vez ocurre la conversión. Para todo aquello en lo que importan los caracteres exactos —identificadores, teléfonos, códigos— trata la detección automática de tipos como algo que hay que desactivar, no corregir más tarde.
Llevar el CSV a otras formas
Convertir a JSON te da tipos reales y anidamiento, lo que hace los datos mucho más fáciles de validar, pero también obliga a resolver explícitamente las ambigüedades anteriores, así que conviene hacerlo pronto y no tarde. En el sentido contrario, al generar inserciones SQL desde un CSV, la misma cuestión del escape vuelve en una forma más peligrosa: las comillas dentro de los valores deben escaparse para SQL, no para CSV.
Una comprobación breve antes de fiarte de cualquier CSV:
- Confirma el delimitador —coma, punto y coma o tabulador— antes de analizar.
- Confirma la codificación y añade un BOM si el archivo va destinado a Excel.
- Nunca partas por el delimitador de forma ingenua; respeta los campos entrecomillados.
- Importa como texto las columnas de identificadores para conservar los ceros a la izquierda.
- Comprueba el número de filas y columnas tras una conversión, no solo las primeras filas.