$lang是最可靠的终端字符集判断依据，因其为主控变量，未被覆盖时lc_ctype等均回退至此值；输出如en_us.utf-8中的utf-8即实际编码，为空或c则终端仅支持ascii。
直接看 $LANG 就行，它决定了当前终端的字符集，绝大多数情况下这就是你要的答案。
为什么 $LANG 是最可靠的判断依据
Linux 终端的字符集行为由 locale 环境变量驱动，而 $LANG 是其中的主控变量——它没被覆盖时，LC_CTYPE、LC_MESSAGES 等都会 fallback 到它的值。所以查 $LANG 不仅快，而且反映的是终端实际生效的编码。
-
echo $LANG输出类似en_US.UTF-8或zh_CN.UTF-8，末尾的UTF-8就是字符集 - 如果输出为空或
C，说明终端处于 C locale，用的是 ASCII，中文会显示为方框或问号 -
locale命令虽然更全，但容易干扰判断：比如LC_ALL被设成空字符串，会让locale显示一堆"C"，但$LANG仍可能有效
locale 输出里哪些字段真有用
locale 的输出看着多，真正决定终端字符渲染的只有 LC_CTYPE —— 它管字符分类、大小写转换、宽字符宽度，直接影响终端能否正确显示中文、emoji、全角符号。
- 优先看
LC_CTYPE="xx_XX.UTF-8"；如果它没设，就 fallback 到$LANG -
LC_ALL是最高优先级开关，一旦非空，它会覆盖所有其他 locale 变量（包括$LANG） -
locale | grep -E "(LANG|LC_CTYPE|LC_ALL)"这条命令能快速筛出关键三行，比扫完整输出高效
文件和终端的字符集不是一回事
别把终端字符集和文件编码混为一谈：file -i filename 或 chardet filename 查的是文件本身的字节编码，而终端字符集决定它“能不能被正确解读并显示”。两者不匹配就会出现乱码。
- 例如：一个 GBK 编码的文本文件，在
$LANG=en_US.UTF-8的终端里用cat打开，大概率是乱码 - 此时改终端字符集（
export LANG=zh_CN.GB18030）可能解决显示问题，但不是修复文件本身 -
iconv -f GBK -t UTF-8 filename才是真正转码文件内容的方法
配置文件里藏了默认值，但不等于当前值
/etc/locale.conf 或 /etc/default/locale 保存的是系统级默认设置，只在新登录 shell 启动时读取一次。已存在的终端 session 不会自动 reload。
- 修改后必须新开终端，或手动
source /etc/locale.conf（不推荐，易污染当前环境） -
systemctl show-environment | grep LANG可查 systemd 服务的默认 locale，和你的交互式终端无关 - 用户级配置如
~/.bashrc中的export LANG=...优先级高于系统配置，但只对从该 shell 启动的进程生效
真正容易被忽略的点是：LC_ALL 为空字符串（LC_ALL=""）比设成 C 更危险——它不会报错，但会让所有 locale 行为退化到 POSIX 默认，连 $LANG 都被无视。遇到诡异乱码，第一反应应该是 echo $LC_ALL，而不是急着改 $LANG。
