第一步是准确识别文件原始编码：用enca -l zh filename确认编码（如gb18030/gbk/utf-8），而非盲目猜测；file命令仅作粗略参考，常返回unknown-8bit。
用 file 和 enca 准确识别文件原始编码
乱码问题的第一步不是改，而是确认当前文件到底是什么编码。直接猜 UTF-8 或 GBK 很容易翻车。file 命令只能粗略判断，比如 file --mime-encoding filename 有时返回 unknown-8bit，等于没说。enca 更可靠，尤其对中文文本：安装后运行 enca -L zh filename，它会结合内容特征给出概率最高的编码（如 GB18030、GBK、UTF-8）。注意：enca 在 CentOS/RHEL 需先 yum install enca，Ubuntu/Debian 是 apt install enca；不加 -L zh 可能误判为西欧编码。
用 iconv 安全转换文件编码（避免损坏）
iconv 是 Linux 自带的编码转换主力，但必须指定正确的源编码，否则越转越乱。基本用法是：iconv -f GBK -t UTF-8 input.txt -o output.txt。关键点：
-
-f参数必须和enca识别出的原始编码一致，不能凭感觉写gb2312却实际是GB18030 - 加
-c参数可跳过无法转换的非法字节（防止整个文件中断），但会丢数据，慎用 - 务必先在小文件上测试，或用
iconv -f xxx -t utf-8 input.txt | head -n 20看前20行是否正常 - 批量转换时，别直接覆盖原文件，先输出到新路径，确认无误再
mv
用 convmv 修复中文文件名乱码（不是文件内容）
Windows 传上来的中文文件名在 Linux 终端显示为 .txt，这是文件系统层的编码错位，iconv 对它完全无效。convmv 专治此病：convmv -f gbk -t utf-8 -r /path/to/dir。注意：
- 默认是预览模式，只打印要改什么，加
--notest才真正执行 -
-r表示递归，但不会进符号链接目录；若需处理，加--allow-chunking - 如果提示
Can't convert encoding: No such file or directory，说明当前 locale 不支持目标编码，先确保locale -a | grep zh_CN.utf8有输出 - XFTP/WinSCP 用户应同步设置「文件名传输编码」为 UTF-8，从源头避免该问题
vim 中实时处理乱码文件（不改原文件编码）
有时你只是想快速看懂一个编码不明的文件，不想动原文件。vim 支持运行时重载编码：:set fileencoding=utf-8 或 :e ++enc=gbk % 强制以 GBK 解析当前文件。更稳妥的是在 ~/.vimrc 加三行：
set encoding=utf-8 set fileencodings=ucs-bom,utf-8,gb18030,gbk,gb2312,cp936 set termencoding=utf-8
这样 vim 会按顺序尝试解码，多数中文文件能自动识别。但要注意：fileencodings 列表顺序很重要，把最可能的放前面；如果文件本身是 UTF-8 但带 BOM，ucs-bom 必须在第一位，否则可能被后面规则错误截断。
真正麻烦的不是转换动作本身，而是搞不清「乱码」到底发生在哪一层：是终端渲染？SSH 客户端传输？文件内容？还是文件名元数据？每层对应不同工具和参数，混用只会让问题更模糊。
