linux中文乱码需按字符编码、终端渲染、字体支持、环境变量四层顺序排查；常见现象为终端显示问号或方块，根源是终端未用utf-8解码或locale未启用，须先locale确认再export lc_all并生成对应locale。
Linux 中文乱码不是单一问题，而是字符编码、终端渲染、字体支持、环境变量四层叠加的结果；单独改某一项往往无效，必须按顺序排查。
终端显示中文为问号或方块
这是最常见现象：ls 列出的中文目录名变成 ??? 或 ，cat 查看中文文本全是乱码。根本原因是终端没用 UTF-8 解码，或系统没加载对应 locale。
- 先确认当前 locale：
locale—— 如果输出里LANG是C或空，说明没启用 UTF-8 支持 - 临时修复：运行
export LC_ALL=en_US.UTF-8（或zh_CN.UTF-8，前提是该 locale 已生成） - 永久生效：编辑
~/.zshrc或~/.bashrc，追加export LC_ALL=en_US.UTF-8，再执行source ~/.zshrc - ⚠️ 注意：如果
locale -a | grep zh_CN.utf8没输出，说明 locale 未生成 —— 需先取消注释/etc/locale.gen中的zh_CN.UTF-8 UTF-8，再运行sudo locale-gen
文件名解压后乱码（如 unzip .zip 含中文）
Windows 打包的 ZIP 文件默认用 GBK 编码存文件名，而 Linux 的 unzip 默认按 UTF-8 解码，导致解压后文件名全乱。这不是终端问题，是归档工具本身的编码盲区。
- 查 ZIP 原始编码：用
file -i archive.zip看不到编码信息，但可凭经验判断（国内 Windows 多为 GBK/GB2312） - 指定解码方式解压：
unzip -O gbk archive.zip（-O是 iconv-style 编码选项，仅部分 unzip 版本支持） - 若不支持
-O，换用7z x archive.zip——7z自动识别常见中文编码，兼容性更好 - 长期建议：在 Windows 端用 7-Zip 或 Bandizip 打包时勾选「UTF-8 文件名」，从源头避免问题
Qt / Java / Python 程序输出中文乱码
程序自身输出中文变 ???? 或控制台直接崩溃，通常不是系统级 locale 问题，而是应用层未显式声明编码或调用错误 API。
- Python 脚本开头加
# -*- coding: utf-8 -*-仅影响源码解析，不影响print()输出 —— 关键是确保sys.stdout.encoding为 UTF-8（可通过export PYTHONIOENCODING=utf-8强制） - Java 控制台乱码：启动时加 JVM 参数
-Dfile.encoding=UTF-8，否则System.out.println("中文")可能被截断 - Qt5+ 显示中文需两步：① 源文件保存为 UTF-8 无 BOM；② 在
main()开头加QTextCodec::setCodecForLocale(QTextCodec::codecForName("UTF-8"))（Qt6 已移除此 API，改用QString::fromUtf8()显式转换）
已存在的乱码文件名怎么删/重命名
文件名本身是乱码（比如 ./.txt），无法直接 rm 或 mv —— 因为 shell 无法正确解析这些字节序列。
- 用 inode 定位：
ls -i查出乱码文件的 inode 号（如528760） - 按 inode 删除：
find . -inum 528760 -delete（注意：路径必须写.，不能省略） - 更安全的做法是先用
find . -inum 528760 -ls确认目标，再加-exec mv {} newname.txt \;重命名 - ⚠️ 切勿用通配符如
rm *或图形界面批量操作 —— 乱码名可能被 shell 错误扩展，误删其他文件
真正麻烦的从来不是“设个环境变量就解决”，而是当乱码出现在日志、数据库字段、脚本参数甚至进程名里时，你得一层层剥开：是输入时错、存储时错、还是输出时错？每一步的编码契约都得对得上。
