记一次惊心动魄的跨平台 NAS 挂载乱码填坑记：Linux/Windows/CIFS 字符集大混战

📝 背景介绍

最近在项目中遇到一个极其诡异的“薛定谔的文件名”现象。
我们的系统架构是这样的：部署在 Linux 上的 Java 程序会从 MinIO 下载文件，并写入到挂载的 NAS 盘中；而部署在 Windows Server 上的 IIS (.NET) 程序则需要从同一个 NAS 盘读取这些文件。

🐛 诡异的现象

起初，Java 程序写入 NAS 的中文文件，在 Linux 终端下 ls 查看完全正常。
但是，当切换到 Windows 系统通过网络驱动器查看该目录时，所有中文文件名都变成了类似 æ°´ 这样的乱码。

为了让系统能跑，我尝试在 Windows 端手动把乱码改回了正确的中文。结果更离谱的事情发生了：在 Windows 端改好的文件，到了 Linux 端反而变成了乱码！ —

🔍 案情侦破：底层到底发生了什么？

经过排查，问题的根本原因出在 Linux 挂载 NAS (CIFS/SMB 协议) 时的字符集协商上。

通过执行 mount | grep /mnt/nas，我发现挂载参数里缺少了至关重要的一项：iocharset=utf8。

它的运行机制（乱码产生全过程）：

1. Linux 默认使用 UTF-8 编码生成中文文件名。
2. 通过 CIFS 协议写入 NAS 时，由于未指定 iocharset，Linux 内核 CIFS 驱动退回到了默认的本地字符集（如 iso8859-1，即 Latin-1）。
3. 驱动把 UTF-8 的中文字节，强行当作 Latin-1 字符翻译成了 SMB 底层的 Unicode 存入 NAS。
4. Windows 读取时，拿到的是错误翻译的 Unicode，显示出来的就是拼音文字符（æ°´）。
5. 反之，在 Windows 手动改对的文件存入真正的 Unicode 中文，Linux 读取时用缺省的单字节字符集去反解，自然也成了乱码。

---

🛠️ 填坑实录：从治标到治本

第一步：修复源头，重新配置挂载参数

必须让 Linux 强制使用 UTF-8 与 NAS 交流。我们修改 /etc/fstab：

# 修改前：
//sfs.xxx.cn123/sfs-name /mnt/nas cifs credentials=/root/.smbcredentials,vers=3.0,dir_mode=0755,file_mode=0755 0 0

# 修改后（加入了 iocharset=utf8）：
//sfs.xxx.cn123/sfs-name /mnt/nas cifs credentials=/root/.smbcredentials,vers=3.0,iocharset=utf8,dir_mode=0755,file_mode=0755 0 0

第二步：遭遇连环坑 mount error(79)

执行 mount -a 后，系统无情地抛出报错：

mount error(79): Can not access a needed shared library

dmesg | tail 显示：CIFS VFS: CIFS mount error: iocharset utf8 not found。

踩坑解析： 原来由于服务器使用的是精简版内核，缺少了处理 UTF-8 字符集转换的底层模块 nls_utf8.ko。
解决办法： 补齐内核模块并加载。

apt-get update
apt-get install linux-modules-extra-$(uname -r)
modprobe nls_utf8

再次 mount -a，成功挂载！此时新写入的文件双端都正常了。

第三步：历史数据的极限救援（高光时刻）

挂载参数修复后，面临一个棘手的问题：NAS 盘里之前存的那堆乱码文件怎么办？ 数据库里存的可是正确的中文路径，必须把乱码恢复回来。

我首先想到了神器 convmv：

convmv -f utf-8 -t latin1 -r .

(注：原理是将误认作 UTF-8 的乱码，逆向转换回 Latin1，由系统重新以正确姿势写入底层)

但是，命令失败了！ 提示 iso-8859-1 doesn't cover all needed characters。
原因是我之前在 Windows 里手动修改了部分文件，导致文件夹变成了“混合状态”（既有纯乱码，又有正常的中文）。convmv 扫描到正常中文字符时，为了保护文件不被毁坏，强制中止了整个目录的转换。

终极绝招：带“试运行”探针的智能转换脚本
为了安全地只转换乱码文件、跳过正常文件，我写了下面这段 Shell 脚本完美解决了问题：

for file in *; do
    # 先进行一次不带 --notest 的试运行，将标准输出和错误输出丢弃
    if convmv -f utf-8 -t latin1 "$file" >/dev/null 2>&1; then
        # 如果试运行成功（说明是纯乱码，符合转换条件），则执行真正的重命名
        convmv -f utf-8 -t latin1 --notest "$file"
    else
        # 如果试运行失败（说明包含无法塞入 Latin1 字典的正常中文字符），则安全跳过
        echo "✅ 跳过正常文件或无法转换的文件: $file"
    fi
done

脚本跑完的一瞬间，整个目录里的乱码文件瞬间变回了清爽的中文，且之前手动改好的文件完好无损。系统平台成功读取到了正确的路径，完美收工！

💡 总结与避坑指南

1. 跨平台网络文件共享（SMB/CIFS），千万别忘了显式声明字符集 iocharset=utf8。
2. 遇到 mount error(79)，第一时间检查内核模块 linux-modules-extra 是否完整安装。
3. convmv 是修复文件名乱码的神器，但处理混合状态的目录时，利用其干跑（dry-run）特性结合 shell 脚本进行逻辑判断，才是最安全、最高效的做法。

---

希望这篇排坑记录能帮到有缘人！如果觉得有用，欢迎点赞收藏！