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客户端实现的一个特定问题,但我不确定基础Unicode组合问题是否也会出现在常规Delphi应用程序中.我想只有Delphi应用程序能够使用两种Unicode编码方式(可能在Delphi XE2中)时才会出现问题.如果是的话,Delphi的开发人员可以做些什么来避免它呢？
有一个小问题,因为在Windows上使用的许多字体都不会以理想的方式呈现分解的形式,通过使用字母和变音符号的组合字形.相反,它回退到渲染字母,而不是将独立的变音符号叠加在顶部,这通常会导致视觉上不那么令人愉悦,可能是不平衡的字形.然而,这不是wiki引用的Subversion错误所引发的问题.检查包含组合或分解字符序列的SVN的文件名实际上是完全正确的; SVN既不知道也不关心组合,它只是按原样使用Unicode代码点.只要后端文件系统使文件名处于与它们放入的状态相同的状态,一切都很好.
Windows和Linux都有文件系统,对组合同样无视.不幸的是,Mac OS X没有.在存储传入文件名之前,HFS和UFS文件系统都会对分解形式执行“规范化”,因此您获取的文件名不一定与您放入的Unicode代码点序列相同.
正是这种[IMO：疯狂]行为混淆了SVN和许多其他程序 – 在OS X上运行时.它特别容易被咬,因为Apple碰巧选择分解(NFD)作为其标准化形式,而其余的大多数世界使用组合(NFC)字符.
(它甚至不是真正的NFD,而是一种不兼容Apple的变体.欢乐.)
解决这个问题的最好方法是,如果可以的话,永远不要依赖存储在其中的确切文件名.如果您只读取给定名称的文件,那很好,因为它将被标准化以匹配当时的文件系统.但是,如果您正在阅读目录列表并尝试将您在其中找到的文件名与您期望的文件名匹配 – 这正是Subversion所做的 – 您将会遇到不匹配问题.
为了可靠地进行文件名匹配,您必须检测到您在OS X上运行,并在进行比较之前手动将文件名和字符串规范化为某种正常形式(NFC或NFD).您不应该在将这两种形式视为不同的其他操作系统上执行此操作.