的Unicode Precomposition和分解與德爾福

Question

的Wikipedia entry for Subversion包含了關於與Unicode編碼的方式不同問題的段落：

雖然Subversion把文件名以Unicode，它並沒有規定 precomposition或分解用於某些重音符號 個字符（如é）。因此，在 運行SVN客戶端添加文件的一些操作系統（如OS X）使用分解編碼， 而在其他操作系統上運行（如Linux）客戶端使用 precomposition編碼，其結果是這些重音 字符做無法正確顯示如果本地SVN客戶端不是 使用相同的編碼與客戶端用於添加文件

雖然這種描述與Subversion客戶端實現一個具體的問題，我不知道如果底層的Unicode組合問題也可以出現在常規的Delphi應用程序中。我想只有在Delphi應用程序能夠同時使用Unicode編碼方式（可能在Delphi XE2中）時纔會出現問題。如果是的話，Delphi開發人員可以做些什麼來避免它？在與文本涉及任何應用程序可能會出現

Answer 1

有一個在Windows上使用將不會呈現在理想的方式分解的形式，通過使用組合標誌符號的字母和變音都很多字體較小的顯示問題。相反，它只能渲染字母，而不是將獨立的變音符號疊加在頂部，這通常導致視覺上不太令人愉悅的，可能不平衡的字形。

不過不是來自維基引用的顛覆錯誤都在談論這個問題。實際上，檢查包含組合或分解字符序列的SVN的文件名是完全正確的; SVN既不知道也不在乎構圖，它只是按原樣使用Unicode代碼點。只要後端文件系統使文件名保持與放入狀態相同的狀態，一切都很好。

Windows和Linux有同樣盲目的組成文件系統。不幸的是，Mac OS X沒有。在存儲傳入文件名之前，HFS +和UFS文件系統都會對分解後的表單執行「規範化」操作，因此您返回的文件名不一定與您輸入的Unicode代碼點的順序相同。

這是[IMO：瘋狂]的行爲，當在OS​​ X上運行時會混淆SVN和許多其他程序。它特別容易咬人，因爲Apple正好選擇分解（NFD）作爲它們的規範化形式，而世界上大多數人使用組合（NFC ）字符。

（它甚至不是真正的NFD，但不兼容的蘋果只變種。喜悅。）

應對這種情況的最好辦法是，如果可以的話，從不依靠準確的文件名有什麼地方存儲下。如果你只讀過一個給定名字的文件，那沒關係，因爲它將被規範化以匹配當時的文件系統。但是，如果您正在閱讀目錄列表並嘗試將您在其中找到的文件名匹配到您期望的文件名所在的位置（這是Subversion正在執行的操作），那麼您將會遇到不匹配問題。

爲了可靠地進行文件名匹配，您必須檢測到您在OS X上運行，並且在進行比較之前手動將文件名和字符串歸一化爲某種標準格式（NFC或NFD）。您不應該在其他處理這兩種表單的操作系統上執行此操作。

Answer 2

同樣的問題。如何避免這種情況取決於應用程序執行的操作以及問題缺乏具體細節。大多數情況下，我認爲你可以通過標準化文本來解決這些問題。這涉及到只要遇到編碼歧義時就使用單個首選表示。

Answer 3

AFAICT，都應該編碼時顯示產生相同的結果，無一不是有效的Unicode，所以我不太看到問題在那裏。如果遇到分解，顯示程序應該能夠處理兩者。代碼點é應該按原樣顯示，而e´應該僅在分解模式下顯示爲é。

問題是不顯示，IMO，它是比較，無論是對平等或詞法，即對於分選（如果同時使用不同的編碼，這失敗）。正如David所說，這就是爲什麼人們應該規範化爲一種編碼。這樣就沒有了任何含糊之處。