Windows NFS 真弱 → 中文乱码导致文件找不到

前提准备

　　项目中有这么一块业务

　　1、 脚本同步 这一环，是运维同事通过脚本实现的，所以我没去关注

　　2、 读取文件并上传 这一环，是我实现的，稳定运行了很长一段时间了，一直没出问题

中文乱码

　　直到有一天， 生产环境 出现了异常信息： /data/userData/Rsync 下不存在文件：测试文件.txt

　　提示很明显，在目录 /data/userData/Rsync 下，没有找到文件 测试文件.txt

　　然后联系运维，让运维去看 本系统 的目录： /data/userData/Rsync 下，文件 测试文件.txt 是否存在

　　运维的反馈是文件存在，还发了截图

　　并且把文件复制给我了

　　然后我将这个文件复制到 测试环境 的 /data/userData/Rsync 目录下， 测试环境 能正常找到文件 测试环境.txt

　　那问题出在哪？

问题排查

　　后面与同个运维同事沟通了下，了解了整个完整流程的细节：

　　其中 CentOS 7 作为 NFS 服务器 ，其系统编码是 UTF-8

Win 2012 作为 NFS 客户端 ，其系统编码是 GBK （chcp 值 936 表示 GBK）

　　我在怀疑是不是 NFS 的问题？

　　怎么验证了？

　　其实最简单的办法就是看一眼 CentOS 7 目录 /data/userData/Rsync 下是不是有中文名乱码文件即可

　　奈何我认为我说清楚了，运维同事也认为他理解了

　　结果南辕北辙，我想看的是 CentOS 7 的目录 /data/userData/Rsync ，运维给我看的却是 Win 2012 下的挂载目录 L:

　　关键是当时我没发现他给我的截图其实不是我想看的！

　　然后我就开始了我的线上环境模拟之旅

　　NFS 服务端

CentOS 7 上搭建 NFS 服务器非常简单

　　1、安装 NFS ，执行 yum install -y nfs-utils 即可

　　2、对客户端 IP 进行授权

　　　　编辑 /etc/exports ，进行授权配置，例如

/data/userData/Rsync/ 表示要共享出去的目录，不存在则需要先创建： mkdir -p /data/userData/Rsync

10.5.108.221 表示客户端 IP 地址，说明共享给谁

(rw,sync,no_root_squash) 表示授权列表， rw 表示客户端可以读写， sync 表示自动同步， no_root_squash 是什么含义，你们自己去查

　　　　涉及到目录的读写，需要对 /data/userData/Rsync/ 配置合适的读写权限，方便演示就简单点： chmod 777 /data/userData/Rsync/

　　　　编辑好之后，使配置生效，执行命令： exportfs -rv

　　3、启动 NFS ： systemctl start nfs-server

　　　　开机启动： systemctl enable nfs-server

　　4、防火墙放行

　　　　为了演示方便，直接关闭防火墙： systemctl stop firewalld

　　NFS 客户端

WIN 2012 作为客户端，配置起来也很简单

　　1、安装 NFS 客户端

控制面板 -> 程序 -> 启用或关闭 Windows 功能

添加角色与功能 ，直接连续下一步，直到 服务器角色

　　　　如果在 WIN 2012 上搭建 NFS 服务器，则上面三个框住的需要勾选上，然后进行 安装

　　　　我们目前是搭建客户端，这个地方可以不勾，下一步，来到 功能

　　　　勾选上 NFS 客户端 ，然后进行安装即可

　　2、防火墙放行，为了演示方便，直接关闭防火墙

　　3、目录挂载

　　　　直接在 cmd 中执行： mount 10.5.108.225:/data/userData/Rsync L:

　　　　不出意外的话，挂载成功

　　此时， 我的电脑 会出现一个网络盘

　　正常来讲，不会有红叉；不影响效果，先不纠结

　　同步

　　简单点模拟，直接在 win 2012 上，往挂载盘（网络盘）写文件，文件名是： 测试文件.txt

　　在 win 2012 的挂载目录 L: 看，中文没乱码，简直太正常了！

　　但是，我们去 CentOS 7 的目录 /data/userData/Rsync/ 看下

　　哦豁，换了个马甲，还真不认识了！

　　程序去找 测试文件.txt ，怎么找得到嘛

　　乱码原因

　　这个时候基本能断定问题出在 NFS ，直接 google 下关键字： Window 2012 NFS 中文乱码 就能找到答案

　　根因就是：windows 内置的 nfs 支持的编码非常有限，不支持 utf-8

问题解决

　　去掉中文

　　既然中文有问题，那就干掉中文

　　和上游系统协商了下，文件名改成英文，中文乱码自然就不存在了

　　有小伙伴可能会有疑问：之前没有中文乱码问题？

　　其实你们心里应该有答案了，没错，就如你们所想：这块业务，之前一直没出现中文名的文件！

　　升级 window 系统

win10 可以开启 Beta 版本 ，来支持 UTF-8

　　具体可参考：一个小设置，让Win10 NFS正常显示中文UTF-8

　　注意看评论区，坑很多，不推荐这种方式

　　至于 Windows 系统的其他版本是否支持该配置，大家结合自己的系统去查阅

　　第三方 NFS 客户端

ms-nfs41-client，人家搭建步骤写的很清楚了

　　换共享方案

Samba 就是其中之一，大家可以去查阅并实现

总结

　　1、 Windows 自带的 NFS 支持的编码非常有限，竟连 UTF-8 都不支持，会导致中文乱码问题

　　2、沟通的时候，一定要清楚的表达自己的意图，要保证人家接收到的信息就是你要表达的信息