在 VS Code 里写了个 Python 小脚本print(你好世界)结果终端直接甩给我四个问号????。这不是个例围绕“vscode、终端、汉字、乱码”这几个关键词网上随手一搜就是一大片求助帖而且不只 PythonJava、C、Node 跑起来照样可能翻车。我自己也在这上面折腾过好几次被 Windows 的编码体系按在地上摩擦过之后再回头看其实套路很清晰说穿了就是程序输出给终端的字节编码和终端用于解码的编码没对齐。这篇就把“为什么是???而不是一串乱码”“到底改哪里”“怎么一劳永逸”讲清楚新手可以直接抄配置老手也能当一份排查手册。1. 问题现象与根因分析1.1 先看一眼“???现场”最常见的现场长这样你在 VS Code 里新建了一个test.py文件编码是 UTF-8代码里写着print(你好世界)按 F5 或点终端运行结果终端输出的不是“你好世界”而是????更诡异的是有时候不是问号而是“浣犲ソ锛屼笘鐣?”或者一排。这三种表现看着不一样本质都是编码链路断了。我最早遇到这种情况时第一反应是“是不是 VS Code 坏了”“是不是系统缺中文字体”后来才发现跟字体、插件、编辑器界面都没关系纯粹是终端管道里的字节没人正确翻译。1.2 编码链路三个环节必须对齐要理解这个问题得把“一个汉字从代码到屏幕”走过的路拆开看中间有三个环节源码编码你的.py、.java、.cpp文件用 UTF-8 还是 GBK 保存的VS Code 右下角会显示当前文件编码默认是 UTF-8。程序输出编码程序运行时print、printf、System.out.println把字符串转成字节流时用的是哪种字符集终端解码编码终端拿到这串字节按什么编码去渲染成字符VS Code 的内嵌终端是个基于 xterm.js 的终端模拟器它天生按 UTF-8 解码字节流这一点基本是写死的没有像 Windows 传统控制台那样的chcp开关可以临时切换。所以只要“程序输出编码”不是 UTF-8终端这边就会解码失败。而中文 Windows 系统默认代码页是 936也就是 GBKPowerShell 5.1 和 CMD 控制台默认输出就是 GBK两边口径完全相反乱码就成了必然。打个比方寄件人用简体中文打包了一个包裹GBK 字节收件人却拿繁体中文的说明书去拆包UTF-8 解码拆出来的东西自然不是原样。1.3 问号不是乱码两种异常形态的区别很多人会疑惑为什么有时看到“????”有时看到“涓冩枃”有时是“锟斤拷”这其实是两种不同的失败模式乱字符如“涓冩枃”“锟斤拷”这是 UTF-8 字节被当成 GBK 解码时产生的效果。UTF-8 中“你好”的字节是E4 BD A0 E5 A5 BD按 GBK 两个字节一个字去切恰好切出“浣犲ソ”这种看起来像繁体但完全不认识的东西。简单说解码器“硬解”了给了你一堆错误但可显示的汉字。??? 或 这是解码器发现字节序列不合法、无法映射到任何字符时用替代符顶替的结果。终端按 UTF-8 解析时遇到 GBK 的中文字节比如D6 D0无法识别就把它替换成 UFFFD显示为 或者在某些转码路径上直接变成?。Java 的PrintStream在遇到没法编码的字符时也会输出?。所以???不是“乱码”的另一种写法而是系统在告诉你我收到了字节但我看不懂。这反而比乱字符好诊断——问题基本就出在“输出编码不是 UTF-8”这一侧。2. 动手前先做三件事定位乱码环节2.1 看清你的终端到底是哪一路VS Code 按Ctrl打开终端后右上角有个下拉框里面显示当前用的是哪种终端Windows PowerShell、Command Prompt、Git Bash或者你自己配的 WSL、远程连接。这一步别跳过因为不同终端默认编码完全不一样Windows PowerShell 5.1默认按系统代码页中文系统就是 GBK/936解释输出。PowerShell 7pwsh默认 UTF-8问题少很多。Command Promptcmd看当前chcp显示的代码页默认也是 936。Git Bash / WSL基本按 UTF-8 走一般没事。在终端里直接敲一个字就知道当前代码页chcp看到936说明当前终端代码页是 GBK看到65001才是 UTF-8。绝大多数出问题的机器这里显示的都是936。2.2 记录你运行的程序和版本不同语言栈在 Windows 上的默认输出编码策略不同排查方向也不一样Python3.7 之后交互式控制台默认尝试用 UTF-8但如果 stdout 被重定向或系统区域设置影响仍可能用 GBK。先跑一句python -c import sys; print(sys.stdout.encoding)看输出。JavaJava 17 及以前默认file.encoding跟随系统GBKJava 18 开始默认 UTF-8。C/Cprintf本身不做转码输出什么字节取决于源文件编码和编译器处理MinGW 和 MSVC 还各有差别。Node.js / Go默认 UTF-8一般不需要折腾除非外部文件用 GBK 读取。先把这些基本信息记下来再往下修就不会无头苍蝇。2.3 用“先 chcp 65001 再运行”做一次探测最快的定位实验在 VS Code 终端里手动执行chcp 65001然后再运行你刚才出问题的那个程序。注意这条命令只对当前终端会话生效关掉重开就失效。观察结果分三种情况中文正常了说明程序本身按 UTF-8 输出只是终端代码页不对。直接跳到第 3 节改默认终端配置。依旧 ??? 或 说明程序输出侧就不是 UTF-8终端切到 UTF-8 也没用。需要按第 4 节从代码/环境变量侧修。从 ??? 变成乱字符说明程序输出的其实是 GBK 字节终端从 UTF-8 切到 GBK 反而“硬解”出了字符但你真正需要的是让程序输出 UTF-8。这一个小实验能帮你把“终端问题”和“程序问题”划分开省得后面盲目改 config。3. 最快速的修复让 VS Code 默认终端以 UTF-8 模式启动3.1 方案 A默认终端改为 CMD 并自动 chcp我自己最常用、也最推荐给 Windows 用户的一招是新增一个“Command Prompt (UTF-8)”终端 profile每次启动自动执行chcp 65001。步骤很简单按CtrlShiftP输入Preferences: Open User Settings (JSON)打开settings.json。在配置对象的顶层加入两段terminal.integrated.profiles.windows: { Command Prompt (UTF-8): { path: C:\\Windows\\System32\\cmd.exe, args: [/K, chcp 65001 nul] } }, terminal.integrated.defaultProfile.windows: Command Prompt (UTF-8)重启 VS Code 或关掉终端重开右上角下拉框里应该显示选中的是 “Command Prompt (UTF-8)”。原理说明一下/K表示执行完后面命令后不退出 CMDchcp 65001把代码页切到 UTF-8nul是为了不打印那行 “Active code page: 65001”保持终端干净。我特别推荐 CMD 而不是改 PowerShell是因为 CMD 不自己额外转换编码程序输出什么字节它就往终端丢什么字节配好代码页之后和 UTF-8 程序对接最直接。PowerShell 5.1 中间还有一层Console.OutputEncoding和$OutputEncoding的套娃容易二次踩坑。3.2 方案 BPowerShell 下设置 OutputEncoding 并持久化如果团队或习惯上离不开 PowerShell不想换 CMD也可以给 PowerShell 5.1“打补丁”。先在当前会话里试这两行[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8然后再运行 Python/Java 程序大概率能解决终端显示层的问题。要永久生效就把它们写进 PowerShell 的 profileif (-not (Test-Path $PROFILE)) { New-Item -Path $PROFILE -ItemType File -Force } notepad $PROFILE在打开的 profile 文件里放入上面两行保存重启 VS Code 终端。不过得提醒一句[Console]::OutputEncoding管的是 PowerShell 自身控制台显示$OutputEncoding管的是 PowerShell 向子进程发送内容或接收子进程输出的编码。对python.exe、java.exe这种原生程序来说它们自己决定 stdout 编码PowerShell 这两句不一定能完全约束住。所以保险起见PowerShell 场景下还要配合第 4 节的代码侧方案一起做。3.3 方案 C用 Windows Terminal 或第三方终端工具兜底如果 VS Code 内置终端怎么配都不顺也可以绕开它程序在 Windows Terminal、Tabby 这类终端里跑。Windows Terminal 同样可以给 profile 配置启动参数在它的设置里找到“命令行”填入cmd /K chcp 65001也能达到同样效果。但我个人不建议把“换终端”当成根治手段——问题本质还是编码约定不一致换终端只是换了一个解码环境。你换去 Linux/Mac 或者用 Win10 自带的 Windows Terminal如果程序输出的还是 GBK 字节照样会乱。所以终端配置属于“快修”代码侧的编码统一才是“根治”。4. 更稳的根治代码和项目侧的正确姿势4.1 Python统一源码、运行时、输出三层编码Python 乱码是 VS Code 里投诉量最大的场景我建议按顺序做三步。第一步源码统一 UTF-8。VS Code 右下角如果显示“UTF-8”说明文件没问题如果显示“GBK 等”点它选择“Save with Encoding”存成 UTF-8。也可以在settings.json里锁死files.encoding: utf8, files.autoGuessEncoding: false第二步运行时强制 stdout 为 UTF-8。Python 3.7 可以这样import sys sys.stdout.reconfigure(encodingutf-8)如果你的代码要在老版本跑就用包装器方式import sys import io sys.stdout io.TextIOWrapper(sys.stdout.buffer, encodingutf-8)第三步通过 VS Code 环境变量统一注入免得每个文件都写一遍。在settings.json里加terminal.integrated.env.windows: { PYTHONIOENCODING: utf-8 }这样凡是这个 VS Code 窗口启动的终端Python 解释器都会强制用 UTF-8 编解码标准输入输出。为什么这三层都要做因为我试过只改文件编码、只写reconfigure、只配环境变量单独做任何一样都有可能被系统区域设置带偏三管齐下才算稳。4.2 Java编译参数和运行参数两个都要管Java 在 Windows 下的乱码有两个独立入口编译期和运行期。编译期默认按平台编码读源码如果你源码是 UTF-8 而用 GBK 编译字符串常量直接乱掉运行期System.out默认按file.encoding编码输出。常规手动编译这么做javac -encoding UTF-8 Hello.java java -Dfile.encodingUTF-8 Hello用 Maven 的话在pom.xml里加properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties顺手提一句如果你的 JDK 已经是 18 以上JEP 400 已经把默认字符集改成了 UTF-8很多乱码问题自动消失。我碰到最多的 Java 乱码案例反而是那些还在用 JDK 8 或 JDK 11 的老项目记好这两个参数基本能解。4.3 C/C源文件编码和 Console 编码两头固定C/C 的情况稍微绕一点但原理一样printf不做转码你源码里字符串字面量的字节是什么输出就是什么。所以核心是保证“源码按 UTF-8 存运行环境按 UTF-8 解”。MSVC 编译环境下最省心的是把源文件存成UTF-8 with BOM然后在main开头加#include windows.h int main() { SetConsoleOutputCP(CP_UTF8); // ... }MinGW/g 则更灵活编译时显式告诉编译器字符编解码g -finput-charsetUTF-8 -fexec-charsetUTF-8 main.cpp-finput-charsetUTF-8告诉编译器源码是 UTF-8-fexec-charsetUTF-8告诉编译器把窄字符串常量转成 UTF-8 字节。这样就算运行终端还是 GBK至少字节进到终端前已经是 UTF-8再用第 3 节的chcp 65001就完整闭环了。4.4 Node.js 与 Go 顺带一提Node.js 和 Go 默认都是 UTF-8一般情况下根本不会出现???。真出现的话多半不是程序输出问题而是Node 读取了 GBK 编码的外部文件没做转码Windows 控制台字体不支持中文显示字体问题不是编码问题Go 在 Windows 控制台下输出中文偶发遇到代码页不匹配直接套用SetConsoleOutputCP(CP_UTF8)或chcp 65001即可。不要把力气花在它们身上先查来源文件编码。5. 实操记录一次完整的排查与修复5.1 现场复现我上周在一台 Windows 11 中文版机器上又遇到了这个经典问题。环境信息如下VS Code 1.85内嵌终端用的是默认 Windows PowerShellPython 3.11代码文件test.py保存为 UTF-8内容只有一个print运行后终端输出????。在 PowerShell 里执行chcp显示936。再看sys.stdout.encoding输出是gbk。链路切到这儿问题已经很清楚了Python 把“你好世界”按 GBK 编码成字节终端按 UTF-8 解码GBK 的字节不是合法 UTF-8 序列被替换成问号。5.2 逐步修复过程我没有改系统设置只动了 VS Code 配置。按上一节的方案 A在settings.json里加了“Command Prompt (UTF-8)” profile并把默认终端切过去。重启终端后右上下拉框显示当前终端是“Command Prompt (UTF-8)”手动敲chcp输出65001。再跑python test.py屏幕上稳稳打出你好世界顺带验证一下 Java同一个 Java 文件UTF-8 源码先javac -encoding UTF-8 Hello.java再java -Dfile.encodingUTF-8 Hello输出也正常。这套组合在后续几天里没再复发。5.3 修复后遇到的新坑修好之后倒是引出一个新问题机器上有个老旧的批处理脚本里面用type输出一个 GBK 编码的日志文件以前在默认 PowerShell 里显示得好好的切到 UTF-8 CMD 之后日志中文变成了乱字符。这就是编码统一的代价——终端按 UTF-8 解码后GBK 内容就“硬解”出乱码了。我的处理方式是给那个老脚本单独留一个“Command Prompt (Default)”profile就是不带/K chcp 65001的普通 CMD需要用老脚本时手动切换过去日常开发用 UTF-8 profile。这也是我不建议在公司全员电脑上直接开“系统 Beta UTF-8”的原因之一后面讲。5.4 顺手补充一个 Linux/WSL 场景同一天同事在 WSL 里ls一个从 Windows 拷过来的目录中文文件名全是???。这跟 VS Code 终端没直接关系但排查思路一样。在 WSL 终端跑locale发现LANG是C.UTF-8且系统没有装完整的zh_CN.UTF-8locale导致文件名里的中文字节无法映射。修法sudo locale-gen zh_CN.UTF-8 export LANGzh_CN.UTF-8把export写进~/.bashrc就能持久化。另外Windows 上压缩的 zip 在 Linux 下解压乱码的问题很常见因为 zip 里的文件名编码是 GBKLinux 默认按 UTF-8 解。这种情况用unzip -O GBK file.zip或者装bsdtar后bsdtar -x -f file.zipbsdtar 会自动尝试编码转换实测比手动-O GBK更省心。6. 常见问题速查与避坑笔记6.1 乱码修复速查表场景典型现象最快修法Windows Pythonprint(中文)显示????settings.json配PYTHONIOENCODINGutf-8 默认终端切 CMD UTF-8Windows JavaSystem.out.println中文变??或乱字符编译-encoding UTF-8运行-Dfile.encodingUTF-8Windows C MSVCprintf中文乱码源文件存 UTF-8 with BOM SetConsoleOutputCP(CP_UTF8)Windows MinGWg 编译的程序中文乱码编译加-finput-charsetUTF-8 -fexec-charsetUTF-8chcp 65001VS Code 终端本身所有中文输出都乱包括echo 你好把默认终端换成带chcp 65001的 CMD profileLinux/WSLls中文文件名显示???locale-gen zh_CN.UTF-8export LANGzh_CN.UTF-8Linux 解压 Windows zip解压后文件名中文乱码unzip -O GBK file.zip或bsdtar -x -f file.zip老批处理/GBK 程序切到 UTF-8 终端后反而乱单独建一个默认代码页的 CMD profile按需切换6.2 避坑笔记第一别轻易开系统的“Beta 版使用 Unicode UTF-8 提供全球语言支持”。控制面板 - 区域 - 管理 - 更改系统区域设置里面有个勾选项勾上后系统代码页全局变成 UTF-8电源重启后 VS Code 终端乱码大概率消失。但代价是很多老中文软件会反过来乱码比如某些国产办公插件、老版游戏、依赖 GBK 的桌面程序。我见过不少人开了之后别的软件冒出更奇怪的字符集问题最后又灰溜溜关掉。除非你确定电脑上没有任何遗留 GBK 软件否则不建议企业办公机这么干。第二别只看 VS Code 右下角的编码按钮。那个按钮只改“编辑器打开/保存文件”的编码比如能把 GBK 文件转存成 UTF-8但它管不到 Python/Java 运行时的 stdout 编码也管不到终端的代码页。很多人改了文件编码发现终端还乱就误以为方案无效其实是没改对层面。第三环境变量是全局的别一个人悄悄改。PYTHONIOENCODING、JAVA_TOOL_OPTIONS这一类环境变量会影响整个终端会话。如果你在团队项目里加了这种配置记得在 README 或.vscode/settings.json里说明不然同事的终端行为会突然“变了一个样”排查半天才发现是环境变量在作怪。放在.vscode/settings.json里比放在系统全局环境变量里更可控跟着项目走只在打开这个项目时生效。第四修改完配置一定要重启终端。VS Code 的settings.json改了之后老终端不会立即应用新配置必须在终端面板里点垃圾桶图标关闭当前 session 再重开。我见过太多人在 settings 里改了defaultProfile但不重开终端跑来问为什么没生效。6.3 最后分享一个小技巧如果你不想为一台机器反复调可以在项目根目录放一份.vscode/settings.json把下面这段放进去整个项目组打开都会自动用 UTF-8 终端跑{ files.encoding: utf8, terminal.integrated.profiles.windows: { Command Prompt (UTF-8): { path: C:\\Windows\\System32\\cmd.exe, args: [/K, chcp 65001 nul] } }, terminal.integrated.defaultProfile.windows: Command Prompt (UTF-8), terminal.integrated.env.windows: { PYTHONIOENCODING: utf-8 } }再配合仓库根目录的.editorconfigroot true [*] charset utf-8 end_of_line lf这样从“文件保存”到“终端运行”再到“代码输出”全部统一 UTF-8以后项目里跟中文乱码的纠缠基本可以归零。我个人在实际项目里的经验是遇到乱码先别慌也别急着装“乱码修复工具”之类的插件。花两分钟看一眼chcp、确认终端种类、再确认程序输出编码90% 的情况都能在五分钟内定位到根因。真正难的不是修这一台机器而是让团队所有机器、所有脚本、所有依赖库都按同一种编码习惯去工作。把 UTF-8 作为唯一约定Windows、Linux、macOS 才能坐在一起愉快地输出中文。