vscode打开乱码文件需点击右下角编码标识→选reopen with encoding→尝试gbk、utf-8 with bom等；可配置settings.json按后缀预设编码，但手动确认过的文件会锁定编码忽略设置。
VSCode 打开乱码文件时怎么强制重新检测编码
VSCode 默认不会自动重检已打开文件的编码，哪怕你手动改过文件内容或从别处复制粘贴进来。乱码出现后，Reload with Encoding 是唯一靠谱的补救动作。
操作路径：右下角状态栏点击当前编码标识（如 UTF-8）→ 选 Reopen with Encoding → 试几个常见编码（GBK、ISO-8859-1、UTF-8 with BOM）。注意：Auto Detect 按钮只在 Reopen with Encoding 菜单里有，不在右键菜单中。
- 乱码刚出现就立刻操作，保存后再重开可能已写入错误编码
-
Auto Detect不是实时监听，只是对当前文件做一次启发式猜测，对混合编码或短文本准确率很低 - 若试了
GBK和UTF-8都不对，大概率是Big5或带 BOM 的变种，别跳过UTF-8 with BOM
怎样让 VSCode 对特定后缀文件默认用 GBK 打开
VSCode 不支持全局“自动识别并切换”，但可以按文件扩展名预设编码。这对老项目里的 .txt、.bat、.log 文件最实用。
在 settings.json 中加配置项：
"files.encoding": "utf8",
"files.autoGuessEncoding": false,
"[plaintext]": {
"files.encoding": "gbk"
},
"[bat]": {
"files.encoding": "gbk"
}
注意：[plaintext] 是 VSCode 内置的语言标识，不是文件后缀；.txt 默认归类到它下面。而 .js、.py 等语言文件不走这个规则，得单独配 [javascript]、[python]。
-
files.autoGuessEncoding: true会拖慢大文件打开速度，且对中文环境误判率高，建议关掉 - 配置生效需重启文件或关闭再重开——修改设置后已打开的文件不会自动刷新编码
- 工作区级
.vscode/settings.json优先级高于用户级，适合项目私有编码约定
为什么改了 settings.json 还是不生效
最常见原因是编码配置被更高优先级的设置覆盖，或者文件已被标记为“已确认编码”。
- 右下角编码显示旁有个锁图标 → 表示该文件编码已被用户手动确认，VSCode 会记住并忽略
settings.json配置 - 检查是否启用了
files.encoding的 workspace 设置（比 user 设置优先级高），用命令面板搜Preferences: Open Workspace Settings确认 - 插件干扰：某些格式化插件（如
Prettier）会在保存时强制转成UTF-8，和你的打开编码无关，但会让“以为配错了” - 终端输出的乱码不是编辑器问题，而是 Windows 控制台默认编码（
CP437或CP936）导致，和 VSCode 编码设置无关
遇到“Unsupported charset”的错误怎么办
这个错误通常出现在通过 file:// 协议打开网络路径、或使用某些远程开发扩展时，VSCode 底层无法解析服务端声明的字符集（比如 HTTP 响应头里的 charset=gb2312）。
此时 VSCode 会 fallback 到 UTF-8，但实际内容是 GBK，于是报错并显示空文件或乱码。
- 不要点“Retry”，没用；先关掉文件，再用
File → Open File...本地打开副本 - 如果必须处理远程文件，改用
SFTP扩展挂载为本地路径，它支持在传输层指定编码 -
Unsupported charset不是 bug，是 Electron 底层限制，VSCode 官方明确不计划支持非标准编码别名（如GB2312和GBK视为不同）
.editorconfig 明确写死 charset = utf-8，然后靠 CI 拦住非 UTF-8 提交——编辑器层面能做的，就是别信 Auto Detect，手动设好后缀映射，出问题秒切编码。
