在 C#中StringInfo，TextElementEnumerator类为文本元素提供方法和属性。在这里，我们可以找到Text Element的定义。
.NET Framework 将文本元素定义为显示为单个字符的文本单元，即字形。文本元素可以是以下任何一种：
是的，它说文本元素是 .NET 中的字形。我自己也测试了一些 unicode 字符，直到我测试了一个韩文字母 ' 가 '之前，这似乎是真的。
众所周知，一些 Unicode 字符由多个代码点组成。我们也可能面临代码点序列，这就是我使用StringInfo而TextElementEnumerator不是简单的原因String。
StringInfo并且TextElementEnumerator可以判断Chars 是否是正确的代理对。并且“\u0061\u0308”，一个由多个代码点组成的Unicode字符，正如预期的那样被识别为一个文本元素。但是对于“\u1100\u1161”，它没有说它也是一个文本元素。
“\u1100”是前导字母“ㄱ”，“\u1161”是元音字母“ㅏ”。它们可以是单独的字符并显示给用户，就像我在这里写的那样，你现在可以看到它们。但是如果它们一起使用，它们会被渲染为一个字符“가”而不是“ㄱㅏ”。
有两种方法可以表示韩文字符“가”：
- 使用来自Hangul Syllable的单个代码点U+AC00。
- 使用Jamo中的两个代码点U+1100和U+1161。
大多数时候使用前者。后者很少使用，说实话，我根本无法想象它什么时候使用.. 反正第一个只是一个预先组合的字母，第二个是一个被视为一个字符的Lead和Vowel的序列。渲染时，它们看起来完全相同，实际上两者在规范上是等效的。以下行在 C# 中也返回 true：
"\u1100\u1161".Normalize() == "\uAC00"
我想知道为什么Normalize()当 C# 认为它们不是一个完整的文本元素时，这里工作得很好。我认为这与我的 .NET 版本有关，但事实并非如此。即使在 Mono 中也会发生这种情况。
我也对此进行了测试，它可以正确地ICU将“\u1100\u1161”视为一个字形！我最初认为并且可以在一些简单的情况下消除对ICU4C的需求，所以我现在非常失望..StringInfoTextElementEnumerator
这是我的问题：
我在这里做错了吗？
或者
.NET 中的文本元素与 ICU 不同，不是用户感知的字符吗？