你的十六进制编辑器应该给字节着色
文章摘要
作者 Alice Pellerin 在这篇文章里提出一个看似细小但极具说服力的主张：所有的十六进制编辑器（hex editor）都应该默认给字节做颜色编码（color coding）。她的核心观点是——人类视觉系统天生擅长发现颜色异常和模式，而单调的黑白十六进制 dump 完全浪费了这种能力，让我们在面对一长串字节时几乎只能逐字节扫读，效率低得令人沮丧。
为了让这个论点更直观，作者给出了若干实例。第一个例子是”在一长串字节里找到唯一的 C0“：在黑白模式下你几乎要逐行盯着看，但加上颜色后这个字节会立刻跳出来。第二组例子展示了模式识别的威力：
- 小整数的高字节：32 位整数往往只用低位，高位字节大量为 0，配色后整列字节会呈现规整的”零色块”，让文件头之类的结构一眼可辨。
- 递增偏移序列：当一连串字节是单调递增的偏移量时，配色会形成一个柔和的渐变带，视觉上立刻能识别。
- 压缩数据 vs Huffman 树：两者的字节分布特征完全不同，配色让两个区段在视觉上自然分块。
- 位图像素数据：对压缩后的图像数据着色，甚至能直接”看到”图像的轮廓。
在配色方案设计上，作者建议按字节首位 nybble（即高 4 位）来分组着色，外加 00 和 FF 两个特殊值各自独占一种颜色，总共 18 种颜色类别。这比 hexyl 等工具仅用 5 类（可打印 ASCII、控制字符、null、非 ASCII、其他）的颗粒度要细得多，能在 UTF-8 编码、压缩流、二进制结构里揭示出更复杂的模式。她的结论是：颜色编码”几乎没有任何代价，却能带来巨大的实用价值”，所有 hex 工具都应当默认开启。
HN 评论精华
- dspillett 把这个观点扩展到了所有工具：万物都应该有”克制的”基础语法高亮——少而精，避免泛滥成灾。但他强调三点：必须留出配置选项给色盲用户与有自定义配色习惯的人；尽量同时使用粗体/斜体作为冗余编码；要保证颜色仅仅是”附加信息”，去掉颜色后不丢失任何语义（这样屏幕阅读器用户也能用）。
- finaard 给开发者一条切实建议：找几个色盲朋友。他自己就经常把界面截图发给色盲朋友看，反馈对修正配色帮助巨大。
- gortok 现身说法，作为有 Deuteranomaly（绿色盲）的用户，他指出男性中有约 8% 存在某种程度的色盲（女性约 0.5%）。这篇博文里使用的颜色对他来说反而难以分辨——色盲用户的体验和正常人相差很大。多位评论者顺势推荐了模拟工具，例如 macOS 上的 Sim Daltonism 应用、Ubisoft 开源的 Chroma 着色器，以及在线的 CoBlis 色盲模拟器，让设计师在没有色盲朋友时也能验证配色。
- cwillu 强调”真人色盲朋友”的不可替代价值：单纯的滤镜模拟无法告诉你”用白色替换绿色更好”或者”哪怕能看见的颜色也可能在口头描述时引发歧义（’我点的紫色按钮没反应’ / ‘应用里根本没有紫色按钮’）”。
- cubefox 抛出一个有趣的延伸：能否给自然语言也做”语法高亮”？让 LLM 给介词、动词、问号自动着色。dspillett 回应：实际上我们已经在做了——标题加粗、强调用斜体、超链接下划线和颜色——只是没那么细粒度。userbinator 提到 Linus Akesson 那篇 2007 年的反语法高亮经典文，cubefox 反驳称该文在 2007 年或许还能立得住，到 2026 年已经显然站不住脚了。这段争论意外地把”颜色 vs 单色”的哲学战火延烸到了文本编辑器领域。