1.1. 目标

CBOR 的目标大致按重要性递减顺序 如下：¶

1. 该表示必须能够无歧义地编码大多数 互联网标准中使用的 常见数据格式。¶

   • 它必须使用二进制编码表示一组合理的基本 数据类型和 结构。这里的“合理”很大程度上 受 JSON 的能力影响，主要增加了 二进制字节串。所支持的结构仅限于 数组和树；不支持循环和格状图。¶
   • 并不要求所有数据 格式都被唯一 编码；也就是说，数字“7”可以 用多种不同方式编码，这是可以接受的。¶

2. 编码器或解码器的代码必须能够足够紧凑， 以支持内存、处理器能力 和指令集都非常受限的系统。¶

   • 编码器和解码器需要能够用非常 少量代码实现 （例如，在 [RFC7228] 中定义的第 1 类受限节点中）。¶
   • 该格式应使用现代机器的 数据表示 （例如，不要求二进制到十进制的转换）。¶

3. 数据必须能够在没有模式描述的情况下被解码。¶

   • 与 JSON 类似，已编码数据应当是 自描述的，以便 可以编写通用解码器。¶

4. 序列化必须相当紧凑，但对于编码器和解码器而言， 数据紧凑性次于代码紧凑性。¶

   • 这里的“合理”以上限 大小为 JSON， 并受实现复杂性的限制，后者限制了 为实现这种紧凑性所能投入的工作量。 使用通用压缩方案或大量 位操作会违反复杂性目标。¶

5. 该格式必须既适用于受限节点，也适用于 高容量应用。¶

   • 这意味着它在编码和解码时 对 CPU 使用必须相当节省。 这既与受限 节点相关，也与数据量非常大的 应用中的潜在使用相关。¶

6. 该格式必须支持所有 JSON 数据类型，以便在 JSON 之间 相互转换。¶

   • 只要所表示的数据处于 JSON 的能力范围内， 它就必须支持合理程度的 转换。必须可以为所有 数据类型定义一种朝向 JSON 的单向映射。¶

7. 该格式必须是可扩展的，并且扩展后的数据必须能够被 早期解码器解码。¶

   • 该格式被设计为可使用数十年。¶
   • 该格式必须支持一种 允许回退的可扩展性形式， 使得不理解某个扩展的解码器 仍能解码该消息。¶
   • 该格式必须能够在未来由后续 IETF 标准进行扩展。¶

1.2. 术语

本文档中的关键词“MUST”、“MUST NOT”、 “REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、 “RECOMMENDED”、“NOT RECOMMENDED”、 “MAY”和“OPTIONAL”应按照 BCP 14 [RFC2119] [RFC8174] 中所述进行解释，但仅当它们像这里所示以全大写形式出现时才如此。¶

术语“byte”按其现在的惯常含义使用，作为 “octet”的同义词。所有多字节值都按网络字节序编码 （即最高有效字节在前，也称为“big-endian”）。¶

本规范使用以下术语：¶

数据项:

一片单独的 CBOR 数据。数据项的结构可以 包含零个、一个或多个嵌套数据项。该术语既用于 表示格式中的数据项，也用于 可由解码器从中导出的抽象概念；前者可以 通过使用术语“已编码数据项”来专门指称。¶

解码器:

解码良构的已编码 CBOR 数据项并将其提供给 应用的过程。形式上说，解码器包含一个解析器，用于 按 CBOR 的语法规则拆分输入，也包含一个 语义处理器，用于将数据准备成适合 应用的形式。¶

编码器:

从应用信息生成 CBOR 数据 项的（良构）表示格式的过程。¶

数据流:

零个或多个数据项的序列，未进一步组装到 更大的包含数据项中（参见 [RFC8742] 了解一个应用）。 构成数据流的独立数据项 有时也称为“顶层数据 项”。¶

良构:

遵循 CBOR 语法结构的数据项。 良构数据项使用 CBOR 中定义的、由其值 所隐含的初始字节以及字节串 和/或数据项，并且不包含后续的无关数据。 按定义，CBOR 解码器只从良构数据项返回内容。¶

有效:

既良构又遵循适用于 CBOR 数据项的 语义限制的数据项（第 5.3 节）。¶

预期:

除了其普通英语含义外，术语“expected”用于 描述应用对其输入数据提出的、超出 CBOR 有效性之外的 要求。良构（总体上可处理）、有效（由 有效性检查通用解码器检查）和预期（由 应用检查）构成可接受性层级。¶

流解码器:

解码数据流并在序列中的每个数据 项被接收时将其提供给应用的 过程。¶

诸如 Infinity、NaN （非数）、负零和次正规数等浮点值的术语和概念 在 [IEEE754] 中定义。¶

在解释位算术或数据类型时，本文档使用 C 编程语言 [C] 中熟悉的记法，例外是 “..”表示包含所给两端点的范围，而上标 记法表示求幂。例如，2 的 64 次方 记作：2⁶⁴。 在本规范的纯文本版本中，上标记法 不可用，因此用替代记法呈现。 该记法并未针对本 RFC 优化；遗憾的是，它 与 C 的异或存在歧义（异或只在附录中使用， 而附录又不使用求幂），因此纯文本版本的读者 需要谨慎理解。¶

示例和伪代码 假定有符号整数使用二进制补码表示，并且 有符号整数的右移会执行符号扩展；这些 假设也在 2020 版 C++ 的第 6.8.1 节（basic.fundamental） 和第 7.6.7 节（expr.shift）中规定（目前可作为 最终草案获得，[Cplusplus20]）。¶

类似于十六进制数的“0x”记法， 二进制记法中的数字以 “0b”为前缀。下划线可以仅为 可读性添加到数字中，因此 0b00100001（0x21）可以写作 0b001_00001，以强调对字节中位的期望解释； 在这种情况下，它被拆分为三位和五位。已编码 CBOR 数据 项有时以“0x”或“0b”记法给出；这些值 首先按 C 中的方式解释为数字，然后按 网络字节序解释为字节串，包括该记法中 表示的任何前导零字节。¶

词语可以用斜体表示强调；在本规范的纯文本 形式中，这通过在词语两侧加下划线字符来表示。 逐字文本（例如，来自 编程语言的名称）可以设置为 monospace 字体；在纯 文本中，这通过用双引号包围 文本来近似表示，但这种方式有些歧义（双引号也保留其通常含义）。¶

2.1. 扩展通用数据 模型

本文档已经通过注册 一些简单值和标签号来扩展此基本通用数据模型，例如：¶

• false、true、null 和 undefined （由 20..23 标识的简单值，第 3.3 节）¶
• 范围和精度 大于上述范围的整数和浮点值 （标签号 2 到 5，第 3.4 节）¶
• 应用数据类型，例如由 RFC 3339 定义的 时间点或日期/时间字符串（标签号 1 和 0，第 3.4 节）¶

扩展通用数据模型的其他元素可以（并且已经） 通过为 CBOR 创建的 IANA 注册表来定义。即使 通用编码器或解码器不知道这样的扩展， 使用该扩展的数据项也可以通过 在应用接口处将它们表示在基本 通用数据模型内，即作为通用简单值或 通用标签，在应用之间传递。¶

换言之，基本通用数据模型按 本文档定义是稳定的，而扩展通用数据模型通过 注册新的简单值或标签号而扩展，但永不缩小。¶

虽然强烈期望通用编码器和解码器 能够以适合其编程环境的形式表示 false、true 和 null （undefined 被有意 省略），但由标签创建的数据模型扩展的实现确实是 可选的，并且属于实现质量问题。¶

2.2. 特定数据模型

基于 CBOR 的协议的特定数据模型通常会取 扩展通用数据模型的 一个子集，并为该子集及其组成部分中的 数据项分配应用语义。 在记录此类特定数据模型并指定数据项的类型时， 最好使用其 通用数据模型名称（“负整数”、“数组”）来识别类型，而不是 引用其 CBOR 表示的方面（“主类型 1”、 “主类型 4”）。¶

特定数据模型还可以指定值等价性（包括 不同类型的值），用于映射键和编码器自由度。例如， 在通用数据模型中，有效映射 MAY 同时具有 0 和 0.0 作为键，并且编码器 MUST NOT 将 0.0 编码为整数 （主类型 0，第 3.1 节）。然而，如果特定数据 模型 声明整数值的浮点表示和整数表示 是等价的，则在单个 映射中同时使用映射键 0 和 0.0 会被认为 是重复的，即使它们被编码为不同主类型，因此是无效的；并且编码器可以 将整数值 浮点数编码为整数，反之亦然，也许是为了节省已编码字节。¶

3.1. 主类型

下面列出主类型以及与该类型关联的附加信息和 其他字节。¶

主类型 0:

范围为 0..2⁶⁴-1（含两端）的无符号整数。已 编码项的值就是实参本身。例如， 整数 10 表示为一个字节 0b000_01010（主类型 0， 附加信息 10）。整数 500 会是 0b000_11001 （主类型 0，附加信息 25），后跟两个字节 0x01f4，即十进制的 500。¶

主类型 1:

范围为 -2⁶⁴..-1（含两端）的负整数。该项的值 是 -1 减去实参。例如，整数 -500 会是 0b001_11001（主类型 1，附加信息 25） 后跟两个字节 0x01f3，即十进制的 499。¶

主类型 2:

字节串。字符串中的字节数等于 实参。例如，一个长度为 5 的字节 串将具有初始字节 0b010_00101 （主类型 2，附加信息 5 表示长度），后跟 5 个二进制内容字节。长度为 500 的字节串 将具有 3 个初始字节 0b010_11001（主类型 2，附加 信息 25 表示两字节长度），后跟两个 字节 0x01f4 表示长度 500，再后跟 500 个二进制 内容字节。¶

主类型 3:

文本字符串（第 2 节），编码为 UTF-8 [RFC3629]。字符串中的字节数等于 实参。包含无效 UTF-8 序列的字符串是 良构但无效的（第 1.2 节）。此类型用于 需要解释或显示人类可读文本的系统，并且 允许区分非结构化字节和具有指定字符集 （Unicode）及编码（UTF-8）的文本。与 JSON 等格式 不同，此类型中的 Unicode 字符从不 转义。因此，换行字符（U+000A）在 字符串中始终表示为字节 0x0a，而绝不表示为 字节 0x5c6e（字符“\”和“n”），也不表示为 0x5c7530303061（字符“\”、 “u”、“0”、“0”、“0”和“a”）。¶

主类型 4:

数据项数组。在其他格式中，数组也称为列表、序列或 元组（不过“CBOR sequence”是稍有不同的东西，参见 [RFC8742]）。 实参是数组中数据项的数量。数组中的项 不需要全都属于同一类型。例如，一个包含 任意类型 10 个项的数组将具有初始字节 0b100_01010（主类型 4，附加信息 10 表示 长度），后跟其余 10 个项。¶

主类型 5:

成对数据项的映射。映射也称为表、 字典、散列或对象（在 JSON 中）。映射由 成对的数据项组成，每对由一个键和紧随其后的 一个值构成。实参是映射中数据项对的数量。 例如，包含 9 对的映射将具有初始字节 0b101_01001（主类型 5，附加信息 9 表示 对数），后跟其余 18 个项。第一项 是第一个键，第二项是第一个值，第三项 是第二个键，依此类推。因为映射中的项成对出现， 它们的总数始终为偶数：包含奇数 个项的映射（最后一个键数据项之后没有值数据）不是良构的。 具有重复键的映射可能是 良构的，但它无效，因此会导致不确定 解码；另见 第 5.6 节。¶

主类型 6:

带标签的数据项（“标签”），其标签号是范围 0..2⁶⁴-1（含两端）的整数，即实参， 其所包含的数据项（标签内容）是紧随 头部之后的单个已编码数据项。 参见 第 3.4 节。¶

主类型 7:

浮点数和简单值，以及“break” 停止码。参见 第 3.3 节。¶

这八个主类型形成一个简单表，显示数据项初始字节 256 个可能值中的哪些被使用 （表 7）。¶

在主类型 6 和 7 中，许多可能值保留供 未来规范使用。有关这些 值的更多信息，请参见 第 9 节。¶

表 1 总结了 CBOR 定义的主 类型， 暂时忽略 第 3.2 节。此表中的数字 N 表示实参。¶

3.2. 某些主类型的 不定长度

四种 CBOR 项（数组、映射、字节串和文本字符串）可以 使用附加信息值 31 以不定长度进行编码。 如果某个项的编码需要在数组或映射内部项数， 或字符串总长度尚未知之前开始， 这会很有用。（在该数据项内部，能够在 全部内容已知之前开始发送数据 项的能力通常称为“流式传输”。）¶

不定长数组和映射的处理方式不同于 不定长字符串（字节串和文本字符串）。¶

83        -- 长度为 3 的数组
   01     -- 1
   82     -- 长度为 2 的数组
      02  -- 2
      03  -- 3
   82     -- 长度为 2 的数组
      04  -- 4
      05  -- 5

0x9f018202039f0405ffff
9F        -- 开始不定长数组
   01     -- 1
   82     -- 长度为 2 的数组
      02  -- 2
      03  -- 3
   9F     -- 开始不定长数组
      04  -- 4
      05  -- 5
      FF  -- “break”（内部数组）
   FF     -- “break”（外部数组）

0x9f01820203820405ff
9F        -- 开始不定长数组
   01     -- 1
   82     -- 长度为 2 的数组
      02  -- 2
      03  -- 3
   82     -- 长度为 2 的数组
      04  -- 4
      05  -- 5
   FF     -- “break”

0x83018202039f0405ff
83        -- 长度为 3 的数组
   01     -- 1
   82     -- 长度为 2 的数组
      02  -- 2
      03  -- 3
   9F     -- 开始不定长数组
      04  -- 4
      05  -- 5
      FF  -- “break”

0x83019f0203ff820405
83        -- 长度为 3 的数组
   01     -- 1
   9F     -- 开始不定长数组
      02  -- 2
      03  -- 3
      FF  -- “break”
   82     -- 长度为 2 的数组
      04  -- 4
      05  -- 5

0xbf6346756ef563416d7421ff
BF           -- 开始不定长映射
   63        -- 第一个键，UTF-8 字符串长度 3
      46756e --   “Fun”
   F5        -- 第一个值，true
   63        -- 第二个键，UTF-8 字符串长度 3
      416d74 --   “Amt”
   21        -- 第二个值，-2
   FF        -- “break”

0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111
5F              -- 开始不定长字节串
   44           -- 长度为 4 的字节串
      aabbccdd  -- 字节内容
   43           -- 长度为 3 的字节串
      eeff99    -- 字节内容
   FF           -- “break”

3.3. 浮点数 和无内容的值

主类型 7 用于两类数据：浮点数和 不需要任何内容的“简单值”。初始字节中 5 位 附加信息的每个值都有其各自的 含义，如 表 3 所定义。与整数的主类型一样， 此主类型的项不携带内容数据；所有 信息都在初始字节（头部）中。¶

与所有其他主类型一样，5 位值 24 表示 单字节扩展：它后面跟随一个附加字节，用来 表示简单值。（为尽量减少混淆，只使用值 32 到 255。）这保持了初始字节的结构： 与其他主类型一样，其长度始终取决于 第一个字节中的附加信息。表 4 列出 已分配和可用于简单值的数值。¶

编码器 MUST NOT 发出以 0xf8（主类型 7，附加信息 24）开头，并继续 以小于 0x20（十进制 32）的字节结尾的双字节序列。这样的序列不是 良构的。（这意味着编码器不能将 false、true、 null 或 undefined 编码为双字节序列，并且这些值只有单字节 变体是良构的；更一般地说，每个 简单值只有一个表示变体。）¶

5 位值 25、26 和 27 分别用于 16 位、32 位和 64 位 IEEE 754 二进制浮点值 [IEEE754]。这些浮点值 被编码在适当大小的附加字节中。（有关 16 位浮点数的一些信息，参见 附录 D。）¶

3.4. 项的标记

在 CBOR 中，数据项可以被标签包围，以赋予其一些 附加语义，这些语义由标签号唯一标识。 标签是主类型 6，其实参（第 3 节）指示 标签 号，并且它包含一个单独的被包围数据项，即 标签内容。 （如果标签要求其内容具有进一步结构，则该结构由 被包围的数据项提供。） 我们使用术语标签来指由标签号和标签内容二者 组成的整个数据项：标签内容就是 被标记的数据项。¶

例如，假设长度为 12 的字节串被标记为 标签号 2，以指示它是无符号大数（第 3.4.3 节）。 已编码数据项将以字节 0b110_00010（主类型 6，附加信息 2 表示标签号）开始，后跟 已编码的标签内容：0b010_01100（主类型 2，附加信息 12 表示长度），再后跟该大数的 12 个字节。¶

在扩展通用数据模型中，标签号的 定义描述了通过该标签号 传达的附加语义。 这些语义可以包括某些带标签数据 项与其他数据项的等价性，包括某些可在 基本通用数据模型中表示的数据项。例如，0xc24101， 一个其标签内容为单字节 0x01 的字节串的大数，等价于整数 1，而后者也可以编码 为 0x01、0x1801 或 0x190001。 标签定义可以指定一种推荐给 通用 编码器的首选序列化（第 4.1 节）；这可能更偏好基本通用数据模型表示， 而不是使用标签的表示。¶

标签定义通常定义哪些嵌套数据项 对此类标签是有效的。标签定义可以将其内容限制为 非常具体的语法结构，如本文档中定义的标签那样； 或者也可以更语义化地定义其内容。后者的一个 示例是标签 40 和 1040 如何接受多种 表示数组的方式 [RFC8746]。¶

作为惯例，许多标签不接受 null 或 undefined 值作为标签内容；相反，期望是可以用 null 或 undefined 值代替整个标签；第 3.4.2 节 提供了关于一个特定标签在应用协议中以及映射 到平台类型时处理这一惯例的进一步考虑。¶

解码器不需要理解每个标签号的标签，并且在一些应用中， 标签可能价值不大，在这些应用中，创建特定 CBOR 数据项的实现 和解码该流的实现 都知道数据流中每一项的语义含义。本规范中标签的主要 目的，是定义日期等通用数据类型。次要目的 是在预见到 CBOR 数据项需要被转换为 另一种格式时提供转换提示，这需要关于项内容的提示。 理解标签语义对解码器而言是 可选的；它可以简单地将标签号和 标签内容一并呈现给应用，而不解释标签的附加 语义。¶

标签将语义应用于它所包围的数据项。 标签可以嵌套：如果标签 A 包围标签 B，而标签 B 包围数据项 C， 则标签 A 应用于将标签 B 应用于数据项 C 后的结果。¶

IANA 维护一个标签号注册表，如 第 9.2 节 所述。 表 5 给出了 [RFC7049] 中定义、并在本节其余部分 给出定义的标签号列表。 （标签号 35 也在 [RFC7049] 中定义；关于该 标签号的讨论见 第 3.4.5.3 节。） 请注意，自 [RFC7049] 发布以来，还定义了许多其他标签号； 完整列表请参见 第 9.2 节 中描述的注册表。¶

从概念上说，标签是在通用数据模型中解释的，而不是在 （反）序列化时解释的。少数标签（目前为标签 号 25 和标签号 29 [IANA.cbor-tags]）已注册为具有可能 需要在（反）序列化时处理的语义：解码器需要 知道且编码器需要控制数据项被编码进 CBOR 数据项的确切 顺序。这意味着这些标签不能在任意通用 CBOR 编码器/解码器之上实现（因为该编码器/解码器可能不会在数据模型层级反映映射中 条目的序列化顺序，反之亦然）；因此它们的 实现通常需要集成到 通用编码器/解码器中。NOT RECOMMENDED 定义具有此 属性的新标签。¶

IANA 分配了标签号 65535、4294967295 和 18446744073709551615（16 位、32 位和 64 位中的二进制全 1）。 这些可以作为实现者的便利手段， 当他们希望用单个整数数据结构来指示 是否存在特定标签或不存在标签时使用。 该分配在 [CBOR-TAGS] 第 10 节 中描述。 这些标签并不打算出现在实际的 CBOR 数据项中； 实现 MAY 将此类出现标记为错误。¶

协议可以通过使用标签号 0 和 1 来用表示时间点的数据 项扩展通用数据模型（第 2 节），通过使用标签号 2 和 3 来表示 任意大小的整数，并通过使用标签 号 4 和 5 来表示任意大小和精度的 浮点值。¶

C2                        -- 标签 2
   49                     -- 长度为 9 的字节串
      010000000000000000  -- 字节内容

C4             -- 标签 4
   82          -- 长度为 2 的数组
      21       -- -2
      19 6ab3  -- 27315

C5             -- 标签 5
   82          -- 长度为 2 的数组
      20       -- -1
      03       -- 3

4.1. 首选 序列化

对于数据模型层级的一些值，CBOR 提供了多种 序列化。 对许多应用来说，期望编码器始终选择 首选序列化（首选编码）；然而，本规范并不 将强制执行这种偏好的负担加在编码器或解码器身上。¶

一些受限解码器解码 非首选序列化的能力可能有限：例如，如果某个应用中只预期 小于 1_000_000_000（十亿）的整数， 解码器可以省略解码整数中 64 位 实参所需的代码。始终使用首选 序列化的编码器（“首选编码器”）可以与此解码器针对该应用中可能出现的 数字进行互操作。一般 来说，首选编码器比那种例如始终使用 64 位 整数的编码器更具有普遍互操作性（并且 也更少浪费）。¶

类似地，受限编码器所支持的 表示变体种类可能有限，以至于它不会 发出首选序列化（“变体编码器”）。例如，受限编码器可以 被设计为 对其编码的整数始终使用 32 位变体，即使 有更短的表示可用（假定应用并不需要只能 用 64 位变体表示的整数）。 因此，不依赖于 只接收首选序列化的解码器（“容忍变体的解码器”）可以说 具有更 普遍的互操作性（尽管它很可能仍然针对 接收首选序列化的情况进行优化）。 CBOR 解码器的完整实现按定义 容忍变体；只有在受限 CBOR 解码器实现遇到变体编码器时，这一区分才相关。¶

首选序列化始终使用表示实参的最短形式 （第 3 节）；它还使用能够保留被编码值的最短 浮点编码。¶

浮点值的首选序列化，是能够保留其值的最短 浮点编码，例如数字 5.5 为 0xf94580， 数字 5555.5 为 0xfa45ad9c00。对于 NaN 值，如果将较短有效数向右用零填充能够重构原始 NaN 值， 则首选较短编码 （对于许多应用，单一 NaN 编码 0xf97e00 即已足够）。¶

只要在项的序列化开始时长度已知， 就首选定长编码。¶

4.2. 确定性编码的 CBOR

一些协议可能希望编码器只发出某种特定 确定性格式的 CBOR；这些协议也可能让解码器检查 其输入是否处于该确定性格式中。这些协议 可以自由定义它们所说的“确定性格式”是什么， 以及期望编码器和解码器 做什么。本节定义了一组可 作为这种确定性格式基础的限制。¶

5.1. 流式 应用中的 CBOR

在流式应用中，数据流可以由 一系列首尾相接串接的 CBOR 数据项组成。在这样的 环境中，如果在前一个数据项结束之后发现数据， 解码器会立即开始解码新的数据项。¶

构成数据项的字节并不一定全部立即 可供解码器使用；一些解码器会缓冲额外数据， 直到可以向应用呈现完整数据项。其他 解码器可以向应用呈现顶层数据项的部分信息， 例如已经能够被解码的嵌套数据项， 甚至是尚未完全到达的字节串的部分内容。 这样的应用也 MUST 具有匹配的流式安全 机制，其中 所需保护可用于呈现给 应用的增量数据。¶

请注意，一些应用和协议不会想要使用 不定长编码。使用不定长编码允许 编码器无需整理全部数据以便计数，但它 要求解码器在等待项结束时分配越来越多的内存。 这对某些应用可能没问题， 但对其他应用则不然。¶

5.2. 通用编码器和 解码器

通用 CBOR 解码器可以解码所有良构的已编码 CBOR 数据项， 并将这些数据项呈现给应用。参见 附录 C。 （诊断记法，第 8 节，可用于 向人呈现良构的 CBOR 值。）¶

通用 CBOR 编码器提供一个应用接口，允许 应用指定任何良构值以编码为 CBOR 数据项，包括编码器未知的简单值和标签。¶

虽然 CBOR 试图最小化这些情况，但并非所有良构的 CBOR 数据都是有效的：例如，已编码文本字符串 0x62c0ae 不包含有效 UTF-8（因为 [RFC3629] 要求始终使用最短 形式），因此不是有效的 CBOR 项。 此外，特定标签可能 设置可能被违反的语义约束，例如，大数标签 包围另一个标签，或标签号 0 的实例包含字节 串，或包含内容不匹配 [RFC3339] 的 date-time 产生式的文本字符串。 不要求通用编码器和解码器为其应用接口作出不自然的 选择，以便处理 无效数据。通用编码器和解码器应转发 简单值和标签，即使其特定码点在编写编码器/解码器时 尚未注册 （第 5.4 节）。¶

5.3. 项的有效性

良构但无效的 CBOR 数据项（第 1.2 节）会在 解释其中编码的数据在 CBOR 数据模型中的含义时造成问题。基于 CBOR 的协议可以分若干层指定，其中 较低层不处理其转发的某些 CBOR 数据的语义。 这些层无法注意到它们不处理的数据中的任何有效性错误， 并且 MUST 按原样转发这些数据。第一个 处理无效 CBOR 项语义的层 MUST 选择以下两种 方案之一：¶

1. 用错误标记替换有问题的项，并继续处理 下一项，或¶
2. 发出错误并完全停止处理。¶

基于 CBOR 的协议 MUST 指定其解码器 对可能遇到的每一种无效项采用这些选项中的哪一种。¶

此类问题可能发生在 CBOR 的基本有效性层级， 或发生在标签的上下文中（标签有效性）。¶

5.4. 有效性与演进

带有效性检查的解码器会付出努力来可靠地 检测具有有效性错误的数据项。例如，这样的 解码器需要有一个 API，用于对包含前一小节所列任一有效性 错误的 CBOR 数据项报告错误（且不 返回数据）。¶

“Concise Binary Object Representation (CBOR) Tags”注册表（第 9.2 节）中定义的标签集合， 以及“Concise Binary Object Representation (CBOR) Simple Values” 注册表（第 9.1 节）中定义的简单值集合， 可以在任何时候增长，超出通用解码器所理解的集合。当 有效性检查解码器遇到 其不识别的此类情况时，可以采取以下两种做法之一：¶

• 它可以报告错误（并且不返回数据）。 请注意，将此情况视为错误可能导致僵化，因此 不鼓励这样做。此错误本身 并不是有效性错误。这类错误更可能 由在已知情况下会执行有效性检查的解码器 提出。¶
• 它可以将未知项（类型、值，以及对于 标签而言， 已解码的带标签数据项）发出给调用解码器的应用， 然后向应用 指示解码器不识别该标签 号或简单值。¶

后一种做法同样适用于不 支持有效性检查的解码器，它提供了对 新注册标签和简单值的前向兼容性，而不要求 编码器与调用应用同时更新。（为此， 解码器的 API 需要具备标记未知 项的能力，使调用应用能够以适合程序的方式 处理它们。）¶

由于有效性检查所需的某些处理可能具有 可观成本（尤其是映射的重复检测）， 支持有效性检查并不是对所有 CBOR 解码器提出的要求。¶

一些编码器会依赖其应用以 使编码器产生有效 CBOR 的方式提供输入数据。通用 编码器也可能希望提供一种有效性检查模式，在其中它 可靠地将其输出限制为有效 CBOR，而不取决于 其应用是否确实提供符合 API 的数据。¶

5.5. 数

基于 CBOR 的协议应考虑到不同语言 环境对可表示数字的范围和精度 有不同限制。例如，基本 JavaScript 数字 系统将所有数字视为浮点值，这可能导致 解码超过 53 个有效位的整数时静默 丢失精度。 另一个例子是，由于 CBOR 将其整数 表示中的符号位保留在主类型中，因此，对于某一长度的有符号 数字，它比同长度的典型平台有符号整数表示 多一位（例如，1+8 字节 整数为 -2⁶⁴..2⁶⁴-1，而 8 字节 int64_t 为 -2⁶³..2⁶³-1）。 使用数字的协议应定义其 对解码器和接收应用处理中非平凡数字的 期望。¶

包含浮点数的基于 CBOR 的协议可以 限制三种格式（半精度、单精度 和双精度）中的哪些需要被支持。对于仅整数 应用，协议可能希望完全排除 浮点值的使用。¶

为紧凑性设计的基于 CBOR 的协议，可能希望排除 对应用来说长于必要长度的特定整数编码， 例如为了省去实现 64 位整数的需要。 预期编码器会使用能够表示给定值的最紧凑 整数表示。然而，不要求确定性编码的 紧凑应用应接受使用长于必要长度 编码的值（例如，将“0”编码为 0b000_11001 后跟两个字节 0x00），只要该应用能够解码给定 大小的整数。 类似考虑也适用于浮点值；建议同时解码 首选序列化和长于必要长度的序列化。¶

面向受限应用的基于 CBOR 的协议，如果在将特定数字表示为整数 与表示为十进制小数或大浮点数之间提供 选择（例如，当指数较小且非负时），可能会表达一种实现质量 期望，即直接使用整数表示。¶

5.6. 为映射指定 键

编码和解码应用需要就映射中将使用哪些类型的 键达成一致。在需要与基于 JSON 的应用 互操作的应用中，通过将键限制为仅文本字符串，可以简化转换； 否则，就必须指定从其他 CBOR 类型到文本字符串的 映射，而这 经常导致实现错误。在键本质上是 数值，并且键的数值排序对应用很重要的应用中， 直接使用数字作为键是有用的。¶

如果要使用多种类型的键，应考虑 这些类型如何在将要使用的特定 编程环境中表示。例如，在 JavaScript Maps [ECMA262] 中，整数键 1 不能与浮点键 1.0 区分。这意味着，如果使用整数 键，则协议需要避免在同一映射中使用 值恰好为整数的浮点键。¶

在解码嵌套于 CBOR 数据项中的数据项时立即交付这些项的解码器 （“流式解码器”）通常不保留 用于确定映射中键唯一性所必需的状态。 类似地，能够在包含的数据项尚未完全可用之前 开始编码数据项的编码器（“流式编码器”）可能 希望通过依赖其数据 源维护唯一性来显著降低其开销。¶

基于 CBOR 的协议 MUST 定义接收应用在 映射中看到多个相同键时 要做什么。协议中的结果规则 MUST 尊重 CBOR 数据模型：它不能规定对具有 相同键的条目进行特定处理，除非它可以规定 映射中具有相同键表示该映射格式错误，且解码器 必须以错误停止。 在处理表现出重复键条目的映射时，通用 解码器可能会执行以下操作之一：¶

• 不接受具有重复键的映射（即，对映射强制 有效性， 另见 第 5.4 节）。这些通用解码器 具有普遍用途。应用可能仍需要根据应用规则执行自己的 重复检查（例如，如果应用在特定映射的键位置将 整数和浮点值视为相等）。¶
• 将所有映射条目传递给应用，包括具有 重复键的条目。这要求应用处理（检查） 重复键，即使应用规则与通用数据模型规则相同 也是如此。¶
• 丢失一些具有重复键的条目，例如，只交付 具有相同键的条目中的最后 （或第一个）条目。使用 这样的通用解码器时，应用在不同运行中、以及使用不同通用解码器时，可能会针对某个 特定键得到不同结果，返回哪个值取决于通用解码器 实现和映射中键的实际顺序。特别是， 应用无法自行验证键唯一性， 因为它们不一定能看到所有条目；如果它们需要验证键 唯一性，就可能无法使用这样的通用解码器。 这些通用解码器只能用于数据源和传输始终 提供有效映射的情况；如果数据源和传输可能受到攻击， 这就不可能。¶

通用解码器需要记录它们实现了这三种方法中的哪一种。¶

CBOR 的映射数据模型不允许给映射表示中 键/值对的顺序赋予语义。因此， 基于 CBOR 的协议 MUST NOT 指定改变映射中键/值对的 顺序会改变语义，除非是指定某些 顺序被禁止，例如它们不满足确定性 编码（第 4.2 节） 的要求。 （映射排序的任何次要影响，例如对时序、缓存使用 和其他潜在侧信道的影响，并不被视为 语义的一部分，但其本身可能足以成为协议要求 确定性编码格式的理由。）¶

受限设备上的应用应考虑使用小 整数作为键，如果它们的映射具有少量经常 使用的键；例如，一组 24 个或更少的 键可以作为无符号整数编码在单个字节中，如果还使用负 整数，则最多可达 48 个。不太频繁 出现的键随后可以使用更长编码的整数。¶

5.7. 未定义值

在一些基于 CBOR 的协议中， undefined 的简单值（第 3.3 节）可能被编码器用作存在编码问题的数据项的替代物， 以允许其余包含数据项 在无害的情况下继续编码。¶

6.1. 从 CBOR 转换为 JSON

CBOR 中的大多数类型在 JSON 中都有直接对应物。然而，有些 没有，而实现 CBOR 到 JSON 转换器的人必须 考虑在这些情况下该怎么做。以下非规范性建议 通过将它们转换为单一替代值来处理这些情况，例如 JSON null。¶

• 整数（主类型 0 或 1）变为 JSON 数字。¶
• 未嵌入于 指定建议编码的标签中的字节串（主类型 2），会以无 填充的 base64url 编码，并变为 JSON 字符串。¶
• UTF-8 字符串（主类型 3）变为 JSON 字符串。 请注意，JSON 要求转义某些字符（[RFC8259]， 第 7 节）： 引号（U+0022）、反斜杠（U+005C）和“C0 控制字符”（U+0000 到 U+001F）。所有其他字符 都不加改变地复制到 JSON UTF-8 字符串中。¶
• 数组（主类型 4）变为 JSON 数组。¶
• 映射（主类型 5）变为 JSON 对象。这只有在 所有键都是 UTF-8 字符串时才可 直接实现。转换器也可以将其他键转换为 UTF-8 字符串 （例如，将整数转换为包含其十进制表示的 字符串）； 然而，这样做会引入键冲突的危险。 另请注意，如果像下面建议的那样忽略 UTF-8 字符串上的标签， 那么如果标签不同但字符串相同， 这将导致键 冲突。¶
• False（主类型 7，附加信息 20）变为 JSON false。¶
• True（主类型 7，附加信息 21）变为 JSON true。¶
• Null（主类型 7，附加信息 22）变为 JSON null。¶
• 浮点值（主类型 7，附加 信息 25 到 27）如果是有限值（也就是说，可以 表示为 JSON 数字），则变为 JSON 数字；如果该值是非有限的（NaN， 或正 Infinity 或负 Infinity），则用 替代值表示。¶
• 任何其他简单值（主类型 7，任何尚未 讨论的附加信息 值）均由替代值表示。¶
• 大数（主类型 6，标签号 2 或 3）通过将 其字节串以无填充 base64url 编码来表示，并变为 JSON 字符串。对于标签号 3（负大数），会在基础编码值前插入 “~”（ASCII 波浪号）。（转换为二进制 blob 而非数字，是为了防止 JSON 解码器可能出现的数值溢出。）¶
• 带有编码提示的字节串（主类型 6，标签 号 21 到 23）按该提示所描述的方式编码，并变为 JSON 字符串。¶
• 对于所有其他标签（主类型 6，任何其他标签 号），标签 内容表示为 JSON 值；标签号会被忽略。¶
• 不定长项在 转换之前会变为定长。¶

CBOR 到 JSON 转换器可能希望遵循 JSON 配置文件 I-JSON [RFC7493]，以最大化互操作性并 增强信心， 使 JSON 输出能够以可预测结果处理。例如， 这会影响可被可靠表示的整数范围， 以及旧版 JSON 实现可能支持的顶层项。¶

6.2. 从 JSON 转换为 CBOR

所有 JSON 值一旦被解码，就会直接映射到一个或多个 CBOR 值。与任何类型的 CBOR 生成一样，必须 就数字表示作出决定。在一种建议的 转换中：¶

• 没有小数部分的 JSON 数字（整数） 表示为整数（主类型 0 和 1，可能是主类型 6， 标签号 2 和 3），选择最短形式；长于 实现定义阈值的整数可以改为表示为 浮点值。默认表示为整数的 范围是 -2⁵³+1..2⁵³-1（充分利用通常用于解码 JSON 的 binary64 表示中 精确整数的范围 [RFC7493]）。 基于 CBOR 的协议或通用转换器实现 可以选择 -2³²..2³²-1 或 -2⁶⁴..2⁶⁴-1（分别 充分使用 CBOR 中通过 uint32_t 或 uint64_t 可用的整数范围），甚至选择 -2³¹..2³¹-1 或 -2⁶³..2⁶³-1（使用二进制补码 有符号整数的常见范围）。 （如果 JSON 是由 JavaScript 实现生成的，则其 精度已经被限制为最多 53 位。）¶
• 带有小数部分的数字表示为 浮点 值，并基于 IEEE 754 binary64 提供的 精度执行十进制到二进制的转换。 JSON 数字的数学值使用 [IEEE754] 第 4.3.1 节中的 roundTiesToEven 过程转换为 binary64。 然后，在以 CBOR 编码时，首选序列化使用能够精确表示该转换结果的最短浮点 表示；例如，1.5 表示为 16 位浮点值（不过 并非所有实现都能高效找到 最小形式）。除了使用默认 binary64 精度之外，也可能存在实现定义的转换 精度限制，这将影响所表示值的精度。 只有当协议中指定时，才应在 CBOR 侧使用十进制表示。¶

CBOR 的设计目标通常是提供比 JSON 更紧凑的编码。 一种可能想到的实现策略是 在单个缓冲区中就地执行 JSON 到 CBOR 编码。该 策略需要仔细考虑许多病态 情况，例如某些字符串在没有转义或转义很少的情况下表示， 且长度超过（或远远超过）255 字节，在 CBOR 中编码为 UTF-8 字符串时可能会扩展。类似地，少数二进制 浮点表示可能会从 JSON 中某些较短的 十进制表示（1.1、1e9）扩展。这可能很难 正确处理，随之产生的任何漏洞都可能被 攻击者利用。¶

7.1. 扩展点

在协议设计中，演进机会通常以 扩展点的形式包含在内。例如，可能有一个 从一开始并未完全分配的码点空间，并且 协议被设计为能够容忍并接纳开始使用比最初分配更多码点的 实现。¶

确定码点空间的大小可能很困难，因为所需范围 可能难以预测。协议设计应尝试使 码点空间足够大，以便它能够在协议预期寿命内 逐渐被填充。¶

CBOR 有三个主要扩展点：¶

“simple”空间（主类型 7 中的值）:

在 24 个高效 （以及 224 个略低效）的值中，只有少数已经 分配。接收未知简单数据 项的实现可能很容易将其按简单项处理，前提是该值的结构 确实简单。 第 9.1 节 中的 IANA 注册表是处理此 码点空间可扩展性的适当方式。¶

“tag”空间（主类型 6 中的值）:

总码点空间 十分充裕；只有极小一部分已经 分配。然而，并非所有这些码点都同样 高效：前 24 个只消耗一个（“1+0”）字节，并且 其中一半已经分配。接下来的 232 个值只 消耗两个（“1+1”）字节，其中近四分之一已经分配。 这些子空间需要一些整理，才能再持续数十年。 接收未知标签号的实现可以选择 只处理所包含的标签内容，或者最好 将该标签作为包裹 标签内容的未知标签号处理。第 9.2 节 中的 IANA 注册表是 处理此码点空间可扩展性的 适当方式。¶

“additional information”空间:

接收到未知 附加信息值的实现无法继续解码， 因此在此空间中分配码点是远超 使用扩展点的重大步骤。而且 剩余的码点也非常少。另见 第 7.2 节。¶

7.2. 整理 附加信息空间

人类思维有时会倾向于填补感知到的小空隙， 以使事物整齐。我们预期附加信息值的码点 空间中剩余的空隙会成为新 想法的吸引物，仅仅因为它们在那里。¶

本规范并不通过 IANA 注册表管理附加信息 码点空间。相反，从该 空间进行分配只能通过更新本规范来完成。¶

对于 n >= 24 的附加信息值， 附加数据的大小通常为 2^n-24 字节。因此，附加 信息值 28 和 29 应被视为 128 位和 256 位数量的候选项，以备需要将它们添加到 协议中。于是，附加信息值 30 是唯一 可供一般分配的附加信息值，并且在通过更新 本规范来分配它之前，应当有非常充分的理由。¶

8.1. 编码指示符

有时在诊断记法中指示实际使用了 若干替代表示中的哪一种是有用的；例如，诊断解码器写作 >1.5< 的数据项可能已被 编码为半精度、单精度或双精度浮点数。¶

编码指示符的约定是：任何以下划线开头， 且后续所有字符都是字母数字或 下划线的内容，都是编码指示符；不对此信息感兴趣者 可以忽略它。例如，_ 或 _3。 编码指示符始终是 可选的。¶

可以在映射左花括号或 数组左方括号之后写一个单独的下划线，以指示该数据项以 不定长格式表示。例如，[_ 1, 2] 包含一个指示符，表明使用了不定长表示来 表示数据项 [1, 2]。¶

下划线后跟十进制数字 n 表示 前面的项（或者，对于数组和映射，表示以前面的 方括号或花括号开始的项）使用了附加信息 值 24+n 编码。例如，1.5_1 是半精度浮点 数，而 1.5_3 编码为双精度。此编码 指示符没有在 附录 A 中显示。（请注意，编码 指示符 “_” 因此是完整形式 “_7” 的缩写，而后者 不使用。）¶

不定长字节串和文本字符串的详细块结构 可以用 (_ h'0123', h'4567') 和 (_ "foo", "bar") 的形式记写。 然而，对于内部没有块的不定长字符串，(_ ) 会在表示字节串（0x5fff）还是文本字符串 （0x7fff）方面产生歧义，因此不使用。 可以改用基本形式 ''_ 和 ""_，且它们仅保留用于 没有块的情况——不是仅含空块的（允许但 并不真正有用的）编码的短形式；后者 需要记写为 (_ '')、(_ "") 等， 以保留块结构。¶

9.1. CBOR 简单值 注册表

IANA 已在 [IANA.cbor-simple-values] 创建了“Concise Binary Object Representation (CBOR) Simple Values”注册表。初始值见 表 4。¶

范围 0 到 19 中的新条目由 Standards Action [RFC8126] 分配。 建议 IANA 从数字 16 开始分配值， 以便将较低数字保留给 连续块（如果有）。¶

范围 32 到 255 中的新条目由 Specification Required 分配。¶

9.2. CBOR 标签注册表

IANA 已在 [IANA.cbor-tags] 创建了“Concise Binary Object Representation (CBOR) Tags”注册表。 [RFC7049] 中定义的标签 在 第 3.4 节 中详细描述， 此后也已经定义了其他标签。¶

范围 0 到 23（“1+0”）中的新条目由 Standards Action 分配。 范围 24 到 255（“1+1”）和 256 到 32767（“1+2”的低 半部分）中的新条目由 Specification Required 分配。范围 32768 到 18446744073709551615 （“1+2”的高半部分、“1+4”和“1+8”）中的新条目 由 First Come First Served 分配。注册 请求模板为：¶

• 数据项¶
• 语义（短形式）¶

此外，First Come First Served 请求应包括：¶

• 联系人¶
• 语义描述（URL）——此描述是 可选的；URL 可以指向类似 Internet-Draft 或 网页的内容。¶

使用 First Come First Served 范围并提出 不能以 32 位表示的标签号建议的申请者 （即大于 4294967295） 应意识到，这可能降低与 不支持 64 位数字的实现的互操作性。¶

9.3. 媒体类型注册表

单个已编码 CBOR 数据 项的互联网媒体类型 [RFC6838]（“MIME type”）是 “application/cbor”，如“Media Types”注册表 [IANA.media-types] 中所定义：¶

类型名:

application¶

子类型名:

cbor¶

必需参数:

n/a¶

可选参数:

n/a¶

编码考虑事项:

二进制¶

安全考虑事项:

见 RFC 8949 的 第 10 节。¶

互操作性考虑事项:

n/a¶

已发布规范:

RFC 8949¶

使用此媒体类型的应用:

许多¶

附加信息:

魔数:

n/a¶

文件扩展名:

.cbor¶

Macintosh 文件类型代码:

n/a¶

联系人及电子邮件地址，用于获取更多信息:

IETF CBOR Working Group (cbor@ietf.org) 或 IETF Applications and Real-Time Area (art@ietf.org)¶

预期用途:

COMMON¶

使用限制:

none¶

作者:

IETF CBOR Working Group (cbor@ietf.org)¶

变更控制者:

IESG (iesg@ietf.org)¶

9.4. CoAP Content-Format 注册表

CBOR 的 CoAP Content-Format 已注册在 “Constrained RESTful Environments (CoRE) Parameters”注册表内的“CoAP Content-Formats”子注册表中 [IANA.core-parameters]：¶

媒体类型:

application/cbor¶

编码:

-¶

ID:

60¶

参考:

RFC 8949¶

9.5. 结构化语法 后缀注册表

基于单个 已编码 CBOR 数据项的媒体类型的结构化语法后缀 [RFC6838] 是 +cbor，IANA 已将其注册在 “Structured Syntax Suffixes”注册表 [IANA.structured-suffix] 中：¶

名称:

简明二进制对象表示 （CBOR）¶

+suffix:

+cbor¶

参考:

RFC 8949¶

编码考虑事项:

CBOR 是二进制格式。¶

互操作性考虑事项:

n/a¶

片段标识符考虑事项:

为 +cbor 指定的片段标识符的语法和语义 SHOULD 与为 “application/cbor” 指定的相同。（在 RFC 8949 发布时，尚未为 “application/cbor” 定义片段标识 语法。）¶

特定 “xxx/yyy+cbor”的片段标识符的语法和语义 SHOULD 按如下方式处理：¶

• 对于 +cbor 中定义的情况，如果 片段标识符按 +cbor 规则解析， 则按 +cbor 中的规定处理。¶
• 对于 +cbor 中定义的情况，如果 片段标识符没有 按 +cbor 规则解析，则按 “xxx/yyy+cbor” 中的规定处理。¶
• 对于 +cbor 中未定义的情况，则 按 “xxx/yyy+cbor” 中的规定处理。¶

安全考虑事项:

见 RFC 8949 的 第 10 节。¶

联系人:

IETF CBOR Working Group (cbor@ietf.org) 或 IETF Applications and Real-Time Area (art@ietf.org)¶

作者/变更控制者:

IETF¶

E.1. ASN.1 DER、BER 和 PER

[ASN.1] 有许多 序列化格式。在 IETF 中，DER 和 BER 是 最常见的。对许多项而言，序列化输出并不特别紧凑， 并且在受限设备上解码数字项所需的代码可能很复杂。¶

很少（如果有的话）IETF 协议采用 Packed Encoding Rules （PER）的若干变体之一。原因可能有很多， 但常见说法之一是 PER 即使在解析数据项的表层结构时 也会使用模式， 因而需要大量工具支持。目前使用着 不同版本的 ASN.1 模式语言，这也阻碍了采用。¶

E.2. MessagePack

[MessagePack] 是一种 简明、广泛实现的计数式二进制 序列化格式，在许多属性上与 CBOR 相似，尽管 稍微不那么规则。虽然其数据模型可以用于表示 JSON 数据，MessagePack 也已用于许多远程过程 调用（RPC）应用以及数据的长期存储。¶

MessagePack 自约 2011 年首次发布以来基本保持稳定； 它尚未经历过一次迁移。MessagePack 的演进 受制于保持与已有存储数据完全向后 兼容的强制要求，而可供扩展的字节码只剩很少。 多年来，MessagePack 用户社区反复请求 在编码中分离二进制字符串和文本字符串， 最近促成了一个扩展提案，但该提案会让 MessagePack 的“raw”数据在二进制 和文本数据用途之间保持歧义。MessagePack 的扩展机制仍然 不清楚。¶

E.3. BSON

[BSON] 是一种为在 MongoDB 数据库中存储类 JSON 映射（JSON 对象） 而开发的数据格式。它的主要 区分特征是支持就地更新， 这阻止了紧凑表示。除了映射键之外，BSON 使用计数式 表示，而映射键以空字节终止。 虽然 BSON 可用于在线路上表示类 JSON 对象， 但其规范受数据库应用需求支配，并已变得有些繁复。 BSON 扩展将如何实现的状态仍不清楚。¶

E.4. MSDTP：RFC 713

Message Services Data Transmission（MSDTP）是 紧凑消息格式的一个非常早期示例；它在 1976 年编写的 [RFC0713] 中描述。 它包含在这里是出于历史价值，而不是因为它 曾经被广泛使用。¶

E.5. 在线路上的 简洁性

虽然 CBOR 的编码器和 解码器代码紧凑性设计目标优先级高于其在线路上简洁性的 目标，许多人仍关注线路大小。表 8 展示了 简单嵌套数组 [1, [2, 3]] 的一些编码示例；对于 编码支持某种形式不定长编码的情况， 也展示 [_ 1, [2, 3]]（外层数组为不定长）。¶

F.1. 非良构 CBOR 数据 项示例

本小节展示若干非 良构 CBOR 数据项示例。每个示例都是一个字节序列，每个字节以 十六进制显示；列表中的多个示例用逗号分隔。¶

良构性错误类型 1（数据过多）的示例，可以很容易地 通过向良构的已编码 CBOR 数据项添加数据来形成。¶

类似地，良构性错误类型 2（数据过少）的示例 可以通过截断良构的已编码 CBOR 数据项来形成。在 测试套件中，专门用需要大量 补充才能完成的不完整数据项进行测试可能是有益的 （例如，从编码一个非常 大大小的字符串开始）。¶

输入过早结束可能发生在头部中，也可能发生在所含 数据中，后者可以是裸字符串，或被包含的数据项，这些项要么 是计数的，要么本应由“break”停止码结束。¶

输入在头部中结束:

18, 19, 1a, 1b, 19 01, 1a 01 02, 1b 01 02 03 04 05 06 07, 38, 58, 78, 98, 9a 01 ff 00, b8, d8, f8, f9 00, fa 00 00, fb 00 00 00¶

数据过短的定长字符串:

41, 61, 5a ff ff ff ff 00, 5b ff ff ff ff ff ff ff ff 01 02 03, 7a ff ff ff ff 00, 7b 7f ff ff ff ff ff ff ff 01 02 03¶

定长映射和数组没有以足够项关闭:

81, 81 81 81 81 81 81 81 81 81, 82 00, a1, a2 01 02, a1 00, a2 00 00 00¶

标签号之后没有标签内容:

c0¶

不定长字符串未由“break”停止码关闭:

5f 41 00, 7f 61 00¶

不定长映射和数组未由“break”停止码关闭:

9f, 9f 01 02, bf, bf 01 02 01 02, 81 9f, 9f 80 00, 9f 9f 9f 9f 9f ff ff ff ff, 9f 81 9f 81 9f 9f ff ff ff¶

下面展示了良构性错误类型 3 （语法错误）五个子类的一些示例。¶

子类 1:

保留的附加信息值:

1c, 1d, 1e, 3c, 3d, 3e, 5c, 5d, 5e, 7c, 7d, 7e, 9c, 9d, 9e, bc, bd, be, dc, dd, de, fc, fd, fe,¶

子类 2:

简单值的保留双字节编码:

f8 00, f8 01, f8 18, f8 1f¶

子类 3:

不定长字符串块不是正确类型:

5f 00 ff, 5f 21 ff, 5f 61 00 ff, 5f 80 ff, 5f a0 ff, 5f c0 00 ff, 5f e0 ff, 7f 41 00 ff¶

不定长字符串块不是定长:

5f 5f 41 00 ff ff, 7f 7f 61 00 ff ff¶

子类 4:

Break 单独出现在不定长 项之外:

ff¶

Break 出现在定长数组或映射或标签中:

81 ff, 82 00 ff, a1 ff, a1 ff 00, a1 00 ff, a2 00 00 ff, 9f 81 ff, 9f 82 9f 81 9f 9f ff ff ff ff¶

Break 出现在不定长映射中，会导致项数为奇数 （break 处于值位置）:

bf 00 ff, bf 00 00 00 ff¶

子类 5:

主类型 0、1、6 搭配附加信息 31:

1f, 3f, df¶

G.1. 勘误处理和 文书性变更

RFC 7049 上的两个已验证勘误 [Err3764] 和 [Err3770]，涉及 文本中的两个编码示例，这些示例已经更正 （第 3.4.3 节：“29” -> “49”， 第 5.5 节：“0b000_11101” -> “0b000_11001”）。此外，RFC 7049 包含一个使用数值 24 作为简单值的示例 [Err5917]， 该示例不是良构的；此示例 已被移除。勘误报告 5763 [Err5763] 指出了标签定义措辞中的 错误；这在重写 第 3.4 节 期间得到解决。勘误报告 5434 [Err5434] 指出， 附录 E 中的 Universal Binary JSON （UBJSON）示例 已不再符合勘误报告提交时的 UBJSON 当前版本。 结果发现 UBJSON 规范自 2013 年以来已完全改变；因此该示例 被移除。其他勘误报告 [Err4409] [Err4963] [Err4964] 抱怨规范编码的映射键排序规则 过于繁重；这些报告促使重新考虑规范编码 建议，并由确定性编码建议取代 （如下所述）。勘误报告 4294 中的编辑性建议 [Err4294] 也已 实施（通过在 第 3.2.2 节 最后一个示例的注释中添加“Second value”， 改进对称性）。¶

其他文书性变更包括：¶

• 使用新的 xml2rfc 功能 [RFC7991]；¶
• 对所用记法提供更多解释；¶
• 更新参考文献，例如从 RFC 4627 更新到 [RFC8259]， 从 CNN-TERMS 更新到 [RFC7228]，以及 从 [ECMA262] 第 5.1 版更新到第 11 版； 添加对 [IEEE754] 的引用 并导入所需定义； 添加对 [C] 和 [Cplusplus20] 的引用； 以及添加对 [RFC8618] 的引用，该引用进一步说明了 附录 E 中的讨论；¶
• 在诊断记法的讨论中（第 8 节）， 现在提到了 [RFC8610] 中定义的“扩展诊断记法”（EDN）， 现在突出了表示 NaN payload 的空白， 并添加了对表示没有块的不定长字符串的说明 （第 8.1 节）；¶
• 添加本附录。¶

G.2. IANA 考虑事项中的变更

IANA 考虑事项已整体更新（文书性变更， 例如现在指向 CBOR 工作组作为规范作者）。 各相应 IANA 注册表的引用被 添加到资料性参考文献中。¶

在“Concise Binary Object Representation (CBOR) Tags”注册表 [IANA.cbor-tags] 中， 从 256 到 32767（“1+2”的低 半部分）空间中的标签不再按 First Come First Served 分配；该范围 现在为 Specification Required。¶

G.3. 建议和其他 资料性组成部分中的变更

在修订本文档时，除了处理勘误报告之外， 工作组还借鉴了 CBOR 在多种应用中近七年的经验。 这导致了一些编辑性变更，包括添加用于说明的表格，同时也 强调了某些方面并淡化了其他方面。¶

一项重要新增内容是 第 2 节，它 讨论 CBOR 数据模型及 CBOR 处理中涉及的小变体。 为这些变体（基本通用、 扩展通用、特定）引入术语，使文档其他 位置的语言更加简洁，也有助于澄清对 实现和格式可扩展性特性的期望。¶

作为一种源自 JSON 生态系统的格式，RFC 7049 受到 当时从 JavaScript 继承而来的 JSON 数字系统影响。 JSON 不提供不同的整数和浮点 值（后者在格式中是十进制的）。CBOR 提供数字的二进制表示，并且确实区分 整数和浮点值。来自实现和使用的经验 表明，文档中应更清楚地划定这两个数字 域之间的分离；暗示整数可以无缝替代浮点 值的语言已被移除。此外，还添加了一个（基于 I-JSON [RFC7493] 的）建议， 用于在 JSON 转换为 CBOR 时处理这些类型，并 推荐使用特定舍入机制。¶

对于数据模型中的单个值，CBOR 通常提供多个 编码选项。新增章节（第 4 节）引入术语 “首选序列化”（第 4.1 节），并为 各类 数据项定义该术语。基于此术语，该章节 随后讨论基于 CBOR 的协议如何定义“确定性 编码”（第 4.2 节），并避免使用 RFC 7049 中的术语“canonical”和“canonicalization”。“核心 确定性编码要求”（第 4.2.1 节） 的建议使得可对这种由协议定义的编码要求提供通用 支持。本文档进一步通过将 RFC 7049 中建议的映射排序 简化为已编码键的简单 字典序排序，降低了确定性编码的实现难度。较旧 建议的描述作为替代保留，现在称为“长度优先映射键 排序”（第 4.2.3 节）。¶

良构和有效数据的术语得到强化并被更 严格地使用，避免在示例之外使用 “syntax error”、“decoding error”和“strict mode”等定义较差的替代术语。 此外，现在明确指出了 应用对其输入数据提出的、超出 CBOR 层级有效性的第三层要求。 良构（总体上可处理）、有效（由 有效性检查通用解码器检查）和预期输入（由 应用检查）被视为可接受性层级体系。¶

非良构简单值的处理已在文本 和伪代码中澄清。添加了 附录 F 以讨论 良构性 错误并为其提供示例。伪代码已更新为 更具可移植性，并添加了一些可移植性考虑。¶

有效性讨论在两个方面得到强化。映射 有效性（重复键处理）得到澄清，并解释了某些实现选择的适用 范围。此外， 在精简标签、标签号和标签 内容术语的同时，添加了关于标签有效性的讨论，并澄清了 标签内容的一般限制以及专门针对标签 1 的限制。¶

在 第 3.4 节 中添加了一条实现说明 （以及面向未来标签定义的说明），关于定义语义依赖于 序列化顺序的标签。¶

标签 35 不由本文档定义；基于 RFC 7049 中定义的注册仍然保留。¶

在 第 3 节 中引入了 “实参”和“头部” 术语，简化了后续讨论。¶

安全考虑事项（第 10 节） 基本被重写并显著 扩展；在多个其他位置，本文档现在更明确地说明 解码器不能简单地容忍良构性错误。¶