Separar letras do alfabeto não é só dividir um texto em caracteres
A maioria das pessoas acha que separar letras é pegar uma string e transformar cada caractere num elemento individual. Isso é verdade, mas a parte que ninguém conta é que o resultado depende inteiramente do que você faz depois disso. Se o objetivo é só visualização, um loop simples resolve. Se é processamento de dados, análise estatística ou até manipulação para Machine Learning, aí a coisa muda de figura rapidamente. Eu passei semanas tentando otimizar um pipeline que separava letras de textos em português para um modelo de classificação de idiomas. O problema era mais simples do que parecia no começo, mas trouxe consequências que eu não esperava. O código que eu tinha initially usava uma expressão regular básica e ia bem até eu testar com textos que continham acentos, cedilhas e ligaturas como o "æ". O separador simplesmente ignorava esses caracteres ou os tratava como ruído, o que distorcia completamente a contagem final de frequência. A solução foi usar Array.from() com o suporte nativo a Unicode, o que fez o script passar de 3 segundos para 40 milissegundos no mesmo arquivo de 2MB.
Como funcionam separadas letras do alfabeto na prática
O conceito em si é direto. Você pega uma sequência de texto e isola cada unidade alfabética individualmente. Em JavaScript, por exemplo, a maneira mais confiável hoje em dia é: const letras = Array.from(texto);
Espera-se que isso gere um array com cada caractere como um item separado. O problema é que String.prototype.split('') também funciona na maior parte dos casos, mas quebra com emojis, caracteres compostos e grafemas que o JavaScript trata como surrogate pairs. Se o seu texto contém apenas ASCII puro, tanto faz qual método usar. Se contém qualquer coisa além, o Array.from ou o spread operator [...texto] são mais seguros. Um detalhe que muita gente deixa passar é a diferença entre código points e grapheme clusters. Um caractere como "ã" pode ser representado como um único code point (U+00E3) ou como uma combinação de "a" mais um acento til (U+0061 + U+0303). O segundo caso, chamado de decomposição canônica, faz com que sua contagem de letras fique errada se você não normalizar o texto primeiro com normalize('NFC').
No meu caso, eu precisava contar a frequência exata de cada letra do alfabeto português em um corpus de 15GB de texto extraído da web. A abordagem ingênua de apenas iterar sobre os caracteres gerou um resultado completamente diferente do esperado quando comparamos com a frequência oficial da língua portuguesa. A razão era exatamente essa: muitos documentos continham caracteres pré-compostos que, sem normalização, eram tratados como letras diferentes ou perdidos na contagem. Depois de adicionar a normalização NFC antes do processo de separação, a precisão subiu para algo em torno de 99,7%, que é muito próximo do valor esperado. Em Python, o cenário é similar, mas com uma particularidade a mais. A função list(texto) já faz a separação por code points corretamente, mas para grapheme clusters você precisa recorrer à biblioteca regex com o flag \X, que reconhece clusters de grafema inteiros. Isso é útil quando você lida com textos que incluem diacríticos combinatórios vindos de fontes OCR ou de transcrições antigas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que vale a pena mencionar é a questão do desempenho. Para textos pequenos, até 10 mil caracteres, a diferença entre métodos é insignificante. Acima disso, você começa a notar diferenças reais. Num teste que fiz com um corpus de 50MB, o método com normalização Unicode levou cerca de 8 segundos, enquanto uma versão sem normalização e usando split ficou em 2,3 segundos. O trade-off entre velocidade e correção precisa ser avaliado caso a caso. Se o seu objetivo é apenas exibir letras separadas numa interface gráfica, como um jogo de forca ou um gerador de senhas, não há motivo para complicar. Um simple split('') ou spread operator resolve sem dor de cabeça. Mas se você está construindo algo que precisa de precisão linguística — análise de frequência, tokenização para NLP, ou até validação de senhas baseada em regra de composição de caracteres — então investir tempo na normalização e na escolha correta do método de separação vale a pena.
O que acontece quando você ignora a normalização Unicode
Existem situações em que letras parecidas visualmente são tratadas como código points diferentes. O caractere "é" pode ser U+00E9 (pré-composto) ou U+0065 + U+0301 (decomposto). Na prática, ambas as formas representam a mesma letra, mas um algoritmo ingênuo vai contar como dois elementos distintos. Isso gera um ruído silencioso que não aparece em testes simples, mas que estraga totalmente a qualidade dos dados quando o volume aumenta. Se você trabalha com dados de múltiplas fontes — arquivos vindos de scanners, exports de diferentes sistemas, textos digitados manualmente — é quase certo que terá uma mistura de formas pré-compostas e decompostas. Normalizar tudo para NFC antes de qualquer processamento é o passo que mais evita dor de cabeça. É rápido, é padrão da indústria, e leva menos de 1% do tempo total do processamento em datasets grandes.
Além disso, é bom saber que existem outros níveis de normalização. O NFC é o mais comum, mas o NFD (decomposição canônica) às vezes é útil quando você quer analisar especificamente os componentes de um caractere, como separar uma letra base dos seus diacríticos para fins de pesquisa morfossintática. O contexto define qual caminho escolher.
Alternativas e quando elas falham
Para quem não precisa de precisão extrema, bibliotecas como lodash ou até funções nativas de split com expressões regulares simples podem bastar. Mas saiba que expressões como /[a-zA-Z]/g filtram apenas letras latinasASCII, o que descarta completamente letras acentuadas, grafias como ñ, ç, þ, Ƿ, e praticamente qualquer outro caractere alfabético que não seja do inglês. Isso pode parecer óbvio, mas já vi projeto inteiro sendo comprometido por esse tipo de filtro aplicado sem crítica. Em resumo, separar letras parece trivial até o momento em que você precisa que o resultado seja confiável. O caminho mais seguro passa por normalização Unicode, escolha adequada do método de iteração e entendimento claro do que exatamente você espera obter no final. Fora isso, o resto é ajuste fino de performance conforme o volume de dados.
