Por qué tu CSV se abre mal en Excel

Excel no mira dentro de un archivo .csv para averiguar cómo está separado. Cuando haces doble clic en uno, usa el separador de listas de la configuración regional de tu sistema operativo, y si ese separador no coincide con el del archivo, cada fila acaba en una sola columna.

En el Reino Unido y en Estados Unidos el separador de listas es la coma. En la mayor parte de Europa continental y en buena parte de Latinoamérica, donde el separador decimal se escribe con coma, el separador de listas es el punto y coma. Así que un archivo separado por comas perfectamente válido enviado desde Londres se abre como una única columna apelmazada en Ámsterdam, Berlín o Madrid, y un archivo con punto y coma hace lo mismo a la inversa. No hay nada dañado; el archivo se está leyendo con la suposición equivocada.

Tres formas de abrirlo bien

1. Impórtalo en vez de abrirlo. En Excel, Datos y después Obtener datos o Desde texto/CSV, y elige el delimitador y la codificación en el cuadro de diálogo. Es la única vía que te da control total y la única que sobrevive a que el archivo se envíe a otro país.
2. Renombra el archivo a .txt. Excel se niega a adivinar con un archivo .txt y muestra en su lugar el asistente de importación, que te pregunta cuál es el separador.
3. Convierte el archivo al separador que espera quien lo va a leer antes de enviarlo. Si sabes que el destinatario tiene una configuración regional de punto y coma, mándale un archivo con punto y coma.

La línea sep=

Tanto Excel como LibreOffice entienden una primera línea especial que anula la configuración regional:

sep=;
name;email;country
Ada;ada@example.com;UK

Funciona, y es la solución habitual para el clásico «el cliente no puede abrir mi exportación». Ten en cuenta que es una convención de hojas de cálculo, no forma parte de ninguna especificación de CSV. Pásale el mismo archivo a un script o a una importación de base de datos y sep=; se leerá como una primera fila normal, que suele acabar convertida en una cabecera de columna falsa. Úsala para archivos destinados a una persona con una hoja de cálculo, no para intercambio entre máquinas.

Entrecomillado y escapado

La referencia informal para CSV es el RFC 4180, que describe la práctica habitual más que dictarla. Sus reglas son cortas:

• Un campo tiene que ir entre comillas dobles si contiene el separador, una comilla doble o un salto de línea.
• Una comilla doble dentro de un campo entrecomillado se escribe dos veces.

id,name,note
1,"Smith, Ada","She said ""hello"" twice"
2,"Multi
line note",fine

La fila 1 tiene tres campos, no cuatro, porque la coma está dentro de las comillas. Las comillas dobladas se reducen a una sola al analizarlas. La fila 2 contiene un salto de línea real dentro de un campo entrecomillado, lo cual es válido y es la razón por la que no puedes dividir un CSV de forma fiable contando líneas.

El escapado con barra invertida (\, o \") es una convención distinta que usan algunas herramientas de bases de datos. No es RFC 4180 y un analizador estricto no la va a entender, así que si tu archivo usa barras invertidas, dilo de forma explícita a lo que vaya a leerlo.

La rotura más habitual que se ve por ahí es un archivo escrito concatenando cadenas, donde un valor que contenía una coma o una comilla suelta nunca llegó a entrecomillarse. Eso produce filas con más campos que la cabecera, que es exactamente el tipo de cosa que señala un validador.

El BOM y por qué los caracteres acentuados se convierten en mojibake

Una marca de orden de bytes (BOM) son tres bytes invisibles al principio del todo de un archivo que lo marcan como UTF-8. Excel en Windows ha dependido históricamente de ella: sin BOM, puede recurrir a una codificación regional antigua, de forma que Müller aparece como Müller y café como café.

La contrapartida es que otros analizadores no siempre la eliminan. Si tu script informa de una primera columna llamada \ufeffid en vez de id, o una búsqueda por "id" falla misteriosamente solo en la primera columna, el culpable es un BOM. Lee el archivo con la codificación utf-8-sig y desaparece.

Regla general: incluye el BOM en los archivos pensados para abrirse en Excel y déjalo fuera de los archivos pensados para que los analice un programa.

Finales de línea

Las herramientas de Windows escriben \r\n al final de cada fila y las de Unix escriben \n. La mayoría de analizadores se apañan con ambos, pero una división ingenua por \n deja un retorno de carro pegado al último campo de cada fila, y por eso un valor que parece UK se niega a ser igual a "UK" en las comparaciones.

Cómo saber qué separador usa un archivo de verdad

Abre el archivo en un editor de texto plano, nunca en una hoja de cálculo, porque la hoja de cálculo ya ha hecho su suposición. Después:

1. Mira las dos o tres primeras líneas. ¿Qué carácter candidato (coma, punto y coma, tabulador, barra vertical) aparece entre lo que claramente son valores de campo?
2. Cuenta cada candidato en varias líneas. El separador real da el mismo recuento en todas las líneas, uno menos que el número de columnas. Un carácter que aparece siete veces en una línea y dos en la siguiente es dato, no estructura.
3. Haz ese recuento fuera de las secciones entrecomilladas. En "Smith, Ada" la coma es contenido, y contarla de forma ingenua es lo que hace que las comas parezcan inconsistentes en un archivo que sí está separado por comas.
4. Vigila las comas decimales. Un archivo europeo suele tener a la vez separadores de punto y coma y comas dentro de los números, como en Ada;1.234,56;UK. Si solo ves comas entre dígitos, son separadores decimales, no separadores de campo.
5. Comprueba los primeros bytes en busca de una línea sep= o de un BOM antes de concluir nada.

Los tabuladores merecen una mención aparte. Un archivo separado por tabuladores suele ser lo más seguro que se le puede dar a una hoja de cálculo, porque los tabuladores casi nunca aparecen dentro de valores reales y Excel los maneja bien por la vía de la importación. El problema es que los tabuladores son invisibles, así que un archivo en el que alguien ha alineado las columnas con espacios se ve idéntico y no se analiza en nada útil.

Una vez que conoces el separador, convertir el archivo es mecánico: léelo con el delimitador y el entrecomillado correctos y después escríbelo con el que espera tu destino, o conviértelo a JSON y sáltate por completo la cuestión del delimitador.