converter插件是notepad++ v7.9+自带的文本与十六进制互转工具，需确保其dll存在且未禁用；它按当前编码读取字节转换，结果受utf-8/gbk等影响，不支持纯连续hex输出，还原失败多因编码不匹配。
Converter 插件是 Notepad++ 自带的进制转换主力，无需额外安装（v7.9+ 默认启用），但容易被禁用或误删；Hex Editor 插件则负责二进制视图，两者分工明确，不能互相替代。
为什么 Converter 插件点不开？
常见现象是菜单里没有「插件 → Converter」，或点击后无响应。这不是功能缺失，而是插件未加载成功。
-
Converter.dll文件可能被自动禁用：检查%ProgramFiles%\Notepad++\plugins\Converter.dll是否存在且大小非零 - v8.6+ 精简版（如 Chocolatey 或企业打包版）常默认剔除该插件，需手动下载
Converter.dll放入plugins目录 - 插件管理器中可能显示为“已禁用”：打开「插件 → 插件管理器 → 显示已禁用插件」，勾选
Converter并重启
ASCII → HEX 转换结果为什么和预期不符？
这个操作本质是按当前文档编码读取字节再转十六进制，不是“字符转 hex”，所以编码决定一切。
- UTF-8 下中文占 3 字节（如“中”→
e4 b8 ad），GBK 下占 2 字节（d6 d0），ANSI（系统默认）下行为不稳定，尤其在中文 Windows 上易出错 - 换行符也会被编码：
\r\n→0d 0a，\n→0a，跨行选中时务必注意 - 不支持非连续选中或列模式选中，仅处理光标拖拽的连续文本块
想把 HEX 字符串还原回原文，但乱码了怎么办？
还原失败几乎全是编码错位导致的，不是插件坏了。
- 必须先确保文档编码与原始 HEX 对应的编码一致：如果 HEX 来自 UTF-8 文本，就先「编码 → 转为 UTF-8」，再执行「插件 → Converter → HEX → ASCII」
-
HEX → ASCII要求输入严格：只允许十六进制字符（0-9、a-f、A-F）、空格、制表符、换行符；中文标点、多余字母、错位空格都会导致解析中断或乱码 - 若原始 HEX 是连续字符串（如
616263），而非空格分隔格式（61 62 63），Converter无法识别，需先用正则替换插入空格，或改用 Python 脚本
需要纯 hex 字符串输出（如 "616263"）怎么办？
Converter 只输出空格分隔格式（61 62 63），这是它的设计限制。要得到无分隔纯字符串，得绕开它。
- 用 Python Script 插件（推荐）：选中文本后按
F6，运行editor.setText(editor.getSelText().encode('utf-8').hex())，结果为小写连续 hex；加.upper()得大写 - 用 PowerShell（Win10+ 自带）：在「运行 → 运行(F5)」中执行
powershell -Command "get-content '$(FULL_CURRENT_PATH)' -Raw -Encoding Byte | ForEach-Object { $_.ToString('X2') } | Out-String -NoNewline" - 别用
certutil -encodehex：它输出的是带地址偏移的 hex dump，不是纯字符串
Converter 和 Hex Editor 解决的是两类完全不同的问题**——前者是文本 ↔ 字节序列的编码转换，后者是文件 ↔ 原始字节流的可视化编辑。混用或期待一方替代另一方，是绝大多数“转不出来”“还原失败”问题的根源。
