convmv是Linux系统下专门用于修复文件名编码乱码的工具，它能够直接对目录项字节序列进行重编码，而不会修改文件内容。在使用时，需先通过“convmv -f GBK -t UTF-8 --notest”命令来预览转换效果，确认无误后，再加上“--notest”参数执行实际转换操作。同时，必须保证LANG环境变量支持目标编码。
file 和 enca 都不能查看文件名的编码格式——它们只分析文件内容。Linux 文件系统本身不存储文件名的编码信息，文件名是以字节序列直接存于目录项（dentry）中的，解释权完全交给用户空间程序（如 shell、ls、glibc）。所以“文件名编码”本质是「当前 locale 下如何解码这些字节」。
为什么 ls 显示中文文件名是乱码或问号
这不是文件名“本身”有错，而是终端或命令行工具用错了字符集去解读那一串字节。常见现象包括：???.txt、.txt、或显示为方块。根本原因是：LANG 或 LC_CTYPE 不匹配文件名生成时的环境。
- Windows 拷入的中文文件名，通常按
GBK字节写入，但 Linux 默认用UTF-8解释 → 出现乱码 ls本身不转码，只是把目录项字节原样传给终端；终端再按LANG设置尝试渲染file -i filename对文件名完全无效——它读的是文件内容，不是目录结构
用 convmv 查看并修复文件名编码
convmv 是唯一专治文件名编码问题的命令，它不碰文件内容，只重编码目录项里的字节序列。
- 先确认当前 locale：
locale，重点看LANG值（如en_US.UTF-8或zh_CN.UTF-8） - 假设你怀疑文件名实际是
GBK编码，但当前环境是UTF-8，可试运行：convmv -f gbk -t utf-8 --notest *.txt - 加
--notest才真正改名；不加则只预览转换效果，安全第一 - 若报
No such file or directory，说明-f猜错了原始编码，换gb2312或big5再试 convmv -l可列出所有支持的编码；convmv --list显示当前 locale 支持的编码别名
用 hexdump 直接看文件名字节（进阶验证）
当 convmv 也识别困难时，跳过猜测，直接看原始字节：
- 用
ls --quoting-style=escape查看带转义的文件名，比如test344270255346226207.txt→ 后面三组八进制对应 UTF-8 的“中文” - 更彻底：用
find . -maxdepth 1 -name '*中*' -printf '%P ' | xargs -0 -n1 printf '%sn' | hexdump -C，观察前几个字节是否符合 UTF-8 规则（如e4 b8 ad）或 GBK（如d6 d0） - 注意：UTF-8 中文首字节范围是
0xe0–0xef，GBK 是0x81–0xfe，且无固定 BOM
vim / less / cat 显示文件名乱码？不是它们的问题
这些工具调用的是 libc 的 readdir() + printf，完全依赖 LC_CTYPE。即使文件名已用 convmv 正确转成 UTF-8 字节，若终端 LANG=C，照样显示为 ???。
- 临时修复：
export LANG=zh_CN.UTF-8（确保系统已安装该 locale，可用locale -a | grep zh_CN检查） - 永久生效：写入
/etc/default/locale或用户级~/.profile vim里用:echo glob('*')看内部识别结果，它受encoding和fileencodings影响，但和文件名编码无关
iconv 当万能钥匙，对文件名硬上 —— 它根本不管文件名。必须分清「内容编码」和「文件名字节解释」是两层事。一旦混淆，所有后续操作都在错误前提下展开。 
