Por que seu OCR está produzindo
Texto Ilegible? 3 Causas Raiz e Correções

Se você está vendo saída ilegível, não está sozinho. Uma comunidade no subreddit existe apenas para pessoas tentando identificar qual idioma seu mojibake "poderia ser". O fórum da comunidade Adobe Acrobat tem dezenas de tópicos não resolvidos de usuários cujo OCR em japonês produziu strings como 蟷ｴ莉｣繧｢繧ｸ繧｢縺ｫ縺翫¢繧九げ繝ｭ繝ｼ繝舌Ν蛹悶 em vez de texto legível. A biblioteca ftfy do Python — uma ferramenta dedicada a corrigir mojibake — foi baixada milhões de vezes porque este é um problema recorrente em toda a indústria.

A boa notícia: texto OCR ilegível não é dano aleatório. Ele segue padrões previsíveis causados por um de três mecanismos raiz. Uma vez identificado o padrão, a correção é repetível.

Causa 1 — Incompatibilidade de Codificação: O Culpado Mais Comum

O sintoma: Caracteres acentuados, símbolos de moeda e aspas inteligentes viram lixo de múltiplos caracteres. O espanhol corazón vira corazón. O símbolo do euro € aparece como €. Aspas curvas “ficam assim”. O documento é majoritariamente legível, mas todo caractere não-ASCII está errado.

Por que acontece: Codificação de caracteres é o acordo entre um arquivo e um leitor sobre como mapear bytes em letras. Quando o mecanismo de OCR lê o arquivo usando uma codificação (digamos, UTF-8) mas o arquivo foi criado com outra (digamos, Windows-1252), os mesmos bytes mapeiam para caracteres completamente diferentes. O resultado é corrupção sistemática — como ler um mapa desenhado em polegadas como se fosse centímetros. Cada medida está errada pelo mesmo fator, e o padrão do erro indica exatamente qual conversão foi aplicada.

Como identificar qual incompatibilidade de codificação você está enfrentando

Certos padrões de mojibake são tão característicos que você pode diagnosticar o erro de codificação apenas olhando para a saída:

Como corrigir incompatibilidades de codificação

Opção 1: Salve novamente com a codificação correta. Abra o documento original (ou a saída do OCR) em um editor de texto como VS Code ou Notepad++ que permita alterar a codificação explicitamente. Use Salvar como → UTF-8. Se o arquivo era originalmente Windows-1252, salvá-lo novamente como UTF-8 com detecção adequada de caracteres geralmente resolve o problema.

Opção 2: Use ferramentas de reparo de mojibake. Para correções em lote ou automatizadas, a biblioteca Python ftfy (pip install ftfy) detecta e reverte automaticamente erros comuns de codificação — incluindo corrupção em múltiplas camadas, onde o texto foi decodificado com a codificação errada, depois recodificado e decodificado errado uma segunda vez. Uma única chamada a ftfy.fix_text() resolve a grande maioria dos erros de codificação simples e dupla.

Opção 3: Force o mecanismo de OCR a reler a camada de imagem em vez da camada de texto. Muitos problemas de texto ilegível em PDFs vêm do fato de o PDF subjacente ter uma camada de texto quebrada ou com codificação personalizada, enquanto a camada visual da imagem está perfeitamente intacta. Se você configurar sua ferramenta de OCR para tratar a página como imagem (em vez de extrair da camada de texto existente), ela reconhecerá todos os caracteres a partir dos glifos renderizados — ignorando qualquer dano de codificação. No Adobe Acrobat, isso significa escolher "ClearScan" ou "Imagem pesquisável (Exata)" em vez de "Imagem pesquisável (Compacta)" nas configurações de OCR.

Causa 2 — Codificação de Fonte: Quando o Glifo Parece Correto, mas o Código do Caractere Está Errado

O sintoma: O PDF é renderizado perfeitamente na tela — cada caractere parece correto — mas copiar texto ou executar OCR produz algo sem sentido: GLYPH<38>, 9%)A:\2A ou sequências repetidas de caracteres sem significado. A página visual está limpa; a camada de texto é uma bagunça.

Por que isso acontece: Um arquivo PDF tem duas camadas de "texto": os glifos visuais (o que você vê renderizado na tela) e o mapeamento caractere-para-glifo (o que um extrator de texto ou mecanismo de OCR lê). Normalmente, essas duas camadas concordam. Mas em PDFs mal gerados, o arquivo de fonte pode conter codificação de glifo personalizada — as formas dos glifos estão corretas (então a página parece boa), mas os códigos de caractere aos quais eles mapeiam são não padronizados ou não têm mapeamentos Unicode.

Essa situação é surpreendentemente comum. Fontes de subconjunto — onde apenas os caracteres exatos usados no documento são incluídos — frequentemente usam IDs de caractere (CIDs) não padronizados para mapeamento interno. Quando um extrator de texto tenta interpretar esses CIDs usando uma tabela de codificação padrão, ele obtém lixo. Um problema relatado no projeto Docling mostrou exatamente isso: um PDF era exibido corretamente, o OCR estava definido como do_ocr=True, e a saída era '() +,- .+.. /01 02034567638469:; 4<8:=> — porque a codificação interna da fonte não mapeava para Unicode padrão.

Cenários em que o lixo de codificação de fonte é mais provável:

• PDFs gerados por software especializado: Ferramentas CAD (AutoCAD, Archicad), geradores de relatórios ERP ou drivers legados de imprimir-em-PDF frequentemente incorporam fontes com tabelas de codificação personalizadas. Uma discussão da comunidade nos fóruns da Adobe descreve um usuário do Archicad cujos PDFs tinham Segoe UI incorporada — e ainda assim produziam texto ilegível, porque a incorporação sozinha não garante mapeamento padrão de caracteres.
• Documentos PDF/A ou com assinatura digital: Formatos de documentos voltados à conformidade às vezes removem ou modificam informações de mapeamento de caracteres durante o processo de conversão.
• Documentos digitalizados que tiveram uma camada de texto oculta adicionada por uma passada anterior de OCR: Se o OCR anterior produziu caracteres incorretos e o PDF foi salvo com essa camada de texto incorporada, a extração subsequente lê o texto errado em cache em vez de executar um novo reconhecimento.
• Documentos com scripts não latinos: Fontes japonesas Shift-JIS, fontes coreanas EUC-KR e fontes chinesas codificadas em GB são fontes frequentes de incompatibilidade de codificação quando o visualizador de PDF ou o mecanismo de OCR usa uma página de código diferente por padrão.

Como corrigir lixo de codificação de fontes

Opção 1: Forçar um novo OCR na camada de imagem. Esta é a correção mais confiable. Diga à sua ferramenta de OCR que ignore a camada de texto existente e lea diretamente das imágenes renderizadas da página. No Acrobat Pro, vá a Herramientas → Escanear 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 completamente la capa de texto existente.

Opción 2: Convertir a un formato de imagen sin pérdida y volver a hacer 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 rotos y le da al motor de OCR una fuente visual limpia. El hilo de la comunidad de Adobe Acrobat sobre el mojibake japonés encontró que exportar a TIFF y volver a hacer OCR resolvió el problema donde 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 tablas /ToUnicode adecuadas, esa es su pistra.

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

El síntoma: Los caracteres individuales son incorrectos de maneras que parecen sustitutos 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, haciendo que las palabras parezcan abreviadas. La salida no es basura total — es sutil, frustrantemente incorrecta.

Por qué sucede: 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 prevalente en:

• Fotos de documentos tomadas con el teléfono en condiciones de 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

Como corrigir texto ilegível relacionado à resolução

Opção 1: Aumente a resolução de entrada. O padrão da indústria para OCR é de no mínimo 300 DPI, sendo recomendados 400–600 DPI para textos pequenos ou densos. Se você estiver trabalhando com uma foto tirada pelo celular, etapas de pré-processamento de imagem como ampliação, nitidez e correção de inclinação podem ajudar antes de enviar a imagem para o mecanismo de OCR.

Opção 2: Use uma ferramenta de extração baseada em visão em vez de OCR tradicional. Esta é a correção estrutural. Os mecanismos de OCR tradicionais (Tesseract, ABBYY, Adobe OCR) dependem da correspondência de padrões caractere por caractere — é por isso que um pixel ausente pode transformar um 5 em um S. A extração moderna por modelo de visão-linguagem (VLM) (a abordagem usada pelo ImageToTable.ai e ferramentas similares) lê palavras e frases inteiras como objetos visuais, usando contexto semântico para resolver ambiguidades. Quando o mecanismo vê "Order S units" e o contexto ao redor é uma fatura, ele entende que S provavelmente é 5 — não porque reconhece melhor o formato do caractere, mas porque "Order 5 units" faz sentido de uma forma que "Order S units" não faz. Para uma explicação de como isso difere do OCR tradicional, leia o que é OCR e de onde vêm suas limitações.

Opção 3: Aplique pré-processamento de imagem antes do OCR. Mesmo um pré-processamento simples pode reduzir drasticamente a confusão de caracteres. Converter para escala de cinza, aplicar limiar adaptativo para binarizar o texto e remover ruídos (manchas, padrões de fundo) dá ao mecanismo de OCR um sinal mais limpo. Consulte nosso guia para melhorar a precisão do OCR para fluxos de pré-processamento testados em campo.

Quando Escalar: O Que Fazer Se Nenhuma das Correções Funcionar

Se você verificou a codificação, conferiu as fontes e pré-processou a imagem — e a saída ainda está ilegível — a ferramenta em si pode não ser a mais adequada para o tipo de documento. Documentos com scripts mistos, fontes decorativas, notação matemática ou sobreposição pesada de carimbos levam o OCR tradicional além dos seus limites de design.

Nesses casos, a solução prática é mudar para uma ferramenta de extração de IA por visão sem modelo que lê documentos de forma holística. Ferramentas como o ImageToTable.ai ignoram completamente problemas de codificação e fonte, pois extraem significado da renderização visual da página, não de uma camada de texto pré-existente. Você envia o documento, nomeia as colunas que deseja e a IA extrai os dados compreendendo a estrutura visual e semântica do documento — sem camada de texto dependente de fonte e sem tabelas de codificação para se preocupar.

FAQ

Texto OCR ilegível não é aleatório — veja o que fazer agora

Quando a saída do OCR parece um alfabeto embaralhado, é tentador culpar o software e seguir em frente. Mas as três causas abordadas aqui — incompatibilidade de codificação, problemas de fonte e confusão de caracteres por resolução — têm cada uma uma assinatura específica e uma correção correspondente. Aprender a distingui-las transforma um mistério frustrante em um diagnóstico repetível.

Comece pelo sintoma: caracteres múltiplos e bagunçados ao redor de acentos (como é) → incompatibilidade de codificação, resolva com re-codificação ou ftfy. Renderização perfeita na tela, mas OCR produz glifos não relacionados → problema de fonte, resolva forçando OCR na camada de imagem. Caracteres individuais trocados por similares (5→S) → problema de resolução, resolva com pré-processamento ou uma ferramenta sensível ao contexto.

A última opção — migrar do OCR baseado em caracteres para extração baseada em visão — contorna as causas raiz por completo ao ler o documento como um humano faria: entendendo o significado em vez de combinar padrões de pixels ou percorrer tabelas de codificação.

Teste em seus próprios documentos ilegíveis. Veja se o problema desaparece quando o motor não depende mais de uma camada de texto.