notepad++“转为utf-8”变乱码是因为它将当前已错解的内存内容重新编码写入，而非智能识别原始编码；必须先“以某编码打开”验证可读性（如gb18030/gbk/utf-8），再执行“转为utf-8”并立即保存，否则会固化乱码。
Notepad++ 本身不自动识别文件真实编码，直接“转为 UTF-8”大概率导致二次乱码——必须先确认原始编码，再执行转换。
为什么“编码 → 转为 UTF-8”会变乱码
Notepad++ 的 转为 UTF-8 功能不是“智能猜编码后重写”，而是把当前内存里已按当前标记编码解出来的文本，再用 UTF-8 编码写回磁盘。如果当前标记错了（比如文件实际是 GBK，但 Notepad++ 错标成 ANSI），那它就拿一堆错解的字节当“原文”去 UTF-8 编码，结果必然崩溃。
- 常见错误现象：
SyntaxError: Non-UTF-8 code starting with '\xef'（Python 报错）、PHP 页面顶部空白、HTML 中文显示为 - 本质原因：文件开头没 BOM，Notepad++ 默认按系统 ANSI（中文 Windows 即 GBK）尝试解析，但有些文件其实是 UTF-8 无 BOM，有些是真正的 GB2312，有些甚至是 BIG5 —— 它不会自动选对
- 正确路径只能是两步：先
以某编码强制重解释（只改显示，不改文件），验证可读 → 再转为 UTF-8（改内容，写新字节）→ 立即Ctrl+S
手动指定原始编码的实操顺序
适用于已打开但显示乱码的单个文件，核心是“试出来再转”。右下角状态栏显示的编码名（如 ANSI）只是 Notepad++ 当前的猜测，不可信。
- 点击菜单
编码 → 字符集 → 中文，依次点GBK、GB2312、GB18030，每点一次观察是否恢复可读（注意标点、引号、括号是否正常） - 若中文仍乱，尝试
编码 → 字符集 → Unicode下的UTF-8或UTF-8-BOM（某些旧导出文件带隐式 BOM） - 确认显示正常后，立刻点
编码 → 转为 UTF-8（不是“UTF-8-BOM”），再按Ctrl+S保存 - 保存后右下角应显示
UTF-8，且关闭再打开仍正常——这才是真正完成
批量转换必须绕过 Notepad++ 的 GUI 误判
逐个文件点菜单太慢，且人工判断易漏。推荐两种可靠批量方案：
- 命令行
iconv（最稳）：iconv -f GBK -t UTF-8 -c file.cpp > file_utf8.cpp，-c跳过非法字节，适合脏数据；可配合find或for循环处理整个目录 - Python Script 插件脚本（需先装插件）：脚本里调用
notepad.open()后，必须插入notepad.setEncoding(ENCODING_GBK)类似语句强制设定源编码，再执行notepad.runMenuCommand("Encoding", "Convert to UTF-8")，否则仍走默认误判逻辑 - 注意：所有批量方案都依赖你提前知道这批文件的真实源编码（比如全项目都是从老 Windows 导出的，基本就是 GBK）；若混杂多种编码，必须先分类或用
chardet预检测
设置默认编码避免新文件再踩坑
新建文件默认用系统 ANSI（中文 Win 就是 GBK），输入中文后直接保存，等于主动制造乱码源头。
- 菜单
设置 → 首选项 → 新建/打开，将“新建文档的默认编码”设为UTF-8 - 务必勾选“以 UTF-8 无 BOM 格式保存新文档”——这个勾选才真正生效，不勾等于白设
- 该设置只影响后续新建文件，对已打开的旧文件无效；历史文件仍需手动转
- 特别提醒：
UTF-8-BOM开头三个字节\xef\xbb\xbf会让 Python、Shell、Node.js 脚本报错，除非对接明确要求 BOM 的旧系统，否则一律选无 BOM
真正麻烦的从来不是转换动作本身，而是确认原始编码——没有 BOM 的 GBK 文件和 UTF-8 文件在字节层面可能完全一致，仅靠工具无法 100% 判定，最终还得靠人眼核对内容逻辑（比如变量名、注释、字符串常量是否合理）。
