我想知道为什么我们没有一些代表Unicode字形簇的字符串而不是代码点或字符的字符串类。在我看来，在大多数应用程序中，程序员在需要时访问字形的组件比必须从代码点组织它们更容易，即使只是为了避免随意地破坏“中间字形”中的字符串，这似乎也是必要的（至少在理论上）。在内部，字符串类可能使用可变长度的编码，例如UTF-8，UTF-16，或者在这种情况下，甚至UTF-32都是可变长度的。或为所有这些子类实现子类（并可以选择在运行时配置选择，以便不同的语言可以使用它们的最佳编码）。但是，如果程序员在检查字符串时可以“看到”字素单元，就不会
Answers:
似乎获得正确性的最佳方法是阻止程序员进行“字符串黑客攻击”……编写自己的自动换行，连字符，字数统计，对正，光标移动等例程是不行的。这些天，所有现代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算法）可以看出，在字形边界处执行各种操作并不比在字符边界处进行处理更正确。
这两个规范描述了查找不同种类边界的算法：
进行文本处理涉及使用算法找到那些边界，然后使用这些边界。
如果您开始深入研究正确处理所有语言的难易程度，您会很快意识到需要一个可以查看整个段落并正确处理它们的库。Windows，Mac，Linux（Qt和GTK）和Java都具有相应的功能，例如http://site.icu-project.org/。
据我所知，不幸的是，在编写Web应用程序时，您几乎必须让浏览器（可能由OS来帮助）执行此操作。您可以使用JavaScript或在服务器端执行的所有操作将其弄乱了。
也许我可以将答案概括为：大多数对自然语言文本的字符串操作都已损坏，因此不必担心字符串类，除了可能需要一个不带任何方法的字符串类;-)