Colocar letras maiúsculas com acento corretamente em sistemas modernos
Depois de anos lidando com normalização de texto em processos de integração e limpeza de dados, posso dizer que o tratamento de maiúsculas acentuadas ainda gera erros recorrentes em campos que são tratados como ASCII puro. O problema não é apenas visual — o acento errado ou ausente quebra indexes de banco, comparações case-insensitive e consultas SQL com COLLATE. A questão básica é simples: o maiúsculo com acento existe na norma Unicode e no padrão de capitalização brasileiro (ABNT NBR 10.524), mas muitos ferramentas simplesmente ignoram isso. Vou explicar como fazer funcionar na prática, porque a teoria já está em qualquer manual.
O maiusculo com acento e o que dá errado no dia a dia
Quando você aplica toUpperCase() em uma string com "São Paulo", "ônibus" ou "juízo", o resultado esperado deveria ser "SÃO PAULO", "ÔNIBUS", "JUÍZO". Em Python, Java e Cisso funciona bem. Em JavaScript, por padrão, também funciona para a maioria dos casos. O problema aparece quando o código passa por normalizações que perdem os acentos antes de aplicar a capitalização, ou quando o sistema converte tudo para ASCII usando um transliterador mal configurado. Aí você termina com "SAO PAULO", "ONIBUS", "JUIZO". No meu caso, encontrei um problema específico em um processamento de notas fiscais eletrônicas onde um serviço de terceiros fazia a normalização do CNPJ e do nome da empresa para uppercase antes de salvar. O nome "Indústria Brasileira" virava "INDUSTRIA BRASILEIRA". Como o campo era indexado sem acento e a consulta de busca também ia sem acento, tudo funcionava na prática. Mas quando precisei validar a correspondência exata entre o documento original e o registro, o strcmp falhava silenciosamente. A correção foi forçar a desativação da normalização de acentos nessa etapa e aplicar o uppercase diretamente, respeitando o alfabeto da língua portuguesa com seus acentos corretos.
A solução técnica mais robusta depende da linguagem e do nível de controle que você precisa. Abaixo mostro os passos práticos.
Como garantir maiúsculas acentuadas corretas em diferentes contextos
Em Python
O método .upper() já respeita os acentos. Para normalização, use unicodedata.normalize('NFC', texto) antes de qualquer operação. Se precisar garantir consistência em um lote grande, recomendo um pipeline que normaliza para NFC primeiro, depois aplica uppercase, depois NFKC apenas se for fazer matching estrito. Isso evita que combinações de caracteres compostos se quebrem em sílabas separadas durante a conversão.
Em JavaScript/Node.js
O .toUpperCase() nativo funciona para a maioria dos acentos latinos. O problema real aparece em strings com caracteres que têm variantes de ligações, como o "" ou em textos que vieram de fontes com grafias alternativas. Use Intl.Locale e .normalize('NFC') quando a entrada for imprevisível, especialmente se os dados vêm de scraping ou de uploads de documentos.
Em bancos de dados
Se você usa PostgreSQL, o UPPER() preserva acentos. O COLLATE pt_BR.UTF-8 lida corretamente com comparações que incluem letras acentuadas. Em MySQL, o problema é mais frequente: versões mais antigas com charset latin1 ou utf8 (não UTF-8mb4) truncavam ou corrompiam caracteres acentuados. A recomendação é migrar para utf8mb4 e usar COLLATE utf8mb4_general_ci, que mantém os acentos nas conversões.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Em planilhas e exportações
O Excel converte maiúsculas com acento de forma inconsistente em versões mais antigas. Se você estiver usando fórmulas como =MAIÚSCULA() e notar perda de acento, verifique o regional do sistema operacional e o charset da fonte de dados. Em muitos casos, copiar o conteúdo diretamente de uma tabela Unicode resolvia. A alternativa segura é exportar como CSV UTF-8 e reprocessar os campos com um script.
Pegadinhas comuns que você vai encontrar
A primeira é a confusão entre normalização NFC e NFKC. NFC mantém as formas compostas — "á" continua sendo um único código. NFKC decompõe em "a" + combining acute. Se seu sistema de busca usa NFKC sem ajustar o indexador, palavras como "café" podem ser tratadas como "caf" + acento separado, quebrando o ranking desimilaridade. A segunda é a suposição de que uppercase é idempotente. Nem sempre é. Caracteres como a letras germânicas "ß" (eszett) se convertem para "SS" em uppercase, não "ß". Em português não é o problema principal, mas se seu sistema aceita multilíngue, isso gera campos duplicados e perda de correspondência em relatórios cruzados.
Outro ponto: ferramentas de limpeza que removem acentos antes de normalizar estão erradas para o contexto brasileiro, mas continuam muito presentes em código legado. Se você herda um sistema assim, a saída mais rápida é manter os acentos, aplicar uppercase, e só remover acentos em campos que realmente precisam de key de busca simplificada. Nunca remova acentos em campos que são identificador único — a menos que ambos os lados do matching estejam consistentemente sem acento.
Como testar se sua implementação está correta
Crie um conjunto de validação com palavras que cobrem todos os acentos do português em maiúsculas: "ÁEVORA", "ÍDOLO", "ÔMEDA", "ÚLTIMO", "ÇAÇAPAVA", "AMOR IMPERATIVO", "GIRO", "SÃO". Aplique seu pipeline e verifique se o output mantém a letra original acentuada e maiúscula. Se algum item saír alterado de forma inesperada, o gargalo está na camada de normalização anterior ao uppercase, não no próprio método de capitalização. Para produção, recomendo expor uma rotina de teste automatizado que rode em cada deploy, comparando a entrada e a saída com o esperado. Leva cerca de 10 minutos para configurar e evita que regressões entrem no pipeline de dados. Em ambientes que já sofrem com inconsistência de caracteres, o custo de não testar esse trecho costuma ser muito maior do que o tempo gasto na validação.
Alternativas quando o native não basta
Se seu sistema exige controle fino sobre o mapeamento de caracteres — por exemplo, você precisa tratar "é" como igual a "e" apenas em chaves de pesquisa, mas preservar a forma acentuada na exibição — considere manter duas colunas: uma normalizada para busca e outra com a forma canônica. Isso é padrão em sistemas de indexação sérios e evita gambiarras de regex ou transliteração manual. Existem bibliotecas específicas para normalização avançada, como a ICU (International Components for Unicode), que oferecem controle completo sobre transformações de case, decomposição e composição. Recomendo se você estiver lidando com dados vindos de múltiplas fontes e regiões.
O manejo de maiúsculas com acento não é um detalhe cosmético. Errar esse passo gera inconsistência em relatórios, falhas em matching e dor de cabeça operacional que persiste por anos se não for corrigido na raiz. Trate como parte obrigatória da limpeza e padronização, não como um ajuste final dispensável.
