Notepad++插件如Python Script、NppExec仅提供运行环境，不自动处理编码；编码行为由脚本调用notepad.runMenuCommand或chcp等命令决定，需手动预判原始编码、强制重载文件、使用宏常量替代菜单字符串，并确保DLL位数匹配、路径无中文、权限正常。
插件本身不处理编码，是脚本或命令在调用时决定编码行为
Notepad++ 插件（如 Python Script、NppExec）自身没有“编码适配层”。它们只是提供运行环境或调度能力，真正触发编码转换的，是你写的脚本里调用的 notepad.runMenuCommand("Encoding", "...") 或 notepad.menuCommand(MENUCOMMAND.xxx)，或者外部命令中显式指定的 chcp 65001。换句话说：插件是扳手，你才是拧螺丝的人。
常见误判是以为装了某个插件就自动“智能识别并转码”，结果批量处理时部分文件仍是乱码——问题不在插件，而在脚本没做编码预判、没强制重载、也没处理 BOM 存在与否。
Python Script 脚本里必须手动 reload 文件才能确保编码正确
直接对未显式指定编码的文件调用 notepad.runMenuCommand，很可能操作的是 Notepad++ 当前缓存的错误解码视图，而非原始字节流。尤其当文件实际是 GBK 但被误判为 ANSI 打开时，Convert to UTF-8 实际是在错误解码基础上二次编码，结果不可逆。
- 务必在
notepad.open()后加notepad.close()再notepad.open()强制重载，或使用notepad.openWithEncoding(path, encoding_id)（需查encoding_id常量，如UNICODE_UTF8） - 不要依赖菜单名字符串（如
"Convert to UTF-8"），改用MENUCOMMAND.FORMAT_CONV2_UTF_8等宏常量，避免中英文界面切换导致匹配失败 - 对
.sql、.cpp这类无 BOM 的旧文件，先用notepad.getEncoding()检查当前识别结果，再决定是否执行转换，而不是无条件覆盖
NppExec 运行外部命令时，chcp 和工作目录缺一不可
比如想用 Python 解释器运行当前脚本，却报 UnicodeDecodeError，大概率不是 Python 版本问题，而是 cmd 默认编码（GBK）和脚本内容（UTF-8）不一致，且工作目录没切到文件所在路径。
- 脚本第一行必须是
NPP_SAVE，否则运行的是上一次保存的内容 - 第二行写
cd "$(CURRENT_DIRECTORY)"，否则import相对模块会失败 - 第三行加
chcp 65001（Windows UTF-8 代码页），不然 Python 读取含中文路径/内容时直接崩 - 最后命令末尾补
& pause，方便看报错信息，别让窗口一闪而过
插件 DLL 加载失败时，90% 是位数/路径/权限三连击
菜单里看不到 Python Script 或 NppExec，不是插件坏了，而是 Notepad++ 根本没加载它。检查顺序必须严格：
- 确认 Notepad++ 是 x64 还是 x86 版本（任务管理器 → 详细信息 → 平台列），下载对应位数的
PythonScript.dll或NppExec.dll - 把 dll 直接扔进
plugins\目录，不是plugins\PythonScript\这类子目录；路径里不能有中文、空格、括号（如C:\Program Files (x86)\就高危） - 右键 Notepad++ 快捷方式 → 属性 → 兼容性 → 取消勾选“以管理员身份运行”，否则插件 DLL 因权限隔离被静默拒绝
- 若仍灰色，右键 dll 文件 → 属性 → 底部点“解除锁定”，Windows 从网络下载的 dll 默认被标记为不安全
真正麻烦的从来不是“怎么装”，而是“为什么看起来装了却不生效”——多数时候，是 dll 没进对目录、位数对不上、或者 Notepad++ 在后台偷偷挂着旧进程。关干净、重路径、查位数，这三步做完，插件基本就听使唤了。
