🔧 编码 · 安全设计
告别 LEB128 的规范性陷阱，Bijou64 用结构设计解决安全问题
Ink & Switch 实验室发布新型变长整数编码格式 Bijou64，确保每个整数映射到唯一合法的字节序列，从根源消除一类安全漏洞。解码速度最高提升 10 倍。
综合公开信息整理•
2026-07-23•
全文约 4 分钟读完
#Bijou64
#变长整数编码
#安全设计
#LEB128
#Ink&Switch
0–247
直接值范围 · 单字节表示
2×
小数字解码速度提升
8–10×
大数字解码速度提升
⚡ 30 秒速览
- 问题根源：LEB128 中同一数字存在多种编码方式，规范检查常被遗漏，形成攻击面。
- 设计方案：Bijou64 通过直接值 + 标签字节 + 固定偏移量的结构设计，保证唯一编码。
- 性能表现：编译器优化友好，小数字解码快 2 倍，大数字快 8–10 倍。
- 社区反馈：部分开发者质疑其与 SIMD 方向的竞争力，以及安全性边界的完整性。
- 可用性：已发布 Rust、JavaScript、Elixir、Go、Perl、Java 多语言实现。
01问题的核心 LEB128 的规范性陷阱
传统变长整数格式 LEB128 将整数拆分为多个 7 位数据块，每个字节用一位标志位表示后续是否还有字节。这种方式导致同一个数字可能存在多个有效字节序列——例如 0 可以编码为 0x00，也可以编码为 0x80 0x00。
在使用加密签名、内容寻址或分布式共识的系统中，这些冗余编码会形成攻击面。虽然规范要求解码器拒绝非规范输入，但开发者经常会遗漏这些验证检查，或者为了优化性能将其移除。这类问题在历史上曾导致 PKCS#1 v1.5、GnuTLS 以及比特币交易可塑性漏洞。
两种思路，两种结局。
LEB128
7 位数据块 + 标志位 → 同一数字多种编码 → 需额外规范检查，易遗漏。
Bijou64
直接值 + 标签字节 + 固定偏移 → 结构保证唯一编码，无需规范检查。
注：规范检查指解码器需验证编码是否为规范形式。Bijou64 从结构上消除了这种需求，而非通过增加检查来弥补。
02设计原理 让不安全的状态根本不存在
Bijou64 的设计者 Brooklyn Zelenka 将其核心思路概括为一句话：「不是通过增加更多检查来实现安全，而是让格式本身保证：即使完全没有规范性检查，对于任何给定值，存在的唯一编码就是规范编码。」
该设计依赖两种主要的结构机制：
0–247直接值范围
单字节，无元数据
248–255标签字节范围
指示后续负载字节数
固定偏移量每级长度加常量
防止填充编码
大端整数负载连续排列
编译器优化友好
注：标签字节 248–255 分别对应 1–8 个负载字节，每个长度级别增加固定常量偏移量，确保小值无法通过填充方式被编码到更大的字节长度中。
03解码性能 2× 到 10× 的提升
由于负载部分是连续的大端整数，编译器可以将解码转换为一次加载操作和一次字节交换。在 x86 和 ARM 硬件上，Bijou64 的实测表现远超 LEB128：
2×
小数字解码速度提升
8–10×
大数字解码速度提升
1 次
加载 + 字节交换
编译器优化核心
更少分支
避免位掩码与
连续位遍历
注：性能对比基于 x86 和 ARM 硬件测试。小数字指 0–247 范围（直接值），大数字指 248 以上范围（需标签字节）。Bijou64 避免了 LEB128 中的位掩码操作及大量分支判断。
但性能数据只是故事的一半。一个设计能否经得起社区的审视，才是真正的考验。
04社区争议 三个方向的不同声音
Hacker News 社区针对该格式提出了多个权衡讨论，涉及性能路径、安全边界和实际需求。
🎯 争议一：SIMD 方向才是未来 性能路径
- 观点：仅与标量解码器比较，忽略了高性能解析的发展方向。当转向 SIMD 指令时，ULEB128 或 sentinel values 因拥有并行化机会而每次都会获胜。
- 补刀：即使是 SIMD 文本解析也会超过 Bijou64 的方案——SIMD 的能力就是这么强大。
性能比较的基准选择至关重要，标量优势不等于整体优势。
🔒 争议二：安全性并未完全消除 安全边界
- 观点：Bijou64 缩小了需要检查的边界范围，但并未完全消除运行时验证。忘记检查 first_byte==255 情况下的范围限制，导致 64 位溢出，和遗漏 LEB128 的范围检查一样是合理的漏洞。
- 更尖锐的批评：Bijou64 甚至可能更易出问题——它会让人认为较小输入根本不需要任何范围检查，因此开发者可能忘记为最大长度情况添加特殊处理。
「看起来安全」可能比「明显需要检查」更危险，安全设计需要防御最粗心的开发者。
🔧 争议三：非规范编码在某些场景是需求 工具链需求
- 观点：LEB128 的非规范特性在 WebAssembly 和 DWARF 的链接器中被有意使用——用于为未链接引用填充空间，以便进行原地修补。
- 结论：可变长度填充对于某些特定工具链来说仍然是一项有意保留的需求，并非所有场景都需要规范唯一性。
设计取舍需场景验证：规范唯一性在安全敏感场景是优势，在工具链场景可能成为限制。
编辑核心判断
编码格式的安全性不能依赖「开发者记得做检查」，而应通过结构设计让不安全的状态根本不存在。Bijou64 在这条路上迈出了扎实的一步，但社区争议也提醒我们：没有银弹，每个设计选择都是一组权衡，安全性与灵活性之间的张力需要场景来裁决。
▶现在就能用
Bijou64 已发布到 crates.io 和 npm，采用 MIT / Apache 2.0 双许可证。同时提供社区维护的 Elixir、Go、Perl、Java 移植版本。
crates.io → bijou64