nppconverter 插件自 notepad++ v7.9 起被官方移除，因其依赖已淘汰的旧插件架构；v7.9+ 用户应使用内置“编码”菜单完成转换，或选用兼容的第三方 converter 插件、python 脚本批量处理。
Notepad++ 自带的 NppConverter 插件已从 v7.9 起被移除，官方不再内置，直接在菜单里找“NppConverter”或“编码转换”会失败——这不是你操作错了，是它真的没了。
为什么找不到 NppConverter 菜单项
NppConverter 是旧版 Notepad++（v7.8.x 及更早）集成的编码转换工具，依赖于过时的插件架构（Docking Plugin API v1）。v7.9+ 重构了插件系统，该插件未适配，因此被彻底剔除。你升级后发现“编码 → 转为 UTF-8”等选项消失，或者菜单里压根没“NppConverter”，属于正常现象。
- 检查版本：
帮助 → 关于 Notepad++，若显示 v7.9 或更高，就确认已不包含该插件 - 不要尝试手动复制旧版
NppConverter.dll到plugins目录——新版 Notepad++ 会忽略或报错Plugin initialization failed - 替代方案不是“装回它”，而是用内置功能或兼容插件
用内置“编码”菜单完成常见转换
v7.9+ 版本把核心编码操作全收进顶部菜单栏的 编码 子菜单，逻辑更直白，且支持无 BOM / 带 BOM 的精细切换。
-
编码 → 转为 UTF-8：强制重编码为 UTF-8（无 BOM），适合 Web 开发、Git 提交 -
编码 → 转为 UTF-8-BOM：加 BOM，兼容某些 Windows 工具（如旧版 Excel） -
编码 → 转为 ANSI：按当前系统默认代码页（如中文 Windows 是 GBK）解码并保存 -
编码 → 以 UTF-8 格式打开：不改变文件内容，仅用 UTF-8 解释当前二进制流（适用于乱码后“碰运气”重读） - 注意：
转为...是破坏性操作（改内容），以...格式打开是非破坏性操作（只改解释方式）
需要批量转码？用 Python 脚本比插件更稳
如果你常要处理几十个文件的编码清洗（比如把一堆 GBK 日志转成 UTF-8），别折腾插件兼容性，写个三行脚本更可靠：
import chardet
with open("file.txt", "rb") as f:
raw = f.read()
enc = chardet.detect(raw)["encoding"] or "gbk"
with open("file.txt", "w", encoding="utf-8") as f:
f.write(raw.decode(enc))
要点：
-
chardet比 Notepad++ 内置检测更准，尤其对混合编码或短文本 - 脚本可加循环遍历目录，
glob.glob("*.log")一行搞定批量 - Notepad++ 的“编码”菜单只作用于当前文件，没有批量入口；强行用插件（如 PythonScript）调用编码转换，反而容易因字符边界出错
真要插件？用 Converter（第三方替代）
如果必须用插件界面操作（比如给非技术人员用），可以安装社区维护的 Converter 插件（非官方，但持续更新）：
- 下载地址：GitHub 搜索
bruderstein/npp-converter，取最新Converter.dll - 放入
plugins目录后重启，菜单出现插件 → Converter → Convert to UTF-8等选项 - 它不依赖旧 API，支持 v8.x，但注意：它只是封装了 Notepad++ 自身的编码 API，底层行为和内置菜单一致，没增加新能力
- 不推荐用于含控制字符或超长行的文件——插件和编辑器一样，会在换行/截断处误判编码边界
真正容易被忽略的是：编码转换是否成功，不能只看菜单点没点，得验证文件头字节（用十六进制编辑器查 EF BB BF）和实际内容是否可读；很多“转完还是乱码”的问题，根源是原始文件本身已损坏或混用了多种编码。
