Por qué CSV es más difícil de lo que parece
CSV es el formato al que la gente tira cuando quiere algo simple. Luego se topa con la primera coma dentro de un valor, y el formato simple empieza a revelar lo poco que en realidad consensúa.
La verdad es que no hay un único CSV. Hay docenas de convenciones ligeramente distintas, y cualquier herramienta que lee un archivo producido por otra está haciendo suposiciones que pueden cumplirse o no. Las trampas de abajo son las que pillan a analistas reales en flujos reales, todas las semanas.
Bugs comunes de CSV de un vistazo
| Bug | Síntoma | Arreglo |
|---|---|---|
| Escape de comillas | Comillas sueltas parten filas | Elige un estilo (duplicado o barra) |
| Codificación errónea | Acentos rotos, caracteres de reemplazo | Guarda y lee como UTF-8 con BOM |
| Coerción numérica | Ceros iniciales desaparecen, IDs como floats | Lee columnas como strings |
| Salto de línea final | Fila vacía fantasma al final | Elimina líneas en blanco al parsear |
| Inferencia de cabecera | Tipos erróneos, desfase de columnas | Pasa un esquema explícito |
| Zona horaria de fechas | Fechas saltan un día | Guarda en ISO 8601 con offset |
El delimitador no siempre es una coma
En la mayor parte de Europa, la coma es el separador decimal. Excel en español, francés, alemán, italiano o portugués exporta CSV usando un punto y coma por defecto, porque usar la coma chocaría con que 1,5 significa “uno coma cinco”.
El formato TSV (Tab Separated Values) es la misma idea con tabuladores. Algunos pipelines usan barras (|) por la misma razón. Ninguno está mal. Simplemente no son el mismo archivo.
Cuando recibes un CSV y el parser te lo mete todo en una sola columna, lo primero a comprobar es el delimitador. Abre el archivo en un editor de texto plano y mira las primeras líneas. Lo que esté entre los valores es tu delimitador, da igual lo que diga la extensión.
Campos entrecomillados y comas internas
La regla estándar es: si un valor contiene el delimitador, envuelves el valor en comillas. Hola, mundo se vuelve "Hola, mundo" en un archivo separado por comas.
La trampa es que la regla tiene variantes. Algunos sistemas duplican la comilla interna ("Dijo ""hola"""). Otros la escapan con barra invertida ("Dijo \"hola\""). Excel usa la versión duplicada, la mayoría de herramientas Unix aceptan las dos. Un archivo que parece bien en una herramienta se vuelve basura en otra.
Cuando algo no parsea, pega el archivo en el convertidor CSV a JSON de AldeaCode. Prueba las variantes comunes de comillas y te enseña qué campos contienen comas, comillas o saltos de línea ocultos. Los datos no salen de tu pestaña.
Saltos de línea internos: el destructor silencioso
Un valor de varias líneas (la nota de un cliente, un párrafo de feedback) puede contener un salto de línea real dentro. El estándar dice que envuelves el valor en comillas y el salto pasa a ser parte del campo.
La mayoría de herramientas lo manejan. Algunas no. Algunas cuentan líneas de forma ingenua y acaban reportando “1.000 filas” cuando el archivo de verdad tiene 800, con 200 saltos de línea escondidos dentro de celdas. Si tu cuenta de filas sale ligeramente desviada después de cada export, los saltos de línea internos son el primer sospechoso.
El arreglo es quitar los saltos del origen antes de exportar, o verificar que tu parser maneja campos multilínea entrecomillados. El contador de texto de AldeaCode es útil cuando necesitas una comprobación de cordura sobre el conteo de filas después del parseo.
Errores de codificación: el BOM y el acento
El bug más común con CSV es abrir un archivo en la codificación equivocada. UTF-8 lleva siendo el default en todas partes desde hace quince años, pero Excel todavía guarda CSV como Windows-1252 o similar por defecto en algunos sistemas.
Si abres un archivo UTF-8 como Windows-1252, cada letra acentuada se vuelve mojibake (pingüino se vuelve pingüino). Si haces lo contrario, el archivo no parsea directamente.
El Byte Order Mark (BOM) son tres bytes invisibles que algunas herramientas de Microsoft prependen a los archivos UTF-8. Le dicen al lector “esto es UTF-8”. La mayoría de parsers modernos manejan el BOM correctamente. Algunos lo parsean como parte del header de la primera columna, dejándote con una columna llamada Nombre en lugar de Nombre. Si tu primera columna se niega a coincidir por nombre, sospecha de un BOM.
Decimales y fechas por locale
1,234.56 en Estados Unidos es el mismo número que 1.234,56 en España. La misma cadena parsea como un número distinto según la locale que asuma tu herramienta.
Lo mismo con las fechas. 01/02/2026 es 2 de enero en EE. UU. y 1 de febrero casi en todos los demás. No hay forma de detectar desde la cadena cuál se quiso decir.
El arreglo robusto es usar formatos ISO dentro del archivo: números sin separadores de miles, fechas como 2026-02-01. El arreglo pragmático es preguntar a la herramienta que produjo el archivo qué locale usó, y parsear con esa locale a propósito. Adivinar es como acabas con enero y febrero intercambiados en tres de cada cinco filas.
Una comprobación previa de 10 segundos
Antes de fiarte de un CSV, haz esto:
- Ábrelo en un editor de texto plano. Confirma el delimitador y la codificación.
- Cuenta las filas contando los saltos de línea, luego cuenta otra vez con tu parser. Si los números no coinciden, hay saltos de línea escondidos dentro de celdas.
- Mira el header de la primera columna. Si tiene caracteres raros al principio, tienes un BOM.
- Haz spot check de algunas filas con caracteres acentuados y números decimales. Si algo parece mal, la codificación o la locale están mal.
Cuando necesites inspeccionar un CSV sin el resto del pipeline, el convertidor CSV a JSON, el formateador JSON y el contador de texto de AldeaCode corren en tu navegador. Los datos no salen de tu pestaña, sin subida, sin log.
CSV es uno de esos formatos que funciona perfecto hasta que no lo hace. Las trampas no están en el spec, están en el hueco entre lo que asume tu herramienta y lo que de verdad contiene el archivo. Diez segundos de inspección te ahorran una tarde de debugging.