Klasa ciągów oparta na wykresach?

Zastanawiam się, dlaczego nie mamy niektórych klas łańcuchów reprezentujących ciąg klastrów grafem Unicode zamiast punktów kodowych lub znaków. Wydaje mi się, że w większości aplikacji programiści mieliby łatwiej uzyskać dostęp do komponentów grafem, gdy jest to konieczne, niż musieliby je organizować z punktów kodowych, co wydaje się konieczne, nawet jeśli tylko po to, by uniknąć przypadkowego zerwania łańcucha w „środkowym grafem” (przynajmniej w teorii). Wewnętrznie klasa łańcuchowa może wykorzystywać kodowanie o zmiennej długości, takie jak UTF-8, UTF-16, lub w tym kontekście nawet UTF-32 ma zmienną długość; lub zaimplementuj podklasy dla wszystkich z nich (i opcjonalnie skonfiguruj wybór w czasie wykonywania, aby różne języki mogły korzystać z ich optymalnego kodowania). Ale jeśli programiści mogliby „zobaczyć” jednostki wykresu podczas sprawdzania łańcucha, nie zrobiliby tego

Wydaje się, że najlepszym sposobem na uzyskanie poprawności jest powstrzymanie programistów przed robieniem „hakowania ciągów znaków” ... pisanie własnych zawijanych słów, dzielenia wyrazów, liczenia słów, justowania, przesuwania kursora itp. Nie jest w porządku. Wszystkie współczesne frameworki interfejsu użytkownika będą teraz robić to za Ciebie.

Oznacza to, że abstrakcja, z którą zwykle pracujesz, jest bardziej „akapitowym obiektem wyświetlanym”, takim jak GTK: http://library.gnome.org/devel/pango/stable/pango-Layout-Objects.html

zamiast ciągu grafemu, takiego jak: http://library.gnome.org/devel/pango/stable/pango-Glyph-Storage.html

Aby dostać się do ciągu glifów, potrzebujesz informacji, które są dostępne tylko na poziomie „widoku”, więc większość zastosowań ciągów może nie mieć tych informacji. Na przykład musisz znać czcionkę, ponieważ czcionki mogą mieć różne ligatury.

Oprócz tego rodzaju praktycznych kwestii, glify prawdopodobnie nie są tym, czego chcesz.

W wielu kontekstach chcesz używać odpowiednich atrybutów Unicode, pokazanych w tym interfejsie API, na przykład: http://library.gnome.org/devel/pango/stable/pango-Text-Processing.html#PangoLogAttr

Jak widać z tej struktury (która odzwierciedla algorytmy Unicode), robienie różnych rzeczy na granicach glifów nie jest bardziej poprawne niż robienie ich na granicach znaków.

Te dwie specyfikacje opisują algorytmy do znajdowania różnych rodzajów granic:

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

Przetwarzanie tekstu polega na znalezieniu granic za pomocą algorytmów, a następnie pracy z granicami.

Jeśli zaczniesz kopać, jak trudno jest poprawnie obsługiwać wszystkie języki, bardzo szybko zdasz sobie sprawę, że potrzebujesz biblioteki, która przegląda całe akapity i odpowiednio je obsługuje. Windows, Mac, Linux (Qt i GTK) i Java są wyposażone w odpowiednie do tego funkcje, a na przykład jest http://site.icu-project.org/ .

O ile wiem, pisząc aplikacje internetowe, musisz niestety pozwolić przeglądarce (prawdopodobnie wspieranej przez system operacyjny) wykonać te czynności. Wszystko, co możesz zrobić w JavaScript lub po stronie serwera, to zepsuć.

Może podsumowałbym odpowiedź jako: większość manipulacji ciągami tekstowymi w języku naturalnym jest zepsuta, więc nie ma sensu martwić się klasą ciągów, poza tym, że nie ma takiej metody ;-)