vscode无法真正批量转换文件编码，因其“另存为”仅改变保存编码而不修复错误解码；必须用iconv或powershell等外部工具按源编码读取字节再重编码。
VSCode 本身不提供“批量转换多个文件编码”的内置功能，所有所谓“一键批量改编码”操作，本质都是绕过编辑器、借助外部工具或脚本完成的。
为什么 VSCode 打开文件后另存为 UTF-8 不等于真正转码
VSCode 的 Save with Encoding（通过命令面板输入 “Change File Encoding”）只影响当前文件的**保存行为**：它会按指定编码重新写入内容，但前提是——VSCode 已经正确**识别并解码**了原始字节。如果源文件是 GBK 编码，而 VSCode 错误地以 UTF-8 解析，再另存为 UTF-8，结果就是乱码被“固化”成 UTF-8 字节，实际内容已损坏。
- 典型症状：
中文显示正常 → 另存为 UTF-8 → 再次打开变问号或方块 - 根本原因：VSCode 解码阶段出错，后续保存只是把错误解析后的字符串“忠实地”转成 UTF-8 字节
- 安全前提：必须先用正确的编码打开文件，确认内容可读，再执行保存
真正可用的批量转码方案：iconv + shell 脚本（Linux/macOS）
跨平台最稳的方式是脱离 VSCode，用 iconv 命令行工具做底层字节转换。它不依赖文本解析，直接按源编码读取原始字节，再按目标编码重新编码输出。
- 安装：
brew install iconv（macOS），sudo apt install icu-devtools（Ubuntu） - 单文件测试（务必先试）：
iconv -f GBK -t UTF-8 input.txt -o output.txt - 批量处理（当前目录下所有 .txt）：
for file in *.txt; do iconv -f GBK -t UTF-8 "$file" -o "utf8_$file"; done
- 递归处理（含子目录）：
find . -name "*.js" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \;
Windows 下推荐：PowerShell + .NET 的 StreamReader/StreamWriter
Windows 自带 PowerShell，利用 [System.Text.Encoding] 类可精准控制读写编码，比记事本或第三方小工具更可控。
- 核心逻辑：用指定编码读取文件字节 → 转成字符串 → 用目标编码写回
- 示例（GBK 转 UTF-8，当前目录所有 .ts 文件）：
$files = Get-ChildItem *.ts<br>foreach ($f in $files) {<br> $content = [System.IO.File]::ReadAllText($f.FullName, [System.Text.Encoding]::GetEncoding("GBK"))<br> [System.IO.File]::WriteAllText($f.FullName, $content, [System.Text.Encoding]::UTF8)<br>} - 注意：
[System.Text.Encoding]::GetEncoding("GBK")在部分系统需用936（代码页号）替代，否则报错Encoding name 'GBK' not supported
VSCode 插件能做什么、不能做什么
插件如 Encode Decode 或 File Encoding 只能帮你快速切换当前文件的保存编码，或批量“设置保存编码”，但**不会自动检测源编码，也不执行真实转码**。
- 它们能做的：
右键 → Set File Encoding → UTF-8，之后该文件保存时用 UTF-8 - 它们不能做的：把一个乱码的 GBK 文件“修复”成可读内容，或批量把 100 个 GBK 文件转成 UTF-8
- 危险操作：在文件已乱码状态下，用插件“强制设为 UTF-8 并保存”——这只会让乱码永久化
真正批量改编码的关键，从来不是选哪个菜单项，而是确认源编码、验证转换前后内容一致性、以及用底层工具直操作字节。VSCode 是编辑器，不是编码转换器；别让它替你做它并不擅长的事。
