這可能比您想要的細節更多，但以下是我對希伯來文正規化問題的看法。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
