De CSV a Excel y vuelta sin estropear tus datos

El problema del separador empieza antes de abrir el archivo

Excel decide cómo dividir un CSV en columnas usando el separador de listas configurado en las opciones regionales del sistema operativo, no mirando el archivo. En un equipo con configuración regional europea, ese separador suele ser el punto y coma, así que una exportación normal separada por comas termina en una sola columna de texto sin dividir. En un equipo configurado para Estados Unidos pasa lo contrario con un archivo separado por punto y coma. Ninguno de estos resultados significa que el archivo esté roto. Significa que Excel ha hecho una suposición basada en ajustes que no tienen nada que ver con cómo se escribió el archivo. Un conversor como CSV a Excel, que analiza el archivo probando varios separadores posibles y comprueba cuál de ellos produce el mismo número de campos en las líneas muestreadas, evita por completo esa suposición, en vez de fiarse de la extensión del archivo o de un ajuste del sistema.

Los ceros a la izquierda y los números largos son las víctimas silenciosas

Lo más dañino que puede ocurrir al convertir de CSV a Excel es que el programa tenga demasiada prisa por convertir texto en números. Un código de producto escrito como 00123 se convierte en el número 123 en cuanto la hoja de cálculo decide que parece numérico, y ese cero inicial ya no se puede recuperar después. Simplemente desaparece. Los identificadores largos fallan de otra forma. Un número de tarjeta o de código de barras de dieciséis dígitos pierde sus últimos dígitos sin ningún aviso, porque los números normales de una hoja de cálculo no pueden almacenar más de unas quince cifras significativas sin redondear. En ambos casos los valores deberían quedarse como texto en lugar de convertirse, y la misma regla vale cuando el destino es un programa y no Excel: CSV a JSON los guarda como cadenas. Los valores que sí son números, como cantidades, precios y totales, deberían seguir convirtiéndose con normalidad para poder sumarlos y usarlos en cálculos.

La codificación es donde se rompen los datos no ingleses

Los archivos exportados desde sistemas contables o bases de datos antiguos con frecuencia no están en UTF-8. Windows-1251 para texto en cirílico y Windows-1252 para caracteres acentuados de Europa occidental son los casos más habituales, y abrir uno con una suposición incorrecta produce la típica pared de caracteres ilegibles. Detectar la codificación real comprobando primero si hay una marca de orden de bytes, validando después de forma estricta como UTF-8 y, si falla, recurriendo a la distribución de los bytes altos, permite captarlo de forma automática. Nadie tiene que adivinar entre una lista de opciones de codificación.

La propia marca de orden de bytes también puede causar daños silenciosos

Una marca de orden de bytes UTF-8 son tres bytes invisibles al principio del archivo que le indican a Excel que el texto que sigue es Unicode. Eso es útil cuando Excel es el destino. Se convierte en un problema en cuanto el destino del archivo es otra cosa. Una herramienta de línea de comandos o un flujo de datos antiguo que no elimine esos bytes termina con ellos pegados al primer carácter de la primera celda de encabezado, así que una columna que debía llamarse «id» deja de coincidir con cualquier cosa que espere exactamente ese nombre. Que haya que conservar o eliminar la BOM depende por completo de qué va a leer el archivo después, no de un valor predeterminado universal.

La conversión en sentido contrario también exige decisiones

Convertir una hoja de cálculo a CSV con Excel a CSV plantea una pregunta que no aparece al ir en la otra dirección. Una celda con una fórmula tiene dos valores: el texto de la fórmula en sí y el número al que se evaluó por última vez, y un CSV solo puede llevar uno de ellos cada vez. Exportar el valor calculado es lo que la mayoría de los sistemas esperan importar. Exportar en cambio el texto de la fórmula es lo que una persona que revise el archivo quiere leer. Las fechas merecen el mismo cuidado explícito. Escribirlas siempre en un formato fijo elegido, en lugar de fiarse de lo que la hoja de cálculo estaba mostrando, evita que el mismo archivo genere fechas con apariencia distinta según los ajustes regionales del equipo que haya hecho el formateo.

Errores habituales y el ajuste que evita cada uno

Dejar el separador decimal en punto. Una exportación con punto y coma de un país que escribe uno y medio como 1,50 necesita el separador decimal en Coma en CSV a Excel; si no, cada precio se queda como cadena y no se deja sumar. Fiarse del tipado automático con identificadores. Protege los ceros iniciales y todo lo que pase de quince dígitos, pero un número de pedido o un código postal sin cero inicial se convierte igualmente en número; si ninguna columna necesita cálculos, los tipos de celda en Todo como texto conservan cada valor tal como está escrito. Meter una exportación de unos cuantos millones de filas en un solo libro. XLSX se detiene en 1 048 576 filas, así que un CSV más largo se rechaza con un enlace a Dividir CSV en lugar de cortarse sin avisar.

En el camino de vuelta, compara tres valores por defecto de Excel a CSV con lo que vaya a leer el archivo después. La codificación de salida es UTF-8 con BOM, la que necesita Excel; un script o un cargador de base de datos suele querer UTF-8 sin más. El formato de fecha es ISO 8601, así que el 14 de marzo de 2026 pasa a ser 2026-03-14 en cualquier equipo, con 14.03.2026, 03/14/2026 y el número de serie de Excel como alternativas. Los finales de línea son CRLF para Windows, con LF para herramientas Unix. Un cuarto ajuste es fácil de pasar por alto: por defecto solo se exporta la primera hoja, así que un libro con una segunda pestaña necesita Todas las hojas, que devuelve un ZIP con un CSV por hoja.