问题标签 [grapheme]

任何想法，如果可以使用正则表达式（python 2.7）将uniq chars unspitted 成unicode graphemes 的代理对？

根据此示例，这可以通过 python 3.x 实现。看这里：

但对于 python 2.7，它似乎不起作用。参见示例：

任何想法如何使它适用于python 2.7？=））））

提前谢谢你！！！=）

在 C#中StringInfo，TextElementEnumerator类为文本元素提供方法和属性。在这里，我们可以找到Text Element的定义。

.NET Framework 将文本元素定义为显示为单个字符的文本单元，即字形。文本元素可以是以下任何一种：

是的，它说文本元素是 .NET 中的字形。我自己也测试了一些 unicode 字符，直到我测试了一个韩文字母 ' 가 '之前，这似乎是真的。

众所周知，一些 Unicode 字符由多个代码点组成。我们也可能面临代码点序列，这就是我使用StringInfo而TextElementEnumerator不是简单的原因String。

StringInfo并且TextElementEnumerator可以判断Chars 是否是正确的代理对。并且“\u0061\u0308”，一个由多个代码点组成的Unicode字符，正如预期的那样被识别为一个文本元素。但是对于“\u1100\u1161”，它没有说它也是一个文本元素。

“\u1100”是前导字母“ㄱ”，“\u1161”是元音字母“ㅏ”。它们可以是单独的字符并显示给用户，就像我在这里写的那样，你现在可以看到它们。但是如果它们一起使用，它们会被渲染为一个字符“가”而不是“ㄱㅏ”。

有两种方法可以表示韩文字符“가”：

1. 使用来自Hangul Syllable的单个代码点U+AC00。
2. 使用Jamo中的两个代码点U+1100和U+1161。

大多数时候使用前者。后者很少使用，说实话，我根本无法想象它什么时候使用.. 反正第一个只是一个预先组合的字母，第二个是一个被视为一个字符的Lead和Vowel的序列。渲染时，它们看起来完全相同，实际上两者在规范上是等效的。以下行在 C# 中也返回 true：

我想知道为什么Normalize()当 C# 认为它们不是一个完整的文本元素时，这里工作得很好。我认为这与我的 .NET 版本有关，但事实并非如此。即使在 Mono 中也会发生这种情况。

我也对此进行了测试，它可以正确地ICU将“\u1100\u1161”视为一个字形！我最初认为并且可以在一些简单的情况下消除对ICU4C的需求，所以我现在非常失望..StringInfoTextElementEnumerator

这是我的问题：

我在这里做错了吗？

或者

.NET 中的文本元素与 ICU 不同，不是用户感知的字符吗？

首先，我使用 Python 3字形库来解决我的问题。（有关字素的更多信息，请参阅这篇文章）。但令我惊讶的是，如果没有专门的库，Python 3 就无法做到这一点……

我求助于字素是因为在多次网络搜索和阅读StackOverflow问题之后，我无法让 Python 3在一系列泰语字符中返回正确数量的字符位置。

例如，这是一个 UTF-8 泰语字符串：

我使用术语字符位置来标识一行/字符串泰语字符中的单个位置。这是因为一个字符位置可能由一个泰语辅音加上，在某些情况下，该辅音上方或下方的元音或声调标记组成。辅音加上元音或音调标记上方/下方占据 Unicode 字符串中的单个字符位置。（一些泰语辅音也可能在其左侧、右侧或两者都有元音。这些元音占据它们自己的字符位置。）

例如，在从示例字符串生成的以下序列中，项目 2 和 7 是元音，项目 10 是音调标记。每个都使用 UTF-8 字符串中的单独字节，但不占用自己的字符位置。第 3 项和第 8 项是位于辅音左侧的元音，因此占据字符位置。

当试图确定示例字符串中的字符位置时，len(thai_str)返回45. 这是不正确的。我能够获得正确数量的字符位置的唯一方法是grapheme.length(thai_str)使用35.

我还使用 编码来获得以下信息：

（计算xe0似乎在每个泰语字符之前出现的实例并不像正确的方法......）

所以 - 在我的示例字符串中计算字符位置的唯一方法是使用 Python 3 库，例如grapheme吗？

有没有办法与 Unicode 字素进行模式匹配？

举个简单的例子，当我运行这个查询时：

我返回了两行，而不仅仅是' Two'. Postgres 似乎只是比较代码点，但我希望它比较完整的字素，所以它应该只匹配' Two'，因为是不同的字素。

这可能吗？

我正在查看 Unicode GraphemeBreakProperty 规范，根据Unicode 标准附件 #29中指定的表格，该Prepend属性应包含所有带有Indic_Syllabic_Category = Consonant_Preceding_RephaorIndic_Syllabic_Category = Consonant_Prefixed或的代码点Prepended_Concatenation_Mark = Yes。该规范列出的代码点如下：

在UnicodeSet 实用程序上搜索具有这些属性的字符仅列出 22 个代码点。什么是1193f以及11941为什么它们包含在PrependGraphemeBreakProperty 中？附件只是没有在表格中列出它们吗？找出为什么表格和规格似乎不同的任何帮助都会很棒！

谢谢！

Unicode 标准将字素簇定义为“用户感知字符”的算法近似。字素簇或多或少对应于人们认为的文本中的单个“字符”。因此，能够将字符串作为字素簇的序列进行操作是编程中自然而重要的要求。

最好的通用字素簇定义是扩展字素簇；还有其他用于特定本地化用途的字素集群算法（定制的字素集群）。

String在 Crystal 中，我如何将 a作为一系列字素簇进行迭代（或以其他方式操作） ？

在 unicode 字符串中，每个字素由一个或多个代码点组成。但是，有一些代码点，例如零宽度连接符 (ZWJ)，它们从来都不是字素的一部分。ZWJ 本身是不可见的。所有这些“非字形”代码点总是不可见吗？