Notepad++乱码主因是编码误判而非文件损坏；须先“以GB18030等格式编码”验证可读性，再“转为UTF-8”保存，顺序颠倒会固化乱码。
Notepad++ 乱码不是文件坏了，而是它用错了编码去读字节——直接点“转为 UTF-8”大概率把乱码固化，必须先让文字“可读”，再保存。
为什么“转为 UTF-8”后反而更乱？
因为 转为 UTF-8 是把当前内存里已解码的内容，按 UTF-8 规则重新生成字节写入磁盘。如果当前显示还是乱码（比如你正用 ANSI 解析一个实际是 GBK 的文件），那内存里存的就是错的汉字映射，再转成 UTF-8，只是把错误“存档”了。
真正起作用的是 以 UTF-8 格式编码 —— 它不改文件字节，只让 Notepad++ 换种方式重新解释现有数据，用于验证原始编码是否正确。
- 试完一种没效果，立刻按
Ctrl+Z撤回，别关窗口（关闭后状态重置） - 右下角显示的编码（如
ANSI）只是 Notepad++ 的猜测，不等于文件真实编码 - 优先尝试
以 GB18030 格式编码：Windows 中文系统下绝大多数旧文本都适用，覆盖所有中文字符（包括户籍生僻字）
怎么确认原始编码并安全转成 UTF-8？
流程只有两步，顺序不能错：
- 先点菜单
编码 → 字符集 → 中文 → GB18030（或GBK、GB2312），看中文是否立刻变清晰 - 文字正常后，再点
编码 → 转为 UTF-8（推荐无 BOM 版本） - 必须立刻按
Ctrl+S保存，否则关闭后更改丢失 - 保存前确认右下角状态栏显示
UTF-8，且全文无方块、问号或标点错位
如果 以 GB18030 格式编码 后标点仍异常（如英文引号变成中文“”），大概率是文件实际为 UTF-8 无 BOM 却被误判为 ANSI，此时应改试 以 UTF-8 格式编码。
编码转换插件真有必要吗？
没必要。Notepad++ 自带的 编码 菜单已覆盖全部常用场景，插件如 Converter 或 Python Script 反而可能劫持编码逻辑，导致菜单行为失常。
遇到反复乱码，优先禁用这些插件再试——多数问题根本不在编码识别能力，而在操作顺序或外部干扰。
- 文件曾被 Excel、微信、某些 IDE 静默另存过，编码可能已被悄悄改掉
- 行尾符混用（
\r\nvs\n）虽不影响显示，但会让部分工具跳过 BOM 判断 - 插件冲突比编码误判更难排查，关掉再试是最快速的排除法
怎么让新文件和 .txt 默认用 UTF-8？
这个设置不解决已打开的乱码文件，但能避免后续重复踩坑：
- 新建文件默认编码：
设置 → 首选项 → 新建文档/默认目录 → 新建文档的默认编码选UTF-8，并勾选以 UTF-8 无 BOM 格式保存新文档 - .txt 文件一打开就用 UTF-8：
设置 → 首选项 → 语言菜单/文档类型，找到Text file，双击 → 勾选Apply to all files with extension:，输入txt，下方Default encoding for this language设为UTF-8 - 改完后，已打开的 .txt 标签页必须手动关闭重开，新规则才生效
最常被忽略的是：改完语言关联后，忘了关掉已打开的 .txt 标签页。它们仍维持旧解析逻辑，不重开就白设。
