发布于2026-07-17 阅读(0)
扫一扫,手机访问
先说一个核心判断:Sublime Text 从来就不是一个真正的十六进制编辑器。这一点,很多开发者直到搞坏几个二进制文件后才真正明白。HexViewer 插件看似提供了十六进制视图,但本质上它只是一个只读的展示窗口——任何在它里面做的修改,保存时都会把十六进制字符串当作普通文本写入,最终导致原始文件面目全非。

说白了,HexViewer 展示的只是字节的字符串表示,比如你看到的 48656c6c6f,并不是原始字节流本身。你在里面把 65 改成 66,Sublime 实际保存的是两个字符 "6" 和 "6",而不是一个字节 0x66。结果就是文件体积膨胀、结构错乱、校验失败,而且不可逆。
注意看状态栏右下角,永远显示着 Hex Viewer (read-only)——这不是一个建议,是硬性限制。
Sa ve as Binary、Apply to Original,也没有任何反向还原功能File → Sa ve,覆盖原文件的也只是 ASCII 文本,回不去了很多人遇到的情况是:打开二进制文件后,命令面板里搜不到 HexViewer 的相关命令。第一反应往往是插件没装,但真实原因往往没那么简单。
Ctrl+S):未命名的缓冲区无法被识别为可解析目标,插件根本不会触发.txt、.log):即使内容全是乱码,插件也会直接跳过HexViewer 必须大小写准确,Hex View、HexEditor 或 hexviewer 都不行Package Control: Satisfy Dependencies 强制重载插件环境,很多时候就能解决验证插件是否安装成功也很简单:菜单栏看 Preferences → Package Settings → HexViewer 是否存在,存在就是正常的。
默认情况下,HexViewer 的 max_file_size 限制是 10MB。超过这个大小会启用流式加载,但很多固件或加密 blob 开头包含 \x00\x00\x9f 这类非法 UTF-8 字节,解析到那里就直接中断,报错 invalid start byte,或者干脆给你一片空白。
解决方法分两步走:
Preferences → Package Settings → HexViewer → Settings,在用户设置中添加 "max_file_size": 104857600(即 100MB)xxd -g1 yourfile.bin | subl -,Windows 上用 certutil -encodehex -f yourfile.bin stdout 4 先查看前几行,确认数据是否可读绕开 Sublime 的文本层才是可靠路径。这里给出几个经过验证的方案:
xxd -g1 file.bin > file.hex,在 Sublime 中编辑、注释、搜索替换,再用 xxd -r -g1 file.hex > file_new.bin 还原回去HxD,Linux 上 Bless,跨平台 010 Editor(支持结构模板和内存映射)File → Reopen with Encoding → Hexadecimal:Sublime 根本没有这个编码选项,纯属误传关键点在于:Sublime 的文件加载机制基于字符编码器,而二进制数据本身没有编码定义。所有想在 Sublime 里直接改十六进制再保存的操作,本质上都是在破坏原始字节流,没有任何例外。