VSCode怎么把当前文件的编码格式改为UTF-8

使用VSCode时遇到文件乱码或编码报错，几乎是每个开发者都会碰到的坑。有些问题看似简单，但背后的设置逻辑和VSCode的“记忆机制”一绕，往往反复折腾也搞不定。这篇文章把最典型的三个困扰整理了一下，一次说清楚。

右下角点“GBK”或“ISO-8859-1”后到底选哪个？

具体操作路径是这样的：看到底部状态栏那个编码标签了吗？直接点击它，菜单就会弹出来。

这个菜单里其实藏着两个完全不同的操作：

选“Reopen with Encoding → UTF-8”，只是临时换一种编码来解读当前文件的内容。文件本身没有被改动，关上再打开，该乱码还是乱码。主要用于快速验证——看看是不是编码猜错了导致的显示异常。

而“Sa ve with Encoding → UTF-8”，才是真正把文件写回磁盘。编辑器里当前的内容，会被以纯UTF-8（无BOM）的格式保存到原文件里。想要一劳永逸地改掉编码，选这个。

有一点得提醒你：菜单灰掉了，说明文件没有被编辑过，没有任何变更可以保存。先按Ctrl+S随便改个空格再保存一次，菜单就恢复正常了。

为什么明明是“Sa ve with Encoding → UTF-8”，Python还是报错？

十有八九，你选的是“UTF-8 with BOM”，不是纯“UTF-8”。

这俩的区别就藏在BOM头上。BOM全称是“字节顺序标记”，是一个在文件最开头写入的不可见特殊字符（U+FEFF）。很多Windows下的编辑器（尤其是早期的记事本）都习惯带BOM，但Python解释器看到这个前缀，会直接抛出SyntaxError: Non-UTF-8 code starting with '\xff'——它认为文件里出现了非UTF-8的非法字符。

之前在Git diff里看到那些奇怪的^@符号，多半也是BOM搞的鬼。

VSCode的状态栏很明确：显示“UTF-8”就是无BOM，显示“UTF-8 with BOM”就是带BOM。选的时候务必看清菜单项，挑不带“with BOM”字样的那一个。

改完之后，下次打开为什么还是乱码？

这个问题最容易被忽视——VSCode会为每个文件记住它“上次开的是用什么编码”。这个偏好是单独存储的，不受全局设置的影响。

所以哪怕你在settings.json里写好了"files.encoding": "utf8"，对已经打开过的文件也完全无效。想让某个文件以后永远默认为UTF-8，必须执行一次“Sa ve with Encoding → UTF-8”。VSCode会把这次的选择记为该文件的“偏好编码”，下次打开时自动沿用。

如果操作方法都试过，文件仍然反复回退到GBK或别的编码，那就得清理一下历史缓存了：关掉文件 → 删除项目目录下的.vscode/workspaceStorage文件夹 → 重启VSCode。那些顽固的编码记忆会被清空。

settings.json里的"files.encoding": "utf8"到底怎么写才生效？

这个问题看似基础，但很多人正是在这里翻了车。关键就三个字：格式必须严格。

正确的写法是"utf8"——全小写，无短横，无BOM后缀。下面这几种写法都是无效的：

• "UTF-8"（大写加短横，忽略）
• "UTF8"（大写，忽略）
• "utf-8"（有短横，忽略）
• "utf8bom"（带BOM后缀，忽略）

另外，记得把"files.autoGuessEncoding": false一起写上。如果这个选项开着，VSCode仍然可能根据文件头自动“猜”回GBK，导致全局设置形同虚设。

对团队项目来说，更推荐使用工作区配置——就在项目根目录的.vscode/settings.json里写这两项。它比用户级设置优先级更高，能避免开发环境不同带来的编码冲突，尤其当项目里还混着一些旧版GBK文件时，效果立竿见影。