根本原因是core.quotepath默认为true，Git将UTF-8中文字符转义为八进制序列；执行git config --global core.quotepath false可直出中文名，但需终端编码匹配UTF-8且字体支持。
git status 显示中文路径为八进制转义（如 \346\200\241）
这是最常见现象，本质是 Git 默认对非 ASCII 字符做 quote 处理，把 UTF-8 字节序列原样转成反斜杠+八进制形式输出。它不表示文件名损坏，只是“看起来乱”。
直接执行：git config --global core.quotepath false 即可关闭该行为。此后 git status、git ls-files、git diff 等命令会直出原始字节——但前提是终端能正确解码这些字节。
- Linux 终端一般默认 UTF-8，设完即生效；若
locale输出不含UTF-8（比如显示POSIX或空），需先配置系统 locale（见下一条） - 别在 tmux/screen 里改完就以为好了，它们可能继承旧环境变量，建议新开终端或运行
source ~/.bashrc - 如果仓库已存在大量乱码路径记录（比如之前用 quote 模式 commit 过），
core.quotepath=false只影响后续输出，历史 log 仍需单独处理
终端本身不支持 UTF-8 或 locale 未启用中文
core.quotepath=false 是必要条件，但不是充分条件。很多用户卡在这一步：Git 配对了，终端却还是显示方块或问号。
先检查当前环境：locale 命令输出中，LANG 和 LC_CTYPE 必须包含 zh_CN.UTF-8 或 en_US.UTF-8 类似值。若为空或为 POSIX，说明系统级 UTF-8 支持未激活。
- 运行
locale -a | grep zh_CN.UTF-8查看是否已生成该 locale；没有则需sudo locale-gen zh_CN.UTF-8+sudo update-locale LANG=zh_CN.UTF-8 - 用户级临时修复：在
~/.bashrc或~/.zshrc末尾加export LANG=zh_CN.UTF-8和export LC_ALL=zh_CN.UTF-8，再source一次 - GNOME/KDE 终端需确认字体设置含中文字体（如
Noto Sans CJK SC），且菜单中「字符编码」明确选为UTF-8
git log 提交信息或作者名中文乱码
core.quotepath 不管 log 内容，它只管文件路径。log 乱码是另一套编码链断裂所致：commit 时存的编码 ≠ log 输出时用的解码器 ≠ 分页器（less）渲染时的字符集。
三步配齐：
-
git config --global i18n.commitencoding utf-8：告诉 Git “我写 commit message 用的是 UTF-8”，避免它误猜成 GBK -
git config --global i18n.logoutputencoding utf-8：强制 log 输出走 UTF-8 编码（Git 2.31+ 中该选项渐进废弃，但 Linux 上仍建议保留） -
export LESSCHARSET=utf-8加入 shell 配置：让分页器less正确渲染 UTF-8 字节，否则即使 Git 输出对了，less也会按默认编码错解
注意：i18n.logoutputencoding 在较新 Git 中可能被忽略，若无效，可尝试 export GIT_PAGER="less -r" 作为补充。
SSH 远程操作时中文路径突然变乱码
本地终端正常，但通过 SSH 连到服务器后 git status 又出现八进制转义，大概率是 SSH 会话没传 locale 环境变量过去。
检查远程服务器的 /etc/ssh/sshd_config 是否含 AcceptEnv LANG LC_*；再看本地 ~/.ssh/config 对应 Host 是否有 SendEnv LANG LC_*。两者缺一不可。
- 改完服务端配置需重启 sshd：
sudo systemctl restart sshd - 某些旧版 OpenSSH 客户端默认不发 locale，可临时测试：
LANG=zh_CN.UTF-8 ssh user@host - 如果服务器上
locale本身就不含 UTF-8，光传变量也没用，得先在服务端生成并启用对应 locale
真正容易被忽略的，是终端模拟器字体和 SSH 环境变量这两层——Git 配置调得再准，字体不支持或 locale 传不过去，照样显示为方块。
