Conversor de codificación y reparador de mojibake

Respuestas rápidas

¿Qué es el mojibake?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

Qué hace esta herramienta

Ejemplos resueltos

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(solo parcial)

Cómo usar esta herramienta

1. 1

   Pega el texto ilegible

   Mételo tal cual: no hace falta identificar antes la codificación. Basta con un fragmento corto; una docena de caracteres suele bastar para fijar la cadena.

2. 2

   Lee el primer candidato y su insignia

   Exacto significa que la cadena reproduce tu entrada exactamente al recorrerla de vuelta. Parcial significa que no lo hace, así que toma el resultado como una pista.

3. 3

   Comprueba la cadena de codificación

   Cada candidato indica en qué codificación se escribió realmente el texto y cuál lo leyó mal. Eso te dice qué arreglar aguas arriba, no solo qué decía el texto.

4. 4

   Inspecciona los bytes si lo necesitas

   La segunda sección muestra cualquier texto como bytes en todas las codificaciones habituales y decodifica hexadecimal en crudo en sentido inverso. Úsala para dimensionar columnas o revisar tramas de protocolo.

Errores que lo empeoran

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Confirma primero la codificación actual
file -I correct.txt   # charset=utf-8 → nada que convertir

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Pasa por un tipo binario para que los bytes se preserven, no se reinterpreten
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Tomar el primer candidato diga lo que diga la insignia
db.update(row.id, candidates[0].text);

// Escribe de vuelta solo lo que supera la ida y vuelta
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Decodifica una sola vez en la frontera, con la codificación que usa realmente el archivo
with open(path, encoding='gbk') as f:
    text = f.read()

Cuándo la necesitas

Una migración de base de datos produjo basura

Las tablas MySQL heredadas declaradas como latin1 que en realidad guardan bytes UTF-8 son, con diferencia, el origen más frecuente. Pega aquí una fila ilegible para confirmar la cadena real antes de escribir el ALTER TABLE: hacer la conversión en la dirección equivocada convierte un problema recuperable en uno permanente.

Un CSV abierto en Excel muestra disparates

Excel en Windows sigue asumiendo la página de códigos del sistema para los CSV sin BOM, así que las exportaciones en UTF-8 salen como mojibake. Confirma aquí la cadena y vuelve a exportar con BOM, o impórtalo con el asistente de texto indicando la codificación de forma explícita.

Archivos de log de un servicio heredado

Las aplicaciones escritas contra GBK o Shift_JIS generan logs en esas codificaciones, y los agregadores de logs modernos lo leen todo como UTF-8. Pega una línea para recuperarla; y como nada se sube, puedes hacerlo con logs de producción.

Nombres de archivo rotos por un ZIP

El formato ZIP no tiene campo de codificación, así que los archivos creados en un Windows chino o japonés llevan nombres en GBK o Shift_JIS que las herramientas Unix leen como UTF-8. Recupera aquí los nombres reales antes de renombrar nada.

Dimensionar una columna de base de datos

La vista de bytes muestra el mismo texto en todas las codificaciones a la vez. Un carácter chino ocupa 3 bytes en UTF-8 pero 2 en GBK, que es exactamente el tipo de diferencia que convierte un VARCHAR(50) en un error de truncamiento.

Cómo se produce el mojibake

Los bytes sobreviven, el significado no

Codificar asigna bytes a los caracteres; decodificar devuelve los bytes a caracteres. El mojibake es una decodificación con el mapa equivocado. Los bytes nunca se dañaron, y por eso ejecutar al revés la decodificación equivocada recupera el original de forma exacta, siempre que esa decodificación equivocada no descartara nada.

Por qué el texto CJK es el más castigado

El ASCII ocupa 0x00–0x7F y todas las codificaciones habituales coinciden en él, así que el texto en inglés pasa indemne. El chino, el japonés y el coreano necesitan secuencias multibyte, y las codificaciones discrepan sobre cómo agruparlas. UTF-8 usa tres bytes por carácter chino; GBK usa dos. Dale bytes UTF-8 a un decodificador GBK y la agrupación se desplaza, produciendo un número distinto de caracteres distintos.

La prueba de ida y vuelta

Para cada cadena candidata, la herramienta vuelve a codificar el texto recuperado con la primera codificación y lo vuelve a decodificar con la segunda. Si eso reproduce la entrada exactamente, la cadena explica cada carácter y el candidato se marca como Exacto. Los candidatos que no superan la prueba se muestran igualmente, porque una recuperación parcial a menudo identifica el texto aunque no pueda reproducirlo.

De dónde salen las tablas de codificación

Las tablas las aporta el TextDecoder del navegador. Codificar en el sentido contrario es más delicado, porque TextEncoder solo admite UTF-8: por eso la herramienta construye un mapa inverso recorriendo el espacio de bytes y preguntando al decodificador qué significa cada secuencia. Así la correspondencia es siempre coherente con el comportamiento del propio navegador, y no se envía ninguna tabla de consulta a tu dispositivo.

La heurística de ordenación y sus límites

Más allá de la prueba de ida y vuelta, los candidatos se puntúan según cuánto del texto son caracteres chinos frecuentes (aquellos cuyo byte inicial en GBK cae en 0xB0–0xF7), restando penalizaciones por caracteres de reemplazo, katakana de ancho medio y caracteres de control. El katakana de ancho medio es una señal fuerte de Shift_JIS porque el japonés normal casi nunca lo usa. Esto es una heurística: desempata, no establece la verdad.

Cómo evitar que vuelva a pasar

Arregla el origen, no solo la cadena de texto

La cadena de codificación que aparece bajo cada candidato te dice qué componente está mal configurado. Reparar el texto sin corregir el juego de caracteres de la conexión, el lector de archivos o la opción de exportación significa volver a hacerlo mañana con datos nuevos.

Confirma la dirección antes de convertir un archivo entero

Pasa primero una línea representativa por esta página. Convertir en la dirección equivocada puede producir caracteres de reemplazo y, a diferencia del error original, ese paso no es reversible.

Fija la codificación de forma explícita en todas partes

Juego de caracteres de la conexión a la base de datos, Content-Type de HTTP, llamadas de apertura de archivos, exportaciones a CSV. Cada punto que recurre por defecto a «la codificación del sistema» es un punto donde el mismo fallo reaparece cuando el código cambia de máquina.

Prefiere utf8mb4 a utf8 en MySQL

El utf8 de MySQL guarda como mucho tres bytes por carácter, así que los emoji y algunos caracteres chinos poco frecuentes se truncan en silencio. utf8mb4 es UTF-8 de verdad. Este fallo es distinto del mojibake y la herramienta de recuperación no puede ayudar, porque los bytes desaparecieron de verdad.

Conserva los bytes originales hasta verificar el arreglo

Haz una copia antes de convertir nada. Mientras existan los bytes originales, toda decodificación equivocada es reversible; en cuanto se sobrescriben con caracteres de reemplazo, ninguna herramienta de esta página ni de ninguna otra los devuelve.

Preguntas frecuentes