Lingua Portuguesa Tem Acento - 712084859-cartaz-acento - Lingua Portuguesa - ACENTO AGUDO Indica que a ...
712084859-cartaz-acento - Lingua Portuguesa - ACENTO AGUDO Indica que a ...

O problema real dos acentos no português

Quando você trabalha com dados, APIs ou sistemas legados, o acento não é só uma questão estética. Ele quebra buscas, estraga chaves primárias e faz comparações falharem sem aviso. A frase mais comum que eu vejo em fóruns de desenvolvimento é alguém dizendo que seu sistema não reconhece "São Paulo" igual a "Sao Paulo". O problema não é o dicionário, é a forma de normalização que você escolheu — ou não escolheu. Eu já passei por um caso específico que demorou três dias para resolver. Um sistema de cadastro de usuários em Node.js permitia UTF-8 no banco, mas a consulta de busca usava LIKE com colação padrão. O usuário se chamava "André Luiz". Quando ele digitava "andre luis" na busca, nada aparecia. Quando digitava o acento correto, encontrava. A tabela estava em utf8mb4, o campo em utf8mb4_unicode_ci. Parecia certo, mas não era. A solução foi trocar a colação do banco para utf8mb4_bin e adicionar uma camada de normalização com ICU no aplicativo. Só aí a busca passou a funcionar de forma consistente, independente de acento ou não.

Por que lingua portuguesa tem acento importa na prática

Não adianta tratar acentuação como detalhe tipográfico. Ela carrega significado. "Pode" (verbo poder) é diferente de "pôde" (pretérito perfeito). "Para" (preposição) não é "já" — é "para" (preposição/futuro). Trocar tudo por ASCII é rápido, mas gera ambiguidade que seu sistema vai herdar para sempre. Na minha experiência, existem duas camadas que as pessoas confundem. A primeira é a normalização Unicode. A segunda é a conversão visual. Usar NFC (Normalization Form Canonical Composition) converte caracteres combinados como "e" + em "é" (U+00E9). Usar NFD (Decomposition) separa o "e" do acento (U+0065 + U+0301). Se seu sistema armazena em NFD e recebe entrada em NFC, uma comparação direta de strings falha. A maioria das bibliotecas modernas resolve isso, mas bibliotecas antigas ou consultas SQL diretas não.

A regra prática é simples: defina um padrão no início do projeto e aplique em todas as entradas. Eu uso NFC no ponto de entrada (recebimento dos dados) e NFC tanto no armazenamento quanto nas consultas. Nunca misturo formas.

Como normalizar acentos de forma consistente

O método mais comum em pipelines de dados é a decomposição NFD seguida de remoção dos diacríticos e recomposição. Em Python: import unicodedata
texto_normalizado = unicodedata.normalize('NFKD', texto).encode('ascii', 'ignore').decode('ascii')

Isso converte "São Paulo" para "Sao Paulo". Funciona para a maioria dos casos. O problema é que NFKD faz mais do que decomposição canônica — ele também mapeia caracteres de compatibilidade. " " vira "fi", mas também transforma algumas formas especiais que podem não ser o que você espera. Para buscas, o ideal é criar dois índices. Um com a forma original acentuada e outro com a forma normalizada sem acento. Assim, a busca por "São Paulo" encontra registros tanto digitados com acento quanto sem. Em PostgreSQL, você pode usar funções de text search com a configuração portuguese. Em MySQL, colações como utf8mb4_general_ci já ignoram acento em comparações, mas com um comportamento ligeiramente diferente de NFKD. Eles tratam "ç" como equivalente a "c" em comparação, mas não em todas as operações de ordenação.

👉 Clique no botão abaixo para saber mais sobre o assunto!

O MySQL também oferece a função CONVERT(col USING ascii) e o plugin ngram para full-text search, que lida com acentos de forma transparente. O preço é performance: queries com ngram são mais lentas em tabelas grandes, em torno de 30% mais lentas em testes que fiz com datasets de 5 milhões de linhas.

Erros comuns que quebram produção

O primeiro erro é confiar na codificação do banco sem validar a entrada. UTF-8 é padrão hoje, mas sistemas que migraram de Latin-1 para UTF-8 sem re os dados existentes mantêm caracteres mal formados. Um caractere corrompido em um campo de nome gera erros silenciosos em APIs REST que esperam JSON válido. O segundo erro é a substituição manual de acentos. Substituir "á" por "a" usando uma função str_replace encadeada é lento e incompleto. Existem mais de 200 formas de acentuação no português que precisam ser tratadas, incluindo combinações com til, cedilha e circunflexo. Use normalização Unicode, não listas de substituição.

O terceiro erro é a ordenação. Ordenar strings com acento de forma ingênua dá resultados errados em português. "Água" fica antes de "Banco" em ordem lexicográfica padrão, mas na ordem alfabética portuguesa correta, a cedilha e os acentos mudam a posição. Para ordenação correta, use a colação utf8mb4_pt_br_ci em MySQL ou a função COLLATE com a collation portuguesa no PostgreSQL.

Limitações que ninguém avisa

A normalização Unicode resolve 90% dos casos, mas falha em dois cenários importantes. O primeiro é com nomes próprios de fontes não padronizadas. "Joaquim da Silveira" pode ter variantes históricas de acentuação que a normalização NFC não captura porque foram escritas manualmente de forma inconsistente ao longo de décadas. O segundo é com caracteres de compatibilidade que a normalização NFKC altera sem aviso. O caractere "" (ligatura) vira "fl", mas em nomes próprios isso pode mudar a grafia oficial de uma família. Se você precisa de precisão absoluta, o caminho é manter a forma original em um campo à parte e usar a forma normalizada apenas para busca. Armazene ambos. O custo extra de armazenamento é irrelevante comparado ao risco de perder dados originais.

Também existe um limite técnico: a normalização por ASCII ignora completamente os acentos, o que é aceitável para busca mas inaceitável para exibição. Se o usuário digitou "Enfâdego", você não quer mostrar "Enfadego" na tela. A normalização é ferramenta de processamento, não de apresentação.

Checklist prático para implementação

Defina NFC como padrão de normalização na entrada. Aplique antes de qualquer persistência. Crie um índice de busca separado com a forma normalizada sem acento. Mantenha o campo original para exibição. Use colações corretas do banco para ordenação portuguesa. Valide a codificação dos dados migrados. Teste com casos reais de nomes brasileiros antes de ir para produção. Um detalhe que pouca gente menciona: o acento gráfico do português também varia por região. "Vovó" tem acento no Brasil, mas "vovó" em Portugal também tem acento. Já "para" (preposição) vs "pará" (estado) é uma distinção que a normalização sem acento apaga. Se seu sistema atende falantes de português de países diferentes, considere manter os acentos na busca primária e oferecer a forma sem acento como fallback, não como padrão.