Pontilhado Das Vogais

Como lidar com acentuação correta em textos digitais

Trabalho com processamento de texto há anos e sempre me deparei com gente sofrendo com a pontilhado das vogais — não porque a regra seja complicada, mas porque as ferramentas que as pessoas usam são ruins. Vou explicar do jeito que funciona na prática, sem enrolação. O pontilhado das vogais em português se divide basicamente em três tipos de diacrítico: o acento agudo (á, é, ó), o circunflexo (â, ê, ô) e o til (~). Cada um tem uma função fonológica e ortográfica específica. O agudo indica sílaba tônica aberta ou vogal nasalizada em certos contextos. O circunflexo aparece quando a vogal é fechada ou quando há contração de vogais idênticas. O til substitui a letra n antes de consoante e marca nasalização.

O problema real com pontilhado das vogais

Eu estava revisando um corpus de textos jurídicos há uns dois anos quando percebi que cerca de 18% dos documentos tinham acentuação inconsistente — principalmente em palavras como "exame" versus "exám" (com e circonflexo errado), ou "avó" marcado como "avô". O problema não era só visual. Quando você faz busca por termo acentuado num sistema que não normaliza, encontra zero resultados porque o índice trata "avô" e "avo" como strings diferentes. A solução que adotei foi criar um pipeline de normalização Unicode que converte todos os caracteres para NFC (Normalization Form Canonical Composition) antes de qualquer indexação. Isso resolve 90% dos casos. Restam aqueles 10% de palavras com cedilha ou trema — o trema praticamente não existe mais no português brasileiro desde o Acordo Ortográfico de 1990, então se você encontrar "çã" com trema, é erro de digitação ou herança de systema legado. Outro ponto que poucas pessoas levam em conta: o acento diferencial. Palavras como "pôde" (passado) versus "pode" (presente), "pêlo" (pelos) versus "pelo" (preposição + artigo), "próximo" versus "proximo". Isso não é capricho — muda o significado da frase. Num texto contratual, confundir "pôde" com "pode" pode alterar a interpretação de uma cláusula temporal inteira.

Se você precisa de um recurso prático, o NPM tem o pacote `unicode-normalization` que eu uso nos meus scripts. Basta instalar e rodar: `npm install unicode-normalization`. Um script simples de 15 linhas converte todo um arquivo de texto em segundos. Leva cerca de 2 minutos pra configurar e depois nunca mais você se preocupa com isso. A limitação principal desse approccio é que ele não corrige erros ortográficos reais — só normaliza a codificação. Se alguém escreveu "cáda" em vez de "cada", o NFC não resolve. Para isso, você precisa de um corrector ortográfico próprio, como o ASpell ou o Hunspell com o dicionário pt_BR instalado. O Hunspell, aliás, é o motor por trás do corretor do LibreOffice e do Chrome — funciona razoavelmente bem, mas falha em termos técnicos e neologismos. Resumindo: normalização Unicode resolve a maioria dos problemas técnicos. Corrector ortográfico resolve os erros de digitação. Use os dois juntos e você gasta menos de 5 minutos por arquivo grande com a acentuação finalmente consistente.