我有一个运行 FreeNAS 8 的家庭文件服务器。几天前，我使用 rsync 从 Mac 上传我的整个 iTunes 库，以便我可以通过网络加载我的库，而不是从慢速 USB 驱动器上加载。这基本上有效，现在 iTunes 运行得更好，但我在访问任何包含非 ascii 字符的歌曲时遇到问题（我在加载 Queensrÿche 曲目时第一次注意到这个问题）。这些文件会显示在 Finder 中，但任何访问它们的尝试都会使它们消失，直到我重新连接到服务器。
经过一番研究，我发现这是因为 OSX 使用与 Linux 不同的 UTF 字符顺序。OSX 文件系统使用 Unicode Normalization Form D (NFD)，而 linux 使用 Form C (NFC)。Rsync 在执行从我的 mac 到服务器的复制时不会转换这些形式，现在当 iTunes 尝试通过网络访问具有特殊字符的文件时，服务器上的文件的编码错误并且 afpd 报告它们没有存在。
解决这个问题的最佳方法是什么？是否可以在将基本库上传到服务器时让 rsync 执行 unicode 转换？我可以将 afpd 配置为以 NFD 格式传输/接收文件名吗？有没有简单的解决方案来更改服务器上的文件名？我发现了一些关于名为 convmv 的程序的内容，但我不知道是否可以在 FreeNAS 上运行它。
我在谷歌上搜索了几个小时来为我的问题找到解决方案，但我无法让它工作：
我必须将 ext4 格式驱动器上的文件结构 rsync 到 hfs+ 格式驱动器。文件夹和文件名可以包含德语元音变音 (äöüß)，并且 OS X 和 Linux 对 UTF8 的处理不同。OS X 文件系统使用 Unicode Normalization Form D (NFD)，而 Linux 使用 Form C (NFC)。
这种行为会导致删除和重新同步名称中带有变音符号的文件，这会产生大量不必要的开销，尤其是当您使用该--backup选项进行rsync 时。
防止这种行为的解决方案是使用，--iconv=UTF8,UTF8-MAC但这仅适用于 Mac 上较新的iconvlib。Ubuntu 14.04 上的实际 iconvlib 不支持伪字符集 UTF8-MAC：
root@ubuntu:~/wartung# iconv -l
...
UTF-7, UTF-8, UTF-16, UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE, UTF7, UTF8, UTF16, UTF16BE, UTF16LE, UTF32, UTF32BE, UTF32LE, ...
使用自制软件的最新 rsync 的 OS X 做到这一点：
bash-3.2$ iconv -l
ANSI_X3.4-1968 ANSI_X3.4-1986 ASCII CP367 …