为何二元组编码（BPE）不适用于二进制数据？如何用其压缩二进制数据？

• 无空闲编码可用：自然语言用BPE时，能借助不常用字符或未占用编码存储合并后的新token，但二进制的256个字节值全是合法有效数据，没有预留的“空闲”编码空间。随便拿一个字节当合并后的token，会和原数据里的同值字节完全混淆，解码时根本分不清是原字节还是合并组合，直接导致数据损坏。
• 统计特性不匹配：BPE核心是抓高频重复的字符组合压缩，自然语言有明确的高频组合（比如英文的"th"、中文的“的”），但二进制数据的字节分布往往更均匀，很多时候没有稳定的高频字节对，就算有，重复模式也和自然语言的语义组合逻辑完全不同，原BPE的合并策略效果会很差。
• 编码冲突无法解决：BPE每次合并二元组后，需要用新符号替换原组合，但二进制里所有符号（字节）都被原数据占用了，替换后没有办法标记“这是合并后的token”，解码时逆向操作会彻底混乱。

• 引入前缀标记区分原字节与合并token：选一个特定字节（比如0xFF）作为前缀，输出合并后的token时先写这个前缀，再写对应编码；原字节则直接输出。注意原数据里可能也有这个前缀字节，所以要对原数据中的前缀字节做转义（比如用0xFF+0xFF表示原数据里的0xFF）。关键是平衡合并的压缩收益和前缀、转义带来的额外开销。
• 复用低频字节作为临时编码：先统计二进制数据中所有字节的出现频率，把出现次数最少的几个字节“腾出来”存储合并后的新token。最后在压缩文件头部记录这些低频字节对应的原字节值，以及合并token对应的二元组映射表。解码时先加载头部映射，再把临时编码还原成原字节或合并前的二元组。
• 结合其他压缩逻辑优化：把BPE作为压缩链的一环，比如先用LZ77找出二进制数据里的长重复序列，再对剩下的字节流用BPE合并高频字节对；或者在BPE处理后，配合霍夫曼编码对合并后的token做变长编码，利用霍夫曼对高频token用短码的特性放大压缩效果。
• 调整BPE的合并优先级规则：针对二进制数据修改合并逻辑，不是只看字节对的出现次数，而是计算合并后能减少的总字节数（比如一个字节对出现N次，合并成一个token能减少N个字节，优先合并这类收益最高的组合），同时必须在压缩文件头部完整记录所有合并token与原二元组的映射关系，确保解码时能完全逆向还原。

内容的提问来源于stack exchange，提问作者nuubae