这也许比你想要的细节更多，但以下是我对希伯来语规范化问题的看法。Unicode 制定了一个规范变音符号顺序（canonical diacritic order），但这在语言学上并不理想。由于非交互变音符号之间的顺序可以是任意的，当被要求时，他们决定不改变顺序。但在希伯来语中，有些情况下交互变音符号的顺序很重要，而规范化会丢失这种顺序。为了解决这个问题，人们使用 CGJ（U+034F）来允许不同的变音符号顺序。这应该被视为单词拼写的一部分。
在所有这些讨论进行的同时，字体通常没有设计来处理 Unicode 规范顺序。但这早已修复，字体可以很好地处理 Unicode 规范排序的文本。
所有这些都是为了说明，我认为没有理由不将数据存储为 Unicode 规范形式（NFC、NFD，我认为在希伯来语中它们是相同的），但如果你有一些遗留数据（旧的 Unicode 数据），那么在规范化时应小心。特别是检查耶路撒冷（Jerusalem）这个词（据我模糊的记忆，这是包含变音符号顺序问题的词之一），它应该包含一个 CGJ（或者在面前有一个视觉表示时仔细查看）。
至于 Lorna 的例子，这两个变音符号之间应该没有困难，因为它们是非交互的（一个在上方，一个在下方）。
This is probably more detail than you want to have, but here is my take on the Hebrew normalization issues. Unicode came up with a canonical diacritic order which was not ideal linguistically. Since diacritic order between non-interacting diacritics can be arbitrary, they decided to not change the order when asked. But there are some situations where order is important for interacting diacritics in Hebrew and that order is lost by normalization. To get around this, people use the CGJ (U+034F) to allow for a different diacritic ordering. This should be considered part of the spelling of the word.
While all this was being thrashed out, fonts were often not designed to handle the Unicode canonical order. But that has long been fixed and fonts can handle Unicode canonically ordered text just fine.
All this to say that I see no reason why data shouldn’t be stored in either Unicode normal form (NFC, NFD which I think are identical in Hebrew), but that if you have some legacy data (old Unicode data) then care should be taken in the normalization. In particular check the word for Jerusalem (IIRC from my foggy memory about words that contain diacritic ordering issues) which should contain a CGJ (or looked at carefully with a visual representation in front of you).
As to Lorna’s example, there should be no difficulty with those two diacritics since they are non-interacting (one above one below).
机器翻译自 English
