Como lidar com texto com a letra r em processamento de dados
Trabalhando com arquivos de exportação de sistemas legados, me deparei recentemente com um problema específico: precisava processar um CSV de 40 mil linhas onde o campo "razão social" continha variants da letra R que pareciam idênticas visualmente, mas tinham códigos Unicode diferentes. A letra R normal é U+0052, mas encontreiInstances de U+0210 (R com traço) e U+0154 (r com agudo) que quebravam completamente minhas expressões regulares. O que a maioria dos desenvolvedores não considera é que o problema do texto com a letra r vai muito além da digitação. Quando você está lidando com normalização de strings em sistemas que atendem múltiplos países, especialmente aqueles que processam nomes próprios e documentos oficiais, a variedade de caracteres que se parecem com R é surpreendentemente grande. R latim, R cirílico (U+0420), R grego (), e as formas com diacríticos listadas acima criam problemas reais de validação e busca.
O problema do texto com a letra r na prática
No meu caso concreto, o sistema de importação que construí estava usando uma verificação simples de equivalência para validar CPFs e CNPJs contra a Receita Federal. Como a maioria dos arquivos viene de planilhas feitas por contadores usando Excel em português, alguns campos eram copiados e colados de documentos escaneados via OCR. O OCR frequentemente confundia R com P ou B, mas o mais frequente era inserir versões com diacríticos que o Excel aceitava sem reclamar. A solução que funcionou foi implementar uma função de normalização com NFKC (Normalization Form KC) do Unicode antes de qualquer processamento. Isso converte todas as variantes para a forma canônica, transformando R com traço em R normal, r com agudo em r normal, e assim por diante. Depois, apliquei uma verificação adicional com a biblioteca unicodedata do Python para isolar caracteres que permanecem estranhos mesmo após a normalização.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para quem não quer implementar isso do zero, existem pacotes como `ftfy` para Python que fazem exatamente esse trabalho de correção de texto problemático. No Node.js, o pacote `normalizer-transliterator` lida bem com esses casos. O tempo de processamento adicional é irrelevante para datasets abaixo de 100 mil registros, mas em volumes maiores convém considerar pré-processamento em lote. Uma coisa que muita gente esquece é que a normalização não resolve todos os casos. O caractere R cirílico e R latino têm o mesmo aspecto visual, mas são completamente diferentes em termos de codificação e não são normalizados um no outro pelo NFKC. Se seu sistema precisa aceitar dados de usuários ucranianos ou russos, você precisa de uma camada extra de mapeamento intencional entre alfabetos, não apenas normalização cega.
A melhor abordagem que encontrei foi combinar a normalização Unicode padrão com uma tabela de mapeamento personalizada que eu mantenho atualizada. Comecei com os caracteres mais comuns encontrados em reclamações de suporte e fui ampliando conforme os problemas apareciam. Esse arquivo de configuração pode ser compartilhado entre equipes e deployments, o que elimina a variabilidade de implementações diferentes tratando o mesmo problema de formas incompatíveis.
