Corrección de Mojibake — Arregla Texto Ilegible

Resumen

El texto ilegible no es un daño. Son bytes correctos leídos con la tabla equivocada. 日本語 codificado en UTF-8 son nueve bytes; leídos como Windows-1252, esos mismos nueve bytes dan 日本語. No se perdió nada — la interpretación era errónea, y revertirla restituye el original exactamente.

Esta herramienta vuelve a codificar en bytes el texto que pega usando la codificación con la que probablemente se leyó mal, decodifica esos bytes con cada codificación en la que realmente podría haber estado, y ordena los resultados. El primer candidato es la pareja que produce UTF-8 válido sin caracteres de reemplazo.

Cómo se usa

1. Pegue el texto ilegible.
2. Lea el primer candidato, marcado con una estrella.
3. Si no es el correcto, revise los demás — cada uno lleva la etiqueta de la pareja que lo produjo.

Por qué el primer candidato suele ser el correcto

El orden no es una suposición sobre el idioma. Se apoya en una propiedad estructural del UTF-8: la codificación declara por sí misma la longitud de sus secuencias. Un byte inicial indica cuántos bytes de continuación siguen, y cada byte de continuación es identificable como tal. Por eso una secuencia de bytes arbitraria falla al decodificarse como UTF-8 casi de inmediato, y el decodificador del navegador informa ese fallo con caracteres de reemplazo.

Así, cuando un candidato se decodifica como UTF-8 sin ningún carácter de reemplazo, eso es una prueba sólida y no una preferencia — los bytes eran UTF-8 válido desde el principio, que es exactamente lo que cabe esperar de un texto que estaba en UTF-8 antes de que algo lo leyera como Latin-1. Los candidatos se ordenan además según si el resultado sigue conteniendo firmas de corrupción, y solo se ofrece un candidato si las reduce.

Por qué el texto correcto se deja intacto

Antes de producir cualquier candidato, se examina la entrada buscando las firmas del texto ilegible: las parejas de bytes concretas que producen las lecturas erróneas en Latin-1 (à /  / †/ ã y sus parientes), los caracteres de control C1 del rango U+0080–U+009F, y los caracteres de reemplazo U+FFFD.

Un texto sin ninguna de ellas se informa como limpio y no se ofrecen candidatos. Esto importa porque la transformación es destructiva aplicada a texto correcto. Grüße y señor son alemán y español corrientes; páselos por una reparación que los suponga corrompidos y obtendrá un sinsentido. Una herramienta que siempre ofrece candidatos invita precisamente a ese error.

Qué no se puede recuperar

Si el texto contiene ?, � o cuadrados vacíos, los bytes originales han desaparecido.

Merece la pena ser preciso con la distinción. El texto ilegible conserva los bytes y pierde la interpretación, así que es reversible. La sustitución pierde los bytes: cuando un conversor encuentra un carácter que su codificación destino no puede representar, escribe un reemplazo y descarta el original. Ninguna herramienta recupera eso, porque no queda nada que reinterpretar. Si aún puede conseguir el archivo de origen, ese es el único camino.

La doble corrupción — corrompido, guardado y corrompido otra vez — a veces se recupera aplicando la reparación dos veces, pero cada pasada agrava cualquier pérdida y los resultados se degradan.

De dónde viene el texto ilegible

El patrón es casi siempre un valor por defecto que nunca se declaró:

• Un CSV abierto en una hoja de cálculo. Excel en Windows supuso históricamente la página de códigos del sistema para los .csv salvo que hubiera BOM de UTF-8, y por eso los archivos exportados llenos de acentos se abren ilegibles. Así café queda como café.
• Una conexión de base de datos sin juego de caracteres definido. Los datos están almacenados correctamente y la conexión convierte mal, así que las mismas filas se leen bien con un cliente y mal con otro.
• Los asuntos de correo. Los encabezados son solo ASCII, así que el no-ASCII viaja como encoded-words de la RFC 2047 que nombran su propio juego de caracteres. Los asuntos en japonés todavía usan ISO-2022-JP de forma habitual, y un decodificador que supone UTF-8 corrompe todos.
• Una respuesta sin charset en su Content-Type. El navegador adivina, y su suposición depende de la configuración regional.
• Un nombre de archivo antiguo en un archivo comprimido. ZIP no tiene un campo de juego de caracteres fiable, así que nombres creados con una página de códigos se leen con otra.

Ejemplos

• Reparar un CSV importado — pegue un campo afectado para identificar la pareja y vuelva a importar con la codificación correcta en lugar de reparar filas una a una.
• Leer un asunto de correo corrompido — para un mensaje completo, el visor .eml decodifica los encoded-words con el juego de caracteres que declara el encabezado, incluido ISO-2022-JP, así que el asunto se lee bien sin ninguna reparación.
• Diagnosticar una cadena de proceso — la pareja que produce la corrección le dice dónde está mal la conversión. «Escrito en UTF-8, leído en Windows-1252» señala una declaración de charset ausente en el lado de la lectura, no un problema de los datos.
• Revisar la salida de un registro — un servicio que registra en una codificación y un agregador que lee en otra solo producen texto ilegible en las líneas no ASCII, y por eso pasa inadvertido hasta que aparece un nombre o un mensaje de error de un sistema traducido.

Notas

Los candidatos se decodifican con el TextDecoder del propio navegador, así que las tablas son las que usa la plataforma — esta página no incluye ninguna tabla de codificación. La compatibilidad con las codificaciones multibyte antiguas la exige el Encoding Standard y está presente en todos los navegadores actuales.

Las codificaciones cubiertas son windows-1252, iso-8859-1, windows-1251 y macintosh en el lado de la lectura errónea, y utf-8, shift_jis, euc-jp, iso-2022-jp, gbk, big5 y euc-kr en el lado original. Se muestran hasta ocho candidatos.

Lea siempre el candidato antes de usarlo. Con una muestra corta, varias parejas pueden producir una salida plausible, y la comprobación estructural no puede decirle en qué idioma debía estar el texto. Todo ocurre en su navegador — véase la política de privacidad.