问题标签 [cbor]

我正在尝试进行结构序列化，其中字节最终将通过管道发送，重构并在它们上调用方法。

我创建了一个特征，这些结构将根据需要实现，并且我使用 serde 和 serde-cbor 进行序列化：

当我尝试使用特征作为类型来重构字节时（假设我不知道正在发送哪个底层对象），编译器抱怨特征没有实现Sized特征：

我想这是有道理的，因为编译器不知道结构应该有多大，也不知道如何为它排列字节。如果我更改反序列化对象的行以指定实际的结构类型，它会起作用：

是否有更好的模式来实现这种序列化+多态行为？

我正在尝试使用node- coap 通过 CoAP 从 IoT 设备传输传感器数据。数据到达 CoAP 服务器时的顺序对我来说很重要。confirmable即使使用请求选项，我也找不到保留数据序列的方法。

我在下面有一个小程序，它显示了我的意思。

如果数据的顺序/顺序很重要，是否可以不使用 CoAP？如果可以，我做错了什么？

上面的节点程序每次运行都会输出不同的顺序。

我正在测试用于解析和生成 CBOR 的库 libcbor-0.5.0，https: //libcbor.readthedocs.io/en/v0.5.0/index.html 。除 cjson2cbor.c 外，所有示例都正常运行。它需要 cJSON.h，所以我将https://github.com/DaveGamble/cJSON添加到我的项目中。

源代码：

...

如果我编译 cc cjson2cbor.c -lcbor -o cjson2cbor

它返回此错误：

我正在使用 nlohmann::json 库在 C++ 中序列化 JSON 对象，我的用例涉及读取 c# 中的 cbor 字节字符串输出。我注意到，当使用 nlohmann::json 库将 json 对象转储到 C++ 中的字符串时，json 字符串值（即 case value_t::string）被转义（调用了 escape_string），没有这样的调用当 json 值是 CBOR 方法中的字符串值时生成。

我正在阅读 CBOR CRF 7049，似乎在序列化为 CBOR 时不需要转义字符串。nlohmann::json 库中的行为是一致的：字符串在序列化时不转义，反序列化时也不例外。但似乎 Newtonsoft.Json（C# 库）期望这一点。这是一个有效的期望吗？或者我在这个过程中做错了什么？

C++ 方面：

C# 方面。cbor_bytes 是 cbor 字节字符串（C++ 输出向量）

到那时，这样的输出字符串格式错误：

并且显然不能被解析：

鉴于文字b'a16568656C6c6f65776f726c64'我希望它被读取，例如第一个数字是'0xa1'，第二个是'0x65'，等等......

这是一个 cbor 编码，{"hello": "world"}但以下程序不会产生预期的输出：

print 1.
现在它解码为好像 'a' 是文字的第一个字符。

在讨论下一代科学数据格式时，需要某种类似 JSON 的数据结构（已确定字段的逻辑分组。此外，最好利用现有编码而不是使用自定义二进制结构。对于序列化格式有很多选择。感谢那些对这些编码有经验的人提供的任何指导或见解。

要求：在我们的格式中，数据需要打包成记录，通常不大于 4096 字节。每条记录必须是独立可用的。数据必须在未来几十年内可读。数据归档和交换是通过存储和传输一系列记录来完成的。数据损坏必须只影响损坏的记录，使文件/流/对象中的所有其他记录可读。

优先事项（大致按顺序）是：

• 稳定性，长期存档使用
• 性能，主要是阅读
• 存储不透明斑点的能力
• 尺寸
• 简单
• 广泛的软件（又名库）支持
• 流能力，传输和可读作为记录生成（如果可能的话）

我们已经开始研究 Protobuf（协议缓冲区 RFC）、CBOR（RFC）和一些MessagePack。

任何有经验的人提供的任何信息都将帮助我们确定最合适的方案，或者更重要的是，避免陷阱和死胡同，我们将不胜感激。

提前致谢！

我正在尝试使用 cbor2 序列化和反序列化对象，但即使在遵循文档之后我也无法正确执行此操作。假设我有以下两个类：

谁能告诉我如何为对象做这件事a？

谢谢

我从服务器获取数据 - 是一个 CBOR 编码的 byte[] 数组，为了解码这个我正在使用cbor-java实现。

如果您对此有一些经验，能否解释一下我如何获取数组的解码内容，而不是DataItem对象。

请帮助提出Flatbuffers和CBOR协议的一些优点和缺点。这两种二进制格式在他们的网站上都声称很好，但我无法在两者之间做出一些很好的区别。

平面缓冲区：

优势：

1. FlatBuffer、Cap'n proto 和其他类似解决方案中的严格输入被视为性能的主要关键点，因为不需要额外的编码/解码。
2. 数据模型允许使用紧凑的数据结构和快速访问的类型对象的简单偏移
3. FlatBuffers 不需要对辅助表示进行解析/解包步骤，然后您就可以访问通常与每个对象内存分配相结合的数据。

坏处：

1. 新的，不像 CBOR 那样标准化。

CBOR

优势：

1. 可以完全在流中创建和处理，无需额外内存
2. 不必预先定义任何模式，因为我们的数据是动态的和多变的
3. 它是来自 IETF 的开放国际标准，使其成为比专有标准更好的选择。
4. 它专为低内存、非转换、基于流的处理而设计，同时还为其他数据类型提供扩展

坏处：

1. CBOR 说它遵循 JSON 模型（所以不是严格类型的对象）
2. 它以相同类型的对象（字符串、整数、映射等）开始。

PS：
感觉在 CBOR 中管理类型与 flatbuffers 相比性能成本很高，但由于 CBOR 是标准化协议，如果这种差异不是很大，我倾向于更喜欢它。请让我知道你们都推荐哪两个以及为什么。

我正在寻找一种用于查询 CBOR 的语言，例如JsonPath或jq，但用于 CBOR 二进制格式。我不想从 CBOR 转换为 JSON，因为 JSON 中不存在某些 CBOR 类型，并且存在性能问题。