notepad++“转为utf-8”变乱码是因为它将当前已错解的内存内容（如把gbk字节误作ansi解出的乱码）直接按utf-8规则重编码写入，而非识别原始编码；必须先“以gb18030等编码打开”验证显示正常，再执行“转为utf-8”并ctrl+s保存。
为什么直接点“编码 → UTF-8”会让中文变乱码
这不是操作错了，是 Notepad++ 的「转为 UTF-8」和「以 UTF-8 格式编码」根本不是一回事。前者把当前内存里已被错误解码的乱码字节，再按 UTF-8 编码规则重新写入文件——相当于把错的答案再抄一遍；后者才是让 Notepad++ 暂时用 UTF-8 规则重新读取原始字节，用来验证原始编码是否对得上。
常见误操作：编码 → UTF-8（灰色菜单项）→ 点了 → 中文更糊了 → 以为工具不行。其实该点的是 编码 → 以UTF-8格式编码 或 编码 → 字符集 → 中文 → GB18030 先试读。
- 优先尝试
GB18030：它能覆盖所有中文汉字（包括生僻字），比GBK和GB2312更稳妥 - 如果文字恢复了，右下角状态栏会立刻显示对应编码名（如
GB18030），这时才能点编码 → 转为UTF-8-BOM -
ANSI在简体中文 Windows 下实际就是GBK的别名，但识别不稳定，不建议依赖
怎么确认当前文档的真实原始编码
不能靠猜，得靠试。Notepad++ 不会自动识别带中文的文件编码，尤其当文件没 BOM、又混用中英文时，很容易误判为 ANSI 或 UTF-8。
正确做法是：先关闭当前文件（不保存），再用「文件 → 打开」重新加载，打开时不要双击，而是用菜单打开，并在弹出对话框里点击右下角「编码」下拉框，依次选 GB18030、UTF-8、UTF-8-BOM —— 哪个能正常显示汉字和标点，哪个就是原始编码。
- 如果
UTF-8和UTF-8-BOM都显示方块，但GB18030正常 → 原始是 GBK 系编码 - 如果
GB18030显示乱码，但UTF-8-BOM正常 → 原始就是 UTF-8-BOM - 避免点
UCS-2 LE/BE：那是记事本老式 Unicode，现在极少遇到，点了大概率全变方块
转完 UTF-8 后保存还乱码？检查这三处
很多人点了 转为UTF-8-BOM 并按了 Ctrl+S，结果发给同事还是乱码。问题往往不在转换本身，而在后续环节。
- 没立刻保存：转换只是改内存，关掉不存就白干；右下角显示
UTF-8-BOM≠ 已写入磁盘 - 被其他程序二次改写：Excel、微信粘贴、某些 IDE 保存时会静默转回 ANSI 或 UTF-8（无 BOM），重新打开前确认来源
- 行尾符干扰 BOM 判断：有些老旧工具（如部分批处理脚本）读取时跳过 BOM，导致它把
EF BB BF当作普通字符，显示为  —— 这不是 Notepad++ 的错，但你可以改用UTF-8（无 BOM）再试
批量转换几十个文件怎么办
Notepad++ 自身不支持跨文件批量编码转换，硬录宏容易播到空标签页报错，且无法判断是否已处理完。真要批量，得绕开图形界面。
推荐用命令行 iconv，它不依赖 Notepad++，直接按指定编码读、按目标编码写，干净可靠：
iconv -f GBK -t UTF-8 -c file1.txt > file1_utf8.txt
-
-f是源编码，-t是目标编码，-c表示跳过非法字节（防中断） - Windows 用户可装 Git Bash 或 WSL；macOS / Linux 直接可用
- 批量处理：用
for循环或find命令，比如for f in *.txt; do iconv -f GBK -t UTF-8 -c "$f" > "utf8_$f"; done
真正麻烦的永远不是转换动作本身，而是你不确定原始编码到底是什么——哪怕只差一个字节，iconv 也会报错或截断。所以批量前，务必先拿一两个样本，在 Notepad++ 里手动确认原始编码。
