Ubuntu终端本身不支持自动识别字符编码，其显示依赖LANG和LC_CTYPE环境变量指定的编码；乱码根源在于终端仅忠实地渲染字节流，而编码探测由vim、less、gedit等上层应用实现，需手动配置locale及工具编码优先级。
Ubuntu终端本身不支持自动识别字符编码
Linux终端（如GNOME Terminal、xterm）没有内置的“自动检测文件或输入流编码”能力。它只忠实地渲染字节流，解码逻辑完全依赖于当前 LANG 和 LC_CTYPE 环境变量指定的编码。所谓“自动识别”，实际是上层应用（如 vim、less、gedit）自己实现的探测逻辑，终端本身不参与。
真正起作用的是 locale 环境变量
终端显示是否正常，取决于你当前 shell 的 locale 设置是否匹配数据来源的编码。比如用 cat 查看一个 GBK 编码的中文文件时，若 LC_CTYPE 是 en_US.UTF-8，就会乱码；换成 zh_CN.GBK 才可能正确显示（但现代系统极少启用 GBK locale）。
Ubuntu 26.04
下载
Ubuntu 26.04 LTS（代号“Resolute Raccoon”）是Canonical于2026年4月23日发布的下一代长期支持版操作系统，提供长达10年的技术支持。它搭载Linux 7.0内核与GNOME 50桌面环境，全面转向Wayland协议，并引入Rust重写的核心工具以增强安全性。官方提供适用于AMD64和ARM64架构的桌面及服务器ISO镜像，是追求前沿技术与极致稳定的开发者
-
locale命令输出中，LC_CTYPE决定终端如何解释输入/输出字节 - Ubuntu 默认只预装
en_US.UTF-8和zh_CN.UTF-8等少数 locale，GBK或GB18030需手动启用 - 修改
/etc/default/locale或用户级~/.profile中的LANG=zh_CN.UTF-8是最稳妥的做法 - 临时切换可用：
LANG=zh_CN.GB18030 LC_CTYPE=zh_CN.GB18030 bash（但仅对当前 shell 有效）
想“自动识别”，得靠具体工具而非终端
如果你希望打开任意编码的文本文件都不乱码，不能指望终端，而要依赖支持多编码探测的程序：
-
vim：靠set fileencodings=utf-8,gb18030,gbk,latin1实现读取时自动尝试（注意顺序！UTF-8 必须放最前） -
less：默认不探测，但可加-r参数配合LANG显示原始字节，或用iconv预转：iconv -f GBK -t UTF-8 file.txt | less -
gedit：自带编码探测，但依赖 GNOME 的gsettings配置，例如：gsettings set org.gnome.gedit.preferences.encodings auto-detected "['UTF-8','GB18030','GBK']" -
file -i和enca -L zh_CN是诊断工具，不是显示工具——它们帮你判断该用什么编码打开，而不是帮你“自动打开”
SecureCRT 或 Xshell 连 Ubuntu 时的常见错觉
很多人以为在 SecureCRT 里设了 UTF-8 就能“自动识别”，其实只是把客户端和服务器约定用 UTF-8 通信。如果远程 Ubuntu 的 locale 是 C 或 POSIX，即使 SecureCRT 发 UTF-8 字节，服务端仍按单字节 Latin-1 解释，结果还是乱码。
- 必须两端一致：
SecureCRT → UTF-8+Ubuntu → LANG=zh_CN.UTF-8 - 检查远程服务器真实 locale：
locale，不是看 SecureCRT 设置 - 不要在
/etc/environment里写LANG=而不加引号，会导致解析失败（常见坑） -
sudo下执行命令时，环境变量可能被重置，记得用sudo -E保留当前 locale
bash 或 gnome-terminal 学会“猜”，那是工具的事。 
