Windows终端中文乱码排查：代码页与UTF-8修复方案

微软专家

在 Windows 下用 PowerShell 处理中文时，管道输出乱码是常见的老问题。很多用户升级到 PowerShell 7 后依然遇到，原因往往不在版本，而在于系统代码页仍停留在 GBK。本文从诊断、修复到原理，完整梳理这条链路，帮助你一次性解决终端中文乱码。

一、30 秒诊断当前环境

首先确认系统代码页和 PowerShell 输出编码是否一致。在 pwsh 中运行以下脚本：

2. pwsh -NoProfile -Command '
3. $oem = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Nls\CodePage").OEMCP
4. $cp = [Console]::OutputEncoding.CodePage
5. $verdict = if ($cp -eq 65001) { "环境正常，管道中文不会乱" } else { "GBK 环境，管道中文会乱 → 执行第二步" }
6. "系统代码页 OEMCP = $oem"
7. "pwsh 管道输出编码 = $cp"
8. "判定: $verdict"
9. '

复制代码

如果输出显示 OEMCP 和输出编码都是 936，说明系统处于 GBK 环境，管道中文输出会被发送端按 GBK 编码，而接收端按 UTF-8 解码，从而乱码。如果显示 65001，说明环境已配置为 UTF-8，无需修复。

二、将系统代码页切换为 UTF-8

核心操作是修改注册表中的三个代码页键：ACP、OEMCP、MACCP，全部改为 65001。修改前先备份：

2. reg export "HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage" "$HOME\code-page-backup.reg" /y

复制代码

然后写入新值：

2. reg add "HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage" /v ACP /t REG_SZ /d 65001 /f
3. reg add "HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage" /v OEMCP /t REG_SZ /d 65001 /f
4. reg add "HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage" /v MACCP /t REG_SZ /d 65001 /f

复制代码

如果不想敲命令，也可以通过图形界面完成：控制面板 → 区域 → 管理 → 更改系统区域设置 → 勾选“Beta: 使用 Unicode UTF-8 提供全球语言支持”。本质上和修改注册表是同一件事。

修改完成后不需要重启，新进程会立即生效。验证方式如下：

2. pwsh -NoProfile -Command '[Console]::OutputEncoding.CodePage'
3. pwsh -NoProfile -Command "Write-Output '中文测试'"

复制代码

如果输出为 65001，且中文正常显示，说明修复成功。

动手前需要了解的几个安全点：

- 修改内容：系统 3 个代码页注册表键 ACP / OEMCP / MACCP，全部改为 65001。
- 回滚方法：使用备份文件恢复，或直接删除这三个键。
- 权限要求：reg add 到 HKLM 需要管理员权限。
- 潜在影响：极少数硬编码 GBK 的老软件可能出现显示乱码，现代开发工具基本不受影响。

这三个键分别控制不同场景的编码：

- ACP：Win32 ANSI 字符串，影响非 Unicode 程序的窄字符串 API。硬编码 GBK 的老 GUI 软件是主要风险源，现代工具走 Unicode API，不受影响。
- OEMCP：控制台和管道输出编码。cmd、pwsh 的管道输出都依赖它，本次乱码的根源就在这里。
- MACCP：古 Macintosh 兼容，基本已废弃，图形界面勾选时会一并修改。

三、乱码的本质：字节错位

乱码的根本原因是发送端和接收端使用了不同的编码。与其靠猜，不如直接查看发送端输出的原始字节。

例如在 Linux/类 Unix 环境下用 od 查看：

2. $ echo '中文测试' | od -A x -t x1z
3. e4 b8 ad e6 96 87 e6 b5 8b e8 af 95
5. $ pwsh -NoProfile -Command "Write-Output '中文测试'" | od -A x -t x1z
6. d6 d0 ce c4 b2 e2 ca d4

复制代码

同样四个汉字，UTF-8 的字节以 e4 b8 ad 开头，GBK 的字节以 d6 d0 开头。看到 d6 d0 就可以断定是 GBK 编码的数据被按 UTF-8 解读了。

四、四种乱码类型与应对方向

“乱码”是统称，实际按错位环节可分为四类：

1. 文件读写乱码：脚本读取旧文件时中文显示乱码。根因是老文件是 GBK 编码，而现代工具默认按 UTF-8 读取。修法：新文件统一用 UTF-8；读旧 GBK 文件时显式指定 -Encoding GBK，再转存为 UTF-8。

2. 管道传输乱码：程序输出到终端或 CI 环境时乱码。字节特征为 d6 d0 与 e4 b8 ad 的差异。根因是输出用系统代码页 936，而接收端按 UTF-8 解析。修法：将系统代码页改为 65001，这是本文的主线。

3. 终端显示乱码：终端里直接显示乱码。根因是终端代码页与输出字节不一致。修法：将终端编码设为 UTF-8，例如 chcp 65001 或在终端设置中修改。

4. 参数传递乱码：中文参数变成问号或被吞。根因是旧版 PowerShell 的 $OutputEncoding 默认 ASCII。修法：升级到 PowerShell 7，其默认编码为 UTF-8。

整体方向只有一个：能 UTF-8 就 UTF-8。它是国际标准，也是现代工具链的默认值；GBK 是历史遗留，只应出现在“读取旧文件”这一场景。

五、Windows PowerShell 5.1 的编码坑

很多人在 Windows PowerShell 5.1 中写脚本时，UTF-8 编码总是出问题。写出来的文件要么带 BOM，要么被 ANSI 默认值坑，读写双方对不上。实际上有三个机制叠加导致：

1. 解析不认“无 BOM 的 UTF-8”。5.1 读取 .ps1 文件时，如果文件头有 BOM 就按 BOM 解码；没有 BOM 就按系统 ANSI 代码页（中文系统即 GBK）解码。现代编辑器默认保存为 UTF-8 无 BOM，5.1 却按 GBK 读取，中文从解析那一刻就错位了。反过来，pwsh 7 默认按 UTF-8 读取无 BOM 文件，如果喂给它 GBK 文件同样会乱，只是方向相反。

2. 5.1 的输出默认值不统一。例如 > 和 Out-File 默认使用 UTF-16LE（带 BOM），Set-Content 默认使用 ANSI（GBK）。用 5.1 写的“UTF-8 脚本”，实际写出的往往不是 UTF-8，换个工具打开又是一轮乱。

3. $OutputEncoding 默认是 ASCII。脚本把中文传给 git、curl 等原生命令时，中文参数会变成问号。微软官方差异文档确认，5.1 默认 ASCII，7 改为 UTF-8 无 BOM。

PowerShell 7 修复了这三条：无 BOM 按 UTF-8 读、文件默认 UTF-8 无 BOM、$OutputEncoding 默认 UTF-8。但它没有修复第四条——管道和控制台输出仍然跟随系统代码页。这正是“换了 pwsh 7 还乱”的原因。

六、为什么升级到 pwsh 7 后管道乱码依然存在

PowerShell 7 的 UTF-8 默认值只覆盖部分场景：

- 文件输出（Out-File / Set-Content / >）：默认 UTF-8 无 BOM，已修复。
- 管道和控制台输出（stdout 被重定向）：[Console]::OutputEncoding 仍等于系统代码页，中文系统下是 936，所以 GBK 没有变。

Windows PowerShell 5.1 和 PowerShell 7 在管道输出上完全一样，都跟随系统代码页。换版本能治好文件乱码，但管道乱码和版本无关，它由系统代码页决定。所以诊断时查的是 [Console]::OutputEncoding.CodePage，而不是 PowerShell 的版本号。

七、总结

遇到中文乱码，第一步是确认字节，第二步是确认发送端和接收端各自使用的编码，错位在哪一环就修哪一环。对于 Windows 下的管道乱码，最直接的修复方式就是把系统代码页从 936 改为 65001，同时用 pwsh 7 替代 5.1，这样文件读写和参数传递的编码问题也能一并解决。掌握这套方法，以后遇到乱码就不再需要背方案，而是能自己推导出问题所在。

热心网友5

感谢楼主整理！这帖子把乱码链路讲得很清楚了，尤其是“字节错位”那段，用 od 看十六进制一下子就能定位问题，比瞎猜编码省事多了。 我补充一个实际操作中的小经验：改完注册表代码页后，有些老程序（特别是用 Delphi 之类写的）确实可能显示乱码，如果平时不依赖它们，问题不大。另外 PowerShell 5.1 无 BOM 的坑我也踩过，后来统一把脚本格式改成 UTF-8 with BOM 才消停，新项目就直接用 7 了。 建议楼主再提一句：如果只用终端临时管道输出，也可以直接用 `chcp 65001` 加 `$OutputEncoding` 临时救急，不一定要动系统全局。不过整体还是按你说的，能 UTF-8 就 UTF-8，一步到位最省心。

热心网友5

感谢楼主整理得这么清楚，尤其是那个“先看原始字节”的思路特别实用。我之前一直靠猜编码，来回试 chcp 和改注册表，看了这篇终于明白根源在发送端和接收端的代码页不一致。 按你给的诊断脚本跑了一下，果然是 OEMCP 936、输出编码也是 936，属于第二种管道乱码。现在改成 65001 后，PowerShell 7 里管道输出中文就正常了，也没遇到什么副作用。 另外补充一点小经验：如果只是想临时让某个终端会话不乱码，不改注册表的话，可以先 `chcp 65001` 再启动 pwsh，但确实不如你这种一次性改彻底的办法干净。

热心网友5

谢谢楼主，写得很清楚，尤其“字节错位”那部分一下子点醒我了。之前一直以为升级到 PowerShell 7 就万事大吉，结果忘了系统代码页还是 936，管道输出照样乱。按你的方法改了注册表后，新开的终端就正常了。备份那步很贴心，回滚也方便。补充一个小经验：有些老程序确实会受影响，我这边有个古董工具显示就花了，但好在只是显示问题，不影响功能。总之，能统一到 UTF-8 还是最省心的方向。