Por que quase todo mundo escreve errado usando alfabeto
A gente dá como certo o sistema de escrita alfabética porque convive com ele desde os seis anos. Na prática, entretanto, há uma distância enorme entre saber que exist e m letras e conseguir transformar um som em código gráfico sem errar feio. O problema não é a teoria. É a aplicação quando o input muda de língua. Todo sistema alfabético parte da premissa de que cada fonema se mapeia para um ou mais grafemas. A ordem alfabética que usamos no dia a dia nada mais é do que a padronização desse mapeamento para fins de indexação. Quando você abre um dicionário, uma lista telefônica ou um arquivo XML com tags alpha e beta, está consumindo o resultado desse arranjo. A confusão começa quando pensam que alfabético significa simplesmente "usar o alfabeto latino". Não é. Alfabético descreve um princípio de correspondência fonema-grafema, ponto.
Eu já precisei organizar um conjunto de grafias de nomes próprios vindos de transliterações árabes e cirílicas para um sistema que só aceitava ASCII. A regra básica do sistema de escrita alfabética dizia que a ordenação deveria refletir a fonética, não a ortografia original. Meu primeiro chute foi usar um normalizer NFKC e deixar o sort automático resolver. O resultado foi um desastre: Yegor ia para o final porque o Y era mapeado como na transcrição inicial, e Egor ficava no meio do Y. O workaround que funcionou foi criar um dicionário de equivalência fonêmica por língua de origem, aplicar uma normalização Reformed Orthodox para o cirílico e depois rodar um collation key baseado em IPA antes de any ordering. Em resumo, parei de tratar a string como texto e passei a tratá-la como sequência de sons representados graficamente. Levou uns três dias, mas economizou semanas de retrabalho manual.
Como construir um sistema de escrita alfabética que não quebre
O passo zero é decidir qual nível de abstração você vai operar. Gráficos, fonemas ou ambos. Se o sistema vai lidar apenas com português padrão, dá para furar a olho usando a tabela ASCII estendida com acentos. Se vai expor o sistema de escrita alfabética a línguas com morfologia não latina, aí precisa de uma camada intermediária. Eu uso um modelo de duas camadas: uma de normalização (NFC + M+N) e outra de mapeamento fonêmico com regras específicas por locale. Na normalização, o cuidado é com os dígrafos e grafemas compostos. NH, LH, AM, ÃO não são sequências arbitrárias; são unidades fonêmicas. Tratá-las como letras separadas quebra a ordenação em qualquer índice que dependa de prefixo. A solução prática é transformar essas sequências em um único token durante a indexação, usando uma tabela de substituição que respeita o Unicode Standard Annex #29 para segmentação de grafemas.
Para a ordenação em si, fuja de strcmp puro. Use a API strcoll com o locale correto, ou, se for construir seu próprio motor, implemente um locale-aware collator seguindo a especificação Unicode UTS #10. O resultado costuma ser uma diferença de performance pequena — alguns milissegundos a mais no worst case — mas elimina a maior parte dos bugs de ordenação que aparecem quando volumes de dados crescem. Um detalhe que quase ninguém considera: a ordem alfabética não é universal. O diaerese em alemão (Ö) e o ß têm regras específicas que mudam a colação. O finlandês trata Ä e Ö como letras próprias no final do alfabeto, não como variantes de A e O. Se seu sistema de escrita alfabética precisa suportar esses casos, a única opção viável é delegar a colação para a biblioteca do sistema operacional ou para o ICU (International Components for Unicode). Tentar recriar essas regras manualmente é perder tempo que você não tem.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros comuns que eu vejo repetindo em projetos reais
O primeiro erro crasso é confundir codificação com alfabetização. Ter um banco de dados UTF-8 não resolve nada se o motor de busca ou a consulta SQL estiver usando BINARY collation. Eu já vi sistemas inteiros quebrarem porque alguém mudou o collation de uma coluna sem ajustar as views que dependiam dela. A correção foi refazer o índices com utf8mb4_unicode_ci e rodar um ptvsr de integridade em todas as tabelas textuais. O segundo erro é tratar caracteres diacríticos como opcionais na indexação. Removeu-os na normalização? A palavra pêra vai se confundir com pera em qualquer busca exata. Isso não é um problema de estética, é um problema de recall. O índice perde palavras inteiras sem aviso. A solução que eu adoto é manter duas versões da string: uma normalizada para exibição e outra com acentos preservados para indexação. A chave primária de pesquisa sempre passa pela versão acentuada.
Um caso limite que vale a pena citar: sistemas que precisam ordenar sobrenomes com partículas (van, von, de, da, del). A regra ingênua é ordenar pela primeira palavra, o que espalha Rembrandt van Rijn longe de Vincent van Gogh porque o motor vê o "R" de Rijn como chave. A prática correta, quando o domínio permite, é normalizar partículas para minúsculas e considerar a ordem léxica do núcleo do sobrenome. Eu fiz isso em um projeto editorial e o ganho foi real: a busca por "Van" passou a encontrar todos os registros relevantes em vez de dividir o conjunto em dois buckets semânticos.
Limitações que ninguém anuncia
O sistema de escrita alfabética funciona bem quando o mapeamento fonema-grafema é consistente. Línguas como o espanhol e o finlandês são relativamente previsíveis. O inglês e o vietnamita são pesadelos se você depender apenas da superfície ortográfica. No vietnamita, por exemplo, a mesma letra D representa dois fonemas distintos dependendo do dialeto, e a tonicidade é marcada por diacríticos que alteram a ordenação. Se seu sistema exige ordenação alfabética rigorosa em vietnamita, esqueça soluções genéricas e construa um collator customizado com base nas regras da ABNT NBR 12506 adaptadas para o idioma. Outra limitação prática: sistemas alfabéticos puros não lidam bem com escribas logográficos misturados. Chinês, japonês e coreano introduzem caracteres que não se encaixam no modelo fonema-grafema. A solução padrão do mercado é usar o Wade-Giles ou Pinyin para chinês, Hepburn para japonês, e o sistema nacional coreano para hangul. Mas essas transliterações são aproximativas. Você perde nuances e ganha ambiguidade. Quando o volume de dados em scripts logográficos é grande, a ordenação alfabética puramente Latin-based fica impraticável. Nesses casos, o caminho mais sensato é manter a ordenação nativa do script e usar a forma latinizada apenas como fallback para interfaces ocidentais.
Se você está começando um projeto do zero, não tente reinventar a colação. Use o ICU, ajuste os níveis de personalização conforme seu locale, e reserve o tempo que economizou para tratar os casos borda que nenhuma biblioteca cobre. A diferença entre um sistema que funciona e um que dá trabalho constante está exatamente aí: nos dez por cento que a teoria bonitinha do sistema de escrita alfabética esquece de mencionar.
