Classe de string baseada em grafemas?

Eu estou querendo saber por que não temos algumas classes de string que representam uma string de clusters de grafema Unicode em vez de pontos ou caracteres de código. Parece-me que, na maioria das aplicações, seria mais fácil para os programadores acessar componentes de um grafema quando necessário do que ter que organizá-los a partir de pontos de código, o que parece necessário mesmo que apenas para evitar a quebra caseira de uma string no "grafema intermediário" (pelo menos em teoria). Internamente, uma classe de cadeia de caracteres pode usar uma codificação de comprimento variável, como UTF-8, UTF-16, ou, neste contexto, até UTF-32 possui comprimento variável; ou implemente subclasses para todas elas (e, opcionalmente, configure a opção em tempo de execução para que idiomas diferentes possam usar suas codificações ideais). Mas se os programadores pudessem "ver" unidades de grafema ao inspecionar uma string, eles não

Parece que a melhor maneira de obter correção é impedir que os programadores façam "hackers de cordas" ... simplesmente não é bom escrever suas próprias rotinas de quebra de linha, hifenização, contagem de palavras, justificativa, movimento do cursor etc. Atualmente, todas as estruturas modernas de interface do usuário farão isso por você.

Ou seja, a abstração com a qual você costuma trabalhar é mais um "objeto de exibição de parágrafo", como no GTK: http://library.gnome.org/devel/pango/stable/pango-Layout-Objects.html

em vez de uma sequência de grafemas, como: http://library.gnome.org/devel/pango/stable/pango-Glyph-Storage.html

Para acessar uma sequência de glifos, você precisa de informações disponíveis apenas no nível "visualizar", portanto, a maioria dos usos de sequências de caracteres pode não ter essas informações. Por exemplo, você precisa conhecer a fonte, porque as fontes podem ter diferentes ligaduras.

Além desse tipo de questão prática, os glifos provavelmente não são o que você deseja.

Em muitos contextos, você deseja usar os atributos Unicode adequados, mostrados nesta API, por exemplo: http://library.gnome.org/devel/pango/stable/pango-Text-Processing.html#PangoLogAttr

Como você pode ver nessa estrutura (que reflete os algoritmos Unicode), fazer várias coisas nos limites do glifo não é mais correto do que fazê-lo nos limites dos caracteres.

Essas duas especificações descrevem os algoritmos para encontrar diferentes tipos de limites:

• http://www.unicode.org/reports/tr14/
• http://www.unicode.org/reports/tr29/

Fazer o processamento de texto envolve encontrar esses limites com os algoritmos e depois trabalhar com os limites.

Se você começar a descobrir o quão difícil é lidar com todos os idiomas corretamente, perceberá rapidamente que precisa de uma biblioteca que analise parágrafos inteiros e os lide adequadamente. Windows, Mac, Linux (Qt e GTK) e Java são fornecidos com facilidades para isso, além de http://site.icu-project.org/, por exemplo.

Ao escrever aplicativos da web, infelizmente você praticamente precisa deixar o navegador (provavelmente ajudado pelo sistema operacional) fazer essas coisas, até onde eu sei. Tudo o que você pode fazer em JavaScript ou no lado do servidor é estragar tudo.

Talvez eu resumisse a resposta da seguinte maneira: a maioria das manipulações de strings no texto em linguagem natural é interrompida; portanto, não faz muito sentido se preocupar com a classe de strings, além de talvez ter um sem métodos ;-)