Loading article…
簡潔バイナリオブジェクト表現（CBOR）は、Carsten BormannとPaul Hoffmanによって作成された、JSONをベースにしたバイナリデータシリアル化フォーマットです。 [ a ] JSONと同様に、名前と値のペアを含むデータオブジェクトの送信を可能にしますが、より簡潔な方法で行います。これにより、人間の可読性を犠牲にして、処理速度と転送速度が向上します。IETF RFC 8949で定義されています。[ 2 ]
その他の用途としては、 CoAP IoTプロトコルスイート[ 3 ]の推奨データシリアル化レイヤーであり、 COSEメッセージの基となるデータフォーマットです。また、 FIDO2プロジェクトの範囲内でクライアント・ツー・オーセンティケータプロトコル（CTAP）でも使用されています[ 4 ] 。
CBORは、古橋貞之氏によって開発・普及されたMessagePackに触発されたものです。CBORはMessagePackを拡張し、特にテキスト文字列とバイト文字列を区別できるようにしました。これは2013年にMessagePackで実装されました。[ 5 ] [ 6 ]
CBORエンコードされたデータは、データ項目のストリームとして認識されます。各データ項目は、3ビットのタイプと5ビットのショートカウントを含むヘッダーバイトで構成されます。これに続いて、オプションの拡張カウント（ショートカウントが24 ～ 27の範囲内の場合）と、オプションのペイロードが続きます。
タイプ0、1、7の場合、ペイロードはなく、カウントが値となります。タイプ2（バイト列）と3（テキスト列）の場合、カウントはペイロードの長さです。タイプ4（配列）と5（マップ）の場合、カウントはペイロード内のアイテム（ペア）の数です。タイプ6（タグ）の場合、ペイロードは単一のアイテムであり、カウントは囲まれたアイテムを表す数値タグ番号です。
[{"x": 1, "yz": true}, [2, "w"]] --> 82 # 配列(2) A2 # マップ(2) 61 # テキスト(1) 78 # "x" 01 # 符号なし(1) 62 # テキスト(2) 797A # "yz" F5 # プリミティブ(21) 82 # 配列(2) 02 # 符号なし(2) 61 # テキスト(1) 77 # "w" 各データ項目の動作は、主要タイプとカウントによって定義されます。主要タイプは、各データ項目の主な動作またはタイプを選択するために使用されます。
5ビットのショートカウントフィールドは、カウント値0 ～ 23を直接エンコードします。ショートカウント値24 ～ 27は、そのカウント値が後続の8、16、32、または64ビットの拡張カウントフィールドに含まれることを示します。値28 ～ 30は割り当てられておらず、使用してはなりません。
型は、カウントフィールドが値を直接エンコードする「アトミック」型0 ～ 1および6 ～ 7と、カウントフィールドが後続のペイロードフィールドのサイズをエンコードする非アトミック型2 ～ 5に分けられます。
非アトミック型2 ～ 5では、長さが不定であることを示すために、ショートカウント31が使用されます。ペイロードは、ブレークマーカーバイト255（型=7、ショートカウント=31）までの以下の項目で構成されます。ショートカウント31は、他のアトミック型0、1、6では使用できません。
タイプ6（タグ）は、カウントフィールドが値を直接エンコードするだけでなく、ペイロードフィールド（常に単一の項目で構成される）も持つという点で特殊です。
拡張カウントとすべてのマルチバイト値は、ネットワーク（ビッグエンディアン）バイト順でエンコードされます。
整数の場合、count フィールドが値であり、ペイロードはありません。タイプ 0 は、2 64 - 1 までの正または符号なし整数をエンコードします。タイプ 1 は、-2 64 から -1 までの負の整数をエンコードし、値は-1 - countとなります。
タイプ2とタイプ3には、ペイロードの長さをバイト単位でエンコードするカウントフィールドがあります。タイプ2は非構造化バイト文字列です。タイプ3はUTF-8テキスト文字列です。
短いカウント値31は、長さが不定の文字列を示します。その後に、同じタイプの長さが定定の文字列が0個以上続き、最後に「ブレーク」マーカーバイトで終了します。項目の値は、囲まれた項目の値を連結したものです。異なるタイプの項目、またはネストされた長さが不定の文字列は許可されません。テキスト文字列は個別に整形式である必要があり、UTF-8文字は項目間で分割できません。
タイプ4には、後続する項目の数をエンコードするカウントフィールドがあり、その数だけ項目が続きます。項目はすべて同じタイプである必要はありません。プログラミング言語によっては、これを「配列」ではなく「タプル」と呼ぶ場合もあります。
あるいは、短いカウント値31の不定長エンコーディングを使用することもできます。これは、255の「ブレーク」マーカーバイトに到達するまで続きます。ネストされた項目も不定長エンコーディングを使用する可能性があるため、パーサーはブレークマーカーと対応する不定長ヘッダーバイトをペアにする必要があります。
タイプ5は似ていますが、キーと値のペアのマップ（辞書、または連想配列とも呼ばれます）をエンコードします。この場合、countはアイテムのペアの数をエンコードします。不定長エンコーディングを使用する場合は、「break」マーカーバイトの前に偶数個のアイテムが存在する必要があります。
セマンティックタグは、カウントが値となる別のアトミック型ですが、ペイロード（後続の単一の項目）も持ち、配列やマップなどでは、この2つは1つの項目として扱われます。
タグ番号は、3ビットのメジャータイプが提供できる情報に加えて、後続の項目に関する追加のタイプ情報を提供します。たとえば、タグが1の場合、後続の数値はUnixタイム値であることを示します。タグが2の場合、後続のバイト列は符号なし多倍長整数をエンコードしていることを示します。タグが32の場合、後続のテキスト文字列はRFC 3986で定義されているURIであることを示します。RFC 8746では、固定サイズの整数または浮動小数点値の同種配列をバイト列としてエンコードするために、タグ64 ～ 87が定義されています。
タグ55799は「CBORデータが続く」という意味で割り当てられています。これは意味的には何もしない操作ですが、対応するタグバイトをCBORファイルの先頭に追加しても、その意味に影響を与えません。これらのバイトは、CBORデータの開始を区別するための「マジックナンバーd9 d9 f7」として使用できます。
すべて1のタグ値0xffff、0xffffffff、および0xffffffffffffffffは、CBORデコードライブラリにタグが存在しないことを示すために予約されています。これらはデータストリームに決して出現してはなりません。
ブレークマーカー擬似アイテムは、タグのペイロードではない可能性があります。
この主要型は、他のカテゴリに当てはまらない様々な特殊値をエンコードするために使用されます。エンコードサイズに関するルールは他の原子型（0、1、6）と同じですが、カウントフィールドの解釈が異なります。
0 ～ 19の値は現在定義されていません。
値 20 ～ 23 は、特殊値false、true、null、 をエンコードするために使用されますundefined。
24という短いカウントは、1バイトの拡張カウントが続くことを示しており、これは将来的に追加の特殊値をエンコードするために使用できます。デコードを簡素化するため、0 ～ 31の値はこの形式でエンコードされない場合があります。32 ～ 255の値は現在定義されていません。
25、26、または27の短いカウントは、後続の拡張カウントフィールドが（ビッグエンディアンの）16ビット、32ビット、または64ビットのIEEE浮動小数点値として解釈されることを示します。これらは拡張カウントと同じサイズですが、解釈が異なります。特に、他のすべての主要な型では、2バイトの拡張カウント0x1234と4バイトの拡張カウント0x00001234は完全に等価です。これは浮動小数点値には当てはまりません。
28 ～ 30の短いカウントは、他の主要なタイプと同様に予約されています。
短いカウント値31は、不定長エンコーディングを終了させる特殊な「ブレーク」マーカーを表します。これは、短いカウント値31が不定長エンコーディングの開始を示す他の主要タイプでの使用法と関連していますが、異なります。これは項目ではなく、定義長ペイロードには含まれません。
IANAはCBORタグレジストリを作成しました。レジストリはhttps://www.iana.org/assignments/cbor-tags/cbor-tags.xhtmlにあります。登録には、以下に概説するテンプレートを含める必要があります。[ 7 ]
DAG -CBOR仕様は、 Protocol Labsによって開発されたCBORのより厳密なサブセットです。DAG-CBORが解決する問題は、CBORではオブジェクトが複数の方法でシリアル化される可能性があることです。たとえば、{"b":1,"a":2}は次のように表現できます。
A2 # マップ(2) 61 # テキスト(1) 62 # "b" 01 # 符号なし(1) 61 # テキスト(1) 61 # "a" 02 # 符号なし(2) または
A2 # マップ(2) 61 # テキスト(1) 61 # "a" 02 # 符号なし(2) 61 # テキスト(1) 62 # "b" 01 # 符号なし(1) これは、1 つのオブジェクトが 2 つの異なるシリアル化を持つ可能性があることを意味します。DAG-CBOR 仕様は、オブジェクトのすべての可能な CBOR 表現の中から、一意の 1 つの CBOR 表現を選択します。CBOR 表現を持つことができるオブジェクトの中には、その性質上一意の表現が許されないため、DAG-CBOR 表現を持たないものがあります。たとえば、不定長のアイテム (文字列、バイト シーケンス、リスト、マップなど) は、CBOR 表現を持つことができますが、DAG-CBOR 表現は持ちません。[ 8 ]
DAG-CBOR仕様では、一貫性のあるコンテンツアドレス指定可能なストレージが実現されます。具体的には、データはバイト列として一意にシリアル化され、このバイト列はハッシュ化されてコンテンツID（CID）として使用され、コンテンツアドレス指定に利用できます。
「DAG」という名称は「有向非巡回グラフ」を意味し、この仕様は特にマークルDAGの形式のデータオブジェクトを可能にするために作成されたものです。
CBORオブジェクト署名および暗号化（COSE ）は、認証済みおよび/または暗号化されたCBORデータ構造のバイナリ形式です。[ 9 ]
CBOR Webトークン（CWT）は、シリアル化フォーマットとしてCBORを使用する署名付きトークンです。これらはJSON Webトークン（JWT）の代替手段です。[ 10 ]