不能一键修复，需分三步：先用“通过编码重新打开”抢救乱码文件，再另存为UTF-8，最后禁用VSCode自动猜码并配置iconv批量安全转换；关键要区分“读错”可救与“写坏”不可逆。
不能一键修复，但可以分三步高效处理：先抢救显示、再统一保存、最后预防复发。关键不是“全选文件批量转码”，而是区分“读错”和“写坏”——前者能救，后者基本不可逆。
看到乱码先别按 Ctrl+S
这是最常踩的坑。VSCode默认用 utf8 解码文件，如果原始是 gbk，它会把两个字节的中文当成非法 UTF-8 序列，显示成“锟斤拷”或方块。此时你若直接保存，VSCode会用 utf8 把这些乱码字符重新编码写回磁盘，原始中文字节永久丢失。
- 右下角状态栏点当前编码（如
UTF-8或GBK），选“通过编码重新打开”，尝试GBK、GB2312、GBK with BOM - 能正常显示后，立刻点“另存为”，在保存对话框右下角手动选
UTF-8编码再保存 - 不要勾选“保存时自动添加 BOM”，
UTF-8 with BOM在跨平台脚本里容易引发新问题
批量转换老项目里的 GBK 文件
单个文件手动操作可行，但几十个 .java、.xml、.properties 文件就得靠命令行。Windows 下用 PowerShell，macOS/Linux 用终端，核心命令都是 iconv —— 它不依赖 VSCode，直接操作字节流，更可靠。
- 先确认哪些文件确实是 GBK：
file -i *.java（Linux/macOS）或Get-ChildItem *.java | ForEach-Object { chcp 65001; iconv -f gbk -t utf8 $_.FullName 2>$null | Select-String "中" }（PowerShell） - 安全批量转存（不覆盖原文件）：
iconv -f gbk -t utf8 input.java > output.java - 确认无误后，用
mv output.java input.java（Linux/macOS）或Move-Item output.java input.java（PowerShell）替换 - 避免对二进制文件（如
.jar、.class）执行iconv，会直接损坏
让 VSCode 默认用 UTF-8 且不再猜错
改完文件编码只是治标，下次拉新代码或同事提交 GBK 文件还会乱。必须切断自动猜测的源头，强制 VSCode 对所有文本文件优先信任 UTF-8，同时保留对 GBK 的兼容入口。
- 打开
settings.json，确保包含以下三项："files.encoding": "utf8"、"files.autoGuessEncoding": false、"files.defaultLanguage": "plaintext" -
"files.autoGuessEncoding": false是重点：VSCode 的自动猜测在纯中文短文件上极不可靠，关掉反而更稳 - 如果项目里明确要求 GBK（如某些遗留 Java Web 项目），可在项目根目录建
.vscode/settings.json，单独设"files.encoding": "gbk"，避免污染全局 - 终端输出乱码是另一条链路，跟文件编码无关，需单独配置
terminal.integrated.profiles.windows加chcp 65001
真正麻烦的从来不是“怎么转”，而是“哪几个文件已经被错误保存过”。建议先用 git status 和 git diff --no-index /dev/null broken-file.java 对比字节，看是否已含 EF BF BD（UTF-8 替换符），一旦出现，说明原始中文已不可恢复。
