SublimeStringEncode 是唯一可靠的 Base64 插件，因其自动处理 UTF-8 编解码、错误提示友好且支持精准选区操作，而其他插件遇中文、emoji 等易崩溃；但需避免全选误编码、超大文件卡死及误将 Base64 当加密使用。
SublimeStringEncode 是唯一值得装的 Base64 插件
别试 Base64、Advanced Encoding 或 AdvancedEncode 这些老插件——它们在遇到中文、\r\n、emoji 或空字节时会静默失败或直接崩溃，错误信息就一行：TypeError: a bytes-like object is required。根本原因是没显式调用 s.encode('utf-8')，把字符串直接喂给了 base64.b64encode()。而 SublimeStringEncode 内部封装了完整安全链：base64.b64encode(s.encode('utf-8')).decode('utf-8')，自动处理字节转换，解码失败还会弹窗提示 Invalid base64 string，不是输出一堆 或空白。
命令面板三步操作，但选区必须精准
全选整文件（Ctrl+A）是最大陷阱，尤其当文件含 YAML 注释、JSON key、HTML 标签或环境变量占位符时，插件会一并编码，结果不可逆。真实场景里该这么选：
- API header 值：用
Ctrl+L逐行选中Authorization: Bearer xxx后面的 token 部分 - K8s Secret 字段：正则搜索
value:\s*"(.+?)"→Find All→ 多光标自动定位所有值内容 - 前端内联资源：鼠标拖选
data:image/png;base64,后面那段长字符串，别带前缀
选完立刻按 Ctrl+Shift+P → 输入 StringEncode: Base64 Encode 回车，原地替换；解码同理，命令是 StringEncode: Base64 Decode。
超长文本要切片，别硬扛 10MB 日志
SublimeStringEncode 对输入长度无硬限制，但 UI 线程会卡死——你点一次命令，编辑器假死 5 秒以上，连撤销都失效。实测临界点在 2–3MB 左右。处理大日志或 dump 文件时：
- 先用
Ctrl+H搜索关键字段（如"error":或base64,），只提取目标片段 - 复制到新 tab 单独处理，避免污染原文件上下文
- 若必须批处理，拆成 500KB 以内小块，用多光标分段执行
控制台硬编码更不靠谱：import base64; print(base64.b64encode(b'...')) 要手动粘贴、加 b''、补 .decode()，错一个字符就报错，还不能作用于选区。
Base64 不是加密，别拿它当保密手段
它只是编码，和 URL encode 一样，目的仅是绕过文本协议限制。你在 Sublime 里编码的 API Key、JWT payload、配置明文，别人拿 Base64 字符串秒解——用浏览器开发者工具跑一句 atob("xxx") 就还原了。真正要保密：
- API Key 放环境变量或密钥管理服务，别塞进代码
- 敏感配置走 KMS 或 Vault，不是 Base64 编一编就安心
- 前端内联图片用 Base64 合理，但别对用户密码、token 做这种“掩耳盗铃”操作
插件再稳，也改不了 Base64 的本质：它不混淆、不打乱、不加盐，只是把字节映射成可打印字符。这点最容易被忽略，尤其当测试加密算法时误把 Base64 当作加密层来验证。
