| CBOR | |
|---|---|
| ファイル名拡張子 | .cbor |
| インターネットメディアの種類 | アプリケーション/cbor |
| フォーマットの種類 | データ交換 |
| 延長から | メッセージパック |
| 標準 | RFC 8949 |
| オープンフォーマット? | はい |
| Webサイト | cbor.io |
簡潔バイナリオブジェクト表現(CBOR)は、Carsten BormannとPaul Hoffmanによって考案されたJSONを大まかにベースとしたバイナリデータシリアル化形式です。 [ a ] JSONと同様に、名前と値のペアを含むデータオブジェクトの転送を可能にしますが、より簡潔な形式で行われます。これにより、人間の可読性は犠牲になりますが、処理速度と転送速度が向上します。CBORはIETF RFC 8949で定義されています。[ 2 ]
その他の用途としては、 CoAP IoTプロトコルスイート[ 3 ]の推奨データシリアル化層であり、 COSEメッセージのベースとなるデータ形式です。また、 FIDO2プロジェクトのクライアント認証プロトコル(CTAP)でも使用されています。 [ 4 ]
CBORは、古橋貞之氏が開発・推進したMessagePackに触発された。CBORはMessagePackを拡張し、特にテキスト文字列とバイト文字列を区別できるようにした。これは2013年にMessagePackに実装された。[ 5 ] [ 6 ]
CBORエンコーディングの仕様
CBORエンコードされたデータは、データ項目のストリームとして扱われます。各データ項目は、3ビットの型と5ビットのショートカウントを含むヘッダーバイトで構成されます。これに続いて、オプションで拡張カウント(ショートカウントが24~27の範囲にある場合)とオプションのペイロードが続きます。
タイプ0、1、7の場合、ペイロードは存在せず、カウントは値です。タイプ2(バイト文字列)と3(テキスト文字列)の場合、カウントはペイロードの長さです。タイプ4(配列)と5(マップ)の場合、カウントはペイロード内のアイテム(ペア)の数です。タイプ6(タグ)の場合、ペイロードは単一のアイテムであり、カウントは囲まれたアイテムを表す数値タグ番号です。
| CBORデータ | データ項目1 | データ項目2 | データ項目 3... | ||||||
|---|---|---|---|---|---|---|---|---|---|
| バイト数 | 1バイト(CBORデータ項目ヘッダ) | 変数 | 変数 | 1バイト(CBORデータ項目ヘッダ) | 変数 | 変数 | 等... | ||
| 構造 | メジャータイプ | ショートカウント | 拡張カウント(オプション) | データペイロード(オプション) | メジャータイプ | ショートカウント | 拡張カウント(オプション) | データペイロード(オプション) | 等... |
| ビット数 | 3ビット | 5ビット | 8ビット×変数 | 8ビット×変数 | 3ビット | 5ビット | 8ビット×変数 | 8ビット×変数 | 等.. |
各データ項目における主要な型とカウントの処理
各データ項目の動作は、主要なタイプとカウントによって定義されます。主要なタイプは、各データ項目の主な動作またはタイプを選択するために使用されます。
5ビットのショートカウントフィールドは、カウント0~23を直接エンコードします。ショートカウント24~27は、カウント値が後続の8ビット、16ビット、32ビット、または64ビットの拡張カウントフィールドにあることを示します。28~30の値は割り当てられておらず、使用しないでください。
タイプは、カウント フィールドが値を直接エンコードする「アトミック」タイプ 0 ~ 1 と 6 ~ 7 と、カウント フィールドが後続のペイロード フィールドのサイズをエンコードする非アトミック タイプ 2 ~ 5 に分けられます。
非アトミックタイプ2~5では、ショートカウント31は不定長を示すために使用されます。ペイロードは、255の「ブレーク」マーカーバイト(タイプ=7、ショートカウント=31)までの項目です。その他のアトミックタイプ0、1、6では、ショートカウント31は使用できません。
タイプ 6 (タグ) は、カウント フィールドが値を直接エンコードするだけでなく、ペイロード フィールド (常に 1 つの項目で構成) も持つという点で異なります。
拡張カウントおよびすべてのマルチバイト値は、ネットワーク (ビッグ エンディアン) バイト オーダーでエンコードされます。
CBORデータ項目フィールドのエンコーディング
小さなフィールドエンコーディング
| バイト数 | 1バイト(CBORデータ項目ヘッダ) | |
|---|---|---|
| 構造 | メジャータイプ | ショートカウント(値) |
| ビット数 | 3ビット | 5ビット |
| 原子 | 0~1、7 | 0~23歳 |
| ブレークマーカー | 7 | 31 |
ショートフィールドエンコーディング
| バイト数 | 1バイト(CBORデータ項目ヘッダ) | 変数 | |
|---|---|---|---|
| 構造 | メジャータイプ | ショートカウント | 価値 |
| ビット数 | 3ビット | 5ビット | 8ビット×変数 |
| 原子 | 0~1、7 | 24~27 | 8、16、32、または64ビット |
| 弦 | 2~3 | 0~23歳 | カウント × 8ビット |
| アイテム | 4~5 | 0~23歳 | カウント × アイテム/ペア |
| タグ | 6 | 0~23歳 | 1つのアイテム |
ロングフィールドエンコーディング
| バイト数 | 1バイト(CBORデータ項目ヘッダ) | 1、2、4、または8バイト | 変数 | |
|---|---|---|---|---|
| 構造 | メジャータイプ | ショートカウント(24~27) | 拡張カウント(ペイロードの長さ) | 価値 |
| ビット数 | 3ビット | 5ビット | 8、16、32、または64ビット | 8ビット × 可変 |
| 弦 | 2~3 | 24~27 | 最大2 64 −1 | カウント × 8ビット |
| アイテム | 4~5 | 24~27 | 最大2 64 −1 | カウント × アイテム/ペア |
| タグ | 6 | 24~27 | タグ、最大2 64 −1 | 1つのアイテム |
整数(タイプ0と1)
整数の場合、カウントフィールドが値となり、ペイロードはありません。タイプ0は正または符号なしの整数をエンコードし、その値は最大2 64 −1です。タイプ1は負の整数をエンコードし、その値は−1−カウントで、−2 64から−1までです。
文字列(タイプ2および3)
タイプ2と3には、ペイロードの長さをバイト単位でエンコードするカウントフィールドがあります。タイプ2は非構造化バイト文字列です。タイプ3はUTF-8テキスト文字列です。
31という短い数値は、不定長文字列を表します。この文字列の後に、同じ型の0個以上の確定長文字列が続き、"break"マーカーバイトで終端されます。項目の値は、囲まれた項目の値を連結したものになります。異なる型の項目、またはネストされた不定長文字列は許可されません。テキスト文字列はそれぞれ整形式でなければなりません。UTF-8文字を複数の項目に分割することはできません。
配列とマップ(タイプ4と5)
タイプ4には、後続の項目の数をエンコードするカウントフィールドがあり、その後に同じ数の項目が続きます。項目はすべて同じ型である必要はありません。一部のプログラミング言語では、これを「配列」ではなく「タプル」と呼びます。
あるいは、ショートカウントが31の不定長エンコーディングを使用することもできます。これは、255の「ブレーク」マーカーバイトまで続きます。ネストされた項目でも不定長エンコーディングが使用される可能性があるため、パーサーはブレークマーカーと対応する不定長ヘッダーバイトをペアにする必要があります。
タイプ5は似ていますが、キーと値のペアのマップ(辞書または連想配列とも呼ばれます)をエンコードします。この場合、カウントはアイテムのペアの数をエンコードします。不定長エンコードを使用する場合、「break」マーカーバイトの前には偶数個のアイテムが必要です。
セマンティックタグ(タイプ6)
セマンティック タグはカウントが値となる別のアトミック タイプですが、ペイロード (後続の単一の項目) も持ち、この 2 つは配列やマップなどの 1 つの項目と見なされます。
タグ番号は、3ビットのメジャータイプが提供できる情報を超えて、後続の項目の追加の型情報を提供します。たとえば、タグが1の場合、後続の数値はUnix時刻値であることを示します。タグが2の場合、後続のバイト文字列は符号なしbignumをエンコードしていることを示します。タグが32の場合、後続のテキスト文字列はRFC 3986で定義されているURIであることを示します。RFC 8746では、タグ64~87が、固定サイズの整数値または浮動小数点値の同種配列をバイト文字列としてエンコードするために定義されています。
タグ55799は、「CBORデータが続く」という意味で割り当てられています。これは意味的には何も行いませんが、対応するタグバイトをCBORファイルの先頭に追加しても、ファイルの意味には影響を与えません。これらのバイトは、CBORデータの開始を区別するための 「マジックナンバーd9 d9 f7」として使用できます。
すべて 1 のタグ値 0xffff、0xffffffff、および 0xffffffffffffffff は、CBOR デコード ライブラリにタグが存在しないことを示すために予約されており、データ ストリームには決して出現しません。
ブレークマーカー疑似項目は、タグのペイロードではない可能性があります。
特殊/フロート(タイプ7)
このメジャータイプは、他のカテゴリに当てはまらない様々な特殊な値をエンコードするために使用されます。他のアトミックタイプ(0、1、6)と同じエンコードサイズ規則に従いますが、カウントフィールドの解釈は異なります。
値 0 ~ 19 は現在定義されていません。
値 20 ~ 23 は、特殊値、、、およびをエンコードするために使用さfalseれます。 truenullundefined
24という短いカウントは、1バイトの拡張カウントが続くことを示します。これは将来、追加の特殊値をエンコードするために使用できます。デコードを簡素化するため、0~31の値はこの形式でエンコードされない場合があります。32~255の値はいずれも現在定義されていません。
ショートカウントが25、26、または27の場合、後続の拡張カウントフィールドは(ビッグエンディアン)16ビット、32ビット、または64ビットのIEEE浮動小数点値として解釈されます。これらの値は拡張カウントと同じサイズですが、解釈方法が異なります。特に、他のすべての主要データ型では、2バイトの拡張カウント0x1234と4バイトの拡張カウント0x00001234は全く同じです。これは浮動小数点値には当てはまりません。
ショートカウント 28 ~ 30 は、他のすべての主要なタイプと同様に予約されています。
ショートカウント31は、不定長エンコードの終了を示す特別な「break」マーカーをエンコードします。これは、ショートカウント31が不定長エンコードの始まりとなる他のメジャータイプと関連しますが、異なります。これはアイテムではなく、定義長ペイロードには出現しません。
セマンティックタグ登録
IANAはCBORタグレジストリを作成しました。レジストリはhttps://www.iana.org/assignments/cbor-tags/cbor-tags.xhtmlにあります。登録には、以下に示すテンプレートを含める必要があります。[ 7 ]
| セマンティックタグタイプ | 範囲 | テンプレート | |||
|---|---|---|---|---|---|
| データ項目 | セマンティクス(短縮形) | 連絡先 | セマンティクスの説明(URL) | ||
| 標準アクション | 0~23歳 | 必須 | 必須 | 該当なし | 該当なし |
| 仕様が必要です | 24–32767 | 必須 | 必須 | 該当なし | 該当なし |
| 先着順 | 32768–18446744073709551615 | 必須 | 必須 | 必須 | 説明はオプションです。 URL はインターネット ドラフトまたは Web ページを指すことができます。 |
暗号化
オブジェクトの署名と暗号化
このセクションは拡張が必要です。不足している情報を追加していただければ幸いです。 (2025年7月) |
CBORオブジェクト署名および暗号化(COSE )は、認証および/または暗号化されたCBORデータ構造のバイナリ形式です。[ 8 ]
ウェブトークン
このセクションは拡張が必要です。不足している情報を追加していただければ幸いです。 (2025年7月) |
CBORウェブトークン(CWT)は、 CBORをシリアル化形式として使用する署名付きトークンです。JSONウェブトークン(JWT)の代替として利用できます。[ 9 ]
参照
注記
参考文献
- ^ Bormann, Carsten; Hoffman, Paul (2013-07-28). 「CBORの設計と概要」(PDF) . IETF Proceedings . 2025年1月28日時点のオリジナルよりアーカイブ(PDF) . 2024年6月1日閲覧.
- ^ Bormann, Carsten. 「CBOR — 簡潔なバイナリオブジェクト表現 | 概要」 . cbor.io. 2025年1月28日時点のオリジナルよりアーカイブ。2016年8月24日閲覧。
- ^ 「CoAP — 制約付きアプリケーションプロトコル | 概要」 。 2017年1月3日時点のオリジナルよりアーカイブ。2016年8月28日閲覧。
- ^ 「FIDO2プロジェクト」。FIDOアライアンス。2018年4月22日時点のオリジナルよりアーカイブ。 2018年5月11日閲覧。
- ^ 「プロトコルに文字列型を追加する今後のMessagePack仕様に関する議論」GitHub。2022年1月4日時点のオリジナルよりアーカイブ。2022年1月4日閲覧。
- ^ Bormann, Carsten; Hoffman, Paul E. (2020年12月). 「RFC 8949: Concise Binary Object Representation (CBOR)」 . IETF. 2025年1月28日時点のオリジナルよりアーカイブ。 2021年12月26日閲覧。
- ^ Bormann, Carsten; Hoffman, Paul E. (2020年12月). 「RFC 8949: Concise Binary Object Representation (CBOR)」 . 2025年1月28日時点のオリジナルよりアーカイブ。2022年3月25日閲覧。
- ^ Schaad, J. (2017年7月). 「RFC 8152: CBOR Object Signing and Encryption (COSE)」 . 2024年11月16日時点のオリジナルよりアーカイブ。2025年7月4日閲覧。
- ^ジョーンズ、M. Wahlstroem、E.エルトマン、S.チョフェニグ、H. (2018 年 5 月)。「RFC 8392: CBOR Web トークン (CWT)」。2025 年 7 月 4 日に取得。
外部リンク
- CBOR バイナリからテキスト表現へ、またその逆へ変換するオンライン ツール。
- CBOR ゾーン: HEX、Base64、Base64URL、または CBOR 診断表記の形式の CBOR 項目または CBOR シーケンスを別の形式に変換するオンライン ツール。