说实话VS Code终端里汉字打印成???这种破事我前前后后帮同事和朋友排了七八次。每次看到别人对着屏幕上一排问号发懵我就知道又是编码问题在作妖。这个问题的坑点在于它不固定——同样的代码有人在Windows上跑得好好的有人一打开终端全是问号有人在VS Code里正常切到系统CMD又乱了。今天我把这个问题的完整解法整理出来从现象、原理到不同场景下的处理方案一篇文章讲透。如果你的日常工作涉及Python脚本、C/C程序、Java项目或者经常在VS Code终端里跑各种命令这篇文章能帮你省下大量排查时间。就算你是个刚入门的新手照着下面的步骤一步步来也能把终端输出汉字乱的毛病治好。1. 先搞清楚???是从哪一步冒出来的1.1 你看到的问号其实分两种终端里出现问号一定要先区分是哪种情况因为处理方向完全不一样。第一种是实打实的问号字符。你在终端里看到的是???而且数量跟汉字数量对得上一个汉字对应一个问号。这种一般是程序在输出的时候自己就把非ASCII字符替换成了?终端其实没做错什么问题出在程序输出的那一端。第二种是显示成问号形状的方块或者乱码。有时候终端显示的不是???而是像涓枃、鏂囨湰这种奇怪字符或者一个个小方块豆腐块。这属于终端用错误的编码去解码了UTF-8字节流解码出来全是无效字符。搞清楚这一点很重要因为网上很多教程只教你改终端编码但如果你遇到的是第一种情况改终端编码毫无卵用。我见过有人折腾了半天设置最后发现是他的Python代码里print函数自己把中文替换成问号了。1.2 为什么会走到这一步编码链路拆解要理解这个问题得先明白一条完整的输出链路程序内部字符串 → 编码成字节 → 终端解码 → 字体渲染。程序里的字符串在内存里是有编码的Python 3默认UnicodeC/C要看编译器设置。当程序往标准输出写数据时它会按照某个编码把Unicode字符串转成字节序列。这个编码在Windows上默认是GBK代码页936在Linux/macOS上默认是UTF-8。终端收到字节序列后又要按照它自己的编码去解码。Windows的CMD默认用GBK解码VS Code的集成终端则取决于它的配置文件。如果程序输出用的是UTF-8而终端用GBK去解就会得到涓枃这种乱码如果程序输出时直接把无法编码的字符替换成?终端解出来的就是整齐的???。最后一步是字体渲染。就算字节解码成功了如果终端用的字体里没有对应的字形也会显示成方块或者问号形状。这一步很多人忽略但踩坑率极高。所以解法要从这三条链路分别下手要么改程序输出编码要么改终端解码编码要么换字体。下面我按从简单到彻底的顺序把各种方案都写上。2. 最常用的修复套路改VS Code终端编码2.1 一条命令临时切换代码页如果你只是临时跑个脚本最快的方法是直接在VS Code终端里执行chcp 65001chcp是Windows下切换代码页的命令65001代表UTF-8。执行完这条命令当前终端窗口的解码方式就切成UTF-8了再运行你的程序中文输出大概率就正常了。注意这个命令只对当前终端会话有效。你关掉这个终端标签页或者新开一个终端又恢复原样了。而且有个小坑执行chcp 65001之后如果程序输出的是GBK编码的字符反而会乱得更厉害。所以你得先确认程序输出的是什么编码。如果你用的是PowerShell还可以用另一种方式[Console]::OutputEncoding [System.Text.Encoding]::UTF8这条命令把控制台的输出编码也切成UTF-8。两种方式可以配合使用实测在VS Code的PowerShell终端里这两条命令一起执行后Python输出中文基本就正常了。2.2 让VS Code每次打开终端都自动切到UTF-8每次手动敲chcp 65001太麻烦了而且容易忘。我推荐直接改VS Code的配置文件让每个终端标签页打开时自动执行切换命令。按CtrlShiftP打开命令面板输入settings.json打开用户设置文件在里面加上这一段terminal.integrated.profiles.windows: { Command Prompt: { path: C:\\Windows\\System32\\cmd.exe, args: [/K, chcp 65001 nul] }, PowerShell: { source: PowerShell, args: [-NoExit, -Command, [Console]::OutputEncoding [System.Text.Encoding]::UTF8; [Console]::InputEncoding [System.Text.Encoding]::UTF8] } }, terminal.integrated.defaultProfile.windows: Command Prompt/K参数的意思是执行完后面的命令后保持窗口不关闭nul是抑制chcp的提示输出不然每次开终端都先蹦出一行Active code page: 65001也挺烦的。设置完之后重启VS Code或者手动关掉终端标签页再重新打开每次都会自动切到UTF-8了。这一招是我实际用得最多的方案配合下面的程序端设置基本能覆盖90%的场景。2.3 设置默认配置文件与字体兜底编码切对了字体也得跟上。VS Code默认的终端字体在Windows上通常是Consolas这个字体对中文的显示支持其实很一般遇到生僻字或者某些特殊符号容易显示成方块。我建议在settings.json里把终端字体改成支持中文的字体terminal.integrated.fontFamily: Cascadia Code, Microsoft YaHei, Consolas, Courier New, monospaceCascadia Code是微软为终端设计的等宽字体对中日韩字符做了fallback处理会把中文字形交给Microsoft YaHei微软雅黑渲染。这样既保持了西文字符的等宽效果中文部分也不至于变成豆腐块。还有一个容易被忽略的设置terminal.integrated.fontFamily如果是空的或者只设置了西文字体终端在渲染中文时会用系统默认字体这个默认字体在某些精简版Windows系统上可能就是缺失的。所以把微软雅黑加进字体列表做兜底是最稳妥的做法。字体这块我踩过的坑是在Windows Server上远程连接VS Code服务器上没装微软雅黑终端中文直接变成一个个空心方块。后来在服务器上装了字体才解决。所以如果你是在服务器环境用VS Code排查编码问题之前先看一眼系统字体齐不齐。3. 从程序输出端根治不同语言场景的对应解法3.1 Python脚本输出中文变成问号Python 3的字符串本身是Unicode问题出在输出环节的编码。在Windows上Python默认会按照控制台的代码页来编码输出如果你用的是GBK代码页936而字符串里含有GBK无法编码的字符Python会抛UnicodeEncodeError。但如果你的代码或者框架里做了errorsreplace处理它就会一声不吭地把字符替换成?打印出来。解决方法有几个按优先级来第一种运行前设置环境变量set PYTHONIOENCODINGutf-8 python your_script.pyPYTHONIOENCODING是Python读取标准输入输出时使用的编码设置为utf-8后print输出的字节流就是UTF-8编码。这个方案不用改代码适合临时跑脚本。第二种在代码里强制重配标准输出import sys sys.stdout.reconfigure(encodingutf-8) print(中文输出)reconfigure是Python 3.7提供的方法可以随时修改标准输出的编码。这个方案的好处是只影响你自己程序的输出不会污染别的程序。第三种一劳永逸的做法在环境变量里永久设置在Windows系统属性里添加用户环境变量PYTHONIOENCODING值为utf-8。这样所有Python脚本的输出默认都是UTF-8编码不用每次手动设置。副作用是如果你的程序要跟GBK编码的文件交互输出可能对不上但绝大多数场景下UTF-8是没问题的。还有一个Python特有的坑如果你用的是Python 2虽然现在很少见了字符串默认是字节串遇到中文会直接乱掉。Python 2的解法是在文件开头加# -*- coding: utf-8 -*-以及把字符串声明成u中文。但现在都2025年了如果还有老项目跑Python 2我建议优先考虑升级迁移而不是继续填编码的坑。3.2 C/C程序在终端输出中文乱码C/C场景稍微复杂因为涉及源码文件自身的编码、编译器的编码选项、运行时的代码页设置三个环节任何一环出问题都会导致乱码。先说源码文件编码。VS Code默认用UTF-8保存文件但MSVC编译器cl.exe默认认为源代码是本地代码页编码GBK。如果两者不一致编译器解析字符串字面量时就会出错或者编译出来的程序里的中文字符串本身就是错的。Visual Studio的MSVC可以用/utf-8参数指定源码编码cl /utf-8 your_program.c如果是GCC/Clang用gcc -finput-charsetUTF-8 -fexec-charsetUTF-8 your_program.c -o your_program-finput-charset告诉编译器源文件是UTF-8编码-fexec-charset告诉编译器把字符串字面量以UTF-8编码存进可执行文件。然后是运行时的输出编码。Windows的控制台程序可以使用Windows API来设置输出代码页#include windows.h int main() { SetConsoleOutputCP(CP_UTF8); // 65001 SetConsoleCP(CP_UTF8); printf(中文输出\n); return 0; }SetConsoleOutputCP函数的作用是让当前进程的输出使用UTF-8编码这样配合终端侧的UTF-8解码中文就不会乱。注意这个API只在Windows上有效跨平台代码需要加上条件编译。Linux/macOS下的C/C程序基本上默认UTF-8编码很少遇到中文乱码问题。如果遇到了先检查系统locale用的是不是en_US.UTF-8或zh_CN.UTF-8locale如果输出不是UTF-8结尾可以用export LANGen_US.UTF-8 export LC_ALLen_US.UTF-8在bash配置里加上这两行重启终端生效。3.3 Java与Node.js场景的编码处理Java程序在终端输出中文乱码最常见的原因是JVM的默认字符集跟终端不一致。Java 18之前JVM默认字符集由系统决定Windows上通常是GBKJava 18开始默认变成UTF-8但老项目可能还带着旧的启动参数。输出乱码时首先检查启动命令java -Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8 YourClassfile.encoding控制文件的读写编码sun.jnu.encoding控制文件名和标准IO的编码。两个都设成UTF-8基本能解决输出中文乱码的问题。另外提一个很常见的坑Maven或Gradle构建工具在编译时用的编码可能跟运行时不一致导致编译后的class文件里中文字符串本身就是错的。解决办法是在pom.xml里显式声明编码properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /propertiesGradle则在build.gradle里加tasks.withType(JavaCompile) { options.encoding UTF-8 }Node.js场景比较有意思。Node.js的console.log输出默认是UTF-8在VS Code终端里通常不会乱。如果你用的是Windows的CMD原生窗口有时会因为CMD的代码页问题显示乱码。这种情况直接chcp 65001就行。如果是在VS Code终端里跑Node.js项目遇到乱码多半是文件读写的编码问题检查一下读取文件时有没有指定正确的编码const fs require(fs); const text fs.readFileSync(file.txt, utf-8);没指定编码时readFileSync返回的是Buffer直接打印会显示成十六进制字节或者乱码。这是新手常犯的错误。另外一个隐藏场景是终端复用工具比如某些终端模拟器会强制把输出转换成当前会话的编码如果你在VS Code里嵌入了其他终端工具编码处理可能跟原生终端不一样。遇到这种情况优先在工具自身的配置文件里指定UTF-8而不是去改系统设置。4. 系统层面的一次性解决方案4.1 Windows系统区域设置里的UTF-8开关如果你不想在每个终端、每个程序里单独设置Windows 10/11系统层面有一个大招打开系统Beta选项让整个系统默认使用UTF-8编码。路径是控制面板 → 区域 → 管理 → 更改系统区域设置 → 勾选Beta: 使用Unicode UTF-8提供全球语言支持。勾选之后重启系统整个系统的非Unicode程序编码都会切到UTF-8CMD、记事本、以及大量不指定编码的程序的默认编码都会变成UTF-8。这样一来VS Code终端里chcp都不用执行了程序输出中文基本都能正常显示。但是这个选项慎开。开启它之后很多老旧的国产软件、某些依赖GBK编码的软件可能会乱码。我自己就遇到过某银行的网银插件开启后界面全乱某老版数据库管理工具日志乱得没法看。这个开关对个人开发者来说很爽但在公司环境或者有历史软件依赖的情况下开之前一定评估一下风险。如果不开系统开关又想解决全局乱码问题可以考虑把系统区域格式改成中文简体中国并确保不勾选任何奇怪的Beta选项然后把非Unicode程序的语言设置为中文简体中国。这本质上还是让非Unicode程序默认GBK编码跟UTF-8系统开关方案是两条路线选一条执行就行千万别两个都开。4.2 文件本身的编码问题VS Code右下角有时候终端编译运行程序时报错信息乱码或者程序输出的乱码跟终端无关而是源文件本身的编码就不对。这种情况在接手老项目时特别常见项目文件是GBK编码存的但VS Code默认按UTF-8打开导致代码里的中文注释、字符串全部乱掉。判断方法很简单看VS Code窗口右下角那里会显示当前文件的编码。如果是UTF-8而文件内容里中文显示成了乱码说明文件实际是GBK编码VS Code猜错了。处理办法点击右下角的编码按钮选择Reopen with Encoding在弹出的列表里选GBK或者GB 18030文件就能正常显示了。如果想让这个文件永久以GBK编码保存再点一次编码按钮选择Save with Encoding选GBK。对于项目级处理更推荐在settings.json里配置自动猜测编码files.autoGuessEncoding: true开启后VS Code会根据文件内容自动猜测编码能减少一部分编码判断错误的情况。但它不是万能的对于纯文本且内容较短的文件猜测准确率不高。我一般建议老项目尤其是带中文注释的C/C、Java项目先统一确认编码再动手改代码新项目全程UTF-8不要混用。还有一个相关的配置文件级坑你的settings.json本身如果是GBK编码保存的里面写的中文注释、字体名称在VS Code里也可能显示乱码。同样用右下角的编码功能检查一下。5. 常见问题与排查技巧实录5.1 排查思路先定位是显示问题还是输出问题遇到终端汉字乱码最快定位问题的方法是做一个最小复现实验第一步在终端里直接输入一个中文命令提示比如echo 中文测试如果echo输出的中文是正常的说明终端解码和字体渲染没问题问题在程序的输出端。如果echo也乱说明终端本身编码或字体有问题优先检查终端配置。第二步如果确认终端没问题看程序内部。写一个最简Python脚本print(中文测试)设置PYTHONIOENCODINGutf-8跑一遍。如果正常了说明你的程序里一定有代码在覆盖标准输出的编码或者你的运行环境变量有异常。如果仍然乱试着把程序输出重定向到文件python script.py output.txt然后用文本编辑器打开output.txt。如果文件内容正常说明程序输出的是UTF-8只是终端解码不对如果文件内容也是乱码说明程序输出时就没编对。这个三步定位法是通用的不管是Python、C、Java还是Node.js都能通过echo测试→简单脚本测试→重定向观察把问题缩小到具体环节。我排查编码问题从来不会一上来就翻终端设置一定是先定位再动手。5.2 常见问题速查表现象可能原因优先处理方案汉字变成???数量与字数一致程序输出端编码失败字符被替换设置PYTHONIOENCODINGutf-8或sys.stdout.reconfigure(encodingutf-8)汉字变成涓枃这类字符程序输出UTF-8终端用GBK解码执行chcp 65001或在VS Code终端配置里加入自动切换汉字显示为方块/豆腐块字体不支持中文渲染终端字体列表加入微软雅黑或Cascadia Code源码里中文就乱文件编码与VS Code猜测不一致右下角Reopen with Encoding选择GBK或UTF-8C/C编译后输出乱码源码编码、编译选项、运行代码页不一致编译加/utf-8MSVC或-fexec-charsetUTF-8运行前调用SetConsoleOutputCP(CP_UTF8)Java编译产物中文乱码Maven/Gradle构建编码与运行编码不一致项目里显式声明UTF-8编码启动加-Dfile.encodingUTF-8第一次运行正常换终端后乱码不同终端的默认代码页不同统一终端配置或在程序端硬性指定UTF-8输出这张表是我日常排查用的速查索引。实际工作中遇到变体问题先对照现象找到最接近的行按优先级尝试绝大多数能快速解决。5.3 一些实操中踩过的坑第一个坑是VS Code终端缓存。修改完settings.json里的终端配置后有时候旧终端标签页仍然带着旧的编码设置。别以为改完配置重启VS Code就万事大吉必须把终端Tab手动关掉再重新打开。有几次同事跟我说按你的方法改了没用我远程一看他开了个终端就没关过配置改了根本没生效。第二个坑是WSL终端的编码跟Windows终端不一样。VS Code里可以同时使用Windows终端和WSL终端两个的编码逻辑完全不同。WSL内部是Linux环境默认UTF-8基本不会乱。但当你通过WSL在Windows文件系统/mnt/c/上创建带有中文文件名的文件时文件名的编码可能会跟Windows侧对上不导致文件在两边看起来名字不一样。这个跟终端乱码是两个问题但经常被混在一起排查如果你的场景涉及文件名乱码单独查一下挂载选项metadata和utf8是否开启。第三个坑是Python虚拟环境特殊字符。有段时间我的项目用conda管理环境conda激活环境时会修改PYTHONIOENCODING或者注入一些脚本输出导致VS Code终端里中文乱码的规律很奇怪有时候刚进终端是好的conda activate之后就开始乱。排查之后发现是conda的初始化脚本里有一段代码把PYTHONIOENCODING设成了GBK相关的值。遇到这种环境管理器导致的编码问题别在VS Code层面硬调找一下环境管理器的配置文件把编码设置统一成UTF-8。第四个坑是远程开发场景。VS Code Remote-SSH连接到Linux服务器时终端本身跑在服务器上编码通常是UTF-8没问题。但如果你在远程终端里运行的程序反过来输出GBK编码比如调用了Windows侧的工具链那就会乱。这种编码在两端来回横跳的场景最耗时间我现在的习惯是远程开发时在服务器端的~/.bashrc里强制设置export LC_ALLC.UTF-8避免locale不一致引入的干扰。最后分享一个我自己的小习惯新项目从第一天开始就全链路UTF-8源文件UTF-8、构建配置UTF-8、运行时显式指定UTF-8、终端代码页65001。前期多花十分钟设置好后面省下的是无数个为什么又乱码了的下午。编码这种东西就是个标准问题——只要约定的标准一致它就不会咬人。