A Ordem Do Alfabeto

O problema real da ordem alfabética

A maioria das pessoas acha que ordenar alfabeticamente é uma questão de comparar letras do A ao Z. Quando você vai implementar isso de verdade, descobre rapidamente que não é nada disso. O Unicode não define uma ordem de colação própria. Ele apenas atribui pontos de código. A ordem depende inteiramente de quem está lendo. Eu já passei meses refatorando um sistema de busca que retornava resultados completamente errados para nomes próprios hispanohablantes porque o banco de dados estava ordenando pelo code point em vez de usar colação adequada. "Chávez" ficava depois de "Cortez" em alguns servidores e antes em outros, sem aviso prévio.

Por que a ordem do alfabeto não é o que parece

O alfabeto português tem 26 letras do ISO, mas o nosso alfabeto oficial, conforme a ortografia vigente, reconhece A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z. As letras K, W e Y não pertenciam originalmente ao conjunto, mas foram incorporadas oficialmente. Isso importa porque muitos sistemas legados ainda tratam essas letras como intrusas na hora de ordenar índices de dicionário. O ponto mais importante que todo mundo erra: ordenar por code point Unicode não é ordenar alfabeticamente. É ordenar por representação binária. A diferença entre "árvore" e "arvore" pode ser zero em um sistema ingênuo ou uma separação enorme em outro, dependendo do algoritmo de colação usado.

Como funciona na prática

O padrão real é o Unicode Collation Algorithm, definido na especificação Unicode Technical Standard #10. Ele mapeia cada caractere para um ou mais pesos de colação e então compara sequencialmente. O espanhol, por exemplo, tem regras específicas para "ll" e "ñ". O dinamarquês coloca "Æ" depois de "Z". O turco tem um problema clássico com o "I": maiúscula de "i" é "İ" (com dot), não "I" (sem dot), e maiúscula de "ı" (sem dot) é "I". Você não percebe que isso existe até o sistema quebrar em produção. Na prática, você raramente implementa o UCA do zero. Você delega para a biblioteca de internacionalização da linguagem que está usando. Em Java, é o Collator com Locale específico. Em JavaScript, é o Intl.Collator. Em Python, é o icu do módulo pyicu ou o locale.strxfrm. Em SQL, é a cláusula COLLATE. Eu tive um caso concreto onde um relatório para exportação precisava listar pacientes por nome. O sistema rodava em um servidor Linux com locale C, que ordena puramente por byte. O banco de dados era PostgreSQL com collate en_US.UTF-8. A consulta direta via SQL dava ordem correta. A exportação via application layer dava ordem errada. A solução foi padronizar tudo com COLLATE "en_US.UTF-8" nas queries e definir explicitamente o Collator com locale PT_BR na camada de aplicação, removendo qualquer dependência do locale do sistema operacional.

Pegadinhas comuns

A primeira armadilha é achar que sort() da sua linguagem resolve. O sort padrão do Python, por exemplo, ordena por code point. Caracteres acentuados ficam agrupados separadamente dos não acentuados. "Ana" vem antes de "área", mas "ábaco" pode aparecer no meio de palavras que começam com "A" maiúsculo, dependendo do que mais estiver na lista. Para resolver, use o padrão de decapitação (decomposition) do Unicode primeiro, depois ordene pelos caracteres base. A segunda é a confusão entre sort e order by. Em muitos bancos relacionais, a ordem de exibição depende da collation da coluna, não da consulta. Se você criar uma tabela com collation binária, todas as consultas de ordenação herdarão esse comportamento cego, e ninguém nota até ver os dados em produção. A terceira é a suposição de que maiúsculas e minúsculas são tratadas igualmente. Em muitas configurações padrão, "Zebra" vem depois de "apple" porque letras maiúsculas têm code points menores. Usar ordenação case-insensitive deve ser explícito, não assumido.

Implementação mínima que funciona

No Python, a abordagem mais simples e razoável para português brasileiro é usar o locale apropriado ou uma biblioteca como locale-core que encapsula o comportamento do glibc. Se não puder depender do glibc, una NFD decomposition com ordenação por code points dos caracteres decompostos: Normalize para NFD. Remova ou trate diacríticos como secundários. Ordene pelos caracteres base. Preserve a formatação original na saída. Isso resolve 90% dos casos do dia a dia. Os outros 10% exigem collation específica por língua, e aí você volta para o UCA via biblioteca dedicada.

Quando tudo isso falha

Algoritmos de colação Unicode são lentos comparados a uma comparação direta de bytes. Em datasets com milhões de registros, o overhead é perceptível. Eu vi consultas que levavam 40 segundos com collation PT_BR e cair para 2 segundos com collation binary, quando a ordem exata não era requisito funcional. A decisão foi aceitar a ordem binária nos relatórios internos e reservar a ordenação linguisticamente correta apenas para telas de consulta ao usuário final, onde o número de linhas era pequeno. Também não existe uma solução única para transcrição de nomes próprios de línguas não latinas. Chinês, árabe, japonês — cada um tem suas próprias regras de mapeamento para ordenação alfabética que variam conforme a norma (pinyin para chinês simplificado, Hepburn para japonês, regras diferentes para árabe conforme o país). Tentar usar um Collator genérico para todos esses casos produz resultados aleatórios que parecem plausíveis mas estão errados.

Referência rápida de collations por idioma

Português do Brasil: pt_BR. Português de Portugal: pt_PT. As diferenças são sutis mas existem, principalmente em palavras com grafias variantes como "acta" versus "ato". Espanhol: es_ES, com tratamento especial para "ñ". Alemão: de_DE, onde "ä" pode ordenar como "ae" em algumas configurações históricas. Francês: fr_FR, com regras específicas para acentos graves e circunflexos. Turco: tr_TR, com o problema do I mencionado anteriormente. Árabe: ar_SA, com ordenação baseada no abjad, não na ordem padrão do alfabeto árabe. A regra prática é: escolha o locale no momento da criação do projeto, não no momento em que alguém reclama que a lista saiu errada. Mudar collation em tabela populada exige rebuild de índices e migração de dados. Se você pular essa etapa, vai corrigir bugs no meio de uma operação crítica e vai levar dois dias de trabalho extra.