notepad++中“代码页”实为字符编码切换，需先以正确编码解析再转存；右下角显示的ansi仅为初始猜测，常误判无bom的utf-8文件；首选gb18030尝试解码，确认显示正常后再“转为utf-8（无bom）”并保存验证。
Notepad++ 里“代码页”不是可调参数，所谓“更改代码页”本质是切换字符编码（charset），必须分两步：先用正确编码重新解析现有字节，再转存为目标编码。直接点“转为UTF-8”却显示更乱，大概率是这一步跳过了。
为什么右下角显示 ANSI 却不能信
Notepad++ 右下角显示的 ANSI 只是它对当前文件字节的初始猜测，中文 Windows 下默认把 ANSI 当作 GBK 解析，但很多 UTF-8 文件没 BOM，它就误判成 ANSI，结果汉字全变问号或方块。这不是 bug，是设计逻辑：它不会自动纠错，只按标记解码。
- 点菜单
编码 → 字符集 → 中文 → GB18030，这是最稳妥的第一试；GB18030覆盖所有简体/繁体/生僻字，比GBK或GB2312更不容易漏字 - 如果文字立刻清晰、标点正常（比如引号是 “” 而不是 ``），说明原始编码就是 GB18030 系
- 若仍乱，再试
UTF-8、UTF-8-BOM—— 注意是「以 UTF-8 格式编码」，不是「转为」 - 别碰
UCS-2 LE/BE，那是记事本老古董，现代文本基本不用
“转为 UTF-8”之前必须确认显示正常
「转为」操作会把当前内存中已解码的内容，按目标编码规则重新生成字节写入磁盘。如果当前界面还是乱码，那“转为 UTF-8”只是把一堆问号固化成 UTF-8 字节，不可逆。
- 只有在
以 GB18030 格式编码后文字完全可读，才能点编码 → 转为 UTF-8 - 选
UTF-8（无 BOM）而非UTF-8-BOM：Python、Shell 脚本遇到 BOM 容易报SyntaxError: Non-UTF-8 code starting with '\xef' - 按
Ctrl+S保存，关掉重开验证 —— 不保存等于没做 - 如果保存后仍乱，检查是否被其他程序（如 Excel、微信）静默另存过，覆盖了原文件
让新文件和 .txt 默认用 UTF-8
改完单个文件没用，下次新建或打开 .txt 还会掉坑里。得设两处：
- 菜单
设置 → 首选项 → 新建文档/默认目录，新建文档编码选UTF-8，并勾选以UTF-8 无 BOM 格式保存新文档 - 右侧语言列表找到
Text file，双击 → 勾选Apply to all files with extension:，填txt（不加点、不加星号）→Default encoding for this language设为UTF-8 - 已打开的 .txt 标签页必须手动关闭重开，新规则才生效；否则它继续用旧解析逻辑
- 别依赖「以UTF-8格式打开所有文件」这个全局选项——它只是尝试解析，遇到明显非 UTF-8 的字节流（比如纯 GBK）会 fallback 回 ANSI，不能替代语言关联
批量处理时绕过 Notepad++ 编码识别
上百个日志或配置文件要转码，图形界面太慢，且容易因误判导致二次损坏。用 iconv 直接按源编码读、目标编码写，更可控。
- 在 Git Bash 或 WSL 中进入目录，运行：
iconv -f GBK -t UTF-8 input.txt > output.txt - 如果报
illegal input sequence，加-c参数跳过非法字节：iconv -f GBK -t UTF-8 -c input.txt > output.txt - 转换后用 Notepad++ 打开
output.txt，确认右下角显示UTF-8且无异常字符 -
iconv不会修改原文件，输出是新文件，安全可逆
最容易被忽略的点：改完语言关联或首选项后，已打开的标签页不会自动刷新编码逻辑，必须手动关闭重开；而「以…格式编码」操作本身不触发保存提示，很多人以为点完就完了，其实还没保存，一关就退回原样。
