Letra Diferente Alfabeto

Alfabetos diferentes não são só curiosidade linguística

Trabalhar com letras de outros alfabetos é mais complicado do que parece à primeira vista. A maioria das pessoas acha que basta converter caracteres e seguir em frente, mas isso raramente funciona na prática. Já perdi horas depurando um sistema de importação de dados porque alguém usou um caractere cirílico que parecia idêntico ao latino na tela, mas tinha código Unicode completamente diferente. O caractere «» (latim) e o «» (cirílico) têm a mesma aparência, mas o primeiro é U+0061 e o segundo é U+0430. Para um humano olhando, são iguais. Para um script de validação, são coisas totalmente distintas. Quando falamos de letra diferente alfabeto, estamos falando de sistemas de escrita que usam conjuntos de caracteres distintos do latino padrão. Cirílico, grego, árabe, devanágari, hebraico, hangul, georgiano, armênio e dezenas de outros coexistem no mesmo espaço digital sem problemas — desde que você entenda como o processamento deles funciona por baixo dos panos. Cada um tem suas próprias regras de direção, ligaduras, formas contextuais e mapeamentos de normalização que quebram scripts feitos para latino puro. O problema real começa quando você precisa gerar, validar ou transformar texto multialfabético. Ferramentas genéricas de regex falham. Consultas de banco de dados perdem dados. Scripts Python que usam [.a-z] para validar campos simplesmente ignoram metade dos alfabetos existentes. Um colega meu tentou fazer autocomplete em russo usando uma biblioteca que assumia byte sequences ASCII e ele passou três dias consertando isso, porque o mapeamento de encoding estava corrompendo os dados antes mesmo de chegar ao frontend.

Como lidar com alfabetos diferentes na prática

A primeira coisa que você precisa fazer é parar de tratar tudo como UTF-8 e esquecer. UTF-8 é apenas a codificação, não a solução. O que realmente importa é trabalhar com code points e normalized forms desde o início. No Python, isso significa usar strings nativas (que já são Unicode desde a versão 3), aplicar NFKC ou NFC conforme o contexto, e nunca confiar em comparações cegas de strings sem normalização prévia. Em JavaScript, o mesmo princípio se aplica, mas com a nuance adicional de que o método normalize() do String precisa ser chamado explicitamente antes de qualquer comparação ou busca. Para mapear caracteres entre alfabetos — transliteração pura —, o padrão da indústria é usar tabelas de correspondência baseadas em ISO 9:1995 ou BGN/PCGN para transliterações russas, e regras similares para outros sistemas. A biblioteca ICU (International Components for Unicode) é o que a maioria dos projetos sérios usa. Ela lida com transliteração, normalização, segmentação e ordenação lexicográfica. Instale via pip install icu ou npm install @unicode/unicode-icu, e use o transliterator diretamente. Não reinvente isso com dicionários manuais.

Problema real que enfrentei

Em 2023, lidava com um lote de registros de imigração que misturava nomes em cirílico, georgiano e armênio. O pipeline de ingestão usava uma validação baseada em regex /^[a-zA-Z\s]+$/ que rejeitava automaticamente qualquer nome contendo caracteres não-latinos. Isso significava que todo o lote era rejeitado. A solução foi substituir a validação por um check baseado em categories Unicode. Em Python: import unicodedata
def is_valid_name(name):
  return all(unicodedata.category(c)[0] in 'LMN' for c in name) Isso aceita letras de qualquer alfabeto sem precisar listar cada um manualmente. Funcionou, mas revelou outro problema: alguns caracteres têm equivalentes normais e decompostos no Unicode. O caractere «ñ» pode ser um único code point (U+00F1) ou a sequência n + tilde combinatório (U+006E U+0303). Sem normalização NFKC antes da validação, o mesmo nome podia passar ou falhar dependendo de como foi digitado. Adicionei .normalize('NFKC') no início da função e o problema foi resolvido.

Armazenamento e consulta em banco de dados

Se você está armazenando texto multialfabético, certifique-se de que o banco de dados esteja configurado com collation adequada. MySQL com collation utf8mb4_unicode_ci funciona para a maioria dos casos, mas tem limitações: não ordena cirílico corretamente, e algumas collations podem tratar caracteres decompostos de forma inconsistente. PostgreSQL com locale en_US.UTF-8 ou pt_BR.UTF-8 é mais previsível. Para ordenação verdadeiramente multilíngue, considere usar extensions como pgicu ou migrar para PostgreSQL com contrib unaccent ativado. Querys de busca também merecem atenção. Um LIKE '%mário%' não encontra 'mário' com til combinatório se o dado foi armazenado decomposto. Use COLLATE ou funções de normalização no lado do banco. No PostgreSQL, a função unaccent() remove diacríticos, mas não é perfeita para todos os alfabetos. Para aramaico ou sinagogos mais complexos, você precisará de uma abordagem manual com tabelas de equivalência.

Renderização em frontend

O maior pesadelo de quem trabalha com multialfabeto no frontend é a renderização. Fontes são o gargalo. A maioria das fontes comuns suporta apenas latino básico, grego e cirílico limitado. Se seu usuário digita em armênio e a fonte do site não tem glifos para esse script, o navegador mostra quadrados ou pontos de interrogação. A solução prática é carregar uma fonte que cubra múltiplos blocos Unicode. fonts.google.com oferece opções como Noto Sans, que cobre arabico, devanágari, cirílico, georgiano, armênio, e muitos outros em um único pacote. Também é importante configurar o atributo lang corretamente no HTML. A tag não é apenas acessibilidade — ela informa o navegador e os assistentes de entrada sobre o script esperado. Sem isso, correctores ortográficos do sistema operacional podem marcar palavras válidas como erros, e selecionadores deIME podem não alternar corretamente entre latim e outros scripts.

Ferramentas úteis

Para converter entre scripts rapidamente, o site transfercript.com permite colar texto e visualizar transliterações em dezenas de alfabetos simultaneamente. Para desenvolvedores, a tool online do ICU (demo.redd.it/icu) é útil para testar normalização e transliteração antes de implementar no código. No terminal, o comando python -c "import unicodedata; print(unicodedata.normalize('NFKC', 'texto'))" resolve a maioria dos problemas de normalização em workflows rápidos. Se você precisa de uma referência rápida de mapeamento de code points por alfabeto, a tabela oficial do Unicode Consortium (unicode.org/charts/) é a fonte primária. Não há substituto confiável para isso. Tabelas de terceiros frequentemente têm erros de mapeamento em caracteres raros ou em sequences de Combining Marks que parecem corretas mas falham em edge cases específicos. Aprendi na prática que alfabetos diferentes exigem tratamento diferente em cada camada do stack — desde a entrada do usuário até a exibição final. Ignorar isso causa falhas silenciosas que são muito mais difíceis de corrigir depois do que prevenir desde o início.