String 英语以外语言的限制和替代方法？

trie数据结构通常是用英语存储字符串的好方法。它的工作原理是构建一棵树，其中每条边都标有一个字母，树中标记节点的路径会拼写出数据结构中的一个单词

这种数据结构在英语中工作得很好，因为英语字母表中“只有”26个字母（“合理的”分支因子），这些字符具有连续的ASCII值（因此子指针可以存储在由每个子指针使用的字母索引键入的数组中），并且有许多英语单词具有共同的前缀（因此结构中存在大量冗余）

我是一个以英语为母语的人，对其他语言和字母表的知识有限，但似乎这些属性中的许多在其他语言中并不适用。例如，我知道法语、西班牙语、德语和匈牙利语经常使用重音字符，而这些字符不会与Unicode空间中的剩余字母一起连续存储。希伯尔ew和阿拉伯语有元音标记，通常在每个字母的上方或下方显示。汉语使用符号系统，韩国语的韩国语字符由三个较小的字符组合而成

---

对于以这些语言和字母表存储的数据，尝试是否仍然有效？对于此类数据，使用尝试需要哪些更改（如果有的话）？是否有任何数据结构可以很好地适用于这些语言和字母表中的字符串，但在英语中没有用处或效率？

我发现没有hat测试对西欧语言、西里尔语和许多其他字母语言都很有效。想想看，我唯一遇到问题的语言是汉语、日语和其他符号书写系统。对于这些语言，trie是无用的

英文字符的顺序Unicode值并不是一个很大的好处。尽管它建议使用简单的节点实现：

CharNode
    char
    array[26] of CharNode

这种结构不是特别有用。它可以使事情变得更快，但内存成本相当高。即使在trie的第二级，该数组也非常稀疏。当你到达第四级或第五级时，它几乎都是死区。我曾经对此进行过分析。我会四处看看，看看是否还有这些数字

我发现在节点中使用可变长度数组的速度几乎与按频率排序的项目一样快。除了第二或第三级trie之外，我要查找的字符几乎总是在该数组的第一或第二位置。而且节省的空间相当大。而不是每个节点26个引用（在我的实现中是104字节），我有一个1字节的计数，然后每个引用有5个字节。因此，只要一个特定节点的子节点少于21个（大部分时间都是这样），我就节省了空间。运行时的代价很小，但在我的应用程序中还不够重要

这是我对trie结构所做的唯一修改，以使其支持我正在使用的所有字母语言。正如我所说，我主要使用西欧语言，对于那些工作非常出色的语言。我知道它确实可以使用希伯来语和阿拉伯语，但我不知道它工作得如何。它满足了我们的目的，但是这是否会让母语为英语的人感到满意还不得而知

我构建的trie对于任何字符符合Unicode基本多语言平面的语言来说都能很好地工作。使用代理项对时有点奇怪，但我们几乎忽略了这些。基本上，我们只是将代理项对视为两个字符，就这样处理了

你必须决定你是否想把重音字符当作单独的字符，或者你想把它们映射出来。例如，考虑法语单词“Galangon”，有些人会拼写“GARCON”。要么是因为他们不知道如何更好地生成字符“ç”。根据您使用trie的目的，您可能会发现将重音字符转换为其非重音对应字符很有用。但我认为这更像是一个输入清理问题，而不是trie问题

---

这是我相当冗长的说法，标准的trie应该适用于任何字母语言，没有任何特定语言的修改。我没有看到任何明显的方式将trie用于标识语言。我对韩语韩语一无所知，所以我不能说trie在那里是否有用。

作为@JimMisc的附录hel的回答是，我想提出一个问题，在其他语言中，通常有多种相同的方式来书写相同的东西。（基于拉丁语/英语脚本），这是一个特别好的例子，其中两种口音的字母很常见。例如，Ặ （U+1EB6）在技术上也可以用顺序Ă+点写入，Ạ + 短，A+短+点，A+点+短

可以通过将字符串转换为标准规范顺序来解决此问题。有4种不同的变体，NFC、NFKC、NFD和NFKD。我在这里不太详细，但前两种是“组合形式”，它倾向于缩短字符串，用重音将基本字符分组，而后两种是“分解的形式”，做相反的事情

这是一个有趣的例子：它是一个字母表，尽管一个音节的所有字母都写在一个块中。单个字母和音节块都以Unicode形式存在。尽管不同音节的数量相当大，但标准化可以解决这一问题。使用NFC/NFKC可能对trie没有用处，但在本例中，使用NFD/NFKD将音节分解为组成字母是可行的

其他几个不相关的问题需要考虑：

• 除了已经提到的garçon/garcon点，还有cote/coté/côte/côté问题，这些都是distinc