应优先检查 lc_ctype，其次 lang，lc_all 会覆盖二者；用 locale 命令确认当前会话实际字符集设置；file -i 和 enca 可检测文件真实编码；vim 中需手动尝试不同编码验证。
直接看 locale 输出里的 LC_CTYPE 或 LANG，它俩谁有值就信谁，优先级是 LC_CTYPE > LANG。
用 locale 查系统默认字符集
locale 是最可靠的第一步，它反映当前 shell 会话的实际生效设置。注意不是所有变量都参与字符集判定：
-
LC_CTYPE是唯一决定文本处理（如正则、大小写转换）所用字符集的变量，它存在且非空时，就以它为准 -
LANG是兜底 fallback，当LC_CTYPE未设置时才起作用 -
LC_ALL会覆盖所有LC_*和LANG，如果它被设成C或空字符串，LC_CTYPE就失效
执行 locale | grep -E '^(LANG|LC_CTYPE|LC_ALL)=' 能快速聚焦关键行。别只扫一眼 LANG 就下结论——常见坑是脚本里误设了 LC_ALL=C，导致中文显示为问号，但 LANG 还写着 zh_CN.UTF-8。
用 file -i 查单个文件的实际编码
file -i 看的是文件内容本身的字节特征，和系统设置无关。它适合诊断“为什么这个文件在终端里乱码”：
- 输出中的
charset=字段就是检测结果，例如charset=utf-8或charset=iso-8859-1 - 如果返回
charset=unknown-8bit，说明文件没明显 BOM 或可识别签名，得换工具 -
file --mime-encoding效果相同，但只输出编码名，更干净
注意：它对纯 ASCII 文本常报 charset=us-ascii，这其实是 UTF-8 的子集，不必惊慌；但若一个中文文件报这个，大概率是编码损坏或根本没中文。
用 enca 或 chardet 辅助识别中文文件
当 file -i 拿不准，尤其面对 GBK/GB2312/Big5 混合的老文本时，enca 更靠谱：
- 装好后运行
enca -L zh filename，-L zh告诉它优先按中文规则匹配 - 输出像
Universal transformation format 8 bits就是 UTF-8，Chinese National Standard; GBK就是 GBK -
chardet（Python 工具）也能用，但对 GBK 识别不如enca稳定，且输出带置信度（如confidence 0.92），低于 0.9 就别信
别依赖 iconv -l 列支持列表来“猜”文件编码——那只是系统能转哪些码，不是文件本身是什么码。
vim 里临时验证编码是否正确
打开文件后，在 vim 命令模式输 :set fileencoding?，看到的不一定是真实编码，而是 vim 自己“猜”的。更实用的是手动试：
- 先
:e ++enc=gbk强制用 GBK 解析，文字正常就说明原文件是 GBK - 再
:e ++enc=utf-8对比，如果中文变乱码，基本排除 UTF-8 -
:set bomb?能确认是否有 UTF-8 BOM 头，有 BOM 的文件在某些工具里会被误判
真正容易被忽略的点是：终端自己的编码设置（stty 不管这个）、SSH 客户端的字符集转发、甚至字体是否支持对应 Unicode 区块——光改对文件编码，终端渲染层不配合，照样是方块。
