企业官网建设流程全解析

一提到 Windows 命令行，几乎所有人在某个阶段都被中文乱码折磨过：Python 脚本 print 一行中文变成天书，Java 程序启动时的中文提示变成方块，git status 里的中文文件名变成一串\346\226\207\344\273\266，批处理文件里的 echo 中文直接糊成一团。我见过很多人在网上搜索"Windows命令行中文乱码修复工具"，下了一堆所谓修复工具，结果不是杀软报毒就是压根没用。其实乱码这件事根本不需要什么花哨的工具，它就是"代码页、区域设置、字体、文件编码"这四件事在互相打架，把每一层的关系摸清楚，手动两分钟就能治好。这篇文章我不打算给一个"万能工具"，而是把 Windows 命令行中文乱码的完整排查和修复思路写清楚，你可以直接照着操作，从临时救急到永久根治全都覆盖。

1. 先辨认你的乱码长什么样：不同"乱法"对应不同病因

1.1 问号、方块和怪字符，其实是三种不同的病

很多人一见到乱码就急着搜"修复工具"，但乱码跟感冒一样，同样是流鼻涕，病因可能是病毒也可能是过敏。Windows 命令行里的中文乱码，大致就分三种形态，你不妨先看一眼屏幕再动手。

第一种是满屏的问号，比如????????。这种情况几乎可以确定是某个程序往控制台输出字节时，控制台根本不知道该用什么编码去解读，于是把每个无法识别的字节都替换成了问号。它常见于老旧程序、或者代码里硬编码了某种编码、但控制台代码页完全不匹配的场景。这种乱码在 CMD 里尤其多，因为 CMD 默认的代码页是 936（GBK），而很多新程序默认输出 UTF-8。

第二种是方块、竖条或者空白的"豆腐块"。这个和编码关系不大，主要原因是控制台字体里没有对应的字形。Windows 自带的点阵字体（就是 CMD 属性里那个"点阵字体"）只包含有限的几个字符集，遇到一些生僻字、特殊符号或者 emoji 时直接显示成方块。解决办法不是改编码，而是把控制台字体改成 TrueType 字体，比如"新宋体"或者"Consolas"。

第三种是最让人抓狂的"乱码中的乱码"，比如鏄傝鏄傝、鈥斺€斺€�、涓浗、绋嬪簭这一类。它的特点是"看起来也是汉字，但每个字都不对"。这种情况本质上是你给控制台的字节和它用来解码的代码页对不上，输入的是 UTF-8 字节，却被按 GBK 解码了。这种"解码错位"是最常见、也是被讨论最多的乱码类型。

1.2 "锟斤拷"和"烫烫烫"是怎么来的

如果你在乱码里看到过锟斤拷三个字，那说明你遇到了一个非常经典的编码事故。要解释它，得先知道 GBK 解码有一个"补位字符"的机制：当遇到无法映射的字节序列时，解码头会强制塞一个替代字符进去。UTF-8 的字节流被 GBK 强行解码，遇到识别不了的连续字节，就会被替换成锟斤拷这种固定组合。

烫烫烫是另一回事。它来自 MSVC 编译器在 Debug 模式下对未初始化内存填充的0xCC字节。0xCC连续出现时，按 GBK 解码就变成了"烫烫烫"。这算编码界的"祖传彩蛋"，如果你在乱码里看见"烫"和"屯"，八成不是编码问题，而是程序读取了未初始化的内存。

还有一类是馃挭、馃槑这样的开头，这是 emoji 或者生僻 Unicode 字符的 UTF-8 字节，被 GBK 解码后的"面目全非"效果。判断方法很简单：乱码里如果出现大量"馃"开头的字，基本可以确定是 UTF-8 字节被 GBK/CP936 解码了，你的修复方向就锁定在"让控制台改用 UTF-8 代码页"上。

1.3 为什么同一个乱码在不同机器上表现不一样

这里要引出第一个反直觉的结论：相同的一段代码，在 A 机器上乱码、在 B 机器上正常，不代表 A 机器有病毒或者系统坏了，它只是说明两台机器的默认代码页或区域设置不一样。Windows 的中文版系统默认 ANSI 代码页是 936（GBK），CMD 的 OEM 代码页也是 936；而英文版系统默认是 437 或 1252。如果你在一台区域设置是英文的机器上跑一个假设输出 GBK 字节的老程序，那乱码的表现肯定和中文系统不一样。

所以排查乱码的第一步不是找工具，而是先回答三个问题：程序输出的是什么编码？字符串在内存里是什么编码？控制台拿什么代码页去解码？这三个答案对不上，乱码就是必然。下面开始一层层看。

2. 控制台中文显示的三块底层拼图：代码页、区域设置与字体

2.1 代码页：控制台在用什么编码解码

Windows 控制台（无论是 CMD、PowerShell 还是 Windows Terminal 里跑命令行的宿主）本质上是一个"字节翻译器"。程序往 stdout 管道里写字节，控制台拿自己的代码页（Code Page）去把这些字节翻译成字符，再交给字体渲染。

每个命令行会话都有两个关键代码页：

• 输入代码页（Console CP），用来解释你键盘敲进去的内容；
• 输出代码页（Output CP），用来解释程序输出的字节。

在 CMD 里敲chcp就能看到当前输出代码页。中文 Windows 上通常是936，也就是 GBK。chcp 65001就是把它切到 UTF-8。

这里必须澄清一个常见误解：代码页只影响"控制台怎么解释字节"，不影响"文件保存在磁盘上的编码"。你磁盘上那个.py文件是 UTF-8 也好、GBK 也好，控制台根本不在意，它只在意程序打出来的字节本身是什么编码。这也是为什么同样一个程序，放到不同代码页的控制台上跑，输出结果完全不同。

PowerShell 用户要注意：PowerShell 5.1 和 CMD 共用一个 conhost 宿主，受同样的代码页支配；PowerShell 7 虽然默认启动是 UTF-8 无 BOM 输出，但如果你在 PowerShell 5.1 里运行脚本，输出编码仍然老实跟着[Console]::OutputEncoding走。这个差异后面再展开。

2.2 系统区域设置里那三个代码页的关系

在控制面板里找到"时钟和区域"→"更改日期、时间或数字格式"→"管理"→"更改系统区域设置"，你会看到一个"非 Unicode 程序的语言"下拉框。这个下拉框控制的是整个系统的三套代码页：ANSI 代码页（ACP）、OEM 代码页（OEMCP）和 Mac 代码页（MACCP）。

• ACP（活动 ANSI 代码页）主要影响那些调用 ANSI API 的老程序，比如用fopen、CreateFileA读写文本文件的老 C/C++ 程序。
• OEMCP 主要影响控制台和命令行工具，CMD 默认的输出代码页就来自 OEMCP。
• MACCP 现在已经基本没人用了，不用管。

在中文区域设置下，ACP 和 OEMCP 都是 936。当你在"区域设置"窗口里把系统区域改成"英语（美国）"，这三套代码页会变成 1252 和 437。这就是为什么中文程序在英文系统上乱码、在中文系统上正常——不是程序坏了，是系统默认的 ACP/OEMCP 变了。

特别提醒一下：那个"Beta：使用 Unicode UTF-8 提供全球语言支持"复选框，表面上把系统默认编码切成了 UTF-8，实际上它把 ACP 改成了 65001。很多人勾选后确实解决了一堆乱码，但也可能让一些老软件出现新乱码，原因就在于此（后文有详细说明）。

2.3 字体和终端渲染：显示不出的字不一定是编码错

编码对了，但屏幕上还是方块，这种问题常被误判为"还是乱码"。我遇到过一整个下午都在用chcp切来切去，最后才发现是字体问题。

Windows 控制台的默认渲染方式有两种：新版本 Windows Terminal 和较新的 conhost 默认用 TrueType 字体渲染，字体可以从"新宋体""宋体""Consolas""NSimSun"等里面选；但旧版 CMD 窗口在属性里允许你选"点阵字体"（也就是 Raster Fonts），这种字体没有完整的中文字形表。你用点阵字体去渲染一个 UTF-8 编码的中文字符串，只要字符稍微生僻一点，渲染层统一显示为方块。

所以当你发现中文变成了清一色的"方块"而不是"乱码符号"时，第一件事不是改编码，而是去 CMD 窗口标题栏右键→"属性"→"字体"，选一个 TrueType 字体，比如"新宋体"或者"Microsoft YaHei UI"，一般立刻就好了。Windows Terminal 的设置里也有字体配置，通常默认字体Cascadia Mono对中文显示支持并不好，我会改绑成正文字体，再单独设置一个中文字体兜底，效果会稳定很多。

3. 最常用的临时修复：chcp 65001 到底改了什么，为什么有时不顶用

3.1 chcp 65001 的正确用法和它的历史包袱

chcp 65001大概是被引用最多的"Windows 中文乱码修复命令"，没有之一。它的作用是把当前控制台的输出和输入代码页临时切换到 UTF-8。你在 CMD 里输入：

chcp 65001

然后再跑之前的程序，中文大概率就正常了。但我必须说清楚一个细节：chcp只对"当前控制台窗口"生效，关掉窗口再开一个新的，代码页又变回默认的 936。如果你只是在当前会话里临时跑一次，这个方法最轻量。

不过chcp 65001在 Windows 10 之前有个著名的坑：控制台切换到 65001 后，某些程序（尤其是不走 Console API、直接往句柄里写字节的老程序）会出现输出错位、滚动异常、甚至直接崩溃。Win10 之后 conhost 重写了很多底层逻辑，这个问题好了不少，但一些老工具仍然会出问题。

还有一个细节：在 CMD 里执行chcp 65001之后，如果批处理脚本里含有 GBK 编码的中文注释或者中文 echo 内容，这些内容反而会马上乱掉，因为解释器已经把代码页切到 UTF-8，而脚本文件里的字节还是 GBK。这引出了批处理脚本最常见的坑（后面单独讲）。

3.2 为什么 chcp 65001 对某些程序无效

你敲了chcp 65001，然后运行一个 Java 程序，发现还是乱码。这时候不要怀疑命令没执行，而是程序自己在内部重新设定了输出编码，或者它压根不往控制台写字节，而是通过System.out走了一趟 JVM 的编码转换。

Java 是这类问题的高发区：JVM 在 Windows 上有一个file.encoding属性，JDK 17 及更早版本里它默认跟随系统 ACP（也就是 GBK 936）。这就意味着哪怕你控制台代码页已经是 65001，JVM 内部还是用 GBK 对System.out的字符串做编码，吐出来的字节是 GBK，控制台按 UTF-8 解读自然乱码。这种场景属于"程序内部控制编码"和"控制台解码编码"两层不匹配，单靠chcp根本治不了，必须在程序层面指定输出编码（具体见第 4 节）。

另外，PowerShell 5.1 里如果只想临时看一次输出，更干净的做法是配合管道：

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

这个作用是直接设置当前控制台的输出编码对象，和chcp 65001等效，但对 PowerShell 内部的字符串管道操作来说更可控一些。

3.3 用控制面板和注册表临时切换默认代码页

如果你想省掉每次都要敲chcp 65001的麻烦，可以改系统默认 OEMCP。最直观的做法是"控制面板→区域→管理→更改系统区域设置"，把"非 Unicode 程序的语言"改成"英语（美国）"或者在系统区域设置里勾选 Beta 版 UTF-8。但这么改影响面非常大，我不建议新手直接去勾 Beta 选项，折腾完可能别的软件先乱掉。

更精准的做法是改注册表。以管理员身份打开regedit，定位到：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage

这个键下可以看到ACP、OEMCP、MACCP三个值。把OEMCP从936改成65001，重启后所有新开的 CMD 窗口默认就是 UTF-8 代码页了。这样改比勾选 Beta 选项的影响面小，因为 ANSI 程序读取文件的 ACP 还是 936，只有控制台输出层被切换成 UTF-8。

提示：改注册表之前务必备份该键的键值，改完需要重启或注销才生效。65001 在某些老程序下仍然有兼容问题，如果你后面发现别的命令行工具不正常，把OEMCP恢复成936即可。

4. 按场景逐个击破：Python、Java、Git、批处理这四种典型乱码的修复思路

4.1 Python：PYTHONIOENCODING 和 PYTHONUTF8

Python 在 Windows 命令行的中文乱码，核心是 stdout 的编码匹配问题。Python 3 的默认字符串编码是 UTF-8，但这只是"字符串在内存中"的事，当print()把文本输出到控制台时，Python 会先用sys.stdout的编码把它转成字节。这个编码在 Windows 上默认是"跟随控制台代码页"——控制台是 936 就用 GBK 输出，控制台是 65001 就用 UTF-8 输出。如果你用chcp 65001切了页面，Python 输出就没问题；如果没切，输出 GBK 到控制台，控制台也在用 GBK 解码，其实也没问题。所以纯 Python 的print乱码不多，真正乱的是重定向到文件时。

比如你在 CMD 里执行：

python myscript.py > output.txt

这行命令输出去的不是"控制台"，而是一个重定向管道。这时候 Python 不再用控制台代码页，而是用文件输出流编码，Windows 中文系统下默认可能还是 GBK。如果你脚本内部指定了 UTF-8，磁盘上的output.txt被 GBK 解析就会乱。解决办法是在脚本开头固定环境变量：

set PYTHONIOENCODING=utf-8 set PYTHONUTF8=1 python myscript.py > output.txt

PYTHONIOENCODING直接指定 stdin/stdout 的编码，PYTHONUTF8（Python 3.7+）把运行时默认编码强制切到 UTF-8。如果你用 PyCharm 这类 IDE，也可以把环境变量固话在运行配置里；如果你用 Docker 容器跑 Python，容器里默认 locale 经常是空的，这个变量同样重要。

4.2 Java：JDK 18 前后的 file.encoding 变化

Java 的乱码问题比 Python 更隐蔽，因为涉及 JVM 这一层编码转换。在 JDK 18 之前，Windows 上System.out默认编码是跟随系统区域的file.encoding，中文环境下就是 GBK。哪怕你在代码里写的是标准字符串，输出到控制台时被 JVM 编码成 GBK，但 CMD 控制台已经被你切成了 UTF-8，于是乱码。

最可靠的临时修法是在启动参数里强行指定编码：

java -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 -jar myapp.jar

JDK 18 开始，JEP 400 把 Java 默认字符集改成了 UTF-8，上述参数在新版本里已经不是必须。但很多企业项目还在用 JDK 8、JDK 11、JDK 17，所以这两个参数依然是排查 Java 启动脚本乱码的必修课。如果你用的是 Eclipse 或 IDEA，也可以在建 Run Configuration 的 VM options 里加，效果一样。

顺带提一个经常被忽略的点：如果你不是直接运行 Java 进程，而是通过 Maven 或 Gradle 启动子进程，那还需要注意 Maven 自身的编码参数。Maven 工具链里有一个project.build.sourceEncoding，在pom.xml中显式设置 UTF-8 能避免编译阶段源码被系统默认编码误读。源码编码错了，编译出来的 class 字符串就会"从根上烂掉"，控制台怎么设置都白搭。

4.3 Git for Windows：文件名转义与 log 乱码

Git 在 Windows 命令行里有两种典型乱码。

第一种是git status里中文文件名显示成"\346\226\207\344\273\266.txt"这样的八进制转义。这不是编码错误，是 Git 默认对非 ASCII 文件名做了 escaping。修复方式很温和：

git config --global core.quotepath false

设置完再跑git status，中文文件名就可以正常显示了。

第二种是git log里提交信息中的中文乱码。提交信息里的中文是用 UTF-8 写入对象库的，但 Windows 的 less 查看器默认用当前控制台代码页去解码。凑凑合合的做法：

git config --global i18n.logOutputEncoding utf-8 git config --global core.pager "less -r"

然后在当前控制台执行chcp 65001，再git log，一般就能正常显示了。如果还不行，检查一下你 Git 提交时本身是不是按 UTF-8 提交的——如果 Git 在core.commitEncoding上被设置成了别的编码，输出端再修也白搭。

4.4 批处理文件：最容易踩的"文件保存编码"坑

这是所有乱码问题里"坑"最多的一个，因为批处理文件（.bat/.cmd）的乱码取决于记事本用哪种编码保存它，而不是 CMD 当前代码页。假设你在 CMD 里运行一个含中文echo的 bat，屏幕上出现乱码，通常是因为文件保存成了 UTF-8，而 CMD 默认用 GBK 解释。

这类问题的标准解法其实有两个流派：

• 流派一：把 bat 文件另存为 ANSI/GBK 编码，这样在任何默认中文区域设置的机器上运行都没问题。
• 流派二：文件头部加上chcp 65001 >nul，文件保存为 UTF-8 with BOM。

问题在于，很多文本编辑器默认用 UTF-8 无 BOM 保存。如果 bat 是 UTF-8 无 BOM 且第一行就chcp 65001，那么受历史 bug 影响，CMD 在代码页切换前后对"当前批处理文件"的解析可能错乱，导致后面的中文回显乱掉。微软后来在较新系统上修复了部分问题，但兼容性仍然不能打保票。

我给一个最省心的经验性答案：批处理文件里尽量不写中文，如果必须写，且你的脚本要分发给别人，就统一用 ANSI/GBK 保存，并在文件开头不加chcp 65001。如果是自己机器上用，且你已把系统 OEMCP 改成了 65001，那就保持 UTF-8 保存即可。批量处理文件编码这件事永远要"文件编码"和"调用方代码页"同步看向，别只调一边。

4.5 顺带一提：数据库命令行与 SSH 会话

MySQL 命令行客户端mysql查询中文乱码时，通常要考虑两层：一是客户端到服务端的连接字符集，二是控制台代码页。裸连时执行：

mysql -uroot -p --default-character-set=utf8mb4

这条参数只管客户端和服务器之间的字符集转换。如果控制台还是 936，你在 GBK 控制台看 UTF-8 的返回内容，仍然是乱。通常配合chcp 65001一起用才稳妥。

如果你是用 SSH 远程连到 Linux 服务器，在 Windows 自带命令行里看中文乱码，同样的道理：服务端输出的 UTF-8 字节流没有问题，问题在你的 Windows 控制台用了 GBK 解码。所以在 Windows Terminal、XShell 或 MobaXterm 这类终端模拟器里把 Session 编码设成 UTF-8，比在服务器层面折腾 locale 更直接。

5. 比较省心的根治思路：Windows Terminal、PowerShell 7 与系统级设置

5.1 Windows Terminal 解决了什么、没解决什么

微软这几年大力推的 Windows Terminal，不是一个简单的"新 cmd 皮肤"，它把控制台后端从 conhost 换成了 OpenConsole，在编码处理上确实强了很多。比如 Windows Terminal 里的 Tab 页可以自定义命令行程序，每一个 profile 都可以指定启动参数。你可以在 profile 的 commandline 字段里写：

cmd /k chcp 65001 >nul

这样打开这个 Tab 就是 UTF-8 代码页。PowerShell 的 profile 也可以类似处理。此外，Windows Terminal 对 Unicode 字体渲染的支持比老控制台好得多，你设置一个支持中文的字体，基本就不会出现方块。

但它"没解决"的是什么？它只是一个终端模拟器，程序往管道里吐字节、以及 JVM/Python 内部怎么编码，它是管不了的。所以即使在 Windows Terminal 里，Java 程序如果不加-Dfile.encoding=UTF-8该乱码照样乱。新瓶装旧酒，底层的编码链路并没有变。

5.2 PowerShell 5.1 与 PowerShell 7 的输出编码差异

Windows 自带的 PowerShell 5.1 和从微软商店安装的 PowerShell 7（pwsh）在编码行为上差异很大。

PowerShell 5.1 使用 .NET Framework，跨进程时它往 stdout 管道里输出的字节编码，由$OutputEncoding决定，这个变量默认在 Windows 中文系统上是 ASCII，遇到中文字符容易直接变成?。很多人在 PowerShell 里跑curl或python，中文变成问号，根因就在$OutputEncoding。改法是在$PROFILE里加：

$OutputEncoding = [System.Text.UTF8Encoding]::new() [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

PowerShell 7 基于 .NET 5+，默认控制台输出就是 UTF-8，整体问题少了一大截。但如果你在 PowerShell 7 里调用一个老的 exe，这个 exe 往管道里写的是 GBK 字节，PowerShell 能正确解码吗？不能，它不会自动猜编码，你需要显式处理。最实用的心态是：凡是跨语言、跨进程的东西，永远显式指定编码比依赖默认值更安全。

5.3 系统级 "Beta UTF-8" 选项：一劳永逸还是后患无穷

控制面板"区域→管理→更改系统区域设置"里那个"Beta：使用 Unicode UTF-8 提供全球语言支持"，从效果上看就是把整个系统的 ACP、OEMCP 都改成 65001，理论上所有新程序都默认 UTF-8，中文乱码从根上消失。

我的观点是：不建议为了"解决 CMD 乱码"去勾选它，原因有三个。 一是它会改变系统全局 ANSI 编码，那些老程序按 GBK 读取文本文件会瞬间变成乱码，你不是在修乱码，是在制造新乱码； 二是它要求重启，而且部分旧版软件、游戏、银行控件和某个行业软件极容易因为 ACP 变化而出现字体或文本异常； 三是你没有必要用它——本文前面提到的所有方案，已经能在不改变全局区域设置的前提下解决 99% 的命令行乱码。全局改动留给那些确实被乱码逼到墙角、且系统里没有老软件依赖的人，而且要做之前务必先拍快照。

5.4 一套我自己在用的环境变量配置

最后分享我自己的习惯做法。我个人的主力终端是 Windows Terminal + PowerShell 7，然后我在系统环境变量里固定了以下值：

PYTHONIOENCODING=utf-8 PYTHONUTF8=1 JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 LESSCHARSET=utf-8

JAVA_TOOL_OPTIONS会被 JVM 自动读取，相当于给所有 Java 进程默认加上了 UTF-8 启动参数，不用每个脚本都写一遍。LESSCHARSET对 Git 的 less 分页也很奏效。这套组合配合 Windows Terminal 的 UTF-8 默认输出，能覆盖 90% 以上的日常开发场景。

注意：JAVA_TOOL_OPTIONS对 JVM 进程是全局生效的，如果你某个老 Java 应用确实依赖 GBK 编码，这种全局配置可能破坏它，使用前想清楚。

6. 写在最后的排查顺序与几处容易误操作的细节

6.1 我的排查顺序（从五分钟到彻底解决）

遇到任何命令行中文乱码，我建议你按这个顺序走，不要一上来就动注册表：

1. 先确认乱码形态：问号？方块？还是"汉字但是字不对"？
2. 如果是方块，先换终端字体。CMD 里右键设置，Windows Terminal 里 Ctrl+Shift+逗号 打开配置文件改字体。
3. 如果是"汉字但不对"或者问号，先运行chcp看当前代码页，再运行chcp 65001看是否恢复。恢复，说明是临时代码页问题；不恢复，继续下一步。
4. 判断乱码来自什么程序：是 Python/Java/Node 等语言运行时，还是 Git、MySQL 等工具，再按对应场景设置环境变量或参数。
5. 如果问题反复出现、每次都要手动切代码页，再把 OEMCP 注册表值改成 65001，或者用 Windows Terminal profile 固定/k chcp 65001。
6. 最后一个选项才是改系统区域设置的 Beta UTF-8 选项。

6.2 容易被误导的三类"经验"

网上关于乱码的说法很多，但有几类我建议你直接跳过。

第一类：让你下载"命令行乱码修复工具"来一键修复的。这种工具的本质通常就是替你执行chcp或者改注册表，完全没有必要引入一个额外的二进制文件，尤其来源不明的工具还可能捆绑别的玩意儿。

第二类："把系统区域设置改成英语（美国）就能解决"。这种说法只适合一部分特定场景，因为切成英语区虽然让 CMD 的 OEMCP 变成了 437，但大多数程序输出的 UTF-8 字节在 437 下同样乱。它只是把一种乱码换成了另一种乱码。

第三类："保存成 UTF-8 with BOM 就行"。BOM 只在部分文件类型（比如批处理、部分文本解析）里有意义，对于一般的源码文件，BOM 反而可能让编译器在最前面读到一个不可见字符。文件编码的选择要跟着实际用途走，不要看到一个"UTF-8 with BOM"就往上套。

6.3 最后一点个人心得

这么多年的经验让我总结出最核心的一条：Windows 命令行中文乱码没有"万能药"，它永远是"源头的字节编码"和"终端的解码代码页"两件事的对齐问题。你说它简单，确实简单——每次遇到乱码无非就是找一个 chcp 或者一个环境变量的事；你说它复杂，也确实复杂——因为每换一门语言、每换一个工具，它们对"自己应该输出什么编码"的默认假设都不一样。

我个人现在的工作流是这样：系统的 ACP 和 OEMCP 保持默认 936 不动，遇到具体项目就在项目内部、脚本内部、或者终端 profile 里显式固定 UTF-8。这样做的实际体验是：日常编程和现代工具全部 UTF-8 互通，而老业务软件依然按照 GBK 环境运行，两边互不干扰。这个平衡也许不是网上流传的"终极方案"，但三年多用下来，我在命令行里再没有因为中文乱码停下过手头的事。你也可以从最简单的那条路开始试，大概率不需要走到注册表那一步。