1. 乱码的根源先搞清楚是谁在“翻译”中文我最早在Windows上被Git中文乱码坑的时候恨不得砸电脑。打开git status文件名变成\346\265\213\350\257\225.txt这种八进制转义敲完git commit -m 测试查看git log直接显示C6E4B2E2一类的天书更离谱的是Git Bash里跑git diff中文文件内容全是乱码但同一个文件在VS Code里打开却正常。先给结论这不是Git坏了也不是你的Windows坏了而是字符编码的“翻译规则”对不上。Git本身的设计十分“天真”它把文件名、提交信息、文件内容统统当成“字节流”来处理根本不主动判断编码。谁来解读这些字节谁规定“这串字节等于哪个汉字”全靠两端的工具自己商量。Windows中文版的历史包袱特别重老一代控制台默认用GBK代码页936而Git for Windows、VS Code、Windows Terminal这些“新派人”默认按UTF-8处理双方鸡同鸭讲乱码自然就出来了。所以解决乱码的本质只有两条路要么统一编码让存储和处理都落到UTF-8要么做转换在显示层的工具里把GBK翻译成UTF-8。这两条思路贯穿整篇文章下面的每个方案都没有跳出这个框架。2. 中文乱码的三副面孔提交信息、文件名、文件内容我习惯把乱码分三类因为它们的产生机制完全不同修法也完全不一样。最忌讳的做法是网上搜到一条命令然后无脑复制结果提交信息的乱码治好了文件名却还是花的。2.1 提交信息与日志乱码Git元数据在“自说自话”这类是最多人踩的坑。你在命令行执行git commit -m 修复登录页面的中文乱码git log一看commit message变成了一系列转义符号或者乱码但文件内容明明没变化。原因是Git元数据commit、tag、reflog里的信息的编码由i18n.commitEncoding和i18n.logOutputEncoding两个配置决定。commitEncoding告诉Git“提交信息是用什么编码写入的”默认是UTF-8logOutputEncoding告诉Git“日志输出时应该以什么编码显示”默认也UTF-8。如果你的终端或Shell消费的是GBK那么Git按UTF-8输出字节流终端却按GBK去解释不花才怪。反过来说如果你在旧版Windows的cmd里用默认GBK输入中文提交信息Git把这个GBK字节流原样记录再按UTF-8读出来混合那也是一锅粥。2.2 文件名与路径乱码转义序列与quotepathgit status显示中文变成类似\346\265\213\350\257\225.txt的转义串这是Git的第二个著名“反人类”设计core.quotepath默认是true。它的官方解释是“对非ASCII字符进行引号转义显示”目的是兼容老旧终端但放今天看纯粹是添堵。此外还有纯乱码情况文件名本身是GBK编码存储Git按UTF-8读取时找不到对应字符显示成“锟斤拷”这类典型的替换字符。为什么会有GBK编码的文件名因为你可能在某次commit时用了GBK环境的工具链或者从旧版SVN迁移历史时没做转码。后面我会给一个相对稳妥的处理顺序。2.3 文件内容乱码与终端输出乱码显示层和存储层同时出错文件内容乱码要分成两种情况一种是文件在磁盘上本来就是UTF-8编码但你的查看工具或终端用GBK打开另一种是文件在磁盘上就是GBK存的老文件而Git和编辑器都按UTF-8打开。前者是显示层问题改终端配置就行后者是存储层问题要做文件转码或.gitattributes标注。终端输出乱码就更乱了git diff里中文文件名、中文内容混杂而且Windows下默认的less分页器还会对输出做再次处理不设置LESSCHARSET时UTF-8内容和GBK控制台碰撞你会看到一半正常一半乱码的“拼盘”。3. 实操修复先改Git配置再改终端配置修乱码要按“先仓库、再终端、后编辑器”的顺序来。仓库层面的配置决定了“字节流是什么编码”终端和编辑器决定“怎么显示字节流”前后端必须匹配缺一个都是白搭。3.1 核心三连commitEncoding、logOutputEncoding、quotepath打开Git Bash执行这几条命令git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8 git config --global core.quotepath false第一条设置提交信息使用UTF-8编码写入第二条让日志输出时也按UTF-8编码输出第三条关闭路径转义让中文文件名直接显示。这三条是从Git层面解决乱码的基础建议直接放到--global全局配置因为绝大多数现代编辑器写中文文件时默认就是UTF-8你没必要让某个老仓库的特殊编码污染全局默认值。你可以用git config --global --list检查是否生效。提交信息乱码且执行上面配置后仍然异常说明历史提交里的信息“已经坏了”那是存量数据问题需要后续用git filter-branch或git rebase处理新提交不会再有这个问题。3.2 终端层Git Bash、cmd、PowerShell三种环境各就各位Git Bash 的修复方案Git Bash可能是乱码重灾区里的重灾区。它明明是个模拟终端但默认代码页有时不跟Windows走。最有效的做法是改启动环境变量export LANGzh_CN.UTF-8 export LC_ALLzh_CN.UTF-8 export LESSCHARSETutf-8把这三行追加到~/.bashrc或~/.profile让Git Bash会话开始时自动加载。重点是LESSCHARSETutf-8没有这一行Git用less分页查看长日志时中文照样乱。因为less分页器会根据LESSCHARSET决定输出时的字符集转换方式。也可以在Git Bash窗口右上角打开“属性/选项”在“文本”里把字符集改成UTF-8。新版Windows Terminal里的Git Bash配合上述环境变量基本能做到开箱即用。cmd的修复方案老的cmd默认代码页936GBK你可以在Git命令前先切换到UTF-8代码页chcp 65001然后在同一个会话里执行git命令。注意chcp 65001只对当前窗口生效而且某些版本的Windows对65001支持不好会出现光标错位、历史记录混乱。如果副作用的代价太大我更建议你别在cmd里用中文git换到Windows Terminal或VS Code集成终端。PowerShell的修复方案PowerShell 5.1以及更早版本需要显式设置输出编码[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8先把输出编码切到UTF-8再执行git log这类命令。PowerShell 7pwsh默认就是UTF-8问题小很多。Windows Terminal搭配pwsh是个很好的组合。3.3 编辑器层VS Code与Notepad的编码设置VS Code有两个层面的编码设置一个是编辑器的文件编码一个是集成终端的编码。你要是只改终端不改文件关联打开旧GBK文件照样乱码。打开设置Ctrl,搜索files.encoding默认值建议保持utf8。你是不是想问我那旧GBK文件怎么办VS Code有“通过编码重新打开”和“通过编码保存”两个命令。你按CtrlShiftP输入“Change File Encoding”选择GBK打开这个乱码文件再改成UTF-8保存就能把旧文件转码迁到新体系。Notepad在Win10 1903之后默认记事本保存就是UTF-8了但老版本还带BOM。带BOM的UTF-8文件在早期Git for Windows里会被当成非UTF-8处理引发行尾或BOM字符乱码。尽量统一用无BOM的UTF-8保存所有现代工具都不需要BOM来识别编码。4. 文件内容乱码的一次到位处理方案如果你照着上面的配置修完文件名和提交信息都正常了但某个历史文件的diff内容还是乱码那说明文件在仓库里存储的字节不是UTF-8。这就需要在仓库层面做一次转码。4.1 判断文件真实编码先用VS Code或Notepad打开文件看右下角显示的是UTF-8还是ANSI/GBK。更直接的方法是看十六进制字节中文“测”的UTF-8编码是E6 B5 8BGBK编码是B2 E2。你可用xxd或 VS Code的Hex编辑器看一眼开头几个中文的字节。粗暴的检测命令file --mime-encoding foo.txt在Git Bash里对某路径执行如果返回iso-8859-1或unknown-8bit多半是GBK系编码。4.2 小规模仓库的转码迁移文件数量少可以逐个转码后重新提交把文件用VS Code以GBK打开再用UTF-8保存。在项目根目录执行git diff确认改动只有编码变化没有内容漂移。git add这些文件提交一次“手动将残留GBK文件转码为UTF-8”。如果全仓库文件统一是GBK且量很大可写脚本批量转码。这里提供一个Python脚本思路import os from pathlib import Path def convert(src_dir, extsNone): exts exts or {.txt, .md, .java, .py, .js} for p in Path(src_dir).rglob(*): if p.suffix in exts and p.is_file(): try: raw p.read_bytes() if b\xef\xbb\xbf in raw[:3]: raw raw[3:] p.write_bytes(raw) text raw.decode(utf-8) except UnicodeDecodeError: try: text raw.decode(gbk) p.write_text(text, encodingutf-8, newline) print(fconverted: {p}) except UnicodeDecodeError: print(fskip: {p})注意脚本里的p.write_text(..., newline)别让Python自动把\n变成\r\n否则编码错误解决完了行尾错误又冒出来。4.3 .gitattributes把仓库“钉”在UTF-8上转码完成之后我想安利一个绝大多数人不知道的习惯在仓库根目录放一个.gitattributes声明文本文件的属性。写文件也可以* textauto *.txt text *.md text *.java text *.c text *.h texttextauto让Git自动识别文本文件并统一处理行尾没有它Windows和Linux开发者协作时经常因为CRLF/LF互相制造无意义diff。配合core.autocrlf默认值新输入到仓库的文本文件会以LF形式存储检出时Windows上转成CRLF。这样既照顾了Windows工具链也保证了仓库内部的字节统一。我用这个组合后新仓库基本没再出现过文件内容乱码。如果你维护的是一个老仓库不想马上让全仓库diff翻天覆地建议分步骤先加.gitattributes但不提交大改接着统一文件转码最后一次性提交。5. 排查速查表与常见误区以下是我在实际群里、公司内网和各种技术社区里见过的典型问题做成速查表方便你按症状对号入座。乱码现象根源处理手段git status显示\346\265\213...转义串core.quotepath默认开启转义git config --global core.quotepath falsegit log中文变C6E4乱码或问号i18n.commitEncoding/logOutputEncoding与终端不匹配两条配置都设成utf-8终端chcp 65001Git Bash里git diff中文内容乱码终端环境变量缺少UTF-8less分页器字符集不对export LANGzh_CN.UTF-8和LESSCHARSETutf-8文件明明UTF-8但VS Code打开乱码VS Code的files.encoding被动车了或旧文件被误判用“通过编码重新打开”强制选择UTF-8仓库里历史中文文件diff乱码文件实际存储码是GBK用VS Code转码或用脚本统一转成UTF-8后重新提交同一仓库老文件正常、新文件乱码编辑器保存时用了不同编码或有带BOM文件混入统一无BOM UTF-8保存增加.gitattributes5.1 误区一疯狂复制git config却不重开终端Git配置是会话启动时读取的部分终端环境变量更是如此。你改了~/.bashrc不重开一个Git Bash窗口旧的bash会话仍然带着旧的LANG当然“没生效”。碰到配置完了还是乱码第一步永远是把那个终端窗口彻底关掉重开一个新的。5.2 误区二把core.autocrlf当真命天子autocrlf解决的是行尾不是编码。我之前见过一个朋友乱码后瞎折腾把core.autocrlf从true改成false结果Windows上绘制的文件行尾全变成了LF编译环境和某些老旧脚本直接抗议。这个配置的作用特别微妙Windows上推荐core.autocrlftrue提交时转LF检出时转CRLFLinux/macOS上推荐input只保证提交时不把CRLF带进去。它和中文乱码没有直接因果关系别乱动。5.3 误区三以为乱码只靠Git配置就能通杀很多乱码其实是终端字体或后端渲染引擎的老毛病。例如Windows Terminal里如果选择了不支持中文的终端字体中文会显示成方块或问号在Git Bash默认的“Courier New”字体下某些汉字也可能渲染失败。请把终端字体设为“微软雅黑”、“Consolas”或“Cascadia Mono”并勾选“显示所有字体”里的中日韩字体回退。字体问题会让你误以为编码没修好实际上编码层早就是UTF-8了。6. 从踩坑到顺滑我个人的日常实践清单我现在处理Windows下Git中文乱码已经有一套流水线式的固定操作新机器配置半小时搞定这里直接分享给你。安装Git for Windows时在“Adjusting your PATH environment”这一步选“Use Git and optional Unix tools from the Command Prompt”这样cmd和PowerShell也能直接调git。打开Git Bash执行上面三条核心Git配置再把三个环境变量写进~/.bashrc。Windows Terminal里新建一个“Git Bash”配置启动参数指向C:\Program Files\Git\bin\bash.exe把默认字体设为Cascadia Mono默认编码开启UTF-8。这一步能一劳永逸地解决绝大多数终端的显示问题。VS Code设置里把terminal.integrated.defaultProfile.windows指向“Git Bash”或“PowerShell”同时确认files.encoding是utf8。这样在VS Code里敲git命令和看文件内容编码完全一致。新项目建好就传一个.gitattributes然后第一次提交前先确认中文文件名显示正常。我踩过最深的坑是一次跨平台协作我在Windows上提交了一个中文注释的脚本同事在Linux上打开全是锟斤拷。排查到最后才发现是我的一台老笔记本上的某编辑器保存文件时偷偷追加了UTF-8 BOM。那之后我给自己定了个死规矩每个项目里既然已经有.gitattributes所有编辑器的保存编码必须是无BOM UTF-8没有例外。这几条做完你的Windows环境基本就能和网上的中文文档、中文协作仓库顺畅交流了。乱码本质就是编码不统一而统一的标准在2025年的今天毫无疑问是UTF-8。你把存储、传输、显示三层的口径全部切到UTF-8它就没有机会乱残留的旧数据做一次显式转码再靠.gitattributes守住后续入库文件的编码纪律。所谓解决方案说到底就是这三件事。