¿Por qué su OCR produce
texto distorsionado? 3 causas principales y soluciones

Si ve una salida distorsionada, no está solo. Una comunidad de subreddit existe únicamente para personas que intentan identificar qué idioma "podría ser" su mojibake. El foro de la comunidad de Adobe Acrobat tiene docenas de hilos sin resolver de usuarios cuyo OCR en japonés produjo cadenas como 蟷ｴ莉｣繧｢繧ｸ繧｢縺ｫ縺翫¢繧九げ繝ｭ繝ｼ繝舌Ν蛹悶 en lugar de texto legible. La biblioteca ftfy de Python — una herramienta dedicada a corregir mojibake — se ha descargado millones de veces porque este es un problema recurrente en toda la industria.

La buena noticia: el texto OCR distorsionado no es un daño aleatorio. Sigue patrones predecibles causados por uno de tres mecanismos raíz. Una vez que identifique el patrón, la solución es repetible.

Causa 1 — Desajuste de Codificación: El Culpable Más Común

El síntoma: Los caracteres acentuados, los símbolos de moneda y las comillas tipográficas se convierten en basura de varios caracteres. El español corazón se convierte en corazón. El signo del euro € aparece como €. Las comillas curvas “se ven así”. El documento es mayormente legible, pero cada carácter no ASCII es incorrecto.

Por qué ocurre: La codificación de caracteres es el acuerdo entre un archivo y un lector sobre cómo mapear bytes a letras. Cuando el motor de OCR lee el archivo usando una codificación (por ejemplo, UTF-8) pero el archivo se creó con otra (por ejemplo, Windows-1252), los mismos bytes se mapean a caracteres completamente diferentes. El resultado es una corrupción sistemática — como leer un mapa dibujado en pulgadas como si fuera en centímetros. Cada medida está desviada por el mismo factor, y el patrón de errores le indica exactamente qué conversión se aplicó.

Cómo identificar el tipo de error de codificación

Ciertos patrones de mojibake son tan característicos que se puede diagnosticar el error de codificación con solo mirar el resultado:

Cómo corregir errores de codificación

Opción 1: Guardar de nuevo con la codificación correcta. Abre el documento original (o la salida del OCR) en un editor de texto como VS Code o Notepad++ que permita cambiar la codificación explícitamente. Usa Guardar como → UTF-8. Si el archivo era originalmente Windows-1252, guardarlo de nuevo como UTF-8 con detección correcta de caracteres suele resolverlo.

Opción 2: Usar herramientas de reparación de mojibake. Para correcciones masivas o automatizadas, la librería ftfy de Python (pip install ftfy) detecta y revierte automáticamente errores de codificación comunes — incluyendo corrupción multicapa donde el texto se decodificó con la codificación incorrecta, luego se recodificó y se decodificó mal una segunda vez. Una sola llamada a ftfy.fix_text() resuelve la gran mayoría de errores de codificación simple y doble.

Opción 3: Forzar al motor OCR a releer la capa de imagen en lugar de la capa de texto. Muchos problemas de texto distorsionado en PDF provienen de que el PDF subyacente tiene una capa de texto rota o con codificación personalizada, mientras que la capa visual de imagen está perfectamente bien. Si configuras tu herramienta OCR para tratar la página como imagen (en lugar de extraer de la capa de texto existente), volverá a reconocer todos los caracteres a partir de los glifos renderizados — saltándose cualquier daño de codificación. En Adobe Acrobat, esto significa elegir "ClearScan" o "Imagen con texto oculto (exacta)" en lugar de "Imagen con texto oculto (compacta)" en la configuración de OCR.

Causa 2 — Codificación de fuente: cuando el glifo se ve bien pero el código de carácter es incorrecto

El síntoma: El PDF se renderiza perfectamente en pantalla — cada carácter se ve correcto — pero al copiar texto o ejecutar OCR se produce un galimatías: GLYPH<38>, 9%)A:\2A o secuencias de caracteres sin sentido que se repiten. La página visual está limpia; la capa de texto es un desastre.

Por qué ocurre: Un archivo PDF tiene dos capas de "texto": los glifos visuales (lo que usted ve renderizado en pantalla) y la asignación de carácter a glifo (lo que lee un extractor de texto o un motor de OCR). Normalmente estas dos capas coinciden. Pero en PDF generados deficientemente, el archivo de fuente puede contener una codificación de glifos personalizada — las formas de los glifos son correctas (por lo que la página se ve bien), pero los códigos de carácter a los que se asignan no son estándar o carecen por completo de asignaciones Unicode.

Esta situación es sorprendentemente común. Las fuentes de subconjunto — donde solo se incluyen los caracteres exactos utilizados en el documento — suelen usar identificadores de carácter (CID) no estándar para la asignación interna. Cuando un extractor de texto intenta interpretar esos CID usando una tabla de codificación estándar, obtiene basura. Un problema reportado en el proyecto Docling mostró exactamente esto: un PDF se mostraba bien, el OCR estaba configurado con do_ocr=True, y la salida era '() +,- .+.. /01 02034567638469:; 4<8:=> — porque la codificación interna de la fuente no se asignaba al Unicode estándar.

Escenarios donde es más probable encontrar basura por codificación de fuente:

• PDF generados por software especializado: Herramientas CAD (AutoCAD, Archicad), generadores de informes ERP o controladores de impresión heredados de print-to-PDF suelen incrustar fuentes con tablas de codificación personalizadas. Una discusión comunitaria en los foros de Adobe describe a un usuario de Archicad cuyos PDF tenían Segoe UI incrustada — y aun así producían texto distorsionado, porque la incrustación por sí sola no garantiza una asignación de caracteres estándar.
• Documentos PDF/A o con firma digital: Los formatos de documentos orientados al cumplimiento normativo a veces eliminan o modifican la información de asignación de caracteres durante el proceso de conversión.
• Documentos escaneados que tenían una capa de texto oculta añadida por una pasada de OCR anterior: Si el OCR anterior produjo caracteres incorrectos y el PDF se guardó con esa capa de texto incrustada, la extracción posterior lee el texto incorrecto almacenado en caché en lugar de ejecutar un nuevo reconocimiento.
• Documentos con escrituras no latinas: Las fuentes japonesas Shift-JIS, las fuentes coreanas EUC-KR y las fuentes chinas con codificación GB son fuentes frecuentes de desajuste de codificación cuando el visor de PDF o el motor de OCR usa por defecto una página de códigos diferente.

Cómo corregir el texto ilegible por codificación de fuentes

Opción 1: Forzar un nuevo OCR en la capa de imagen. Esta es la solución más fiable. Indique a su herramienta de OCR que ignore la capa de texto existente y lea directamente de las imágenes de página renderizadas. En Acrobat Pro, vaya a Herramientas → Escaneo y OCR → Reconocer texto → En este archivo y asegúrese de que el motor de OCR trate el documento como una imagen escaneada. En ocrmypdf, use la bandera --force-ocr para sobrescribir por completo la capa de texto existente.

Opción 2: Convertir a un formato de imagen sin pérdida y volver a aplicar OCR. Exporte las páginas del PDF como archivos TIFF o PNG de alta resolución (al menos 300 DPI) y luego ejecute OCR sobre esas imágenes. Esto elimina todos los metadatos de codificación de fuentes dañados y le da al motor de OCR una fuente visual limpia. El hilo de la comunidad de Adobe Acrobat sobre el mojibake en japonés encontró que exportar a TIFF y volver a aplicar OCR resolvió el problema cuando el OCR directo del PDF había fallado.

Opción 3: Verificar la incrustación de fuentes con Preflight. En Adobe Acrobat Pro, use Herramientas → Producción de impresión → Preflight y ejecute un perfil de análisis de fuentes. Esto le muestra si las fuentes están completamente incrustadas, incrustadas como subconjunto o faltantes, y si incluyen mapas de caracteres Unicode. Si una fuente está incrustada como subconjunto sin las tablas /ToUnicode adecuadas, esa es la prueba definitiva.

Causa 3 — Resolución y confusión de caracteres: cuando la calidad de imagen decepciona al OCR

El síntoma: Caracteres individuales incorrectos de maneras que parecen sustituciones razonables: 5 se convierte en S, 0 se convierte en O, 1 se convierte en l (L minúscula), rn se convierte en m. La puntuación desaparece. Los trazos finos en caracteres como e o a faltan, lo que hace que las palabras parezcan abreviadas. La salida no es basura total — es sutil y frustrantemente incorrecta.

Por qué ocurre: Los motores de OCR funcionan comparando formas de caracteres con modelos de glifos conocidos. Cuando la imagen de entrada tiene resolución insuficiente, los píxeles disponibles no son suficientes para distinguir entre caracteres visualmente similares. Una letra S a 72 DPI ocupa aproximadamente 10–12 píxeles verticalmente — a esa resolución, el serif de un 5 y la curva de una S pueden parecer idénticos. Esto no es un problema de codificación; es una restricción fundamental de la teoría de la información. Si la imagen no contiene suficientes píxeles para representar las características distintivas de cada carácter, ningún motor de OCR — por avanzado que sea — puede hacer una suposición perfecta cada vez.

Esta clase de error es especialmente frecuente en:

• Fotos de documentos tomadas con el teléfono con poca luz o en ángulo
• Páginas enviadas por fax o fotocopiadas repetidamente donde cada generación pierde detalle
• Escaneos antiguos de microfilm de registros históricos
• Documentos con tamaños de fuente pequeños (8 puntos o menos) escaneados a 200 DPI o menos

Cómo corregir el texto ilegible relacionado con la resolución

Opción 1: Aumente la resolución de entrada. El estándar de la industria para OCR es un mínimo de 300 DPI, con 400–600 DPI recomendados para texto pequeño o denso. Si trabaja con una foto tomada con el teléfono, los pasos de preprocesamiento de imágenes como el escalado, la nitidez y la corrección de inclinación pueden ayudar antes de enviar la imagen al motor de OCR.

Opción 2: Use una herramienta de extracción basada en visión en lugar de OCR tradicional. Esta es la solución estructural. Los motores de OCR tradicionales (Tesseract, ABBYY, Adobe OCR) dependen del reconocimiento de patrones carácter por carácter, por lo que un píxel faltante puede convertir un 5 en una S. La extracción moderna con modelos de lenguaje y visión (VLM) (el enfoque utilizado por ImageToTable.ai y herramientas similares) lee palabras y oraciones completas como objetos visuales, usando el contexto semántico para resolver la ambigüedad. Cuando el motor ve "Order S units" y el contexto circundante es una factura, entiende que S probablemente sea 5 — no porque reconozca mejor la forma del carácter, sino porque "Order 5 units" tiene sentido de una manera que "Order S units" no lo tiene. Para una explicación de cómo esto difiere del OCR tradicional, lea qué es el OCR y de dónde provienen sus limitaciones.

Opción 3: Aplique preprocesamiento de imágenes antes del OCR. Incluso un preprocesamiento simple puede reducir drásticamente la confusión de caracteres. Convertir a escala de grises, aplicar umbral adaptativo para binarizar el texto y eliminar el ruido (motas, patrones de fondo) le da al motor de OCR una señal más limpia. Consulte nuestra guía para mejorar la precisión del OCR para conocer flujos de trabajo de preprocesamiento probados en el campo.

Cuándo escalar: qué hacer si ninguna de las soluciones funciona

Si ha verificado la codificación, revisado las fuentes y preprocesado la imagen — y el resultado sigue siendo ilegible — es posible que la herramienta no sea la adecuada para ese tipo de documento. Los documentos con escrituras mixtas, fuentes decorativas, notación matemática o sellos superpuestos llevan al OCR tradicional más allá de sus límites de diseño.

En estos casos, la solución práctica es cambiar a una herramienta de extracción con IA de visión sin plantilla que lea los documentos de manera integral. Herramientas como ImageToTable.ai evitan por completo los problemas de codificación y fuentes porque extraen el significado de la representación visual de la página, no de una capa de texto preexistente. Usted sube el documento, nombra las columnas que desea y la IA extrae los datos comprendiendo la estructura visual y semántica del documento — sin capa de texto dependiente de fuentes, sin tablas de codificación de las que preocuparse.

Preguntas frecuentes

El texto OCR distorsionado no es aleatorio — esto es lo que debe hacer

Cuando el resultado del OCR parece un alfabeto revuelto, es tentador culpar al software y seguir adelante. Pero las tres causas aquí cubiertas — errores de codificación, problemas de codificación de fuente y confusión de caracteres por resolución — tienen cada una una huella específica y una solución correspondiente. Aprender a distinguirlas convierte un misterio frustrante en un diagnóstico repetible.

Empiece por el síntoma: basura de varios caracteres alrededor de acentos (como é) → error de codificación, solución con recodificación o ftfy. Renderizado perfecto en pantalla pero el OCR produce glifos no relacionados → problema de codificación de fuente, solución forzando OCR sobre la imagen. Caracteres individuales intercambiados por similares (5→S) → problema de resolución, solución con preprocesamiento o una herramienta consciente del contexto.

La última opción — pasar de OCR basado en caracteres a extracción basada en visión — evita las causas raíz al leer el documento como lo haría un humano: entendiendo el significado en lugar de emparejar patrones de píxeles o recorrer tablas de codificación.

Pruebe con sus propios documentos distorsionados. Vea si el problema desaparece cuando el motor ya no depende de una capa de texto.