1. 中文乱码的根源先搞懂编码不匹配是怎么回事很多人遇到VS Code中文变乱码第一反应是软件坏了其实绝大多数情况跟VS Code本身没半毛钱关系问题出在文件的编码格式和编辑器读取时用的编码格式不一致。这个逻辑一旦想明白后面所有的设置技巧都是顺手的事。我先用一个最直白的类比来解释。你把一段中文用拼音写下来GBK编码然后让一个只认识普通话拼音的人去读UTF-8解码他读出来的可能是另一套符号因为拼音方案对不上号。电脑里的编码也是一样写入文件时用的编码规则和读取文件时用的编码规则决定了一个文件能不能被正确显示。只要是这两者不一致显示出来的就是一堆锟斤拷、烫烫烫或者方框问号□。1.1 为什么中文文件这么容易翻车原因在于中文编码体系本身就存在两种主流方案在互相竞争GBK/GB2312这是国内早期Windows系统尤其是简体中文版默认使用的编码方案一个汉字占2个字节。UTF-8这是现代互联网和跨平台开发的主流编码方案一个汉字占3个字节兼容ASCII。VS Code默认情况下读取文件时会优先尝试UTF-8但如果你手里的文件是老旧编辑器或者Windows自带记事本生成的GBK编码文件VS Code用UTF-8去猜它自然就会读出乱码。更麻烦的是当你把GBK编码的文件用UTF-8重新解码并保存之后原本的汉字可能彻底损坏想恢复都难。这里有一个必须承认的事实UTF-8 已经是事实标准但存量文件里依然大量存在 GBK 编码。尤其是一些老项目、早期Windows环境下的文本文件、某些国产软件导出的数据随手一查全是GBK。所以乱码这件事短期之内不会彻底消失学会正确处理才是正路。1.2 常见乱码的几种症状我在实际排查中发现乱码的表现形式还不太一样很多人因为看不懂症状就误判成了别的问题乱码形态常见原因典型场景菱形问号文件是UTF-8但被按GBK读取网页源码、后端日志文件锟斤拷锟斤拷锟斤拷文件是GBK被转成UTF-8后又转回GBK重复转换编码导致的损坏矩形方框□□□字体不支持该字符集中文内容加载了非中文字体一半汉字一半英文乱文件混合编码部分GBK部分UTF-8多个编辑器轮流编辑过的文件把症状和原因对上号之后再去处理就有方向感了。下面我按轻重缓急给你一套可以直接落地的操作方案。2. 已经乱码的文件怎么救两种思路、四步操作文件已经显示成乱码的时候先别急着改内容更不要在乱码状态下直接CtrlS保存。你一旦保存了就等于把乱码后的内容写回了文件原文可能再也找不回来。正确的操作思路只有两个换一种方式重新读取或者换一种编码重新保存。2.1 第一种思路重新打开换对编码这是最安全的操作因为它在不修改文件内容的前提下让VS Code换一种解码方式来读取文件。在VS Code右下角找到状态栏上的编码按钮显示为UTF-8或者GBK之类的字样。点击这个编码按钮顶部会弹出一个命令面板显示重新打开方式Reopen with Encoding。在列表里选择通过编码重新打开Reopen with Encoding然后选择GBK或者GB18030。如果列表里没有就选择更多选项手动输入编码名称。只要文件的原始编码是GBK你用GBK重新打开乱码立刻就会恢复成正常中文。这个操作不会修改文件本身只是改变了VS Code读取文件的方式相当于换个眼镜看东西。这里有三个编码术语需要区分清楚避免选错GB2312最早期的中文编码标准字符覆盖少。GBKGB2312的超集Windows中文版常用覆盖了绝大部分汉字是现在最常用的中文编码。GB18030GBK的超集覆盖几乎所有中文和少数民族文字兼容性更强。遇到老文件时如果你不确定到底是GBK还是GB18030优先试GBK。如果还乱码再逐个试验反正只是换读取方式不会伤害文件。2.2 第二种思路转换编码并保存把文件正规化这是处理日后还要在VS Code里长期维护的文件时更推荐的操作。举个例子你从某套老的业务系统里面导出了一批GBK编码的文本文件现在团队统一使用UTF-8编码那么你最好一次性把它们洗成UTF-8免得之后每次打开都要手动调整读取方式。操作流程是按照上面的方法先用正确的编码比如GBK把文件打开确保显示正常。再次点击右下角的编码按钮。这次不要选重新打开而是选择通过编码保存Save with Encoding。在列表中选择UTF-8。这个操作的本质是先把文件按GBK解码成正确的字符内容再用UTF-8规则重新编码并写回硬盘。保存完成之后这个文件就变成标准UTF-8了之后在任何现代编辑器里打开都不会乱码跨平台协作也顺畅很多。注意文件从GBK转成UTF-8属于再生操作转换前最好先备份原文件。反过来从UTF-8转成GBK会丢失一些特殊字符比如生僻字、特殊符号一般不推荐。2.3 批量处理文件时的Excel版WPS方案如果你手头的乱码文件有几十个甚至上百个在VS Code里一个个打开再保存确实太慢了。这种时候我一般会先判断文件是纯文本还是表格如果是CSV/Excel导出的文件可以直接用表格软件来转换打开表格软件时选择数据→从文本/CSV导入在文件原始编码里选择GBK。等中文正常显示后再用另存为方式导出为CSVUTF-8或者直接复制粘贴到新文件里保存。VS Code本身不擅长批量编码转换但它的插件市场里也可以搜索到编码转换类的辅助插件不过我更推荐你在项目里固定用一套自己写的脚本处理这个后面会讲到。3. 新建文件依然是乱码问题出在VS Code的默认编码设置很多人在老文件处理完后新建一个文件敲几个中文字符发现还是乱码。这就说明不是文件本身的问题而是VS Code的默认编码设置没有配置对。VS Code本身的默认编码就是UTF-8如果你一开始用的是英文版系统、或者之前改过lang相关配置就有可能出现默认编码被带偏的情况。3.1 检查并修改全局设置settings.json 里的两个关键参数VS Code的设置项非常多和编码直接相关的核心参数就这几个files.encoding默认编码可以设置为utf8、gbk、gb18030等。files.autoGuessEncoding是否启用自动猜测编码。当值为true时VS Code打开文件会尝试根据文件内容自动判断编码这能在一定程度上缓解乱码但不保证100%准确。files.autoGuessEncoding与files.encoding的关系前者开启后VS Code会忽略后者的读取模式先猜后看。修改方法快捷键CtrlShiftP打开命令面板。输入首选项打开设置JSON进入settings.json。加入或修改以下内容{ files.autoGuessEncoding: true, files.encoding: utf8 }files.encoding: utf8的意思是新建文件时默认采用UTF-8编码写盘。files.autoGuessEncoding: true的意思是读取已有文件时如果编码不明确可以自动尝试识别。我做个小结如果你的项目是国际化的现代项目建议保持 utf8 并开启自动猜测。如果你的项目是老系统维护周围所有人的文件都是GBK那就把默认编码改成 gbk省的每次都要手动切。3.2 针对特定语言文件的编码配置某些情况下你可能只希望特定类型的文件使用特定编码其他文件保持默认。这种需求用语言关联配置可以优雅地实现。比如你希望所有.txt文件一律用GBK打开而.js、.py文件用UTF-8可以这样写{ [plaintext]: { files.encoding: gbk }, [javascript]: { files.encoding: utf8 } }这个配置我实际用下来觉得特别适合混合编码的团队项目。以前我们有个数据仓库的脚本工程历史遗留的.sql文件全是GBK但新增的.js脚本是UTF-8。全项目统一改UTF-8风险太大所以我直接按语言类型区分各开各的基本消停了乱码问题。3.3 为什么会改了设置还是乱码优先级问题这里有一个很多人忽略的细节VS Code对单个文件生效的编码设置优先级高于全局设置。意思是如果你之前对某个文件手动执行过通过编码保存操作VS Code会记录下这个文件的个体编码偏好。之后即使你修改了全局配置这个文件依然会按个体偏好来读取。因此你改了全局设置后乱码依旧存在很可能就是因为文件级别的覆盖设置没清掉。解决办法在命令面板搜索重新打开时选择所有文件重置编码设置Reset File Encoding之类的命令或者直接删除workspaceStorage中的相关缓存最省事的办法是把文件内容复制到新文件里以新文件的身份重新关联。4. 终端里运行结果显示乱码编码问题不只影响编辑器很多人解决了编辑器里的乱码但一运行Node.js脚本或Python脚本控制台终端面板里输出的中文又是乱码。这个乱码和文件编码无关它发生在程序输出文本→终端解析显示这个环节。我在排查前端项目时遇到这种问题次数不少所以单独讲一下。4.1 VSCode集成终端的编码设置VS Code的终端本质上是调用系统的ShellWindows上是PowerShell或CMDmacOS/Linux上是bash/zsh。终端显示乱码时首先要检查的是操作系统的代码页Code Page设置。在Windows上使用命令chcp查看当前活动代码页。如果显示的是936GBK那表示现在终端以GBK解码输出。如果程序输出的是UTF-8编码的文本两者不匹配就会乱。此时可以临时切到UTF-8代码页chcp 65001不过这个办法只对当前终端窗口有效关掉就失效。想永久生效建议在VS Code的设置里找到terminal.integrated.profiles.windows为PowerShell或CMD指定启动参数。{ terminal.integrated.profiles.windows: { PowerShell: { source: PowerShell, args: [-NoExit, -Command, chcp 65001 $null] } }, terminal.integrated.defaultProfile.windows: PowerShell }这样每次打开集成终端都会自动把代码页切到UTF-8输出中文不会乱。4.2 环境变量层面的根治PYTHONIOENCODING 与 NODE_OPTIONS如果你在终端里运行Python脚本输出中文乱码通常是因为Python在标准输出时使用了默认的编码可能与终端编码不一致。可以临时设置环境变量set PYTHONIOENCODINGutf-8或者在Python代码里显式写入import sys import io sys.stdout io.TextIOWrapper(sys.stdout.buffer, encodingutf-8)Node.js环境则可以在启动命令中指明NODE_OPTIONS--utf8-text-only不过实际测试下来最省心的还是在系统级把全局代码页切到UTF-8Windows 10以上支持Beta版使用Unicode UTF-8提供全球语言支持这个选项但这会影响整个系统的编码行为需要根据业务环境谨慎开启。4.3 日志文件被看乱不是日志写错了还有一种常见误判程序明明按UTF-8写日志日志文件用记事本打开却是乱码。这时候你要知道记事本尤其是在Windows上默认会用系统的ANSI编码GBK来读取文本文件UTF-8文件里有中文时自然就乱了。这种情况不怪程序也不怪VS Code正确做法是用VS Code打开日志文件利用自动猜测编码功能显示或者在记事本里另存时选择UTF-8编码再打开。我见过太多人因为这个问题反复重启服务结果纯属打开方式不对。5. 从根上减少乱码一劳永逸的编码管理习惯讲到现在你可能已经发现乱码问题说到底是一个读写编码约定的问题。如果项目里所有人、所有工具、所有文件都遵守同一套编码契约乱码几乎不可能出现。所以下面我分享几个从源头管住编码的方法和习惯。5.1 团队级一个.editorconfig直接锁定编码契约VS Code支持EditorConfig for VS Code插件。在项目根目录下创建.editorconfig文件root true [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true这个文件是团队协作时的编码公约。只要大家安装了EditorConfig插件VS Code打开文件时会自动套用这些规则新建文件也会默认遵循。这就避免了一人用LF、一人用CRLF、一人GBK、一人UTF-8的混乱局面。我强烈建议所有有一定规模的项目都配一个。注意Editor Config 插件不会自动转换已有文件的编码它只保证新建文件和未保存文件的编辑行为遵循规则。存量文件还是要靠第一节的方法手动转。5.2 个人级代码文件的外层保险——用Git提交前检查编码如果你负责维护一个仓库可以加一条简单的编码检查逻辑在提交前把所有非UTF-8文件检测出来。以Python为例不需要装额外库一行脚本就能扫出异常文件import os import sys target_dir sys.argv[1] if len(sys.argv) 1 else . bad_files [] for root, dirs, files in os.walk(target_dir): if any(part.startswith(.) for part in root.split(os.sep)): continue for f in files: if f.endswith((.txt, .js, .py, .json, .md)): path os.path.join(root, f) with open(path, rb) as fp: data fp.read() try: data.decode(utf-8) except UnicodeDecodeError: bad_files.append(path) if bad_files: print(以下文件不是UTF-8请先转换) for b in bad_files: print( -, b) sys.exit(1)这个脚本可以挂到Git的pre-commit钩子里也可以作为CI的一个检查步骤。这样就算团队里有成员不小心用旧工具保存了GBK文件在提交前就会被拦截下来而不是等别人拉代码之后发现乱码再回来排查。5.3 文件头的看不见的标记BOM到底该不该要关于UTF-8还有一个容易踩的细坑BOM字节顺序标记。UTF-8文件开头可以带3个字节的特殊标记EF BB BF有BOM的UTF-8被Windows记事本识别得更可靠但某些Linux工具和编译器遇到BOM反而会报错。VS Code右下角编码按钮上如果显示UTF-8 with BOM表示文件带BOM。如果你发现文件在其他工具里出现了奇怪的开头空行或者解析错误大概率就是BOM的问题。此时可以把文件重新保存成无BOM的UTF-8编码。我在做跨平台项目时的习惯是前端和纯文本文件保留BOM避免Windows记事本误解服务端代码不用BOM保证Linux下编译和执行的兼容。这个经验不一定符合所有场景但在实际项目中确实帮我少踩了很多坑。5.4 从工具栏直接解决看文本文件但不想改编码的需求最后补充一个日常小技巧。当你只是临时查看某个文件并不想修改也不想动任何设置那么直接右键单击编辑器上方标签页选择通过编码重新打开然后逐个尝试。这是一种轻量级处理方式完全是临时生效不会污染项目配置。另外VS Code的状态栏右下角编码按钮也可以用来快速查看当前文件是什么编码。如果显示灰色或不显示任何编码说明VS Code还没识别到编码信息这时候可以手动点一下强制指定。熟记这个入口后处理编码问题的速度会快很多。6. 那些年我踩过的编码坑和最终心得这一节是我自己想分享的真实教训如果你也有类似的经历应该会感同身受。先说最大的一个坑乱码状态下一定不要直接点保存。我遇到过一个同事打开CSV文件看到中文乱码以为是文件本身坏了随手CtrlS保存了一次结果几千行中文全部变成了锟斤拷的乱码字符整个文件直接报废。后来用Git历史才恢复出来。乱码不等于文件损坏它只是读法不对但你一旦用错误的读法保存了那就是真损坏了。第二坑是把编码转换当成一个永久修复。转换编码只能在编码规则明确的情况下可靠进行。如果文件本身混用了多种编码部分GBK、部分UTF-8转出来的内容一定会有瑕疵。这种文件最安全的方式是重新获取原始文件或者从源头调整导出程序。第三点是不要迷信自动猜测编码。files.autoGuessEncoding确实能解决大部分乱码但猜测本身是概率性的。特别是一些短文本文件——比如只有三五行字的配置文件——猜测的结果可能完全错误。所以重要文件还是应该明确指定编码。最后一个小心得处理编码问题真正高手的做法不是等乱了再调而是在项目一开始就约定好编码、换行符、文件头格式并把这些约定固化在编辑器配置和自动化检查里。一套配置花费的时间远远小于后面每个月都要帮同事处理乱码投诉的时间。如果你现在手头正有几个乱码文件我建议你按照这篇文章的顺序走一遍先用重新打开救回内容再用通过编码保存统一格式最后把默认设置和Team配置理顺。大概率能在十分钟内解决掉八成以上的乱码问题。剩下的两成往往需要你去追一下文件究竟是从哪个工具、哪台机器、哪套系统里出来的——编码问题的根子经常不在编辑器里而在文件的出生环境上。