如何处理 NFS 服务器 (UTF-8) 和 Windows 7？

Question

NFS 共享使用mount server:/share x:命令挂载。
使用 samba 共享（并使用 UTF-8）创建的文件（西里尔文）“????? ????????? ??????????.txt”显示为“????? ??‹?? ?‚?µ?????‚???????‹?? ?????????????µ???‚.txt”在 Windows 下通过 NFS 共享。
如何让windows使用UTF-8？

Answer 1

微软的NFS客户端在Windows 7中没有解决方案

在此设置下无法解决您的问题，甚至无法解决此问题的“正确答案”中给出的方法。这不是一个错误，它是故意制造您面临的障碍。NFS 客户端的设计者不可能提供使用 BIG5、EUC-KR、EUC-JP、ksc5601、GB18030、SHIFT-JIS 的选项，而只是忘记UTF-8 并在十年内忘记修补它是不可能的. 除了 UTF-8 之外，各种版本的 Windows 都使用所有这些编码，这并非巧合。事实上，微软的意图是将旧的 UNIX 和 Windows 结合起来，促进从 Unix 到 Windows 的迁移，必须仔细衡量，这并没有给它的竞争对手 Linux 一个容易存在的环境。任何使 Linux 不同于 Unix 或现代 Unix 不同于 old-unix-to-be-replaced 的特性都被排除在外。这是营销的精确性，工作做得很好。

让我向您展示每条路是如何被阻止的：

解决客户端是不行的：

想法是找到一些可以动态转码文件名的软件，例如通过在FS和OS之间插入一个层。或者，找到一些可以为另一个软件设置环境以使用该文件系统的软件。没有已知的 Windows 软件可以做到这一点。这不起作用，因为与允许每个应用程序使用不同编码的 Linux 不同，Windows 为 FILESYSTEM 配置编码。

要解决服务器是不行的：

大多数 NFS 服务器都是 Linux。理论上，可以使用 fuse-convmvfs 制作文件系统的镜像并将其导出。Oleg Lobach 演示了执行此操作的代码，并且未经测试就将其标记为正确。它不起作用，因为 Linux 的 NFS 服务器只能导出 NFSv4 中的 FUSE 文件系统，而不能导出 NFSv2/v3，同时，Windows 7（以及 Unix v3.5 的服务）仅支持 NFSv2/v3，而不支持 NFSv4。我在另一个答案中详细展示了这个限制。

TechNet 中详细说明了该问题：

POSIX 文件名不是 ASCII 而是字节流. NFS 文件系统上的文件名也是如此。将字节流解释为特定代码集中的文件名作为客户端应用程序的练习。如果文件名字节流表示有效的 UTF-8 字符串，但客户端应用程序已将代码集设置为 ISO-8859-5，则任何问题都是应用程序的错误。但我们谈论的是 Windows。在 Windows 上，文件名的解释不留给应用程序。相反，从 NFS 服务器发送到 Windows 客户端机器的文件名字节流必须转换为 UTF-16 字符串才能被操作系统消化。因此，文件名字节流的解释必须由 NFS 客户端服务在每个挂载点的基础上执行。该应用程序在其中没有发言权。这就是问题所在。如果用于创建文件名的远程代码集是 UTF-8，这是 POSIX 世界中多年来的默认值，那么从 Windows 应用程序的角度来看，没有机会获得正确的文件名，因为文件名的解释已经完成由不允许从 UTF-8 转换为 UTF-16 的 Windows NFS 客户端。事实上，NFS 客户端只支持有限数量的代码集转换为 UTF-16，所有这些都相当老式。这不仅仅是一个特定的场景。在您从 Windows NFS 客户端访问设置为使用 MBCS（如 UTF-8 或 GB-18030）的机器上的 NFS 共享的所有情况下，您都会遇到此问题。从 Windows 应用程序的角度来看，没有机会获得正确的文件名，因为文件名的解释已经由不允许从 UTF-8 转换为 UTF-16 的 Windows NFS 客户端完成。事实上，NFS 客户端只支持有限数量的代码集转换为 UTF-16，所有这些都相当老式。这不仅仅是一个特定的场景。在您从 Windows NFS 客户端访问设置为使用 MBCS（如 UTF-8 或 GB-18030）的机器上的 NFS 共享的所有情况下，您都会遇到此问题。从 Windows 应用程序的角度来看，没有机会获得正确的文件名，因为文件名的解释已经由不允许从 UTF-8 转换为 UTF-16 的 Windows NFS 客户端完成。事实上，NFS 客户端只支持有限数量的代码集转换为 UTF-16，所有这些都相当老式。这不仅仅是一个特定的场景。在您从 Windows NFS 客户端访问设置为使用 MBCS（如 UTF-8 或 GB-18030）的机器上的 NFS 共享的所有情况下，您都会遇到此问题。NFS 客户端仅支持有限数量的代码集转换为 UTF-16，所有这些都相当老式。这不仅仅是一个特定的场景。在您从 Windows NFS 客户端访问设置为使用 MBCS（如 UTF-8 或 GB-18030）的机器上的 NFS 共享的所有情况下，您都会遇到此问题。NFS 客户端仅支持有限数量的代码集转换为 UTF-16，所有这些都相当老式。这不仅仅是一个特定的场景。在您从 Windows NFS 客户端访问设置为使用 MBCS（如 UTF-8 或 GB-18030）的机器上的 NFS 共享的所有情况下，您都会遇到此问题。

如果您选择切换，有一些解决方案：

最好的解决办法当然是放弃Windows。现在这并不重要，全球趋势不再是发布仅适用于 Windows 的软件。如果您坚持使用旧的 Windows 应用程序，您可以更改您的要求：

• 切换 NFSv2/v3 客户端：您可以为 Windows 安装 dokan 用户端安装驱动程序，然后是 Neko NFS 驱动器，它将 NFS 映射到带有“Unicode”选项的设备驱动程序。单击该选项以使 UTF8 工作。它支持 NFSv2 和 v3，但不支持 v4。它还不支持符号链接（就像微软的客户端那样）。

• Siwtch NFSv4 客户端：您可以保留内置的 NFS 客户端，以供 UMICH CITI 用于 Windows 的 NFS 4.1 免费参考实现，尽管安装困难，但应该可以解决问题（因为 NFS4 明确要求 UTF-8）或使其成为可能使用上面提到的变通方法fuse-convmv。

• 切换操作系统：Windows Server 2012 添加了对 NFS 4.1 服务器的支持，因此它们也有可能包含 NFS 4.1 客户端。

如果您的服务器仅支持 NFSv3，例如，如果您使用 OpenWRT（即使是最新版本的 OpenWRT 服务器仍然无法执行 NFSv4），这两个开关都将无法工作。

Answer 2

您可以使用fuse-convmvfs：通过fuse-convmvfs挂载您的服务器文件夹（输入字符集 - utf8，输出 - cp1251）并配置nfsd以使用转换后的FS

例子：

> convmvfs /mnt/converted-folder -o srcdir=/path/to/source/foleder, icharset=utf8,ocharset=cp1251

> vi /etc/exports
/mnt/converted-folder 192.168.1.*(rw,sync)