Kelas string berdasarkan pada grapheme?

Saya bertanya-tanya mengapa kita tidak memiliki beberapa kelas string yang mewakili string cluster graphode Unicode alih-alih poin kode atau karakter. Tampak bagi saya bahwa dalam sebagian besar aplikasi akan lebih mudah bagi programmer untuk mengakses komponen dari suatu grapheme ketika diperlukan daripada harus mengatur mereka dari titik kode, yang tampaknya perlu bahkan jika hanya untuk menghindari dengan santai memecahkan string dalam "mid-grapheme" (setidaknya dalam teori). Secara internal kelas string mungkin menggunakan pengkodean panjang variabel seperti UTF-8, UTF-16, atau dalam konteks ini bahkan UTF-32 adalah panjang variabel; atau mengimplementasikan subclass untuk semuanya (dan secara opsional mengkonfigurasi pilihan pada saat run-time sehingga bahasa yang berbeda dapat menggunakan penyandian optimal mereka). Tetapi jika programmer dapat "melihat" unit grapheme ketika memeriksa sebuah string, bukankah

Sepertinya cara terbaik untuk mendapatkan kebenaran adalah untuk menjaga programmer dari melakukan "peretasan string" ... itu tidak apa-apa untuk menulis bungkus kata Anda sendiri, tanda hubung, jumlah kata, pembenaran, gerakan kursor, dll rutinitas. Semua kerangka kerja UI modern akan melakukan hal ini untuk Anda hari ini.

Artinya, abstraksi yang biasa Anda kerjakan adalah lebih dari "objek tampilan paragraf," seperti untuk GTK: http://library.gnome.org/devel/pango/stable/pango-Layout-Objects.html

daripada string grapheme, seperti: http://library.gnome.org/devel/pango/stable/pango-Glyph-Storage.html

Untuk mendapatkan string mesin terbang, Anda memerlukan info yang hanya tersedia di level "view", jadi sebagian besar penggunaan string mungkin tidak memiliki info ini. Misalnya, Anda harus mengetahui font, karena font dapat memiliki ligatur yang berbeda.

Selain hal-hal praktis semacam itu, mesin terbang mungkin bukan yang Anda inginkan.

Dalam banyak konteks, Anda ingin menggunakan atribut Unicode yang tepat, yang ditunjukkan dalam API ini misalnya: http://library.gnome.org/devel/pango/stable/pango-Text-Processing.html#PangoLogAttr

Seperti yang dapat Anda lihat dari struct itu (yang mencerminkan algoritma Unicode) melakukan berbagai hal pada batas-batas mesin terbang tidak lebih benar daripada melakukannya pada batas karakter.

Dua spesifikasi ini menjelaskan algoritma untuk menemukan berbagai jenis batasan:

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

Melakukan pemrosesan teks melibatkan menemukan batas-batas tersebut dengan algoritma dan kemudian bekerja dengan batas-batas tersebut.

Jika Anda mulai menggali betapa sulitnya menangani semua bahasa dengan benar, Anda akan segera menyadari bahwa Anda memerlukan perpustakaan yang melihat seluruh paragraf dan menanganinya dengan benar. Windows, Mac, Linux (Qt dan GTK), dan Java semua dilengkapi dengan fasilitas untuk ini, ditambah ada http://site.icu-project.org/ misalnya.

Saat menulis aplikasi web, sayangnya Anda cukup banyak harus membiarkan browser (mungkin dibantu oleh OS) melakukan hal ini, sejauh yang saya tahu. Yang dapat Anda lakukan dalam JavaScript atau di sisi server adalah mengacaukannya.

Mungkin saya akan meringkas jawabannya sebagai: sebagian besar manipulasi string pada teks bahasa alami rusak, jadi tidak banyak gunanya mengkhawatirkan kelas string, selain mungkin memiliki satu tanpa metode di atasnya ;-)