如果你在 Cursor 的终端里看到过中文这种东西大概率已经明白「乱码一时爽排查火葬场」是什么体验。我最近连续处理了好几个项目的输出乱码从 PowerShell 里 Python 的 print到 WSL 里编译报错再到 Git 文件名那一串\346\226\207折腾一圈后发现绝大多数乱码的根源都一样编码对不上。这篇文章不绕弯子直接记录我排查 Cursor 终端乱码的全部过程以及每个场景下最省事的解决方案。适合被中文乱码困扰的 Cursor 用户也适合刚转 Windows 平台的开发者参考。1. Cursor终端乱码解决先搞懂乱码从哪来1.1 乱码的本质是编码错位先说一个最基础的事实计算机本身不认识文字只认识字节。你看到的这是、涓暥、口口口其实都是同一串字节被不同“翻译规则”解释出来的结果。Windows 中文版默认用 GBK代码页 936来解码控制台输出而 Cursor 作为 VS Code 的衍生编辑器默认按 UTF-8 解码。一个中文的 UTF-8 编码是E4 B8 AD如果终端按 GBK 去读就会变成「涓」这种字符反过来GBK 编码的中文被按 UTF-8 解码又会变成ä¸æ–‡。可以打个比方一个写好的便签用的是普通话拼音但读便签的人只会广东话拼音字全认识意思完全不对。乱码就是这种“编码普通话”和“解码广东话”之间的错位。要解决要么让输出方和接收方都用 UTF-8要么都统一成 GBK。现在跨平台协作越来越多UTF-8 已经是事实标准所以我们的目标就是把 Cursor 终端里的所有环节都掰到 UTF-8 这条线上。1.2 Cursor终端与系统shell的关系很多人第一次用 Cursor 终端时以为它是独立的模拟器其实不是。Cursor 的集成终端是一个前端界面真正干活的是你系统里的 shell。Windows 下默认调起 PowerShell 5.1Linux 下默认调起 bashmacOS 下默认调起 zsh。Cursor 只是把这些 shell 的输出渲染到面板里同时套了一层自己的字符编码解析逻辑。这个关系很关键因为它决定了两件事第一乱码不一定怪 Cursor可能是 shell 本身给的字节就是乱的第二想彻底解决不能只改 Cursor还得改 shell 的编码、程序的输出编码、甚至系统的代码页。这也是为什么网上搜“Cursor 终端乱码”会得到一堆五花八门的答案——因为每个人卡住的环节不同。我的排查顺序是先确认 Cursor 配置再看系统代码页然后分 shell 和程序逐个处理。2. 第一步先改配置给Cursor终端一个 UTF-8 环境2.1 修改 settings.json 的编码参数不管你现在乱码长什么样我建议先把 Cursor 的编码相关配置统一改成 UTF-8。操作很简单打开 Cursor按CtrlShiftP输入Preferences: Open User Settings (JSON)然后把下面这段塞进去{ terminal.integrated.encoding: utf8, files.encoding: utf8, files.autoGuessEncoding: true, terminal.integrated.defaultProfile.windows: PowerShell, terminal.integrated.fontFamily: Cascadia Code, Consolas, Microsoft YaHei UI, monospace }terminal.integrated.encoding控制终端对进出数据的编码假设files.encoding控制编辑器里文件保存和读取的默认编码files.autoGuessEncoding会在打开历史遗留的 GBK 文件时自动猜编码避免文件内容本身乱码。这几项是基础改完重启 Cursor 终端很多直接在终端里输出中文的场景会立刻正常。注意terminal.integrated.defaultProfile.windows里的值要根据你实际想用的 shell 写。保持默认 PowerShell 没问题但后面我会建议你按场景切换。这段配置只对 Cursor 生效不影响系统里其他终端的表现。2.2 调整系统代码页和语言选项如果你在 Cursor 终端里执行chcp看到返回936那说明当前控制台代码页还是 GBK。临时解决可以在终端里执行chcp 65001执行后当前终端窗口的代码页会变成 UTF-8中文输出立刻正常。但关掉终端再打开就失效了所以想一劳永逸有几个选项。选项一改注册表让新开的控制台窗口默认走 65001。用管理员身份打开 PowerShell 或 CMD执行reg add HKCU\Console /v CodePage /t REG_DWORD /d 65001 /f改完重启终端生效。这个改动对 CMD、PowerShell 和 Windows Terminal 的新窗口都有效但对已经存在的进程无效。选项二控制面板 - 区域 - 管理 - 更改系统区域设置勾选“Beta 版使用 Unicode UTF-8 提供全球语言支持”。这个方案是系统级的效果猛但副作用也猛一些老软件尤其是默认 GBK 的国产软件会变乱码因为它们的源码是 GBK 写死并输出 GBK 的系统强制 UTF-8 后反而把它们的输出搞乱了。我不建议新手机器一上来就开这个先把前两个方案试完再说。选项三装一个 Windows Terminal然后在 Cursor 里把默认终端 profile 改成 Windows Terminal。Windows Terminal 对 UTF-8 的支持最完整还能单独配置每个 profile 的编码行为后面我会重点讲这个。2.3 字体和界面中文的补充设置有些“乱码”其实不是编码问题是字体缺字。比如中文在终端里显示成一排方框口口口或者某些字符显示成问号这通常是当前字体没有覆盖中文字形。光标、下划线都正常就是字出不来那就得换字体。在 Cursor 的 settings.json 里设置terminal.integrated.fontFamily推荐用Cascadia Code或者Consolas同时加上一个中文字体作为 fallback比如terminal.integrated.fontFamily: Cascadia Code, Consolas, Microsoft YaHei UI, SimHei, monospaceMicrosoft YaHei UI就是微软雅黑显示中文很稳。注意字体名称有空格的要加引号。设置完可以直接生效不用重启。另外热搜里总有人问 Cursor 中文界面怎么设置这里顺带提一句终端乱码和界面语言是两码事。Cursor 界面要汉化去扩展市场搜Chinese (Simplified) Language Pack安装然后CtrlShiftP执行Configure Display Language选中文(简体)并重启。这个操作不会影响终端编码别指望靠装语言包解决乱码。3. 不同shell场景的乱码分别怎么治3.1 PowerShell 5.1 的倔脾气Windows 自带的 PowerShell 5.1 是乱码重灾区因为它的默认输出编码不是 UTF-8。最典型的场景是你在 Cursor 终端里跑一个 Python 脚本脚本里print(中文)结果输出一堆ä¸æ–‡但跑到 CMD 里可能又正常。这是因为 PowerShell 5.1 的[Console]::OutputEncoding默认跟着系统代码页走系统是 936 它就默认 GBK 解码哪怕你已经chcp 65001也不行。解决办法是在 PowerShell profile 里强制设置编码。先执行notepad $PROFILE如果提示文件不存在先创建New-Item -Path $PROFILE -ItemType File -Force然后在这个文件里写入[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8第一行控制 PowerShell 如何解读外部程序比如 Python的输出第二行控制 PowerShell 向外部程序传递字符串时的编码。两行一起设置后重启 Cursor 终端再跑 Python、Node、git 这些命令中文基本就正常了。我见过有人在终端里手动执行这两行然后说“当时好了重启又坏了”——因为这样的设置不会持久化必须写进$PROFILE。另外如果你还在用 PowerShell 5.1我强烈建议升级到 PowerShell 7winget install Microsoft.PowerShell7 默认 UTF-8省掉很多折腾。装完在 Cursor 的 settings.json 里把默认 profile 指向PowerShell的新版本即可。3.2 WSL/Ubuntu 终端先查 locale在 WSL 里跑命令输出中文乱码跟 Windows 这边的关系通常不大先查 locale。打开 Cursor 终端进入 WSL前提是 Cursor 安装了 WSL 扩展执行locale如果LANG是空的或者不是zh_CN.UTF-8/en_US.UTF-8中文就会出问题。安装中文语言环境sudo apt update sudo apt install -y language-pack-zh-hans sudo update-locale LANGzh_CN.UTF-8然后重启 WSLwsl --shutdown再重新进入再看locale确保输出里有LC_ALL和LANGzh_CN.UTF-8。WSL 终端乱码还有一个隐蔽原因Windows 侧的字体不支持中文。WSL 里的程序输出的确实是 UTF-8但 Cursor 终端用的是 Windows 字体渲染如果字体 fallback 没配好照样显示方块。所以我一般会在 WSL 场景下把terminal.integrated.fontFamily加上微软雅黑效果立竿见影。另外如果你在 WSL 里用nano或vim编辑含中文的文件要确保终端里也设置 UTF-8否则编辑界面会乱但保存的文件字节可能没问题打开时再乱。3.3 Git Bash 与 CMD 下的奇奇怪怪如果你在 Cursor 里添加了 Git Bash 作为终端中文乱码的解法有点不一样。Git Bash 本质是 MSYS2 环境它自己有 locale 概念。在C:\Program Files\Git\etc\bash.bashrc或用户自己的~/.bashrc里加上export LANGzh_CN.UTF-8然后重新打开终端。Git Bash 里git status显示中文文件名时经常变成\346\226\207\344\273\266这种八进制转义这不是乱码是 git 默认对非 ASCII 路径做了转义。执行git config --global core.quotepath falsegit 就会默认输出原始中文。这个配置对 Cursor 终端、PowerShell、CMD 里的 git 命令都生效因为它是 git 本身的配置。CMD 的情况最简单。CMD 的老问题是默认代码页 936你用chcp 65001切到 UTF-8 后旧的 CMD 在某些 Windows 版本上显示会有点毛刺但基本能用。如果你在 Cursor 的默认终端里执行cmd /c 某命令输出中文乱码大概率是子进程沿用了系统代码页可以在命令前面加上cmd /c chcp 65001 nul 你的命令。不过装了 Windows Terminal 之后我基本不单独用 CMD 了推荐你也试试。4. 程序输出乱码Python/C/Node/Java 的各自解法4.1 Python 中文输出乱码Python 3 的源码默认 UTF-8但在 Windows 控制台输出时sys.stdout可能被绑定到 GBK 编码有时会导致两套编码打架。最常见的两种乱码终端代码页是 65001但 Python 认为 stdout 编码是 GBK输出时做了一次错误的编码转换。终端代码页是 936Python 直接输出 UTF-8 字节流终端按 GBK 解码。第一种情况在 Python 代码开头加一行就能解决import sys sys.stdout.reconfigure(encodingutf-8)第二种情况可以先chcp 65001再运行或者设置环境变量PYTHONIOENCODINGutf-8。想全局生效可以在 PowerShell profile 里加$env:PYTHONIOENCODING utf-8这里要特别提醒PYTHONIOENCODINGutf-8会让 Python 往 stdout 写 UTF-8如果终端代码页还是 936乱码反而更严重。所以正确的组合是终端 UTF-8 Python stdout UTF-8两者必须同步。除了输出读取文件也可能乱码。比如打开一个 Windows 记事本保存的 GBK 文件直接用open(file.txt)读print 出来就是乱码。解决办法是读文件时显式指定编码with open(file.txt, encodinggbk) as f: content f.read()或者反过来如果你确定文件是 UTF-8就写encodingutf-8。我一般会先问一句这个文件是谁生成的如果是从老 Windows 软件里导出的十有八九是 GBK如果是代码仓库里的新文件基本是 UTF-8。4.2 C/C 与串口(ESP32/minicom)乱码C/C 的中文乱码分两个层面编译期和运行期。源码文件用 UTF-8 保存但 MSVC 编译器默认按本机代码页解释源码可能把 UTF-8 的中文当成 GBK 去解析编译告警或错误信息里的中文就乱了。解决办法是在编译参数里加/utf-8让 MSVC 明确源码和运行时都用 UTF-8。GCC 则用gcc -finput-charsetUTF-8 -fexec-charsetUTF-8 main.c -o main运行期程序printf(中文)输出到 Windows 控制台如果控制台是 GBK 而程序按 UTF-8 输出依然乱。Windows 下最简单的处理是在main开头加#ifdef _WIN32 SetConsoleOutputCP(CP_UTF8); #endif然后保证终端代码页也是 65001。这个函数是 Windows API包含windows.h。如果不想写平台相关代码也可以用setlocale(LC_ALL, )让程序跟随系统 locale但这样只能保证 GBK 环境下正常未必匹配 UTF-8 终端。至于热搜里提到的 minicom 乱码、ESP32 串口乱码其实和 Cursor 终端本身没太大关系。串口终端出现中文乱码大多数是波特率、数据位、校验位不匹配或者开发板固件输出的是 UTF-8/GBK 而串口工具按另一种解码。用 minicom 的话CtrlA O进入配置选择 Serial port setup确认波特率跟固件一致。如果板子输出 UTF-8minicom 也要设置成 UTF-8一般minicom -s里的Local echo附近会有编码选项。排查顺序永远先看串口参数再看编码。4.3 Node.js、Java 和 Git 的编码注意点Node.js 在 Windows 下 console.log 中文乱码很多时候不是 Node 的锅是终端代码页不对。Node 源码和输出都按 UTF-8 处理但 Windows 控制台如果处于 936 状态显示就会乱。最省心的办法是把终端切到 65001或者使用 Windows Terminal。如果你在 Cursor 终端里已经设置了terminal.integrated.encoding: utf8一般 Node 输出不会有问题。极少数情况下你需要在启动 Node 前设置环境变量NODE_OPTIONS--no-experimental-fetch之类但那是功能问题跟编码没关系。Java 的处理比较直接。老版本 Java 在 Windows 命令行输出中文乱码通常是因为默认文件编码跟随系统。运行 Java 程序时加一个 JVM 参数java -Dfile.encodingUTF-8 -jar your.jar如果是编译源码也可以用javac -encoding UTF-8指定源码编码。Java 18 以后默认 UTF-8这个参数逐渐变成冗余项但为了兼容老项目加上没坏处。Git 相关的乱码很容易被忽略。除了前面说的core.quotepath false还有提交信息乱码。如果你发现git log里中文 commit message 显示乱码执行git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8这两行让 git 在读写 commit 信息时都按 UTF-8 处理。另外如果文件内容本身没问题只是 git diff 中显示中文乱码那还是终端解码问题先确认终端是 UTF-8。5. 乱码问题速查表与隐藏细节5.1 一张表对照症状和解决方案下面这张表是我实际排查时常用的速查表基本覆盖了 Cursor 终端里能遇到的大部分中文乱码。症状根本原因直接方案中文变成中文UTF-8 字节被 GBK 解码终端执行chcp 65001中文变成涓暥这类汉字GBK 字节被 UTF-8 解码让程序按 GBK 输出或切换终端代码页为 936中文变成一排方块口口口终端字体缺少中文字形设置fontFamily加入Microsoft YaHei UIPowerShell 里其他命令正常Python 输出乱码Python stdout 编码和终端不一致sys.stdout.reconfigure(encodingutf-8)或设置PYTHONIOENCODINGutf-8Cursor 终端乱系统自带的 PowerShell 不乱只有 Cursor 的终端编码配置不对设置terminal.integrated.encoding: utf8WSL 里所有中文都乱locale 未设置或设置错误sudo update-locale LANGzh_CN.UTF-8git status 中文路径变成\346\226\207git 默认转义非 ASCII 文件名git config --global core.quotepath falseJava 程序输出中文乱码JVM 默认编码与终端不一致启动加-Dfile.encodingUTF-8minicom 串口中文乱码波特率/编码不匹配minicom -s设置波特率确认终端编码表格不是万能钥匙但能帮你快速缩小范围。我自己的习惯是先看终端代码页再看程序输出编码最后才怀疑 Cursor 本身。90% 的情况在终端代码页这一步就能解决。5.2 容易忽略却坑死人的细节有几个细节我吃过亏写出来给你提个醒。第一chcp 65001只对当前终端窗口生效对 Cursor 里已经打开的终端面板有效但新建面板时如果 Cursor 配置没改又会回到默认代码页。所以别只执行 chcp 就完事要把 settings.json 里的配置一起改了。第二files.autoGuessEncoding不是万能探测。它遇到 GBK 和 UTF-8 都能解释的文本时可能会猜错导致文件内容被错误转换后再保存把原本正常的文件搞坏。所以如果你打开一个老项目要注意先备份再保存。第三在 Cursor 里改了 settings.json如果你开了多个终端面板正在运行的旧面板可能不会立刻应用新配置。老老实实关掉所有终端重新打开或者重启 Cursor再测试。第四Windows 系统勾选“Beta 版使用 Unicode UTF-8”是一个全局开关影响的不只是 Cursor。一旦某些旧软件出现新乱码你很难想起是这个开关引起的。我的建议是别开用终端级和程序级方案替代。第五PowerShell profile 文件里设置$OutputEncoding后如果之后又在终端里手动执行chcp 936可能导致 PowerShell 传给外部程序的字符串变成 UTF-8 字节但外部程序按 GBK 读反而乱。要改就统一改成 UTF-8不要混用。第六如果你用 Git Bashexport LANGzh_CN.UTF-8可能会影响一些 MSYS2 工具对路径的处理偶尔出现奇怪的路径截断。遇到这种情况可以改成export LANGC.UTF-8既能保证 UTF-8 输出又避免中文 locale 的某些副作用。6. 我的最终配置和踩坑心得6.1 一份可以直接抄的settings.json折腾到最后我现在的 Cursor 配置长这样基本两年没动过{ files.encoding: utf8, files.autoGuessEncoding: true, terminal.integrated.encoding: utf8, terminal.integrated.defaultProfile.windows: PowerShell, terminal.integrated.fontFamily: Cascadia Code, Consolas, Microsoft YaHei UI, monospace, terminal.integrated.rightClickBehavior: paste, terminal.integrated.cursorStyle: line }PowerShell profile 里$PROFILE[Console]::OutputEncoding [System.Text.Encoding]::UTF8 $OutputEncoding [System.Text.Encoding]::UTF8 $env:PYTHONIOENCODING utf-8WSL 的~/.bashrc末尾export LANGzh_CN.UTF-8Git 全局配置git config --global core.quotepath false git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8这套组合拳下来Windows 桌面、WSL、Git Bash 三种常用终端的中文输出都稳了。如果你还在被 Program Files 下的旧 CMD 工具折腾那就把terminal.integrated.defaultProfile.windows改成Windows PowerShell或Command Prompt反正 core 配置不变。6.2 几次翻车后我最终保留的习惯有一次我想偷懒直接勾选了系统“Beta 版使用 Unicode UTF-8”结果第二天开公司内部老系统导出的 Excel 时一堆中文描述变成乱码数据库里的中文也显示异常最后只好回滚设置花了一上午收拾残局。那次之后我确定了一个原则编码问题只在工具链内部解决不动系统全局开关。还有一个教训是别在团队项目里混用编码。很多项目里既有 UTF-8 源码又有人用 Windows 记事本存 GBK 的配置文件。虽然files.autoGuessEncoding能自动识别但一旦有人用默认编码保存文件字节就被改了git diff 会像爆炸一样可怕。规范做法是在项目根目录放一个.editorconfigroot true [*] charset utf-8 end_of_line lf insert_final_newline true这样不管谁打开 Cursor、VS Code 还是其他编辑器都会按 UTF-8 处理从源头消灭乱码。另外我养成了一个习惯遇到乱码先执行chcp看代码页再执行file 文件名看文件真实编码这样排查效率比盲改配置高得多。如果你现在正被 Cursor 终端的中文乱码折磨我建议你从第 2 章的 settings.json 改起那一步能解决一半问题再按第 3 章对应的 shell 场景处理又能解决三成剩下两成是程序本身的编码问题对照第 4 章的方案逐个击破即可。别慌乱码不可怕可怕的是瞎改。按这个顺序来基本一个小时内就能全部搞定。