notepad++ 不支持真正批量转 utf-8 无 bom，所有伪批量操作易漏保存、串标签、固化乱码；必须用 nkf 或 iconv 命令行主干转换，notepad++ 仅用于抽检和补救。
Notepad++ 本身不支持真正意义上的批量转为 UTF-8 无 BOM —— 所有“批量”操作都是伪批量，漏保存、串标签、固化乱码的风险极高。必须用命令行工具（如 nkf 或 iconv）做主干转换，Notepad++ 只用于抽检和补救。
为什么“全选 → 转为 UTF-8 无 BOM”根本不可靠
Notepad++ 的 编码 → 转为 UTF-8 无 BOM 菜单项只作用于当前活动标签页，不支持多文件并发处理。所谓“批量”，实际是：打开多个文件 → 切换每个标签页 → 手动点一次菜单 → 再按 Ctrl+S → 关闭前还得确认右下角是否真显示 UTF-8（不是 UTF-8-BOM）。过程中只要漏按一次 Ctrl+S，或切错标签页，那个文件就还是原编码，但你完全察觉不到。
- 未保存就关闭标签页，转换结果直接丢失（No warning, no log）
- 多个中文文件原始编码可能混杂（有的 GBK，有的 GB18030，有的 UTF-8 with BOM），统一“转为”会把部分文件搞成双重乱码
- 插件如
Python Script或Converter声称支持批量，但实测在 2026 年最新版中仍存在跳过文件、崩溃、不写磁盘等问题
Windows 下真正能批量转为 UTF-8 无 BOM 的方法
推荐使用 nkf（Network Kanji Filter），轻量、稳定、专为日文/中文编码设计，Windows 下开箱即用。
- 下载
nkfWindows 版（nkf.exe），丢进PATH或当前目录 - 进目标文件夹，执行：
nkf -w --overwrite *.txt *.log *.conf（-w表示输出 UTF-8 without BOM；--overwrite直接覆盖原文件） - 若需保留备份，改用：
for %f in (*.txt) do nkf -w "%f" > "utf8_%f" - 注意：不要对二进制文件（如
.exe、.png）运行该命令
替代方案（Git Bash / WSL）：iconv -f GBK -t UTF-8//IGNORE *.txt | sed '1s/^\xEF\xBB\xBF//' -i —— 但 iconv 自动探测源编码容易出错，务必先用 file -i 或 Notepad++ 抽样确认原始编码。
Notepad++ 只能干两件事：验证和救火
批量转完后，必须用 Notepad++ 抽查验证，不能只信命令行输出成功。
- 随机打开 3–5 个刚转换的文件，看右下角是否稳定显示
UTF-8（不是UTF-8-BOM，也不是ANSI） - 检查开头是否有隐藏字符：按
Ctrl+Shift+P打开 Hex Editor 插件（需提前安装），看前 3 字节是不是EF BB BF；如果是，说明 BOM 没去掉 - 如果某个文件打开后仍是乱码，说明它原始编码不是
GBK，而是GB18030或BIG5，要单独用nkf -X（GB18030）或nkf -E（BIG5）重转 - 千万别在 Notepad++ 里用
Search → Replace in Files处理编码问题——它不改编码，只按当前错误解码去替换，大概率写入乱码
最容易被忽略的细节：新建文件默认 ≠ 安全
即使你用 nkf 批量转完了所有旧文件，新创建的文件仍可能带 BOM，除非你手动改了默认设置。
- 进
设置 → 首选项 → 新建，把“编码”下拉框选为UTF-8 without BOM（不是UTF-8） - 勾选“以 UTF-8 无 BOM 格式保存新文档”——这个勾选才是生效关键
- 已打开的旧文件不会受此影响，仍需单独处理
真正的麻烦从来不在“怎么转”，而在“怎么确认没转错”。BOM 是看不见的，乱码是滞后的，而 Notepad++ 不记录任何转换历史、不校验保存结果、也不提示你漏保存了哪个标签页。
