書記素に基づく文字列クラス？

コードポイントや文字ではなく、Unicode書記素クラスタの文字列を表す文字列クラスがないのはなぜでしょうか。ほとんどのアプリケーションでは、プログラマーが必要なときに書記素のコンポーネントにアクセスする方が、コードポイントからコンポーネントを整理する必要があるよりも簡単であるように思えます。 （少なくとも理論的には）。内部的に文字列クラスは、UTF-8、UTF-16などの可変長エンコーディングを使用する場合があります。この場合、UTF-32も可変長です。または、それらすべてのサブクラスを実装します（オプションで、実行時に選択肢を構成して、さまざまな言語が最適なエンコーディングを使用できるようにします）。しかし、プログラマーが文字列を検査するときに書記素ユニットを「見る」ことができれば、

正確さを得る最善の方法のように思われるのは、プログラマーが「文字列ハッキング」をしないようにすることです...独自のワードラップ、ハイフネーション、ワードカウント、位置揃え、カーソル移動などのルーチンを書くことはできません。最近のすべてのUIフレームワークでは、この作業が最近行われます。

つまり、通常使用する抽象化は、GTKなどの「段落表示オブジェクト」に近いものです。http： //library.gnome.org/devel/pango/stable/pango-Layout-Objects.html

次のような書記素文字列ではなく：http : //library.gnome.org/devel/pango/stable/pango-Glyph-Storage.html

グリフの文字列を取得するには、「ビュー」レベルでのみ利用可能な情報が必要です。そのため、文字列のほとんどの使用では、この情報がない場合があります。たとえば、フォントには異なる合字を使用できるため、フォントを知る必要があります。

この種の実用的な問題は別として、グリフはおそらく望んでいるものではありません。

多くのコンテキストでは、たとえば次のAPIに示されている適切なUnicode属性を使用する必要があります。http： //library.gnome.org/devel/pango/stable/pango-Text-Processing.html#PangoLogAttr

（Unicodeアルゴリズムを反映する）その構造体からわかるように、グリフの境界でさまざまなことを行うのは、文字の境界で行うよりも正確ではありません。

これらの2つの仕様は、さまざまな種類の境界を見つけるためのアルゴリズムを記述しています。

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

テキスト処理を行うには、これらの境界をアルゴリズムで見つけて、境界を操作する必要があります。

すべての言語を正しく処理するのがどれほど難しいかを詳しく調べ始めると、段落全体を調べて適切に処理するライブラリが必要であることがすぐにわかります。Windows、Mac、Linux（QtとGTK）、およびJavaにはすべてこのための機能が付属しており、たとえばhttp://site.icu-project.org/もあります。

残念ながら、私が知る限り、Webアプリを作成するときは、ブラウザー（おそらくOSの助けを借りている）にこれを実行させる必要があります。JavaScriptまたはサーバー側でできることは、それを台無しにすることだけです。

多分私は答えを要約すると：自然言語テキストのほとんどの文字列操作は壊れているので、おそらくメソッドのないものを除いて、文字列クラスについて心配することはあまりありません;-)