2. CBOR エンコーディングの仕様

CBOR でエンコードされたデータ項目は、このセクションで説明されるように構造化およびエンコードされます。エンコーディングは表 5 にまとめられています。

各データ項目の初期バイトには、主タイプ (上位 3 ビット、セクション 2.1 で説明) に関する情報と追加情報 (下位 5 ビット) の両方が含まれます。追加情報の値が 24 未満の場合、それは小さな符号なし整数として直接使用されます。それが 24 から 27 の場合、可変長整数のための追加バイトが直後に続きます。追加情報の値 24 から 27 は、その長さがそれぞれ 1、2、4、または 8 バイトの符号なし整数であることを指定します。追加情報値 31 は、セクション 2.2 で説明される不定長項目のために使用されます。追加情報値 28 から 30 は将来の拡張のために予約されています。

すべての追加情報値において、結果の整数は主タイプに応じて解釈されます。それは実際のデータを表す場合があります。例えば整数型では、結果の整数が値そのものに使用されます。代わりに長さ情報を提供する場合もあります。例えばバイト文字列では、それは後続するバイト文字列データの長さを与えます。

CBOR デコーダーの実装は、初期バイトの 256 個の定義済み値すべてを持つジャンプテーブルに基づくことができます (表 5)。制約のある実装のデコーダーは、代わりに初期バイトと後続バイトの構造を使用して、よりコンパクトなコードにすることもできます (これがどのようになるかのおおよその印象については付録 C を参照)。

2.1. 主タイプ

以下に、主タイプと、そのタイプに関連する追加情報およびその他のバイトを示します。

主タイプ 0: 符号なし整数。5 ビットの追加情報は、整数そのもの (追加情報値 0 から 23 の場合) または追加データの長さのいずれかです。追加情報 24 は値が追加の uint8_t で表現されることを意味し、25 は uint16_t、26 は uint32_t、27 は uint64_t を意味します。例えば、整数 10 は 1 バイトの 0b000_01010 (主タイプ 0、追加情報 10) で表されます。整数 500 は 0b000_11001 (主タイプ 0、追加情報 25) に続いて 2 バイトの 0x01f4 (10 進数で 500) となります。

主タイプ 1: 負の整数。エンコーディングは符号なし整数 (主タイプ 0) の規則に従いますが、値は -1 からエンコードされた符号なし整数を引いたものになります。例えば、整数 -500 は 0b001_11001 (主タイプ 1、追加情報 25) に続いて 2 バイトの 0x01f3 (10 進数で 499) となります。

主タイプ 2: バイト文字列。文字列の長さ (バイト単位) は、正の整数 (主タイプ 0) の規則に従って表現されます。例えば、長さが 5 のバイト文字列は、初期バイトが 0b010_00101 (主タイプ 2、長さのための追加情報 5) となり、その後に 5 バイトのバイナリ内容が続きます。長さが 500 のバイト文字列は、3 つの初期バイトが 0b010_11001 (主タイプ 2、2 バイト長を示す追加情報 25) となり、その後に長さ 500 を示す 2 バイトの 0x01f4 が続き、さらに 500 バイトのバイナリ内容が続きます。

主タイプ 3: テキスト文字列。具体的には、UTF-8 [RFC3629] としてエンコードされた Unicode 文字の文字列です。このタイプの形式はバイト文字列 (主タイプ 2) のものと同一です。つまり、主タイプ 2 と同様に、長さはバイト数を示します。このタイプは、人間が読めるテキストを解釈または表示する必要があるシステムのために提供され、構造化されていないバイトと、規定されたレパートリーとエンコーディングを持つテキストとを区別できるようにします。JSON のような形式とは対照的に、このタイプの Unicode 文字がエスケープされることはありません。したがって、改行文字 (U+000A) は文字列内で常にバイト 0x0a として表現され、バイト 0x5c6e (文字 "" と "n") や 0x5c7530303061 (文字 "", "u", "0", "0", "0", "a") として表現されることはありません。

主タイプ 4: データ項目の配列。配列はリスト、シーケンス、またはタプルとも呼ばれます。配列の長さはバイト文字列 (主タイプ 2) の規則に従いますが、長さは配列が占めるバイト数ではなくデータ項目の数を示します。配列内の項目はすべて同じタイプである必要はありません。例えば、任意のタイプの 10 個の項目を含む配列は、初期バイトが 0b100_01010 (主タイプ 4、長さのための追加情報 10) となり、その後に残りの 10 個の項目が続きます。

主タイプ 5: データ項目のペアのマップ。マップはテーブル、ディクショナリ、ハッシュ、または (JSON では) オブジェクトとも呼ばれます。マップはデータ項目のペアで構成され、各ペアはキーとその直後に続く値からなります。マップの長さはバイト文字列 (主タイプ 2) の規則に従いますが、長さはマップが占めるバイト数ではなくペアの数を示します。例えば、9 個のペアを含むマップは、初期バイトが 0b101_01001 (主タイプ 5、ペア数を示す追加情報 9) となり、その後に残りの 18 個の項目が続きます。1 番目の項目が 1 番目のキー、2 番目の項目が 1 番目の値、3 番目の項目が 2 番目のキー、というようになります。重複するキーを持つマップは整形式である可能性がありますが、有効ではなく、したがって不確定なデコードを引き起こします。セクション 3.7 も参照してください。

主タイプ 6: 他の主タイプのオプションの意味論的タグ付け。セクション 2.4 を参照。

主タイプ 7: 浮動小数点数、および内容を必要としないシンプルデータ型、ならびに "break" 停止コード。セクション 2.3 を参照。

これら 8 つの主タイプにより、データ項目の初期バイトの 256 個の可能な値のうちどれが使用されるかを示す単純な表が得られます (表 5)。

主タイプ 6 および 7 では、可能な値の多くが将来の仕様のために予約されています。これらの値の詳細についてはセクション 7 を参照してください。

2.2. 一部の主タイプにおける不定長

4 つの CBOR 項目 (配列、マップ、バイト文字列、およびテキスト文字列) は、追加情報値 31 を使用して不定長でエンコードできます。これは、配列やマップ内の項目数、または文字列の合計長が判明する前に項目のエンコードを開始する必要がある場合に有用です。(この適用は、データ項目内での「ストリーミング」と呼ばれることがよくあります。)

不定長の配列およびマップは、不定長のバイト文字列およびテキスト文字列とは異なる扱いになります。

2.2.1. 不定長の配列とマップ

不定長の配列およびマップは、追加情報値 31 を使用して、配列またはマップに含まれるデータ項目の数を示さずに単に開かれます。初期の主タイプおよび追加情報バイトの後には、他の配列やマップと同様に、配列またはマップの要素が続きます。配列またはマップの終わりは、通常なら次のデータ項目が含まれる位置に "break" 停止コードをエンコードすることによって示されます。"break" は主タイプ 7 および追加情報値 31 (0b111_11111) でエンコードされますが、それ自体はデータ項目ではありません。それは配列またはマップを閉じるための単なる構文上の機能です。つまり、"break" 停止コードは配列またはマップの最後の項目の後に置かれ、データ項目の代わりに他の場所に現れることはできません。このように、不定長の配列およびマップは、追加情報値 31 で始まり "break" 停止コードで終わることを除けば、他の配列やマップと見分けがつきません。

不定長の配列およびマップでは、"break" 停止コードの前に任意の数の項目 (配列の場合) およびキー/値ペア (マップの場合) を置くことができます。不定長の配列項目またはマップ項目をネストすることに対する制限はありません。"break" は単一の項目のみを終了させるため、ネストされた不定長項目には、不定長項目を開始するタイプバイトの数と正確に同数の "break" 停止コードが必要です。

例えば、エンコーダーが抽象的な配列 [1, [2, 3], [4, 5]] を表現したいとします。確定長のエンコーディングは 0x8301820203820405 となります:

83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5

不定長エンコーディングは、必要に応じてこのデータ項目内でエンコードされる 3 つの配列のそれぞれに独立に適用でき、次のような表現になります:

0x9f018202039f0405ffff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break" (inner array) FF -- "break" (outer array)

0x9f01820203820405ff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5 FF -- "break" 0x83018202039f0405ff 83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break"

0x83019f0203ff820405 83 -- Array of length 3 01 -- 1 9F -- Start indefinite-length array 02 -- 2 03 -- 3 FF -- "break" 82 -- Array of length 2 04 -- 4 05 -- 5

不定長マップの例 (たまたま 2 つのキー/値ペアを持つ) は次のようになります:

0xbf6346756ef563416d7421ff BF -- Start indefinite-length map 63 -- First key, UTF-8 string length 3 46756e -- "Fun" F5 -- First value, true 63 -- Second key, UTF-8 string length 3 416d74 -- "Amt" 21 -- -2 FF -- "break"

2.2.2. 不定長のバイト文字列とテキスト文字列

不定長のバイト文字列およびテキスト文字列は、実際には、まとめて 1 つの連続した文字列として扱われる、0 個以上の確定長のバイト文字列またはテキスト文字列 ("チャンク") の連結です。不定長の文字列は主タイプと追加情報値 31 で開かれますが、その後に続くのは確定長を持つ一連のバイト文字列またはテキスト文字列 (チャンク) です。チャンクの並びの終わりは、その並びで次のチャンクが現れる位置に "break" 停止コード (0b111_11111) をエンコードすることによって示されます。チャンクの内容は連結され、不定長文字列の全体の長さはすべてのチャンクの長さの合計になります。まとめると、不定長の文字列は、そのチャンクの不定長配列がエンコードされるのと同様にエンコードされますが、不定長文字列の主タイプが (テキストまたはバイト) 文字列のものであり、そのチャンクの主タイプと一致する点が異なります。

不定長のバイト文字列の場合、不定長指示子と "break" の間のすべてのデータ項目 (チャンク) は、確定長のバイト文字列項目でなければなりません (MUST)。パーサーが "break" を見る前にバイト文字列以外の項目タイプを見た場合、それはエラーです。

例えば、次のシーケンスを想定します:

0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111

5F -- Start indefinite-length byte string 44 -- Byte string of length 4 aabbccdd -- Bytes content 43 -- Byte string of length 3 eeff99 -- Bytes content FF -- "break"

デコード後、これは 7 バイトの単一のバイト文字列になります: 0xaabbccddeeff99。

不定長のテキスト文字列は不定長のバイト文字列と同じように動作しますが、そのすべてのチャンクが確定長のテキスト文字列でなければならない (MUST) 点が異なります。これは、単一の UTF-8 文字のバイトをチャンク間で分割できないことを意味します。新しいチャンクは文字境界でのみ開始できます。

2.3. 浮動小数点数と内容のない値

主タイプ 7 は 2 種類のデータのためのものです: 浮動小数点数と、内容を必要としない「シンプル値」です。初期バイトの 5 ビット追加情報の各値は、表 1 で定義されるように、それぞれ独自の意味を持ちます。整数の主タイプと同様に、この主タイプの項目は内容データを運びません。すべての情報は初期バイトにあります。

5 ビット値	意味
0..23	シンプル値 (値 0..23)
24	シンプル値 (後続バイトで値 32..255)
25	IEEE 754 半精度浮動小数点数 (16 ビットが後続)
26	IEEE 754 単精度浮動小数点数 (32 ビットが後続)
27	IEEE 754 倍精度浮動小数点数 (64 ビットが後続)
28-30	(未割り当て)
31	不定長項目のための "break" 停止コード

表 1: 主タイプ 7 における追加情報の値

他のすべての主タイプと同様に、5 ビット値 24 は 1 バイトの拡張を示します。シンプル値を表現するために追加のバイトが後続します。(混乱を最小にするため、値 32 から 255 のみが使用されます。) これにより初期バイトの構造が維持されます。他の主タイプと同様に、これらの長さは常に最初のバイトの追加情報に依存します。表 2 は、シンプルタイプに割り当てられている値と利用可能な値を示します。

値	意味
0..19	(未割り当て)
20	False
21	True
22	Null
23	未定義値
24..31	(予約)
32..255	(未割り当て)

表 2: シンプル値

5 ビット値 25、26、27 は、16 ビット、32 ビット、64 ビットの IEEE 754 バイナリ浮動小数点値のためのものです。これらの浮動小数点値は、適切なサイズの追加バイトにエンコードされます。(16 ビット浮動小数点については付録 D を参照。)

2.4. 項目のオプションのタグ付け

CBOR では、データ項目の前にオプションでタグを置いて、その構造を保ちながら追加の意味を与えることができます。タグは主タイプ 6 であり、タグの整数値で示される整数を表します。(唯一の) データ項目は内容データとして運ばれます。タグが構造化データを必要とする場合、その構造はネストされたデータ項目にエンコードされます。タグの定義は、通常、タグが運べるネストされたデータ項目の種類を制限します。

タグの初期バイトは正の整数 (主タイプ 0) の規則に従います。タグの後には任意のタイプの単一のデータ項目が続きます。例えば、長さ 12 のバイト文字列が正のビッグナム (セクション 2.4.2) であることを示すタグでマークされているとします。これは 0b110_00010 (主タイプ 6、タグのための追加情報 2) に続いて 0b010_01100 (主タイプ 2、長さのための追加情報 12)、さらにビッグナムの 12 バイトが続く形でマークされます。

デコーダーはタグを理解する必要がないため、特定の CBOR データ項目を作成する実装とそのストリームをデコードする実装がデータフロー内の各項目の意味を知っているアプリケーションでは、タグの価値は小さい可能性があります。本仕様におけるタグの主な目的は、日付のような共通のデータ型を定義することです。第 2 の目的は、デコーダーがジェネリックな CBOR デコーダーであり、項目の内容に関するヒントから恩恵を受けられる可能性がある場合に、オプションのタグ付けを可能にすることです。意味論的タグを理解することはデコーダーにとってオプションであり、タグの初期バイトを読み飛ばしてタグ付きデータ項目自体を解釈することもできます。

タグは常にその直後に続く項目に適用されます。したがって、タグ A の後にタグ B が続き、その後にデータ項目 C が続く場合、タグ A はデータ項目 C にタグ B を適用した結果に適用されます。つまり、タグ付き項目はタグと値からなるデータ項目です。タグ付き項目の内容は、タグ付けされているデータ項目 (値) です。

IANA はセクション 7.2 で説明されるようにタグ値のレジストリを維持しています。表 3 は初期値の一覧であり、定義はこのセクションの残りの部分にあります。

タグ	データ項目	意味
0	UTF-8 文字列	標準の日付/時刻文字列。セクション 2.4.1 を参照
1	複数	エポックベースの日付/時刻。セクション 2.4.1 を参照
2	バイト文字列	正のビッグナム。セクション 2.4.2 を参照
3	バイト文字列	負のビッグナム。セクション 2.4.2 を参照
4	配列	10 進小数。セクション 2.4.3 を参照
5	配列	ビッグフロート。セクション 2.4.3 を参照
6..20	(未割り当て)	(未割り当て)
21	複数	base64url エンコーディングへの予期される変換。セクション 2.4.4.2 を参照
22	複数	base64 エンコーディングへの予期される変換。セクション 2.4.4.2 を参照
23	複数	base16 エンコーディングへの予期される変換。セクション 2.4.4.2 を参照
24	バイト文字列	エンコードされた CBOR データ項目。セクション 2.4.4.1 を参照
25..31	(未割り当て)	(未割り当て)
32	UTF-8 文字列	URI。セクション 2.4.4.3 を参照
33	UTF-8 文字列	base64url。セクション 2.4.4.3 を参照
34	UTF-8 文字列	base64。セクション 2.4.4.3 を参照
35	UTF-8 文字列	正規表現。セクション 2.4.4.3 を参照
36	UTF-8 文字列	MIME メッセージ。セクション 2.4.4.3 を参照
37..55798	(未割り当て)	(未割り当て)
55799	複数	自己記述 CBOR。セクション 2.4.5 を参照
55800+	(未割り当て)	(未割り当て)

表 3: タグの値

2.4.1. 日付と時刻

タグ値 0 は、[RFC4287] のセクション 3.3 で精緻化された、[RFC3339] で説明される標準形式に従う日付/時刻文字列のためのものです。

タグ値 1 は、UTC 時間で 1970-01-01T00:00Z からの相対秒数の数値表現のためのものです。(Portable Operating System Interface (POSIX) が定義する非負の値については、秒数は POSIX の "seconds since the epoch" [TIME_T] と同じ方法で数えられます。) タグ付き項目は正または負の整数 (主タイプ 0 および 1)、または浮動小数点数 (追加情報 25、26、または 27 を持つ主タイプ 7) にできます。数値は負 (1970-01-01T00:00Z より前の時刻) にでき、浮動小数点数の場合は小数秒を示すことができます。

2.4.2. ビッグナム

ビッグナムは、主タイプ 0 および 1 が提供する基本的な整数表現に収まらない整数です。これらはバイト文字列データ項目としてエンコードされ、ネットワークバイトオーダーの符号なし整数 n として解釈されます。タグ値 2 の場合、ビッグナムの値は n です。タグ値 3 の場合、ビッグナムの値は -1 - n です。これらのタグを理解するデコーダーは、先頭にゼロを持つビッグナムをデコードできなければなりません (MUST)。

例えば、数 18446744073709551616 (2**64) は、0b110_00010 (主タイプ 6、タグ 2) に続いて 0b010_01001 (主タイプ 2、長さ 9)、さらに 0x010000000000000000 (1 バイトの 0x01 と 8 バイトの 0x00) として表現されます。16 進数では:

C2 -- Tag 2 29 -- Byte string of length 9 010000000000000000 -- Bytes content

2.4.3. 10 進小数とビッグフロート

10 進小数は、整数の仮数と 10 を底とするスケール係数を組み合わせます。これらは、バイナリ浮動小数点では多くの 10 進小数に厳密な表現がないため、アプリケーションが 1.1 のような 10 進小数の厳密な表現を必要とする場合に最も有用です。

ビッグフロートは、整数の仮数と 2 を底とするスケール係数を組み合わせます。これらは、CBOR がサポートする 3 つの IEEE 754 形式 (セクション 2.3) の範囲または精度を超える可能性のあるバイナリ浮動小数点値です。ビッグフロートは、IEEE 754 をサポートする必要なしに基本的なバイナリ浮動小数点機能を必要とする制約のあるアプリケーションでも使用できます。

10 進小数またはビッグフロートは、ちょうど 2 つの整数 (指数 e と仮数 m) を含むタグ付き配列として表現されます。10 進小数 (タグ 4) は 10 を底とする指数を使用し、10 進小数データ項目の値は m*(10e) です。ビッグフロート (タグ 5) は 2 を底とする指数を使用し、ビッグフロートデータ項目の値は m*(2e) です。指数 e は主タイプ 0 または 1 の整数で表現されなければなりません (MUST)。仮数はビッグナム (セクション 2.4.2) にすることもできます。

10 進小数の例として、数 273.15 は 0b110_00100 (タグの主タイプ 6、タグの種類のための追加情報 4) に続いて 0b100_00010 (配列の主タイプ 4、配列の長さのための追加情報 2)、さらに 0b001_00001 (最初の整数の主タイプ 1、値 -2 のための追加情報 1)、さらに 0b000_11001 (2 番目の整数の主タイプ 0、2 バイト値のための追加情報 25)、さらに 0b0110101010110011 (2 バイトの 27315) として表現できます。16 進数では:

C4 -- Tag 4 82 -- Array of length 2 21 -- -2 19 6ab3 -- 27315

ビッグフロートの例として、数 1.5 は 0b110_00101 (タグの主タイプ 6、タグの種類のための追加情報 5) に続いて 0b100_00010 (配列の主タイプ 4、配列の長さのための追加情報 2)、さらに 0b001_00000 (最初の整数の主タイプ 1、値 -1 のための追加情報 0)、さらに 0b000_00011 (2 番目の整数の主タイプ 0、値 3 のための追加情報 3) として表現できます。16 進数では:

C5 -- Tag 5 82 -- Array of length 2 20 -- -1 03 -- 3

10 進小数およびビッグフロートは、Infinity、-Infinity、NaN の表現を提供しません。10 進小数またはビッグフロートの代わりにこれらが必要な場合は、セクション 2.3 の IEEE 754 半精度表現を使用できます。特定の数を整数として表現するか 10 進小数またはビッグフロートとして表現するかの選択がある制約のあるアプリケーションでは (例えば指数が小さく非負の場合)、整数表現を直接使用するという実装品質への期待があります。

2.4.4. 内容ヒント

このセクションのタグは、ジェネリックな CBOR プロセッサが使用する可能性のある内容ヒントのためのものです。

2.4.4.1. エンコードされた CBOR データ項目

包含するデータ項目が解析されている時点では直ちにデコードされることを意図していない、埋め込まれた CBOR データ項目を運ぶことが有益な場合があります。タグ 24 (CBOR データ項目) は、埋め込まれたバイト文字列を CBOR 形式でエンコードされたデータ項目としてタグ付けするために使用できます。

2.4.4.2. CBOR から JSON へのコンバータのための予期される後続エンコーディング

タグ 21 から 23 は、テキストベースの表現と相互運用する際にバイト文字列が特定のエンコーディングを必要とする可能性があることを示します。これらのタグは、エンコーダーが書き込んでいるバイト文字列データが後で特定の JSON ベースの用法に変換される可能性が高いことを知っている場合に有用です。その用法は、一部の文字列が base64、base64url などとしてエンコードされることを規定します。エンコーダーは、メッセージサイズを削減するため、エンコーダーのコードサイズを削減するため、またはその両方のために、自身でエンコードを行う代わりにバイト文字列を使用します。エンコーダーはコンバータがジェネリックであるかどうかを知らないため、バイナリ文字列を JSON に変換する適切な方法が何であると考えるかを示したいのです。

タグ付けされるデータ項目は、バイト文字列またはその他の任意のデータ項目にできます。後者の場合、タグはそのデータ項目に含まれるすべてのバイト文字列データ項目に適用されます。ただし、予期される変換でタグ付けされたネストされたデータ項目に含まれるものは除きます。

これら 3 つのタグタイプは、[RFC4648] で定義される 3 つの基底データエンコーディングへの変換を示唆します。base64url エンコーディングではパディングを使用しません (RFC 4648 のセクション 3.2 を参照)。つまり、末尾の等号 ("=") はすべて base64url エンコードされた文字列から削除されます。後のタグで、RFC 4648 の他のデータエンコーディングや、バイナリデータを文字列にエンコードする他の方法が定義される可能性があります。

2.4.4.3. エンコードされたテキスト

インターネットで広く使われている形式のデータを保持するテキスト文字列があり、それらの形式がデコーダーによって検証され、アプリケーションに適切な形で提示できる場合があります。これらの形式のいくつかにはタグがあります。

• タグ 32 は [RFC3986] で定義される URI のためのものです。

• タグ 33 および 34 は、[RFC4648] で定義される base64url および base64 エンコードされたテキスト文字列のためのものです。

• タグ 35 は、Perl Compatible Regular Expressions (PCRE) / JavaScript 構文 [ECMA262] の正規表現のためのものです。

• タグ 36 は、[RFC2045] で定義される MIME メッセージ (すべてのヘッダーを含む) のためのものです。

タグ 33 および 34 は 21 および 22 と異なり、前者ではデータが base エンコードされた形で転送され、後者では生のバイト文字列の形で転送されることに注意してください。

2.4.5. 自己記述 CBOR

多くのアプリケーションでは、データ項目のエンコードに CBOR が使われていることは文脈から明らかです。例えば、特定のプロトコルが CBOR の使用を規定しているか、その使用を規定するメディアタイプが示されている可能性があります。しかし、CBOR データがファイルに保存され、曖昧さを解消するメタデータが使われていない場合など、そのような文脈情報が得られないアプリケーションもあります。ここでは、データ自体に何らかの識別特性があれば役立つ可能性があります。

タグ 55799 はこの目的のために定義されています。それは後続のデータ項目に特別な意味を与えるものではありません。つまり、タグ 55799 でタグ付けされたデータ項目の意味は、そのデータ項目自体の意味と完全に同一です。

このタグのシリアライゼーションは 0xd9d9f7 であり、これは頻繁に使われるファイルタイプの識別マークとしては使われていないようです。特に、有効な CBOR データ項目が後続する場合、どの Unicode エンコーディングにおいても有効な Unicode テキストの開始にはなりません。

例えば、デコーダーが CBOR と JSON の両方を解析できる場合があります。そのようなデコーダーは 2 つの形式を機械的に区別する必要があります。エンコーダーがデコーダーを助ける簡単な方法は、CBOR 項目全体にタグ 55799 を付けることです。そのシリアライゼーションが JSON テキストの先頭に現れることは決してありません。