Notepad++字母乱码（如print变prënt）是因文件实际编码与解码方式不匹配，需先手动验证原始编码（如GBK/UTF-8），再用notepad.convertEncoding()配合正确ID（如notepad.ENCODING_UTF8）转换并立即保存，否则仅“以某编码打开”无效且不改变文件字节。
print 变成 prënt 或变量名崩坏）不是字体问题，而是文件实际编码与 Notepad++ 当前解码方式不匹配——脚本根本没被正确读取，Python 解释器自然报错。必须重编码，不能只“以某编码打开”。
为什么 Convert to UTF-8 在 Notepad++ 里不生效？
你点了菜单里的 Convert to UTF-8，保存后还是乱码或运行报错，大概率因为：
• 当前标签页根本没真正识别出原始编码，Convert to UTF-8 是在错误字节流上做无效转换；
• 文件已含 BOM，但 Notepad++ 把它当 ANSI 解析，再转 UTF-8 就叠了两层错；
• 脚本里有非 ASCII 字符（如中文路径、注释），而原始编码是 GBK，却用 UTF-8 模式去转，字节映射全乱。
用 Python Script 插件批量转码前，必须确认三件事
插件能自动化操作，但无法猜编码。以下检查缺一不可：
• 打开一个典型乱码文件 → 点 编码 菜单 → 逐个试 GBK、UTF-8、UTF-8-BOM，直到内容（包括变量名、关键字、注释）全部清晰可读；
• 确认右下角状态栏显示的编码名（如 GBK）是你手动选中后“能看清”的那个，不是 Notepad++ 自动检测的默认值；
• 记下这个真实源编码（比如 GBK），后续脚本里 notepad.convertEncoding() 的输入参数必须严格匹配，不能写 "gbk" 或 "GB2312" —— Notepad++ 内部编码名是大小写敏感的固定字符串。
notepad.convertEncoding() 的坑比想象中多
这个函数不接受编码字符串常量，只认 Notepad++ 内置编码 ID（整数）。直接传 "UTF-8" 会静默失败，文件内容不变：
• 正确做法：查表用预定义常量，例如 notepad.convertEncoding(notepad.ENCODING_UTF8)；
• 常见 ID：notepad.ENCODING_UTF8、notepad.ENCODING_ANSI（Windows 下即 GBK）、notepad.ENCODING_UTF8_BOM；
• 切记：调用后必须立刻执行 notepad.save()，否则转换只停留在内存，关闭标签页就丢；
• 如果文件路径含中文或空格，notepad.open() 可能失败，建议先用 os.path.normpath() 标准化路径。
批量处理时最易忽略的致命点
脚本跑完看似全部“转成功”，但部分文件仍报错，往往卡在：
• 某些文件被其他程序占用（如 IDE 正在索引、Git 正在 diff），notepad.open() 失败，脚本跳过但不报错；
• 子目录里有二进制文件（如 .pyc、.exe），脚本没过滤，打开后变成乱码块，convertEncoding() 对非文本文件无意义；
• 转换后未验证：右下角状态栏显示 UTF-8 ≠ 文件真以 UTF-8 存盘，要关掉再重开，看是否还保持正常显示；
• 不同扩展名需不同策略：.py 文件必须转 UTF-8（无 BOM），但 .bat 或旧版 .ini 可能依赖 ANSI，硬转反而破坏功能。
