delphi - 使用 Delphi 进行 Unicode 预组合和分解

Question

Wikipedia entry for Subversion包含一段关于不同 Unicode 编码方式的问题的段落:

While Subversion stores filenames as Unicode, it does not specify if precomposition or decomposition is used for certain accented characters (such as é). Thus, files added in SVN clients running on some operating systems (such as OS X) use decomposition encoding, while clients running on other operating systems (such as Linux) use precomposition encoding, with the consequence that those accented characters do not display correctly if the local SVN client is not using the same encoding as the client used to add the files

虽然这描述了 Subversion 客户端实现的特定问题，但我不确定常规 Delphi 应用程序是否也会出现底层 Unicode 组合问题。我猜想只有当 Delphi 应用程序能够使用两种 Unicode 编码方式(也许在 Delphi XE2 中)时才会出现这个问题。如果是，Delphi 开发人员可以采取什么措施来避免这种情况？

Answer 1

存在一个小显示问题，即 Windows 上使用的许多字体无法通过使用字母和变音符号的组合字形以理想的方式呈现分解形式。相反，它会退回到渲染字母，而不是在顶部覆盖独立的变音标记，这通常会导致视觉效果不太令人满意，并且可能会出现不平衡的字形。

然而，这并不是 wiki 中引用的 Subversion bug 所讨论的问题。实际上，将包含组合或分解字符序列的文件名检入 SVN 是完全没问题的； SVN 既不知道也不关心组合，它只是按原样使用 Unicode 代码点。只要后端文件系统使文件名保持与放入时相同的状态，一切都很好。

Windows 和 Linux 的文件系统同样无法组合。不幸的是，Mac OS X 没有。 HFS+ 和 UFS 文件系统在存储传入的文件名之前都会对分解形式执行“标准化”，因此您返回的文件名不一定与您输入的 Unicode 代码点序列相同。

正是这种[IMO:疯狂的]行为在 OS X 上运行时使 SVN 和许多其他程序感到困惑。它特别容易被咬，因为 Apple 碰巧选择了分解 (NFD) 作为其规范化形式，而大多数世界其他地区使用组合 (NFC) 字符。

(它甚至不是真正的 NFD，而是一个不兼容的 Apple 专用变体。欢乐。)

解决这个问题的最好方法是，如果可以的话，永远不要依赖存储的确切文件名。如果您只读取给定名称的文件，那很好，因为它将被标准化以匹配当时的文件系统。但是，如果您正在阅读目录列表并尝试将其中找到的文件名与您期望的文件名相匹配(这就是 Subversion 正在做的事情)，您将会遇到不匹配的情况。

要可靠地进行文件名匹配，您必须检测您正在 OS X 上运行，并在进行比较之前手动将文件名和字符串标准化为某种正常形式(NFC 或 NFD)。您不应该在将这两种形式视为不同的其他操作系统上执行此操作。