Unicode组合和分解形式

我知道某些角色有组合和分解的变体。我也理解应用程序应该是一致的，并且在与第三方合作时使用一种或另一种，并面临挑战

我不太明白的是： -为什么这两种形式存在 -在实现一个简单的后端数据库时，我应该选择哪一个

似乎大多数人都在使用组合表单（Windows、SMB）。另一方面，HFS+上的MacOSX使用的是分解形式

例如，当使用合成和分解重音法语e（é）时，它们在屏幕上看起来相同，但搜索可能不会返回结果，排序可能无法按预期工作。我倾向于采用组合形式，但在我看来，法语和法语（我知道这不是一个好例子）在结果集中不会“彼此接近”，也许他们应该如此

我不知道Lucene在做什么。。。 对我的用例有什么建议

更新日期：2015-02-19

问题是应该使用哪种形式的NFC或NFD在后端数据库中持久化字符串、文件名等？ 此外，我正在为Windows、Linux和MacOSX实现VFS，因此返回文件系统的一致视图是至关重要的。 从表面上看： Mac喜欢接收分解形式的文件名，因此必须对该平台进行规范化

组合和分解形式的存在是为了兼容性：有多个编码具有组合字符，Unicode必须允许使用所有这些字符进行双向无损转换。我所知道的最令人震惊的例子是Windows-1258，它允许以合成和分解的形式表示相同的重音字符，就像Unicode一样

他们不添加新的预合成字符的原因很简单，因为没有需要它的新编码

选择组合字符的主要原因是旧软件中更好的渲染支持以及大多数用例明显的简单性。这些是否重要，你必须自己决定

Lucene有几个过滤器处理这个问题，例如

ICUFoldingFilter

至于排序，无论使用合成字符还是分解字符，naive算法都会失败。我建议为您选择的语言使用一个像样的Unicode排序库

---

作为一个一般性的问题，这是一个过于宽泛的问题，也是一个很大程度上基于观点的问题。关于您的用例，您并没有实际描述它。即使详细描述了预期的数据处理和其中使用的工具，我恐怕这也会偏离主题。显而易见的谷歌搜索覆盖了很多这方面的内容。也许还可以读书。TR#15包含两次“推荐”这个词，两次都是NFC，但是如果你关心eénear等价性，分解可能是一个更好的选择。非常感谢。