Detectar y corregir errores de codificación (UTF-8 vs ANSI) en Windows

Si trabajas con archivos de texto, CSV o XML en Windows es bastante fácil toparse con caracteres raros, acentos rotos o mensajes del tipo “secuencia de bytes no válida en UTF-8”. Estos problemas suelen deberse a una codificación inapropiada para el uso que le vamos a dar, o a una conversión que se ha realizado a medias.

En esta guía te explico, paso a paso, cómo detectar y corregir errores de codificación entre UTF-8 y ANSI en Windows, qué herramientas usar (Notepad, Excel, Google Drive, utilidades de consola) y cómo evitar que vuelvan a aparecer. Además, verás opciones avanzadas del propio Windows para trabajar en UTF-8 en procesos y APIs Win32, así como recomendaciones concretas para flujos de importación de datos como los de Merchant Center.

¿Por qué fallan las codificaciones en Windows?

La causa más frecuente es que el archivo no está realmente en el formato que la aplicación espera, aunque el editor indique otra cosa o lo “autodetecte” de manera optimista; por ejemplo, un CSV en ISO-8859-1/Latin-1 o ANSI que una plataforma de importación da por UTF-8 y termina lanzando el error de bytes inválidos.

Otra situación común es el lío con el preámbulo BOM en UTF-8. Aunque no es obligatorio en UTF-8, muchos editores en Windows lo añaden para identificar inequívocamente la codificación. Sin BOM, algunos programas asumen ANSI o interpretan el contenido con heurísticas que no siempre aciertan, generando esos caracteres “raros”.

Por último, a partir de ciertas versiones de Windows 10 (1903 en adelante), existen mecanismos para forzar que un proceso use UTF-8 como página de códigos. Si no se usan y nos movemos entre APIs -A y -W, o entre herramientas antiguas y modernas, se puede crear una mezcla desafortunada de ANSI, UTF-8 y UTF-16.

Errores típicos: “secuencia de bytes no válida en UTF-8”

Este mensaje aparece al importar datos cuando el archivo que subimos no es UTF-8 real, aunque lleve extensión .csv o .txt. La plataforma de destino espera secuencias válidas de UTF-8 y encuentra bytes que no encajan, de ahí el error.

Algunas suites generan CSV en ISO-8859-1/ANSI y al subirlos a un sistema que solo acepta UTF-8, fallan. También pasa si se guarda como “UTF-8” pero se introdujo doble codificación o un BOM mal gestionado, o si la herramienta añadió caracteres que rompen el flujo.

En entornos como Merchant Center, además, hay validaciones extra: acepta UTF‑8, UTF‑16, Latin‑1 y ASCII, pero si subes XML debes declarar encoding correcto en el prólogo o el feed no se procesa.

Cómo convertir a UTF-8 sin errores (pasos probados)

Si tienes una hoja de cálculo o CSV que no entra por codificación, estos procedimientos te dan un UTF-8 válido en casi cualquier escenario. Son métodos recomendados y ampliamente utilizados.

Opción 1: Google Drive + Hojas de cálculo

Este flujo es muy robusto y no requiere instalar nada adicional; conviertes el archivo a UTF-8 limpio en pocos pasos.

1. Abre Google Drive y crea una hoja nueva en Hojas de cálculo de Google. Importa tu CSV en esa hoja.
2. Revisa que los caracteres acentuados y eñes se vean bien; si es así, ve a Archivo > Descargar > Valores separados por comas (.csv).
3. El archivo descargado estará en UTF-8; podrás subirlo a tu sistema sin el error de bytes inválidos.

Si te encuentras con que al importar salen símbolos, lo normal es que el CSV original no describiera bien su separador o comillas. Vuelve a importarlo eligiendo adecuadamente el separador y el conjunto de caracteres que detecte Drive.

Opción 2: Microsoft Excel (guardar como CSV UTF-8)

Excel moderno permite guardar directamente en CSV UTF-8, lo cual suele ser suficiente para la mayoría de plataformas de importación.

1. Abre el CSV en Excel y elige Archivo > Guardar como.
2. Selecciona el tipo CSV UTF-8 (delimitado por comas) (*.csv) y guarda.

Después de guardar, es recomendable no reabrir y volver a guardar el archivo en Excel si solo querías comprobar los datos. Si abres para revisar, cierra sin guardar para evitar posibles cambios en la codificación y el separador.

Opción 3: Excel + Bloc de notas (cuando Excel no ofrece UTF-8)

En algunos entornos, Excel no muestra la opción de UTF-8 al exportar; en ese caso, una ruta segura es usar el formato Texto Unicode (.txt) y terminar la conversión en Bloc de notas.

1. Abre el .xlsx en Excel y guarda como Texto Unicode (.txt). Esto genera un archivo tabulado en UTF-16.
2. Abre ese .txt con el Bloc de notas; verás caracteres extraños para algunos símbolos porque Notepad no visualiza todo Unicode perfectamente, pero no te preocupes.
3. Reemplaza todas las tabulaciones por comas para convertirlo a CSV: copia un tabulador y usa Reemplazar por “,”.
4. Elige Archivo > Guardar como, pon la extensión .csv y selecciona UTF-8 como codificación.

Ahora tendrás un .csv en UTF-8 válido. Abre solo para verificar y, si detectas algo raro, corrige en la hoja original y repite el proceso sin volver a guardar en Excel el CSV final.

Guardar como ANSI en Windows: por qué a veces “no se queda”

Hay casos en los que abres un .txt en el Bloc de notas, seleccionas Guardar como > ANSI y, al reabrirlo, aparece como UTF‑8 de nuevo. ¿Qué está pasando? Puede deberse a que el contenido tenga caracteres no representables en ANSI, a que el editor aplique heurísticas, o a que el archivo ya tuviera un BOM que confunda la detección.

Con Notepad++ conviene distinguir “Codificar en” de “Convertir a”. La opción adecuada para cambiar la codificación real del archivo es Convertir a ANSI o Convertir a UTF-8 (con o sin BOM), y luego guardar. Usar solo “Codificar en” cambia cómo se interpreta, no necesariamente cómo se guarda.

En Windows, muchos editores añaden BOM en UTF-8, lo que ayuda a programar y a intercambiar ficheros de forma inequívoca. Sin embargo, en entornos Mac y Linux no siempre se añade; sin BOM, detectar si es UTF‑8 o ANSI se basa en heurísticas compatibles en la mayoría de casos, pero pueden fallar en archivos “limítrofes”.

Merchant Center: codificaciones admitidas y buenas prácticas

Merchant Center soporta UTF‑8, UTF‑16, Latin‑1 y ASCII. Si no estás seguro de la codificación de tu feed, utiliza la opción de detección automática. Para archivos guardados con el Bloc de notas, asegúrate de elegir ANSI o UTF‑8 en “Codificación”.

Si subes XML en Latin‑1 o UTF‑16, debes declararlo explícitamente en el prólogo del documento. Sustituye la cabecera por la adecuada, por ejemplo: ISO‑8859‑1 o UTF‑16 en el atributo encoding.

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml version="1.0" encoding="UTF-16"?>

Para corregir el catálogo desde el propio Merchant Center, ve a Productos > Requiere atención, filtra por el problema, edita los artículos afectados y confirma que los atributos básicos se ajustan a UTF‑8.

Si son muchos productos, descarga el listado .csv desde el icono de descarga, compara con tu fuente original y vuelve a subir los datos corregidos. Este proceso asegura que el feed final esté en UTF‑8 coherente con lo que la plataforma valida.

Forzar UTF-8 como página de códigos del proceso en Windows

Desde Windows 10 versión 1903 puedes indicar que tu proceso use UTF-8 como página de códigos por defecto, evitando conversiones ambiguas y facilitando la compatibilidad en entornos modernos.

Para una app empaquetada, declara la propiedad en el appxmanifest; para una aplicación Win32 sin empaquetar, usa un manifiesto de fusión. En ambos casos, defines la página activa como UTF‑8.

Ejemplo appx manifest (aplicación empaquetada):

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" ...
         xmlns:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
         xmlns:uap8="http://schemas.microsoft.com/appx/manifest/uap/windows10/8"
         IgnorableNamespaces="... uap7 uap8 ...">
  <Applications>
    <Application ...>
      <uap7:Properties>
        <uap8:activeCodePage>UTF-8</uap8:activeCodePage>
      </uap7:Properties>
    </Application>
  </Applications>
</Package>

Ejemplo manifiesto de fusión (Win32 sin empaquetar):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity type="win32" name="..." version="6.0.0.0"/>
  <application>
    <windowsSettings>
      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
    </windowsSettings>
  </application>
</assembly>

Si apuntas a versiones anteriores de Windows, la declaración puede existir, pero tendrás que gestionar detección y conversión como siempre. Con 1903 o superior como target mínimo, el proceso irá en UTF‑8 y te ahorras muchos dolores de cabeza.

APIs Win32: variantes -A frente a -W y conversiones

Muchas APIs Win32 vienen en versiones -A y -W. Las primeras trabajan con char* siguiendo la página de códigos ANSI del sistema, y las segundas usan UTF‑16 (WCHAR). Tradicionalmente, Windows resaltó las -W, pero las builds modernas han mejorado la compatibilidad de -A con UTF‑8 cuando la ACP es UTF‑8.

Para interoperar, a menudo debes convertir entre UTF‑8 y UTF‑16. Las funciones MultiByteToWideChar y WideCharToMultiByte son las herramientas estándar para ello, y con CP_UTF8 funcionan muy bien si se invocan con las banderas correctas.

Cuando llames con CodePage = CP_UTF8, usa dwFlags = 0 o MB_ERR_INVALID_CHARS. Si no, puedes encontrarte con ERROR_INVALID_FLAGS. Esto te garantiza que los caracteres inválidos se detectan en la conversión y no se silencian.

Detectar UTF‑8, ANSI y el papel del BOM

En los formatos de texto, muchos codificadores añaden un BOM (Byte Order Mark) al inicio. En UTF‑8 son tres bytes que permiten reconocer la codificación de forma inequívoca. No es obligatorio, pero es práctico a la hora de intercambiar archivos entre equipos y herramientas diversas.

¿Qué pasa si no hay BOM? Los editores recurren a heurísticas: inspeccionan patrones de bytes posibles en UTF‑8 y, si encajan, asumen esa codificación. Esto funciona casi siempre, pero hay casos borde; por ejemplo, un archivo con acentos y eñes puramente ANSI puede engañar a algunos detectores y causar identificación errónea.

En la práctica, si vas a compartir archivos entre entornos heterogéneos, es buena idea incluir el BOM en UTF‑8, o al menos acordar una convención clara en tu equipo para que todo el mundo guarde de la misma forma.

Conversión masiva con FileEncodingConverter

Si necesitas convertir montones de archivos en una estructura de carpetas, una opción muy útil es una utilidad de consola como FileEncodingConverter. Permite indicar carpeta base, codificación de destino y filtros por extensión para procesar en lote.

Esta herramienta admite ANSI, ASCII, Unicode, UnicodeBI, UTF32, UTF7, UTF8 y UTF8BOM. Si omites la codificación, utiliza la ANSI del sistema como valor por defecto; por tanto, conviene indicar la salida explícitamente si tu objetivo es UTF‑8.

Además, permite dos modificadores muy prácticos: /f para forzar que recodifique aunque “ya esté” en ese formato (útil para añadir BOM a UTF‑8) y /b para modo batch (no detenerse al final, ideal para scripts .bat).

Ejemplo de uso para convertir a Unicode Big Endian (UnicodeBI) solo HTML y TXT, o para consolidar a UTF‑8 con BOM en XML, TXT y HTM que contengan “ES” en el nombre:

FileEncodingConverter C:\MiCarpeta UnicodeBI
FileEncodingConverter C:\MisArchivosDeDatos UTF8 *ES*.xml,*.txt,*.htm* /f
FileEncodingConverter C:\MisArchivosDeDatos UTF8BOM *ES*.xml,*.txt,*.htm* /f

Un detalle interesante: puede detectar UTF‑8 sin BOM mediante heurística; aun así, en archivos límite puede no acertar al 100%. Para esos casos, el modificador /f y convertir a UTF8BOM te asegura un identificador inequívoco.

Qué hacer cuando Notepad++ “identifica mal”

Notepad++ y otros editores poseen detectores de codificación que, ante ciertos archivos con acentos y eñes (puramente ANSI), pueden clasificarlos como otro idioma o fallar al abrirlos. En ocasiones Notepad++ llega a marcarlos como hebreo o muestra caracteres corruptos.

Como referencia, el antiguo Bloc de notas de Windows tendía a asumir ANSI por defecto, y Visual Studio suele identificarlos correctamente. Pero la lección es clara: si el archivo no incluye BOM y contiene caracteres “sensibles”, la detección puede no ser fiable.

Recomendación práctica: usa “Convertir a UTF‑8” y guarda. Si vas a intercambiar esos archivos con terceros, considera “UTF‑8 con BOM” para que no haya dudas en el destinatario.

Checklist rápido para importar CSV y XML sin sorpresas

Antes de subir un archivo a una plataforma que exige UTF‑8, recorre esta lista y evitarás el clásico “no se puede procesar el feed”.

• Asegúrate de que el archivo está realmente en UTF‑8 (usa Drive, Excel UTF‑8 o Notepad con “Guardar como” UTF‑8).
• Si es XML, declara el encoding correcto en el prólogo (UTF‑8, UTF‑16, ISO‑8859‑1, etc.).
• No reabras y guardes el CSV final en Excel salvo que vayas a exportarlo otra vez como UTF‑8.
• Elimina caracteres raros antes de exportar (comillas curvas, símbolos invisibles, tabuladores no deseados).

Cuando el foro no ayuda: a dónde acudir

En hilos de comunidades oficiales puede que un moderador te remita al área de Windows Q&A para incidencias fuera del alcance del foro. No es mala idea publicar allí si tu problema es del sistema o del editor por defecto.

Por otra parte, al navegar por plataformas como Reddit verás banners de privacidad y cookies. No influyen en tu codificación, solo son avisos de tratamiento de datos y preferencias de seguimiento.

Desarrolladores: trabajar correctamente con UTF‑8 en Windows

Si desarrollas en Win32/.NET y necesitas interacción con APIs -A/-W, valora forzar UTF‑8 en el proceso mediante manifiesto (Windows 10 1903+) o trabaja siempre con las variantes -W (UTF‑16) convirtiendo con MultiByteToWideChar/WideCharToMultiByte.

Para conversiones con CP_UTF8, especifica dwFlags = 0 o MB_ERR_INVALID_CHARS a fin de detectar problemas de datos y evitar errores como ERROR_INVALID_FLAGS. Esto protege tu pipeline de texto frente a secuencias inválidas.

Casos límite y mejores prácticas con BOM

Hay archivos con solo acentos y eñes (sin otros símbolos) que pueden confundir a la heurística de detección y hasta hacer fallar una recodificación a UTF‑8. Son raros, pero existen; precisamente por eso, el uso consistente del BOM en UTF‑8 facilita que cualquier herramienta reconozca la codificación.

Si estás en un entorno controlado (todos tus sistemas saben que usas UTF‑8 sin BOM o ANSI), puedes prescindir del BOM. Pero en el intercambio con terceros, añadirlo es una forma simple de evitar ambigüedades y ahorrar soporte.

Solución a un caso real: “mi archivo siempre vuelve a UTF‑8”

Cuando intentas forzar ANSI en un .txt y al abrirlo “regresa” a UTF‑8, revisa estos puntos: el contenido puede tener caracteres fuera de ANSI, el editor puede estar añadiendo BOM o la detección automática te muestra otra cosa distinta a lo guardado.

Prueba a usar Notepad++ con “Convertir a ANSI” (no solo “Codificar en”). Si persiste, quizá debas reemplazar símbolos por equivalentes ANSI o cambiar el flujo para trabajar todo en UTF‑8, que es la codificación más utilizada en la web y en integraciones.

Si la plataforma de destino exige UTF‑8 (como muchos importadores), lo más eficiente es convertir todo el pipeline a UTF‑8 desde el origen (Excel/Drive) y olvidarte de ANSI salvo que una herramienta antigua lo imponga.

A grandes rasgos, la mejor estrategia hoy es que tus archivos estén en UTF‑8 y, cuando intercambies con terceros, considerar el uso de BOM para que la detección sea inequívoca. Si te topas con “secuencia de bytes no válida en UTF‑8”, recurre a Google Drive o a “CSV UTF‑8” de Excel, o usa el flujo Excel > Texto Unicode > Bloc de notas (guardar como UTF‑8). En desarrollos, fuerza UTF‑8 por manifiesto o usa conversiones claras entre UTF‑8 y UTF‑16 con las banderas adecuadas. Y si necesitas tratar muchos ficheros, una utilidad de consola como FileEncodingConverter te ahorra horas de trabajo.