Corrector de mojibake

Comparación de hipótesis de codificación
El texto pegado y todos los resultados permanecen en este navegador. El modo por pasos conserva un registro validado en esta pestaña durante un máximo de 30 minutos y solo añade a la URL un identificador opaco de tarea. No se envía nada mediante nuestros servidores ni una API de reparación.

Pega el texto que parece dañado

Pega un texto como café o una cadena japonesa que haya quedado ilegible por una incompatibilidad de codificación. El original no cambia en el editor.

Máximo de 50.000 caracteres. Esta herramienta solo compara texto Unicode pegado; no inspecciona ni repara archivos, secuencias de bytes, bases de datos o cabeceras HTTP.

Mojibake es información legible que aparece con caracteres equivocados porque sus bytes se descodificaron con un juego de caracteres incompatible. Un ejemplo conocido es café: café se codificó en UTF-8, pero sus bytes se interpretaron como Latin-1 o Windows-1252. Pega el texto visible para comparar hipótesis de reparación estrictamente reversibles. La herramienta mantiene intacto el original, identifica cada resultado como una hipótesis y realiza la comparación de forma local en el navegador.

Cómo comparar una hipótesis de reparación de mojibake

  1. 1

    Pega el texto visible

    Usa el texto exactamente como lo recibiste. La herramienta no sube ni examina un archivo de origen.

  2. 2

    Acepta la comparación

    Pide al navegador que contraste interpretaciones de bytes Latin-1 y Windows-1252 con un descodificador UTF-8 estricto.

  3. 3

    Compara sin dar nada por hecho

    Lee el original intacto junto a cada resultado reversible y selecciona uno únicamente si el contexto lo respalda.

  4. 4

    Copia texto sin formato

    Copia, descarga o imprime una hipótesis seleccionada sin sobrescribir el original.

Qué puede establecer una reparación de mojibake y qué no

Una codificación asigna caracteres a bytes y permite recuperarlos. UTF-8 representa é con los dos bytes C3 A9. Si un programa descodifica esos bytes como Windows-1252 o ISO-8859-1, el resultado visible puede ser é. Una hipótesis de reparación útil invierte ese error concreto: trata los caracteres antiguos visibles como valores de bytes, descodifica esos bytes como UTF-8 de manera estricta y comprueba que volver a codificar el resultado en UTF-8 produzca exactamente los mismos bytes.

La comprobación de ida y vuelta descarta secuencias UTF-8 incompletas o mal formadas. También rechaza cualquier resultado que contenga el carácter de sustitución , porque la información que representa ya se ha perdido. Una ida y vuelta válida aporta indicios para una hipótesis, pero no demuestra qué codificación usó el sistema de origen ni qué quiso escribir la persona autora.

Texto visible Hipótesis probada Posible resultado Qué comprobar
café Bytes UTF-8 leídos como Latin-1 café Contrastar la ortografía con la fuente
It’s Bytes UTF-8 leídos como Windows-1252 It’s Revisar la puntuación y el estilo
文字化け Bytes UTF-8 leídos como Latin-1 文字化け Comparar el japonés con una copia fiable
café Dos errores de codificación consecutivos café Inspeccionar las dos pasadas controladas

Por qué el texto japonés necesita contexto

El término japonés 文字化け se usa para describir caracteres que aparecen deformados. Un texto japonés en UTF-8 puede convertirse en una larga mezcla de letras latinas, símbolos y caracteres semejantes a controles cuando sus bytes se descodifican mediante una asignación antigua equivocada. La reversibilidad resulta útil, pero un nombre corto o un carácter aislado todavía puede ser ambiguo. Contrasta el resultado con el documento original, una exportación de la base de datos, la persona remitente u otra copia autorizada.

Límites y recuperación más segura

Esta herramienta recibe texto Unicode que el navegador ya ha descodificado. No puede recuperar bytes descartados con anterioridad, deducir la codificación de un archivo binario, reparar una columna de una base de datos ni cambiar una cabecera HTTP Content-Type. Si no aparece ningún resultado, conserva el original. Siempre que sea posible, consigue los bytes reales de origen, crea una copia de seguridad, identifica la codificación declarada y la real y descodifica una sola vez con una herramienta preparada para archivos o secuencias de bytes. Nunca guardes repetidamente el texto dañado sobre la única copia de origen.

Preguntas frecuentes

No. Significa que una interpretación concreta de bytes antiguos se descodificó como UTF-8 válido y superó una comprobación exacta de ida y vuelta. Varias interpretaciones pueden producir el mismo texto legible o textos diferentes. Siguen siendo necesarios el contexto y una fuente autorizada.

Puede que los caracteres visibles no representen bytes UTF-8 interpretados como ISO-8859-1 o Windows-1252, que la secuencia esté incompleta o que un carácter de sustitución ya haya eliminado información. Conserva el original e inspecciona los bytes reales y los metadatos de codificación.

No. Solo compara texto Unicode pegado. No lee archivos, no detecta su codificación, no se conecta a bases de datos, no reescribe valores almacenados ni repara cabeceras del servidor. Haz una copia de seguridad antes de usar un proceso de conversión que opere con bytes.

No. La comparación, la selección, la copia, la creación del TXT y la preparación para imprimir se realizan en el navegador. El modo por pasos puede conservar un registro validado en esta pestaña durante un máximo de 30 minutos y solo añade a la URL un identificador opaco de tarea.

Herramientas relacionadas