メインコンテンツまでスキップ

付録 E. 他のバイナリ形式と CBOR の設計目標との比較

CBOR の提案は、コンピュータ自体の歴史と同じくらい長いバイナリ形式の歴史を受け継いでいます。異なる形式は異なる目標を持っていました。ほとんどの場合、その形式の目標が表明されることはありませんでしたが、その形式が最初に使用された文脈から推測できることもあります。普遍的に使用できることを意図した形式もありましたが、すべてのプロトコルとアプリケーションのニーズを満たすバイナリ形式は存在しないことが歴史によって証明されています。

CBOR は、目標の集合から出発し、まさにそれらを満たそうとすることにおいて、これらの形式の多くと異なります。このセクションでは、何十もある形式のうちのいくつかを CBOR の目標と比較し、特定のプロトコルやアプリケーションに CBOR と別の形式のどちらを使いたいかを読者が判断する助けとします。

ここでの議論は、どの形式に対する批判も意図していないことに注意してください。私たちの知る限り、CBOR 以前のどの形式も、私たちが割り当てた優先順位で CBOR の目標をカバーすることを意図したものではありませんでした。セクション 1.1 の目標の簡単な要約は次のとおりです:

  1. インターネット標準の最も一般的なデータ形式の曖昧さのないエンコーディング

  2. エンコーダーまたはデコーダーのコードのコンパクトさ

  3. スキーマ記述が不要であること

  4. 合理的にコンパクトなシリアライゼーション

  5. 制約のあるアプリケーションと制約のないアプリケーションの両方への適用可能性

  6. 良好な JSON 変換

  7. 拡張性

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. UBJSON​

  • [UBJSON] は、JSON が使用するデータモデルに厳密に限定されたバイナリ形式を使用して、JSON をより高速かつやや小さくするという設計目標を持っています。したがって、例えばバイナリデータをサポートする意図は明確にありません。ただし、JSON 構文の文字列として表現される「高精度数値」は存在します。UBJSON はコードのコンパクトさのために最適化されておらず、そのタイプバイトのコーディングは人間の認識のために最適化されており、小さな整数のようなネイティブ型のコンパクトな表現のためではありません。UBJSON はほとんどがカウント付きですが、配列やマップ (JSON オブジェクト) のストリーミングをサポートするために、予約された "unknown-length" 値を提供しています。これらのコンテナ内では、UBJSON はパディングのための "Noop" タイプも持っています。

E.5. MSDTP: RFC 713​

Message Services Data Transmission (MSDTP) は、コンパクトなメッセージ形式の非常に初期の例です。1976 年に書かれた [RFC0713] で説明されています。ここに含めるのは歴史的価値のためであり、広く使われたことがあるためではありません。

E.6. 回線上の簡潔さ​

エンコーダーおよびデコーダーのコードのコンパクトさという CBOR の設計目標は、回線上の簡潔さという目標より優先されますが、多くの人々は回線上のサイズに注目します。表 6 は、単純なネストされた配列 [1, [2, 3]] のエンコーディング例をいくつか示しています。そのエンコーディングが何らかの不定長エンコーディングをサポートしている場合、[_ 1, [2, 3]] (外側の配列が不定長) も示されます。

形式[1, [2, 3]][_ 1, [2, 3]]
RFC 713c2 05 81 c2 02 82 83
ASN.1 BER30 0b 02 01 01 30 06 02 01 02 02 01 0330 80 02 01 01 30 06 02 01 02 02 01 03 00 00
MessagePack92 01 92 02 03
BSON22 00 00 00 10 30 00 01 00 00 00 04 31 00 13 00 00 00 10 30 00 02 00 00 00 10 31 00 03 00 00 00 00 00
UBJSON61 02 42 01 61 02 42 02 42 0361 ff 42 01 61 02 42 02 42 03 45
CBOR82 01 82 02 039f 01 82 02 03 ff

表 6: さまざまな簡潔さのレベルの例