Por qué tu CSV muestra caracteres extraños en Excel y cómo corregir la codificación (Guía 2026)

Diagnóstico en 30 segundos: tus datos no están dañados, están mal leídos

Lo primero que hay que establecer cuando un CSV se abre con caracteres extraños es si los datos están dañados o solo se muestran mal, porque los dos casos tienen soluciones muy distintas, y la solución equivocada puede convertir un problema de visualización en una pérdida real de datos. Esta es la prueba de 30 segundos. Abre el mismo archivo en un editor de texto simple, el Bloc de notas en Windows o TextEdit en modo de texto plano en un Mac, o en Hojas de cálculo de Google mediante Archivo y luego Importar. Si los caracteres se ven correctos allí, tus datos están intactos y solo la visualización en Excel está mal. El archivo en disco contiene los bytes correctos, y Excel simplemente los está decodificando con la codificación equivocada. Ese es el caso más común, y todas las soluciones de esta guía parten de él.

La segunda pista es qué caracteres están mal. Si el texto simple en inglés, los números y los signos de puntuación se ven bien, pero las letras con tilde, las diéresis, las cedillas, el signo del euro y las escrituras no latinas se ven mal, estás ante un problema de codificación, no ante un problema de delimitador ni ante datos dañados. Un problema de delimitador mete filas enteras en una sola columna. Los datos dañados desordenan todo o eliminan filas. Un problema de codificación es preciso: rompe exactamente los caracteres que necesitan más de un byte en UTF-8 y deja todo lo demás intacto. Si tu archivo muestra José donde debería mostrar José, o München donde debería mostrar München, ese patrón es la huella de unos bytes UTF-8 leídos como una codificación antigua de un solo byte, y te indica tanto la causa como la solución.

La tercera comprobación decide si el rescate sigue siendo posible. Si los caracteres distorsionados también se ven en el editor de texto, es posible que el archivo se haya vuelto a guardar después de la lectura incorrecta, y que los caracteres equivocados ya estén escritos en el archivo. Todavía no entres en pánico, y sobre todo no vuelvas a guardar encima del original. La sección de rescate más adelante en esta guía trata exactamente este caso, incluido el único caso en el que los caracteres son realmente irrecuperables: cuando un carácter fue sustituido por un signo de interrogación o por un símbolo de sustitución durante un guardado, la información original desapareció de esa copia, y solo los datos de origen pueden regenerarla. Hasta que lo hayas comprobado, mantén intacto el archivo original, trabaja sobre una copia y nunca guardes un archivo distorsionado encima del bueno.

Por qué Excel adivina mal: un archivo CSV no lleva etiqueta de codificación

Para entender por qué esto sigue ocurriendo, necesitas un dato sobre el formato CSV: un archivo CSV es texto plano sin ningún encabezado que indique qué codificación usa. Un archivo de hoja de cálculo lleva consigo su estructura y su codificación de texto. Un archivo CSV no lleva ninguna de las dos cosas. Son solo bytes, comas y saltos de línea. Cuando un programa lo abre, el programa debe decidir cómo convertir esos bytes en caracteres, y los distintos programas deciden de forma distinta. Los editores de texto modernos y Hojas de cálculo de Google detectan UTF-8 automáticamente en la mayoría de los casos, y por eso el mismo archivo se ve correcto en ellos. Excel, cuando haces doble clic en un archivo CSV, no detecta nada. Asume la codificación predeterminada de tu sistema, que en muchos sistemas Windows es una página de códigos antigua como Windows-1252, y no comprueba si esa suposición fue correcta.

Esa suposición es todo el problema. UTF-8 representa un carácter como é con dos bytes, y un carácter como € con tres bytes. Una codificación antigua de un solo byte lee cada byte como un carácter propio, de modo que una é se convierte en dos caracteres equivocados, é, y un € se convierte en tres, €. El archivo no cambió. El lector cambió el significado de los bytes. Por eso el problema también sigue un patrón según la región y según la máquina. Un colega con un sistema cuya codificación predeterminada coincide con la del archivo lo ve correctamente, mientras tú ves texto distorsionado, y el mismo archivo puede verse bien en un ordenador y mal en otro. Ningún ordenador está averiado, y el archivo no está dañado. Los dos lectores simplemente no están de acuerdo sobre lo que significan los bytes, y Excel, al hacer doble clic, confía en su propio valor predeterminado sin preguntar.

Esto también explica por qué el problema aparece tan a menudo con archivos convertidos desde JSON. JSON es UTF-8 por definición, así que una conversión de JSON a CSV produce de forma natural un CSV en UTF-8, con cada nombre con tilde, cada ciudad y cada símbolo de moneda de los datos de origen. La conversión es correcta. La apertura no coincide. El conversor de esta página, por ejemplo, descarga UTF-8 simple sin marca de orden de bytes, que es la opción correcta para subidas web, bases de datos, Hojas de cálculo de Google y Python, pero eso significa que un doble clic en Excel de Windows puede adivinar la codificación equivocada. Saber que el desajuste está en el paso de apertura, no en el paso de conversión, te dice dónde corregirlo: en la importación, o con un BOM, como muestran las secciones siguientes.

Lee el texto distorsionado: qué te dicen los caracteres extraños

El texto distorsionado no es aleatorio, y aprender a leerlo te dice cuál era el carácter original y confirma el diagnóstico antes de tocar nada. El patrón característico es à seguida de otro carácter. Siempre que veas é, ä, ü o ç, estás viendo un carácter UTF-8 que se leyó como Windows-1252. La à es el primer byte de la secuencia UTF-8, leído erróneamente como un carácter propio, y el segundo carácter es el segundo byte, también leído mal. Una vez que conoces el patrón, puedes decodificar el texto distorsionado mentalmente: é era é, ü era ü, ç era ç, ão era ão, como en São Paulo, que aparece como São Paulo. El signo del euro es el caso más llamativo: € tiene tres bytes en UTF-8, así que aparece como los tres caracteres €. Un guion largo aparece como â€, y un apóstrofo curvo aparece como ’.

El patrón cambia según la escritura, y ese cambio también es diagnóstico. Los nombres en escritura latina producen el patrón à de arriba. El japonés, el coreano y otras escrituras no latinas producen texto distorsionado más largo, porque cada carácter tiene tres bytes en UTF-8, así que un carácter se convierte en tres caracteres equivocados: Tokio, escrito como 東京, aparece como una serie de caracteres como æ±äº¬, y un nombre coreano se convierte en una serie parecida. Si ves ese tipo de texto distorsionado largo, el diagnóstico es el mismo, UTF-8 leído como una codificación de un solo byte, solo que los caracteres implicados son de tres bytes. Si en cambio ves signos de interrogación o símbolos de diamante negro donde deberían ir caracteres, el diagnóstico es distinto: esos símbolos significan que la información ya se perdió durante un guardado, no que solo se leyó mal en pantalla, y la sección de rescate explica qué hacer en ese caso.

El bloque de código siguiente muestra las lecturas incorrectas exactas, producidas al tomar texto UTF-8 correcto y decodificarlo como Windows-1252, de la misma forma que lo hace Excel al hacer doble clic. No son ejemplos inventados. Cada pareja se generó de forma mecánica, así que puedes comparar tu propio archivo con ellas y confirmar el diagnóstico antes de corregir nada. Si tu archivo muestra el lado izquierdo de una de estas parejas donde debería mostrar el lado derecho, tienes un problema de codificación, y la solución de importación de la sección siguiente reparará la visualización sin cambiar el archivo.

Correct text  ->  What Excel shows\nJosé García  ->  José GarcÃ\u00ada\nMünchen      ->  München\nFrançois     ->  François\nSão Paulo    ->  São Paulo\n€50,000      ->  €50,000\ncafé — ok    ->  café — ok\n東京 (Tokyo)  ->  æ\u00b1京\n김민준        ->  김민준

Fíjate en lo que demuestra la tabla: no falta nada. Cada carácter equivocado corresponde a un byte real del original, solo que decodificado con la tabla equivocada. Por eso la solución de importación funciona de forma tan completa. Cuando indicas a Excel que el archivo es UTF-8, decodifica los mismos bytes con la tabla correcta, y cada carácter vuelve a ser él mismo, sin ediciones, sin buscar y reemplazar y sin introducir datos. Si tu archivo coincide con este patrón, sáltate la sección de rescate y ve directamente a la solución de importación. No tienes un archivo dañado. Tienes un archivo mal leído.

Solución 1: importa el archivo y dile a Excel que es UTF-8

Esta es la solución que conviene probar primero, porque no cambia nada de tu sistema, nada del archivo, y funciona con cualquier CSV en UTF-8 sea cual sea su delimitador. En lugar de hacer doble clic en el archivo, abre primero Excel y luego importa el archivo mediante la importación guiada, donde eliges tú mismo la codificación. La vista previa del cuadro de diálogo de importación te muestra de inmediato si elegiste bien: los caracteres se muestran correctamente en la vista previa exactamente como aparecerán en la hoja. Si la vista previa sigue mostrando texto distorsionado, todavía no cambiaste nada, y puedes probar otro origen de archivo antes de cargar.

• ▸En Excel, ve a Datos, luego a Desde texto o CSV, y selecciona tu archivo.
• ▸En el cuadro de diálogo de vista previa, establece el origen del archivo en 65001: Unicode (UTF-8). En versiones antiguas de Excel, la misma opción aparece como Unicode (UTF-8) en el Asistente para importar texto.
• ▸Revisa la vista previa. Si los caracteres ya se leen correctamente, continúa. Si todavía se ven mal, es posible que el archivo no sea UTF-8 en absoluto, así que prueba los demás orígenes de la lista uno a uno y observa la vista previa.
• ▸Establece el delimitador en el carácter que usa el archivo, coma, punto y coma, tabulación o barra vertical, y comprueba que las columnas se dividan correctamente en la misma vista previa.
• ▸Haz clic en Cargar. Para las columnas que deben mantenerse como texto, como los códigos con ceros iniciales, establece esas columnas como Texto en el paso de importación, antes de cargar.

Convierte esta forma de abrir archivos CSV en tu forma habitual, no solo en tu medida de rescate. Hacer doble clic es adivinar tanto el delimitador como la codificación. Importar es elegir ambas cosas, y la elección tarda unos diez segundos más. La misma solución funciona en un Mac, donde la ruta de importación también es la fiable: abre un libro en blanco, ve a Datos, luego a Desde texto, elige el archivo, selecciona Unicode (UTF-8) como origen del archivo y termina. Hojas de cálculo de Google no necesita ninguna corrección en la mayoría de los casos, porque Archivo y luego Importar detecta UTF-8 automáticamente, y por eso un archivo que se ve roto en Excel a menudo se ve perfecto en Sheets. Esa diferencia es en sí misma un diagnóstico: si Sheets lo muestra bien y Excel lo muestra mal, el archivo está bien y Excel adivinó mal.

Solución 2: añade un BOM para que el doble clic funcione

Si abres el mismo tipo de archivo todos los días, importar cada vez se hace pesado, y la solución duradera es dar a Excel la pista que necesita al hacer doble clic. Esa pista es un BOM, una marca de orden de bytes: tres bytes invisibles al principio del archivo que dicen que este archivo es UTF-8. Excel comprueba si hay un BOM antes de adivinar, así que un archivo UTF-8 con BOM se abre correctamente al hacer doble clic incluso en un sistema Windows cuya codificación predeterminada es Windows-1252. El BOM es invisible en Excel y en la mayoría de los editores, y no cambia ninguna fila de datos. Solo afecta a los tres primeros bytes del archivo.

La forma más fácil de añadir uno no necesita código. Abre el archivo en el Bloc de notas, ve a Archivo y luego a Guardar como, y establece la lista desplegable de codificación en UTF-8 con BOM, luego guarda. El archivo ahora se abre correctamente al hacer doble clic en Excel. Si produces archivos desde un script, añade el BOM en el momento de escribir en lugar de corregir archivos después. En Python, eso es una sola palabra: abre el archivo con la codificación utf-8-sig en lugar de utf-8, y Python escribe el BOM por ti. El fragmento siguiente lo muestra, y los bytes que produce se verificaron: el archivo empieza con los tres bytes del BOM, seguidos de los datos en UTF-8 simple.

with open("customers.csv", "w", encoding="utf-8-sig", newline="") as f:\n    f.write("name,city\n")\n    f.write("José García,München\n")\n# First bytes of the file: EF BB BF, then the UTF-8 data.\n# Excel now opens it correctly on double-click.

Dos advertencias antes de añadir un BOM en todas partes. Primero, algunas herramientas tratan un BOM como datos, no como marcador. Un analizador estricto de CSV puede leer el primer encabezado como BOM más nombre en lugar de nombre, lo que rompe una búsqueda por encabezado. El conversor de esta página descarga deliberadamente sin BOM exactamente por este motivo: el UTF-8 simple es correcto para subidas web, bases de datos y Python, y el BOM es solo una comodidad para el doble clic en Excel. Así que añade un BOM a las copias destinadas a Excel, no al archivo principal que alimenta otras herramientas. Segundo, un BOM no repara un archivo que no es UTF-8. Si el archivo se escribió en Windows-1252, añadir un BOM encima empeora las cosas, porque Excel decodificará entonces datos de un solo byte como UTF-8 y producirá texto distorsionado nuevo. Añade un BOM solo a un archivo que sepas que es UTF-8, lo que puedes confirmar con la prueba del editor de texto de la sección de diagnóstico.

Rescata un archivo que ya se ve distorsionado

Hasta ahora, cada solución asumió que el archivo en disco sigue siendo correcto y que solo la visualización está mal. Pero a veces la versión distorsionada ya se guardó, y la pregunta pasa a ser si los caracteres originales todavía se pueden recuperar de la copia guardada. La respuesta depende de qué hizo exactamente el guardado, y hay dos casos que conviene distinguir. En el primer caso, el archivo en disco todavía contiene los bytes UTF-8 originales, y solo la visualización en Excel está mal. Ese es el caso que detecta la prueba del editor de texto: el editor muestra los caracteres correctamente, así que no se perdió nada, y la Solución 1 repara la visualización. En el segundo caso, el archivo en disco ahora contiene los propios caracteres equivocados, porque alguien lo abrió en Excel, vio el texto distorsionado y lo volvió a guardar en CSV, escribiendo los caracteres mal leídos en el archivo.

El segundo caso a menudo todavía se puede recuperar, y la prueba es si el texto distorsionado sigue el patrón à de la sección del decodificador. Si el archivo guardado contiene literalmente los caracteres é donde debería ir é, la recuperación es una recodificación: lee el archivo como si fuera Windows-1252, lo que recupera los bytes UTF-8 originales, y luego decodifica esos bytes como UTF-8, lo que recupera los caracteres originales. El fragmento siguiente hace exactamente eso, y se verificó con un archivo real: un nombre escrito como José, leído mal como José, volvió a ser José después del recorrido completo, byte a byte. Trabaja sobre una copia, nunca sobre la única versión, y comprueba el resultado en un editor de texto antes de volver a abrirlo en Excel.

with open("mangled.csv", "r", encoding="cp1252") as f:\n    text = f.read()\n# Encode back to the bytes Excel misread, then decode as UTF-8.\nfixed = text.encode("cp1252").decode("utf-8")\nwith open("fixed.csv", "w", encoding="utf-8") as f:\n    f.write(fixed)\n# Verified: José -> José, München -> München.

El truco de recodificación tiene un límite estricto, y es importante respetarlo. Funciona solo cuando los caracteres mal leídos sobrevivieron intactos al guardado, como é y sus compañeros. Si el guardado sustituyó caracteres por signos de interrogación, o por el símbolo de diamante negro de sustitución, la información original desapareció de esa copia. Ninguna decodificación puede recuperar un carácter que fue sustituido por un marcador, porque el marcador no contiene información sobre qué carácter sustituyó. En ese caso, deja de reparar la copia y regenera el archivo desde su origen: vuelve a exportarlo desde la base de datos, la herramienta o el JSON del que provino, y esta vez ábrelo con la Solución 1 o dale un BOM con la Solución 2. Y hagas lo que hagas, conserva la copia dañada aparte hasta que el archivo regenerado se compruebe. Eliminar la única copia antes de verificar el sustituto es la forma en que un problema recuperable se convierte en un conjunto de datos perdido.

Qué significa esto para los archivos del conversor de esta página

El conversor de esta página produce exactamente el tipo de archivo del que trata esta guía, así que vale la pena indicar su comportamiento con claridad. La descarga es UTF-8 simple sin BOM. Eso se verificó con el código real, no se supuso: la descarga crea un Blob de tipo text/csv con charset=utf-8 y no escribe ninguna marca inicial, y el motor de conversión se ejecutó con una muestra que contenía José García, München, François, Łódź, São Paulo, una cantidad en euros, Tokio en japonés y nombres coreanos, y produjo cada carácter de forma idéntica a nivel de byte, sin BOM al inicio de la salida. Así que si tu archivo convertido muestra caracteres extraños en Excel, la conversión no dañó nada. El archivo es UTF-8 correcto, y Excel adivinó la codificación equivocada al hacer doble clic.

Eso te da dos opciones limpias para los archivos convertidos. La primera es la ruta de importación: abre el archivo descargado con Datos, luego Desde texto o CSV, establece el origen del archivo en 65001: Unicode (UTF-8) y carga. Los caracteres se leerán correctamente, y no cambiaste nada del archivo, así que sigue siendo válido para cualquier otra herramienta. La segunda es la ruta del BOM: abre el archivo descargado en el Bloc de notas, guárdalo como UTF-8 con BOM y conserva esa copia para Excel, mientras conservas la descarga original para cualquier otra cosa. No vuelvas a convertir los datos para corregir un problema de visualización de codificación, y no pegues la salida convertida en una hoja de cálculo para guardarla de nuevo, porque ese recorrido puede introducir exactamente los desajustes de delimitador y codificación que esta guía existe para evitar. Corrige la apertura, no los datos.

Un detalle más del conversor importa aquí. El conversor te permite elegir el delimitador antes de descargar, y esa elección es independiente de la codificación. Un archivo puede tener el delimitador correcto y una visualización de codificación incorrecta al mismo tiempo, o la codificación correcta y el delimitador incorrecto, o ambas cosas mal a la vez. Si tu archivo convertido se abre en una sola columna y los caracteres se ven mal, corrige ambos ajustes en la misma importación: elige el delimitador que elegiste en el momento de la conversión, y establece el origen del archivo en 65001. La guía complementaria sobre el problema de una sola columna trata la mitad del delimitador en detalle, y está enlazada en las guías relacionadas más abajo.

Lista de prevención: expórtalo bien para que nadie tenga que corregirlo

Los problemas de codificación son un desajuste entre quien escribe y quien lee, así que la prevención consiste en hacer que quien escribe declare lo que escribió, de una forma que el lector respete. Repasa esta lista cuando produzcas un CSV, y la próxima persona que lo abra no necesitará esta guía. Primero, conoce tu codificación en el momento de exportar. Si tus datos contienen algo más allá del ASCII simple, exporta en UTF-8, y dilo en el nombre del archivo o en la nota que lo acompaña, porque un archivo CSV no puede decirlo por sí mismo. Segundo, si el público usa Excel en Windows, añade un BOM a la copia para Excel, o exporta con el formato CSV UTF-8 de Guardar como en Excel, que escribe un BOM por ti. Tercero, si el archivo también alimenta otras herramientas, conserva una copia en UTF-8 simple sin BOM para ellas, porque algunos analizadores tratan un BOM como parte del primer encabezado.

Cuarto, nunca guardes un archivo rescatado encima del original hasta haber verificado el rescate en un editor de texto. Un guardado desde Excel reescribe tanto el delimitador como la codificación con los valores predeterminados propios de Excel, lo que puede reintroducir el desajuste para el siguiente lector, o convertir un problema de visualización en una pérdida real de datos. Quinto, cuando recibas un archivo, ábrelo primero en un editor de texto si algo parece raro, y confirma la codificación antes de dejar que ninguna hoja de cálculo lo guarde encima. Y sexto, conserva los datos de origen. Un CSV es una instantánea aplanada, no los datos en sí, así que si un rescate sale mal, los datos de origen te permiten exportar de nuevo limpiamente en lugar de reparar una copia dañada. La mayoría de las historias de terror sobre codificación terminan cuando alguien descubre demasiado tarde que el CSV dañado era la única copia. No dejes que ese sea tu archivo.

Guías relacionadas

• El archivo CSV se abre en una sola columna en Excel: por qué pasa y cómo corregirlo (Guía 2026) →
• ¿Cómo puedo convertir un archivo JSON a CSV en línea? (Guía 2026) →
• ¿Cuáles son las formas de convertir JSON a CSV localmente? 6 métodos comparados (Guía 2026) →
• Por qué Excel elimina los ceros a la izquierda de tus códigos CSV y cómo conservarlos (Guía 2026) →
• Por qué Excel cambia las fechas de tu CSV e intercambia el día y el mes, y cómo evitarlo (Guía 2026) →
• Por qué guardar tu CSV en Excel lo cambia y cómo mantener el original a salvo (Guía 2026) →
• Por qué tu CSV es demasiado grande para Excel y qué hacer en su lugar (Guía 2026) →

Preguntas frecuentes