O dilema chapéu ou chapeu que ninguém resolve de verdade
A pergunta parece boba até você tentar colocar um campo com esse nome num banco de dados, gerar uma URL amigável ou exportar um arquivo CSV para um sistema legado. A diferença entre chapéu e chapeu não é só estética. É uma questão que quebra scripts, confunde filtros e gera tickets de suporte que ninguém quer abrir.
chapéu ou chapeu — o que a norma realmente diz
A ortografia oficial do português exige o acento circunflexo em chapéu. O vocábulo vem do gótico hopja, passando pelo latim tardio, e o acento marca o fechado da vogal tônica. Sem ele, fica chapeu, que é uma forma errada segundo o Acordo Ortográfico de 1990 e o Vocabulário Ortográfico da Língua Portuguesa (VOLP) do Dicionário Priberam. Ou seja, se o texto é formal, vai com acento. Sem discussion. Mas aí mora o problema. O mundo digital não segue norma ortográfica. Ele segue encodificação, collation e limitações de input que você não escolheu.
Onde a coisa trav na prática
Eu já passei por isso três vezes em projetos diferentes. A primeira foi quando o time de marketing criou uma página de produto chamada /chapeu-solar no CMS. O SEO técnico gerava sitemaps com essa URL e, quando migramos para um novo ambiente, o novo servidor tinha um collation diferente e tudo que vinha com acento ia para uma caixa de procura inválida. O link era 404. Isso aconteceu em um domingo à tarde, não é brincadeira. A segunda situação foi com um script Python que lia arquivos CSV vindos de um ERP europeu. Alguns registros vinham com chapéu e outros com chapeu porque o ERP tinha sido configurado num período de transição pós-acordo ortográfico. Eu Passei cerca de 45 minutos depurando uma query SQL que simplesmente não encontrava os registros acentuados, porque a comparação era case-sensitive e a coluna usava Latin1 em vez de UTF8.
A terceira, e essa é a mais irritante: uma API de terceiros que normaliza strings removendo acentos automaticamente antes de processar. Você passa chapéu, ela trata como chapeu. Seu banco de dados guarda a forma original, a API consulta a forma normalizada e, quando você tenta cruzar os dois, nada bater.
Solução prática para o dia a dia
A maioria dos casos pode ser resolvida com duas camadas: normalização consistente e padronização de input. No lado técnico, eu recomendo aplicar Unicode Normalization Form NFC (Compose) nos dados de entrada antes de escrever no banco. Isso garante que o caractere U+00E9, por exemplo, sempre apareça como é único e não como sequência decomposta. Se você trabalha com Python, o módulo unicodedata resolve isso em duas linhas:
👉 Clique no botão abaixo para saber mais sobre o assunto!
import unicodedata
valor_normalizado = unicodedata.normalize("NFC", texto_original) No lado do banco de dados, verifique o collation. Em PostgreSQL, a extensão unaccent permite consultas que ignoram acentos de forma controlada. Em MySQL, o collation UTF8MB4_general_ci já é tolerante a acentos em comparações, mas ainda assim você pode ter divergências entre INSERTs de sistemas diferentes. O ideal é forçar o mesmo charset em todas as conexões e não confiar no charset padrão do servidor.
Para URLs, use slugs normalizados. Transforme chapéu em chapeu no momento da geração do slug e guarde essa versão canonica em uma coluna separada. Assim, o SEO não perde o acento no
O que não funciona e por que você deve evitar
Não adianta simplesmente trocar o acento em todos os lugares e esperar que o sistema se ajuste. Já vi times adotarem a estratégia de sempre remover acentos de tudo, argumentando que simplifica a vida. Funciona até você precisar apresentar um relatório formal, imprimir uma etiqueta ou integrar com um órgão público que exige a grafia correta. Aí o sistema que você "simplificou" vira um problema de compliance e retrabalho. Também não recomendo confiar em regex para detectar variações. Expressões como [cç]hapede[êéè] funcionam para casos isolados, mas quebram quando o texto vem de OCR, de user-generated content ou de sistemas que usam codificação problemática. Você vai gastar mais tempo afinando a regex do que resolviendo a causa raiz, que é quase sempre o charset ou o collation.
Quando vale a pena aceitar a variação
Existe um cenário em que chapéu ou chapeu virar assunto interno sem grande impacto: bases de dados históricas que não podem ser reescritas e cujo legado já está estabilizado. Nesse caso, eu sugiro criar uma camada de abstração com mapeamento de sinônimos. Uma tabela simples que relaciona as duas formas e resolve buscas de forma transparente. Custa horas de trabalho inicial e economiza dias de dor de cabeça posterior. Outro ponto: se você está desenvolvendo para um público que digita em teclados sem acentos fáceis, como alguns layouts internacionais, a forma sem acento pode ser um fallback aceitável desde que o sistema traga a forma acentuada na exibição final. Isso é comum em campos de busca onde o usuário final não se importa com a grafima, só quer encontrar o produto.
Resumo do que eu faço antes de virar problema
Na minha experiência, o checklist mínimo é: padronizar o charset de entrada e saída para UTF8, aplicar NFC nos strings antes de persistir, decidir se a URL será a forma canonizada sem acento, documentar essa decisão e garantir que o collation do banco suporte ocharset escolhido. Fazer isso no início do projeto corta em cerca de 80% os tickets relacionados a caracteres especiais que costumam aparecer nos meses seguintes. O custo é baixo e o risco de esquecer algum desses passos é alto, então escreva em algum lugar visível. Senão, alguém vai reclamar de um link quebrado numa segunda-feira pela manhã.