Por qué tu CSV rompe los acentos y las fechas en Excel

Tres averías, una sola queja

La frase que la gente escribe es siempre la misma: el CSV está roto. Lo que quieren decir es una de tres cosas distintas, y esas tres no tienen nada en común salvo la extensión del archivo. Los acentos están mal: es un problema de codificación. Todo está en la primera columna: es un problema de separador. Los valores son correctos pero con la forma equivocada — 03/04 se ha vuelto una fecha, un código postal ha perdido su cero, una referencia larga se ha convertido en algo con una E dentro — y eso no es ni lo uno ni lo otro: ocurre después de haber leído el archivo correctamente.

Distinguirlas exige un solo gesto: abrir el CSV en un editor de texto plano en vez de en una hoja de cálculo. Bloc de notas, TextEdit, gedit, cualquier cosa que muestre los bytes como texto y no intente ser servicial. En esa ventana no hay columnas, ni celdas, ni tipos: solo líneas con caracteres entre los campos. Si los acentos se ven bien ahí, el archivo es correcto y la culpa está por entero en cómo lo lee Excel. Si también se ven mal ahí, la culpa está aguas arriba, en lo que escribió el archivo, y ningún ajuste de importación lo reparará.

Los acentos: tres bytes que faltan al principio del archivo

En UTF-8, una letra sin acento ocupa un byte y una acentuada ocupa dos. Ese es todo el mecanismo. Cuando un programa lee un archivo UTF-8 creyéndolo escrito en una página de códigos heredada de un byte, muestra cada uno de esos dos bytes como un carácter propio, y el destrozo resultante es del todo determinista. Peña se convierte en Peña, niño en niño, Málaga en Málaga y ¿Sí? en ¿Sí? — donde, para colmo, el segundo carácter de la í es un guion discrecional invisible, así que la palabra parece haber perdido la letra en vez de haberla duplicado. Cada letra acentuada crece exactamente un carácter, y el primero del par es casi siempre una Ã, de ahí el aspecto tan reconocible del estropicio.

El remedio en el que convergió toda la industria cabe en tres bytes al principio mismo del archivo: EF BB BF, la marca de orden de bytes de UTF-8. No codifica ningún carácter y no imprime nada; existe únicamente para que un lector sepa qué está mirando. La página de Microsoft sobre el tema lo dice en una línea — un CSV en UTF-8 se abre con normalidad si se guardó con marca de orden de bytes — y ofrece una vía de importación para los que carecen de ella. Esa sola frase explica por qué casi todos los botones de exportar que has pulsado producen un archivo que empieza con tres bytes invisibles.

El conversor de este sitio no la añade. El CSV que te entrega es UTF-8 sin marca de orden de bytes, y el primer byte del archivo es el primer carácter de tu primer encabezado de columna. Eso es lo correcto según la norma — RFC 4180 define el formato y no menciona nunca una marca — y lo incorrecto para hacer doble clic en una máquina Windows europea. El resto de este artículo trata en buena parte de qué hacer con ese hecho, y la versión corta es: importa el archivo en vez de abrirlo.

El separador: lo decide tu sistema operativo, no el archivo

El nombre valores separados por comas sugiere que la coma forma parte del formato, y RFC 4180 lo define así. Excel no lee el formato: lee un ajuste. La página de solución de problemas de Microsoft lo dice sin rodeos: cambiar el separador de listas en la configuración regional de Windows afecta al delimitador que se emplea al abrir o al guardar un archivo de valores separados por comas, porque Excel usa el carácter separador de listas de Windows como delimitador de los archivos .csv. Añade que la coma es el separador de listas por defecto de la configuración regional inglesa estadounidense.

Que el ajuste no sea una coma en todas partes es cuestión de aritmética, no de gusto. Donde la coma es el separador decimal, no puede además separar campos sin ambigüedad: una fila con un precio de mil doscientos treinta y cuatro coma cinco sería indistinguible de dos campos. Windows entrega por tanto un punto y coma como separador de listas en las configuraciones francesa, alemana, española, italiana y portuguesa, y una coma en las inglesas. Esa es toda la línea divisoria, y por eso una exportación escrita por un servicio estadounidense y abierta en Lyon, Leipzig, León, Livorno o Lisboa llega como una sola columna muy ancha.

De ahí se siguen dos cosas que la gente entiende mal. La primera: cambiar el separador de listas de Windows para arreglar un archivo es un cambio global que afecta a todas las aplicaciones de la máquina, y la propia documentación de Microsoft lo advierte; no es un remedio archivo por archivo y se te olvidará que lo hiciste. La segunda: el delimitador es una propiedad del archivo y el ajuste es una propiedad del lector, así que un archivo nunca está bien ni mal en abstracto: está bien para un lector al que le has dicho la verdad. El cuadro de diálogo de importación existe justamente para que se la puedas decir.

Los tipos: Excel adivina, y adivina mientras abre

Un CSV no tiene tipos. Todo campo es texto, y RFC 4180 asigna a las comillas una única tarea: proteger un campo que contenga una coma, una comilla o un salto de línea. En ninguna parte del formato se puede decir esto es una cadena, no lo toques. Así que una hoja de cálculo que abra uno tiene que adivinar, campo por campo, y las conjeturas están hechas para el caso común, no para el tuyo. Un campo que dice 03/04 parece una fecha y se vuelve una. Un campo que dice 01234 parece un número y pierde su cero. Un campo de dieciséis dígitos parece un número muy grande, y la página de Microsoft enuncia el límite sin suavizarlo: Excel tiene una precisión máxima de 15 dígitos significativos, de modo que para cualquier número de 16 dígitos o más, todo lo que pase del decimoquinto se redondea a cero y el valor se muestra en notación científica.

El caso de las fechas merece un párrafo propio por la forma en que falla. Un campo que dice 02/03/2026 es el 2 de marzo en Madrid y el 3 de febrero en Chicago, y ambas lecturas son legítimas: nada en el archivo dice cuál se quiso decir. Pero un campo que dice 13/03/2026 no tiene decimotercer mes, así que un lector que espere el mes primero no puede interpretarlo como fecha y lo deja como texto. Pasa un año entero de fechas y casi dos de cada cinco son ambiguas: 144 de los 365 días caen el doce del mes o antes. La columna resultante es en parte fechas silenciosamente intercambiadas y en parte texto alineado a la izquierda, sin ningún mensaje de error. Es el fallo silencioso más caro del trabajo de oficina.

Parte del daño ocurre antes incluso de que intervenga Excel, y este conversor no es inocente de ello. Una celda de hoja de cálculo es un valor bruto más un formato de presentación, y el CSV solo puede llevar uno de los dos: lo que se escribe es el texto formateado. Pasa el mismo 2 de marzo de 2026 con un formato de día primero y el archivo recibe 02/03/2026; pasa el valor idéntico con un formato de mes primero y el archivo recibe 3/2/26. Peor aún, un identificador de dieciséis dígitos en una columna con formato general sale del libro ya escrito como 1.23457E+15, porque así lo mostraba el libro. Al identificador lo destruyó el formato, no el lector. Nada aguas abajo puede recuperarlo.

Lo que arregla de verdad cada caso

Importar en vez de abrir. Ese solo cambio resuelve de golpe los dos primeros problemas y te da la herramienta para atacar el tercero. Datos, luego Desde texto/CSV, abre una vista previa con el origen del archivo y el delimitador visibles y modificables, y la vista previa se redibuja al cambiarlos, así que ves los acentos recolocarse y las columnas separarse antes de comprometerte. Elegir Transformar datos en lugar de Cargar permite después fijar el tipo de una columna a Texto — la propia guía de Microsoft sobre conservar ceros iniciales señala justo esta vía — y una columna con tipo Texto conserva sus ceros, conserva sus dieciséis dígitos y no se vuelve una fecha.

Existe una palanca más reciente y más duradera que muy poca gente conoce. En Microsoft 365 y Excel 2024, tanto en Windows como en Mac, Archivo, Opciones, Datos contiene una sección llamada Conversión automática de datos con cuatro casillas: quitar ceros iniciales y convertir en número; conservar los 15 primeros dígitos de los números largos y mostrarlos en notación científica si hace falta; convertir los dígitos que rodean la letra E en notación científica; y convertir en fecha las combinaciones de letras y números con aspecto de fecha. Desmarcar las dos primeras es el mejor uso de diez segundos para cualquiera que maneje datos de referencia, porque detiene la destrucción en el origen en vez de exigirte recordar un ritual de importación cada vez.

Lo que no funciona también merece una lista, porque son las sugerencias que te van a dar. Envolver un campo en comillas no detiene la conversión: las comillas son estructurales, dicen dónde acaba el campo, y Excel las quita antes de empezar a adivinar. Renombrar el archivo para que deje de ser un .csv cambia la ruta de código que lo abre, efecto real pero frágil en el que apoyarse. Formatear la columna como Texto una vez abierto el archivo no hace nada, porque los dígitos se perdieron durante la carga y Microsoft lo dice: un formato de texto solo afecta a lo que introduzcas después. Y poner un signo igual delante de un valor entrecomillado sí fuerza texto, pero convierte el campo en una fórmula en lugar de un valor, se muestra como caracteres literales en cualquier otro programa que lea el archivo, y un signo igual inicial es el vector clásico de la inyección de fórmulas en hojas de cálculo. No se lo mandes a nadie.

Lo que este conversor pone en el archivo

Leído en el código fuente en vez de en el argumentario: la herramienta Excel a CSV lee tu libro en el navegador, te deja elegir una hoja y escribe esa hoja con una coma entre campos, codificación UTF-8 y sin marca de orden de bytes. Los campos se entrecomillan solo cuando hace falta — cuando contienen una coma, unas comillas dobles o un salto de línea — que es exactamente lo que exige RFC 4180 y nada más. Un campo que contenga una comilla la ve duplicada, según la misma regla. No se sube nada: el libro se analiza en tu máquina y el CSV no sale de ella.

Dos de esas decisiones morderán al lector europeo que haga doble clic en el resultado, y conviene saber cuáles. La coma pondrá todo en la columna A en una máquina cuyo separador de listas sea el punto y coma. La ausencia de marca de orden de bytes estropeará los acentos en una máquina que recurra a una página de códigos heredada. Ambas se curan con el mismo procedimiento de importación y ninguna se cura quejándose del archivo, que es conforme a la norma. Si envías el CSV a una persona y no a un programa, di qué separador y qué codificación usaste: una línea en el correo ahorra una tarde.

Un hábito vale más que todos los ajustes de este artículo: arregla el libro antes de exportarlo, no el CSV después. Pon las columnas de identificadores en Texto dentro de la hoja de cálculo, para que los códigos postales y los números de cuenta ya sean cadenas cuando ocurra la conversión. Pon las columnas de fechas en un formato inequívoco — el año primero, con cuatro cifras, luego el mes, luego el día — para que el texto exportado no pueda leerse de dos maneras en ninguna configuración regional del mundo. Hazlo una vez, y cada exportación de ese libro será limpia para todos los lectores, para siempre, sean cuales sean sus ajustes regionales.

Preguntas frecuentes

He abierto el archivo y cada fila está en la columna A. ¿Está roto el CSV?

Casi con seguridad no. Lo que ves es a Excel dividiendo por un carácter que tu archivo no usa. Microsoft documenta que Excel toma el delimitador de los archivos .csv del separador de listas de Windows, así que un archivo separado por comas en una máquina configurada con punto y coma no encuentra ninguno y concluye que cada línea es un campo enorme. Abre el archivo en un editor de texto y mira la primera línea: el carácter que hay entre los encabezados es el delimitador real. Ciérralo, ve a Datos y a Desde texto/CSV, y elige ese carácter en la vista previa. Dos cosas que no hacer: no dividas la columna a mano, porque volverás a hacerlo el mes que viene; y piénsatelo dos veces antes de cambiar el separador de listas de Windows, ya que la propia documentación de Microsoft advierte de que es un cambio global que afecta a todas las aplicaciones de la máquina.

¿Por qué poner comillas alrededor de un campo no impide que Excel lo convierta en fecha?

Porque las comillas en un CSV son puntuación, no anotación. RFC 4180 les da una única tarea: marcar dónde empieza y termina un campo cuando el propio campo contiene una coma, unas comillas dobles o un salto de línea. No llevan información sobre lo que el campo significa, y el formato no ofrece ningún otro sitio donde meter esa información: un CSV no tiene realmente ningún concepto de tipo. Así que el lector quita las comillas como parte del análisis, exactamente como debe, y solo entonces empieza a adivinar qué tiene entre manos. Por eso todos los remedios que publica Microsoft están del lado de la lectura y no de la escritura: importar la columna como Texto, o desactivar las conversiones automáticas. Nada de lo que escribas en el archivo restringirá la conjetura.

¿Basta con poner sep=; en la primera línea para que Excel lo entienda?

Funciona en Excel y es una trampa en todo lo demás. Esa primera línea es una extensión propia de Excel: RFC 4180, que define el formato CSV, no la menciona y ningún analizador conforme está obligado a entenderla. Así que el archivo se vuelve más fácil para un programa y más difícil para todos los demás: un script, una importación a base de datos, un programa de contabilidad o un compañero en Mac leerán esa línea como una fila de datos con un campo llamado sep=; y fallarán o importarán en silencio un registro basura en lo alto de tu tabla. Si el archivo va a una persona que lo abrirá en Excel y en ningún otro sitio, es una comodidad razonable. Si va a una cadena de proceso, o a alguien cuyas herramientas desconoces, no lo pongas: manda el archivo limpio y di en una frase qué separador y qué codificación usaste.

Mi número de referencia de 16 dígitos ahora acaba en ceros. ¿Dónde han ido los dígitos?

Se redondearon, y no son recuperables desde ese archivo. Microsoft enuncia la regla directamente: Excel tiene una precisión máxima de 15 dígitos significativos, y para cualquier número de 16 dígitos o más todo lo que pase del decimoquinto se redondea a cero. El valor se muestra luego en notación científica porque ya no cabe de forma útil en la columna. Lo importante es que esto no es un problema de presentación: ensanchar la columna o cambiar el formato de número no traerá de vuelta los dígitos, porque han desaparecido del valor almacenado. Vuelve a la fuente original, importa la columna como Texto y no dejes nunca que un número de referencia, un número de cuenta, un número de tarjeta o un código de producto largo exista como número en ningún punto de la cadena. En Microsoft 365 y Excel 2024 también puedes desactivar la conversión sin más: Archivo, Opciones, Datos, y desmarca la opción sobre conservar los 15 primeros dígitos de los números largos.

¿Coma o punto y coma? ¿Cuál es realmente el correcto?

Según la norma, la coma. RFC 4180 define el formato con comas entre campos, un retorno de carro y un salto de línea al final de cada registro, y comillas dobles alrededor de cualquier campo que contenga uno de esos caracteres. Todos los lenguajes de programación, bases de datos y herramientas de datos la siguen, así que la coma es lo que hay que usar para todo lo que vaya a leer una máquina. En la práctica, sin embargo, el punto y coma es lo que espera una hoja de cálculo en la mayor parte de Europa continental, por la razón aritmética de que allí la coma ya es el separador decimal. La regla practicable es decidir por destino y no por principio: coma para máquinas y para todo lo que cruce una frontera, punto y coma cuando el archivo va directo al Excel de un compañero cuya configuración regional conoces. Y elijas lo que elijas, dilo: una línea indicando el separador y la codificación previene toda la clase de problemas de la que trata este artículo.