4个版本

0.2.2 2024年1月24日
0.2.1 2023年5月8日
0.2.0 2021年11月21日
0.1.0 2020年12月3日

#48 in Encoding

Download history 480807/week @ 2024-04-30 490309/week @ 2024-05-07 518459/week @ 2024-05-14 510693/week @ 2024-05-21 596655/week @ 2024-05-28 628069/week @ 2024-06-04 646591/week @ 2024-06-11 599951/week @ 2024-06-18 648445/week @ 2024-06-25 585629/week @ 2024-07-02 674770/week @ 2024-07-09 684854/week @ 2024-07-16 667210/week @ 2024-07-23 664322/week @ 2024-07-30 656425/week @ 2024-08-06 588198/week @ 2024-08-13

2,695,770 每月下载量
3,553 个crate中使用 (直接使用159个)

Apache-2.0

185KB
4K SLoC

Workflow Status Average time to resolve an issue Percentage of issues still open Maintenance

ciborium

欢迎使用Ciborium!

Ciborium包含为serde实现的CBOR序列化和反序列化

快速开始

你可能正在寻找 from_reader()into_writer(),这是主要函数。请注意,字节切片也是读取器和写入器,可以像流一样传递给这些函数。

对于动态CBOR值创建/检查,请参阅 Value

设计决策

始终将数值序列化为最小大小

尽管CBOR规范有不同的数值宽度,但这只是线上的压缩形式,并不是直接表示“整数宽度”或“浮点宽度”。因此,ciborium始终将数字序列化为最小可能的无损编码。例如,我们将 1u128 序列化为单个字节(01)。同样,我们还可以将其自由解码为 u128

虽然这会有一些小的性能成本,但选择这个方案有几个原因。首先,规范似乎通过使用单独的位来表示符号来暗示这一点。其次,规范要求实现处理前导零;宽松地阅读这暗示了需要无损转换的要求。第三,像Python这样的动态语言没有“整数宽度”的概念,这使得这是与这些语言最大化线兼容性的实用选择。

这种转换始终是无损的。对于浮点数,这意味着只有当转换回原始大小具有与原始相同的原始位时,我们才将它们转换为更小的尺寸。

与其他实现的兼容性

ciborium 项目遵循 鲁棒性原则。因此,我们的目标是接受的内容尽可能宽松。这意味着我们希望与其他实现进行线缆兼容,但在编码方面则不一定。

这一点的显著例子是 serde_cbor 使用固定宽度的数字编码,并且不会无损转换。这意味着 ciborium 将成功解码 serde_cbor 的编码,但反过来可能不行。

将 Map 表示为值序列

其他 serde 解析器通常采取使用 BTreeMapHashMap 来实现其编码的底层 Map 类型的方法。这个 crate 选择使用 Vec<(Value, Value)> 来表示 Map 类型。

这个决定是因为这种类型保留了线上对的数据对顺序。此外,对于需要 BTreeMapHashMap 属性的用户,可以简单地使用 collect() 将值收集到相应的类型中。这提供了最大的灵活性。

低级库

ciborium crate 在 (私有) basic 模块中开始了低级库的构建。我们可能会在将其调整到良好的状态后扩展它,以便于应用程序的使用。如果您愿意在此方面与我们合作,请与我们联系。或者,我们可能将此代码分支到一个不依赖于 serde 的独立 crate 中。

内部类型

ciborium crate 包含了许多实现有用 serde 特性的内部类型。虽然目前还没有公开,但如果有必要,我们可能会在将来选择公开它们。通常,这个 crate 对公开 API 采取保守的方法,以避免破坏。

打包编码?

打包编码使用数值偏移来表示结构字段名称和枚举变体名称。这可以在线上节省大量空间。

虽然这个 crate 的作者喜欢打包编码,但通常应该避免使用,因为它可能很脆弱,因为它将 Rust 代码的不变性暴露给远程参与者。我们可能会考虑将来添加这一点。如果您对此感兴趣,请与我们联系。

许可证:Apache-2.0

依赖项

~0.6–1.2MB
~28K SLoC