周末我对 Solana 区块链中的一些区块链开发人员进行了一些研究，发现了一个名为 Compact-u16 的结构。文档中对此的定义如下：“compact-u16 是 16 位的多字节编码。第一个字节在其低 7 位中包含该值的低 7 位。如果该值高于 0x7f，高位被置位，该值的下 7 位被放入第二个字节的低 7 位。如果该值大于 0x3fff，则高位被置位，该值的剩余 2 位被放入第二个字节的低 7 位。第三个字节的 2 位。”。
我已经编码 30 多年了。也许我对此比较老套，但为什么有一个结构可以在 3 个字节中存储 16 位数据呢？从我的角度来看，这是非常低效的。是否有一个原因？在进一步的研究中，我发现了一个与汇编指令指针相关的文档，其中引用了 7 个指令指针，这些指令指针对于在上下文切换进出处理器堆栈时缓存值很有用。但此构造用于网络应用程序平台。就像从字面上看，我没有理由能够证明使用 3 个字节来存储 16 位数据是合理的。如果开发人员想要使用优雅的位映射解决方案来压缩空间，为什么不直接使用信号量呢？为什么要创建一个全新的构造，将数据的存储需求增加 33%。
我缺少什么？
在阅读 Compact-u16 描述时，我也有一些类似的困惑。根据solana python 模块中解析它们的代码，我相信它们正在做一些概念上类似于 UTF-8 的事情，并根据数字的大小将数字存储在 1-3 个字节中。
基本上，每个字节不是具有 8 位数字，而是具有 7 位数字和一个指示数字是否在下一个字节中继续的标志（最高有效位）。对于最大的数字，它们需要一个额外的字节，但对于小于 128 的数字，它们只需要一个字节。由于 Solana 似乎使用它们来存储数组的长度，因此如果数组的长度通常小于 128，那么它们最终将在所有事务中传输的总字节数减少。
我为自己设计的一些例子：
hex | compact-u16
--------+------------
0x0000 | [0x00]
0x0001 | [0x01]
0x007f | [0x7f]
0x0080 | [0x80 0x01]
0x3fff | [0xff 0x7f]
0x4000 | [0x80 0x80 0x01]
0xc000 | [0x80 0x80 0x03]
0xffff | [0xff 0xff 0x03])