出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2026/02/26 15:17 UTC 版)
|
|
この記事は英語版の対応するページを翻訳することにより充実させることができます。(2025年3月)
翻訳前に重要な指示を読むには右にある[表示]をクリックしてください。
|
| ファイル拡張子 |
.cbor
|
|---|---|
| インターネットメディアタイプ |
application/cbor
|
| フォーマットの種類 | データ交換 |
| 拡張元 | MessagePack |
| 標準 | RFC 8949 |
| オープンフォーマット? | はい |
| ウェブサイト | cbor.io |
Concise Binary Object Representation(CBOR)は、JSONを大まかにベースとしたバイナリデータのシリアライズフォーマットである[注釈 1]。Carsten BormannとPaul Hoffmanが設計した。CBORは、JSONのように名前と値のペアを含むデータオブジェクトの転送を可能にするが、より簡潔な方法で表現される。これにより、人間可読性を犠牲にする代わりに、処理と転送の速度が向上している。IETFの RFC 8949で定義されている[2]。
他の用途の中でも、CoAP Internet of Thingsプロトコルスイート[3][出典無効]の推奨データシリアライズレイヤーや、COSEメッセージの基礎となるデータフォーマットである。また、FIDO2プロジェクトの範囲内では、Client-to-Authenticator Protocol(CTAP)でも使用されている[4]。
CBORは、古橋貞之により開発・促進されたMessagePackに触発されたもので、特にテキスト文字列とバイト文字列を区別できるように拡張されている[5][6]。
CBORでエンコードされたデータはデータアイテムのストリームとして表される。各データアイテムには、3ビットのタイプ(type)と5ビットのショートカウント(short count)からなるヘッダーバイトが含まれる。その後に、(ショートカウントが24-27の範囲の場合)オプションの拡張カウント(extended count)と、オプションのデータペイロード(data payload)が後続する。
タイプ0、1、7の場合、ペイロードは存在せず、カウント自体が値となる。タイプ2(バイト文字列、byte string)とタイプ3(テキスト文字列、text string)の場合、カウントはペイロードの長さとなる。タイプ4(配列、array)とタイプ5(マップ、map)の場合、カウントはペイロード内のアイテム数(ペアの数)である。タイプ6(タグ、tag)の場合、ペイロードは単一のアイテムであり、カウントは格納されたアイテムを記述する数値タグ番号(numeric tag number)となる。
| CBORデータ | データアイテム1 | データアイテム2 | データアイテム3... | ||||||
|---|---|---|---|---|---|---|---|---|---|
| バイト数 | 1 バイト(CBORデータアイテムヘッダー) | 可変数 | 可変数 | 1 バイト(CBORデータアイテムヘッダー) | 可変数 | 可変数 | etc... | ||
| 構造 | 主要タイプ | ショートカウント | 拡張カウント(オプション) | データペイロード(オプション) | 主要タイプ | ショートカウント | 拡張カウント(オプション) | データペイロード(オプション) | etc... |
| ビット数 | 3 ビット | 5 ビット | 8 ビット × 可変数 | 8 ビット × 可変数 | 3 ビット | 5 ビット | 8 ビット × 可変数 | 8 ビット × 可変数 | etc.. |