Copias texto de una base de datos o documento y se ve así: "échéance" o "‘comillas tipográficas’". Eso es mojibake: texto que fue codificado en un conjunto de caracteres y decodificado en otro. Esta guía explica exactamente por qué sucede, cómo identificar qué discrepancia de codificación tienes delante y cómo corregirla en segundos con las herramientas adecuadas.
¿Qué es el mojibake?
Mojibake (文字化け) es un término japonés que significa "transformación de caracteres": describe el texto ilegible que aparece cuando una cadena se interpreta con la codificación de caracteres equivocada. En lugar de "résumé" ves "résumé". En lugar de un apóstrofo tipográfico ves "’". Los caracteres no están corruptos a nivel de bytes — los bytes están bien. El problema es que el software que los lee usa el manual equivocado para traducir bytes a caracteres.
El problema de la traducción de bytes a caracteres
Cada codificación de caracteres es un mapeo entre números (bytes) y caracteres. La letra "e" es el byte 0x65 en prácticamente todas las codificaciones. Pero una "é" acentuada se representa de forma distinta según la codificación: en UTF-8 es la secuencia de dos bytes 0xC3 0xA9, mientras que en Latin-1 es el byte único 0xE9. Cuando un programa lee los bytes UTF-8 0xC3 0xA9 con reglas Latin-1, produce dos caracteres separados — Ã y © — en lugar del único carácter é. Esa sustitución es el mojibake.
- é se convierte en é — bytes UTF-8 leídos como Latin-1 (el patrón más común)
- ü se convierte en ü — la misma discrepancia para la u con diéresis alemana
- ’ (apóstrofo derecho) se convierte en ’ — comilla tipográfica UTF-8 mal leída como Latin-1
- – (raya corta) se convierte en – — común en texto pegado desde Word o PDF
- Carácter de reemplazo Unicode — un carácter válido fue forzado a un contexto que no puede representarlo
Note
Por qué ocurren los errores de codificación
Los errores de codificación son un problema de fronteras del sistema. Ocurren cuando el texto cruza una frontera — entre un archivo y una aplicación, entre una base de datos y una API, entre un servidor web y un navegador — y el lado emisor y el receptor no coinciden sobre qué codificación usa el texto. En un mundo donde UTF-8 es el estándar universal, estos errores deberían ser raros. Pero son frecuentes porque los sistemas heredados, las herramientas de Windows y ciertas bases de datos aún usan codificaciones antiguas por defecto.
Las fuentes más comunes
- Archivos CSV de Excel — Excel guarda CSV como Windows-1252 en Windows por defecto, no UTF-8. Al abrirse en Linux o en Python, los caracteres acentuados se corrompen.
- Bases de datos MySQL con charset latin1 — las instalaciones antiguas de MySQL usan `latin1` por defecto para los juegos de caracteres de columna. Almacenar datos UTF-8 en ellas causa mojibake al leer.
- Cabeceras y cuerpos de correo — clientes de correo que no declaran un charset o que malinterpretan una declaración de charset producen mojibake en los campos De, Asunto y cuerpo.
- Extracción de texto de PDF — los archivos PDF incrustan fuentes con mapeos de glifos personalizados que no siempre corresponden a puntos de código Unicode estándar, produciendo salidas ilegibles al copiar.
- Respuestas HTTP sin charset en Content-Type — un servidor que envía `Content-Type: text/html` sin `; charset=utf-8` deja que el navegador adivine, y a menudo adivina mal.
UTF-8 vs Windows-1252 — la discrepancia más frecuente
Windows-1252 (también llamado CP1252) es un superconjunto de Latin-1 desarrollado por Microsoft para las lenguas de Europa occidental. Usa un solo byte por carácter y cubre 256 puntos de código — suficiente para inglés, francés, alemán, español y portugués. UTF-8 usa de uno a cuatro bytes por carácter y cubre los 1,1 millones de puntos de código Unicode. Cuando el texto UTF-8 se lee como Windows-1252, las secuencias multibyte producen los característicos patrones de mojibake de dos o tres caracteres. Al revés — texto Windows-1252 leído como UTF-8 — produce caracteres de reemplazo (□ o ?) porque los bytes altos individuales no son secuencias UTF-8 válidas.
Un texto sin metadatos de codificación no es texto — es una secuencia de bytes esperando ser malinterpretados.
Cómo detectar problemas de codificación
Detectar un problema de codificación suele ser sencillo: la apariencia visual del mojibake es lo bastante distintiva para identificar el patrón de discrepancia. Pero para la detección programática, o para texto que parece correcto pero contiene problemas invisibles, necesitas técnicas específicas.
Reconocimiento visual de patrones
El diagnóstico más fiable es el propio patrón de mojibake. El texto UTF-8 leído como Latin-1 produce un prefijo característico "Ã" seguido de un segundo carácter — por ejemplo, é por é, à por à, ü por ü. La puntuación tipográfica de Word o de los editores de texto enriquecido produce secuencias que empiezan por †— por ejemplo, ’ por ’ y “ por ". Si ves estas secuencias, la solución es recodificar los bytes de Latin-1 de vuelta a UTF-8.
Detección programática de codificación
Para archivos y flujos de datos donde no puedes ver el contenido visualmente, usa la biblioteca `chardet` (Python) o el paquete `jschardet` (Node.js) para autodetectar la codificación a partir de los patrones de bytes. Estas bibliotecas analizan la frecuencia y distribución de los valores de byte para identificar la codificación más probable. No son 100% precisas — las cadenas cortas y con pocos caracteres no ASCII son más difíciles de clasificar con confianza — pero manejan bien los casos comunes. Usa el Buscador de Caracteres Unicode para inspeccionar puntos de código individuales y sus representaciones de bytes esperadas al depurar caracteres concretos.
Tip
Cómo corregir mojibake en línea
La forma más rápida de corregir texto con mojibake es la Herramienta de Reparación Unicode y de Codificación. Funciona enteramente en tu navegador — sin subida al servidor, sin registro — y maneja automáticamente las discrepancias UTF-8/Latin-1 más comunes, el deterioro de comillas tipográficas y la eliminación de caracteres invisibles.
Identifica el patrón de discrepancia de codificación
Antes de corregir el mojibake, identifica qué discrepancia estás tratando. Mira los caracteres ilegibles: si ves secuencias é o ü, el texto es UTF-8 leído como Latin-1. Si ves secuencias ’ o “, el texto contiene comillas tipográficas o puntuación tipográfica que se corrompió de la misma manera. Si ves signos de interrogación o símbolos □, la codificación fue al revés — bytes no UTF-8 fueron forzados a un contexto UTF-8.
Pega el texto corrupto en la herramienta de reparación
Abre la Herramienta de Reparación Unicode y de Codificación y pega tu texto con mojibake en el campo de entrada. La herramienta analiza inmediatamente el texto e identifica la reparación más probable: recodificación de Latin-1 a UTF-8, arreglo de secuencias de comillas tipográficas, eliminación de caracteres de ancho cero, normalización de formas Unicode o eliminación de marcas de orden de bytes. La detección ocurre en tu navegador — tu texto no sale de tu dispositivo.
Selecciona el par de codificaciones y aplica la corrección
Si la detección automática es correcta, haz clic en Reparar para aplicar el arreglo. Si la selección automática no coincide con tu caso, elige manualmente la codificación de origen (con la que se leyó incorrectamente el texto) y la codificación de destino (con la que debería haberse leído). Para la mayoría del contenido web, el par es Latin-1 → UTF-8. Para archivos CSV de Windows, el par suele ser Windows-1252 → UTF-8.
Copia el texto reparado y verifícalo
Tras la reparación, copia el resultado y pégalo de nuevo en tu contexto original — un editor de documentos, una interfaz de base de datos o un archivo de código. Verifica que todos los caracteres acentuados, comillas y símbolos especiales se muestran correctamente antes de guardar o confirmar los cambios. Para la reparación masiva de datos en una base de datos, prueba el patrón en una muestra de filas antes de ejecutar el arreglo en toda la tabla.
Herramienta de Reparación Unicode y de Codificación
Corrige mojibake, repara artefactos de codificación, normaliza Unicode y elimina caracteres invisibles — gratis, en el navegador, sin subida de archivos.
Patrones de mojibake comunes y sus correcciones
Distintas discrepancias de codificación producen distintos patrones visuales. Reconocer el patrón te indica tanto la causa como la corrección correcta — qué par de codificaciones aplicar o qué operación de reparación ejecutar.
| Patrón de mojibake | Carácter original | Causa | Corrección |
|---|---|---|---|
| é | é (e aguda) | UTF-8 leído como Latin-1 | Recodificar Latin-1 → UTF-8 |
| ü | ü (u diéresis) | UTF-8 leído como Latin-1 | Recodificar Latin-1 → UTF-8 |
| À | À (a grave) | UTF-8 leído como Latin-1 | Recodificar Latin-1 → UTF-8 |
| ’ | ’ (apóstrofo derecho) | UTF-8 leído como Latin-1 | Recodificar Latin-1 → UTF-8 |
| “ | “ (comilla doble izquierda) | UTF-8 leído como Latin-1 | Recodificar Latin-1 → UTF-8 |
| – | – (raya corta) | UTF-8 leído como Latin-1 | Recodificar Latin-1 → UTF-8 |
| ’ | ’ (apóstrofo derecho) | UTF-8 leído como Windows-1252 | Recodificar Windows-1252 → UTF-8 |
| ? o □ | Cualquier carácter no ASCII | No UTF-8 en contexto UTF-8 | Hallar la codificación original con chardet |
El problema de la doble codificación
Una variante especialmente dañina es el doble mojibake — cuando el texto ha sido mal codificado dos veces. Produce secuencias como © en lugar de ©, o Æ¢ en lugar de ¢. Sucede cuando el texto ya con mojibake se guarda y luego se lee con la codificación equivocada una segunda vez. El proceso de reparación requiere dos rondas de recodificación en orden inverso. La Herramienta de Reparación Unicode y de Codificación detecta y maneja automáticamente los patrones de doble codificación más comunes.
Warning
Prevenir errores de codificación
La solución a largo plazo del mojibake es imponer UTF-8 en cada frontera de tu sistema — almacenamiento de archivos, base de datos, API y capa web. Estos son los lugares específicos donde las declaraciones de codificación deben ser explícitas.
Bases de datos — declara UTF-8 en todas partes
En MySQL y MariaDB, establece el juego de caracteres por defecto en `utf8mb4` (no `utf8` — el `utf8` de MySQL solo cubre secuencias de 3 bytes y excluye emojis y caracteres Unicode raros). Establécelo en tres niveles: el valor por defecto del servidor en `my.cnf`, el charset de la base de datos y los charsets de las columnas individuales. En PostgreSQL, el valor por defecto ya es UTF-8 en las nuevas instalaciones. En SQLite, el texto siempre es UTF-8 por defecto.
-- MySQL: set all levels to utf8mb4
ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;Archivos — guarda siempre como UTF-8
Al guardar archivos de texto, exportaciones CSV o archivos de configuración, elige siempre UTF-8 como codificación. En VS Code, la codificación se muestra en la barra de estado — haz clic para cambiarla. En Excel, exporta CSV usando "CSV UTF-8 (Delimitado por comas)" en lugar del predeterminado "CSV (Delimitado por comas)". Para scripts de Python que escriben archivos, pasa siempre `encoding='utf-8'` a la llamada `open()` explícitamente en lugar de confiar en el valor por defecto del sistema. Limpia el texto tras pegar desde fuentes externas con el Limpiador de Texto de Correo, que elimina caracteres invisibles y normaliza los espacios automáticamente.
APIs y HTTP — declara el charset en Content-Type
Cada respuesta HTTP que contenga texto debe incluir una declaración de charset: `Content-Type: application/json; charset=utf-8` o `Content-Type: text/html; charset=utf-8`. Sin ella, el cliente adivina — y los clientes HTTP antiguos usan Latin-1 por defecto para las respuestas `text/html`. Para páginas HTML, añade además `<meta charset="UTF-8">` como primer elemento dentro de `<head>`. Para APIs JSON, `Content-Type: application/json` implica UTF-8 según la RFC, pero ser explícito elimina la ambigüedad y previene problemas con clientes no conformes.
Lista de verificación de codificación por contexto
- Archivos Python: añade la cabecera `# -*- coding: utf-8 -*-` para Python 2; en Python 3 es innecesaria pero inofensiva
- Cadenas de conexión MySQL: incluye `charset=utf8mb4` en el DSN — p. ej. `mysql+pymysql://user:pass@host/db?charset=utf8mb4`
- Lecturas de archivos en Node.js: pasa `encoding: "utf8"` a `fs.readFile()` o usa `Buffer.from(data).toString("utf8")`
- Documentos XML y HTML: incluye siempre `<?xml version="1.0" encoding="UTF-8"?>` y `<meta charset="UTF-8">`
- Bibliotecas de envío de correo: establece `Content-Type: text/plain; charset=utf-8` y `Content-Transfer-Encoding: 8bit` o `quoted-printable`
Normalización Unicode y caracteres invisibles
Más allá de la clásica discrepancia UTF-8/Latin-1, otros dos problemas de Unicode producen fallos sutiles más difíciles de detectar: discrepancias de normalización y caracteres invisibles. Ambos pueden hacer que las comparaciones de cadenas fallen, que las búsquedas en bases de datos no encuentren y que los resultados de búsqueda estén incompletos — incluso cuando el texto se ve idéntico en pantalla.
Formas de normalización Unicode
Unicode permite representar el mismo carácter visible de varias maneras. La letra "é" puede codificarse como un único punto de código precompuesto (U+00E9) o como la combinación de "e" (U+0065) seguida de un acento agudo combinante (U+0301). Ambas se ven idénticas en pantalla pero son secuencias de bytes diferentes que fallan en las comparaciones de igualdad de cadenas. Por eso buscar "résumé" en una base de datos a veces no encuentra resultados — el texto almacenado usa otra forma de normalización. NFC (Descomposición Canónica seguida de Composición Canónica) es la forma normal recomendada para la mayoría de las aplicaciones. La Herramienta de Reparación Unicode y de Codificación normaliza el texto a NFC como parte de su proceso de reparación.
Caracteres invisibles y de ancho cero
Los caracteres de ancho cero son puntos de código Unicode que ocupan espacio en una cadena pero se renderizan como nada visible. Los insertan con frecuencia los procesadores de texto, las aplicaciones de chat y las operaciones de copiar y pegar desde PDF o páginas web. Los culpables habituales son el espacio de ancho cero (U+200B), el espacio de ancho cero sin salto (U+FEFF, que también es la marca de orden de bytes) y varios caracteres de control de texto bidireccional (U+200E, U+200F, U+202A-U+202E). Estos caracteres rompen patrones regex, confunden a los tokenizadores y hacen que cadenas de apariencia idéntica se comparen como desiguales. Usa el Buscador de Caracteres Unicode para identificar puntos de código sospechosos en una cadena.
Note
Buscador de Caracteres Unicode
Busca cualquier carácter Unicode por punto de código o nombre, o pega un carácter para identificar puntos de código invisibles o sospechosos en tu texto.
Key takeaways
- El mojibake se produce al leer bytes de texto con la codificación equivocada — lo más común son bytes UTF-8 leídos como Latin-1 o Windows-1252.
- El patrón é (por é) es la firma diagnóstica del mojibake UTF-8-como-Latin-1 — reconocer el patrón te dice la corrección exacta necesaria.
- La Herramienta de Reparación Unicode y de Codificación detecta y corrige automáticamente patrones comunes de mojibake, caracteres invisibles y problemas de normalización Unicode en tu navegador.
- Nunca corrijas el mojibake con buscar-y-reemplazar sobre secuencias ilegibles — repara siempre a nivel de codificación recodificando los bytes correctamente.
- Prevén los errores de codificación declarando UTF-8 explícitamente en cada frontera del sistema: archivos, bases de datos, respuestas de API y cabeceras HTTP.
- Los caracteres invisibles (espacio de ancho cero, BOM, controles bidireccionales) causan fallos de comparación y de búsqueda incluso cuando el texto parece correcto — deben eliminarse programáticamente.
- Las discrepancias de forma de normalización Unicode (NFC vs NFD) hacen que cadenas de apariencia idéntica fallen en las comparaciones de igualdad — normaliza a NFC antes de almacenar o comparar texto.