“转为UTF-8”会让乱码更严重，是因为该操作将当前已错误解码的内存内容（如用ANSI解析GBK文件导致的错字）按UTF-8规则重新编码，使错误固化且不可逆；真正安全流程是先以GB18030正确解码确认中文清晰，再转UTF-8并保存。
为什么“转为UTF-8”会让乱码更严重
因为 转为UTF-8 是把当前内存里已解码的内容，按 UTF-8 规则重新编码写入磁盘。如果当前显示还是乱码（比如你正用 ANSI 解析一个实际是 GBK 的文件），那内存里存的就是错的映射——再转一次，只是把错误固化成 UTF-8 字节，不可逆。
真正安全的操作顺序只有两步：以GB18030格式编码 → 确认中文清晰 → 转为UTF-8 → Ctrl+S 保存。
- 状态栏显示
ANSI不代表文件真是 ANSI，中文 Windows 下它大概率就是GBK或GB18030 -
以UTF-8格式编码和以UTF-8-BOM格式编码效果常一样，但 BOM 文件开头多EF BB BF，某些 Python 脚本会报SyntaxError: Non-UTF-8 code starting with '\xef' - 试错时别关窗口，
Ctrl+Z可撤回上一次编码切换；一关窗，状态重置，又要重来
怎么快速确认原始编码
右下角状态栏显示的编码只是 Notepad++ 的猜测，不能信。必须手动验证：
- 点菜单
编码 → 字符集 → 中文，优先依次点GB18030、GBK、GB2312，看到中文清晰、标点正确（比如引号是“”不是``）就停 - 若全是方块或问号，试试
以UTF-8格式编码——很多网页源码、Linux 日志实际是 UTF-8 无 BOM，却被误判为ANSI - 避免点
UCS-2 BE或UCS-2 LE，那是记事本老式双字节 Unicode，现在极少遇到，点了反而更乱
保存后还是乱码？检查这三个干扰点
流程走对了还乱码，问题可能不在编码本身：
- 文件被 Excel、微信或某些 IDE 静默另存过，原始编码已变，得确认来源再处理
- 行尾符混用（
\r\nvs\n）虽不影响显示，但某些工具会因此跳过 BOM 判断，导致后续识别失败 - 禁用
Python Script、Converter等插件再试——它们有时劫持编码逻辑，让菜单行为失常
怎么让新文件和 .txt 默认用 UTF-8
改完单个文件只是治标。要从源头减少误判：
- 菜单
设置 → 首选项 → 新建文档/默认目录：新文档默认编码选UTF-8，并勾选以UTF-8 无 BOM 格式保存新文档 - 让
.txt文件一打开就用 UTF-8：菜单语言 → 定义语言，在Apply to all files with extension:输入txt（不加点），下方Default encoding for this language设为UTF-8 - 改完语言关联后，已打开的
.txt标签页必须手动关闭重开，新规则才生效
最常被忽略的是：改完编码后没按 Ctrl+S，关掉就退回原样；而 以…格式编码 操作本身不触发保存提示，很容易误以为已经搞定。
