CBOR-新しいバイナリデータ表示形式

簡潔なバイナリオブジェクト表現 （ オブジェクトの 圧縮バイナリ表現 ）は、最も単純な実装コード、コンパクトな出力データの形成、およびバージョン情報の交換を必要とせずに形式を拡張する可能性を提供するように設計されたデータ形式です。



CBOR形式標準は、 Carsten BormannとPaul Hoffmanによって作成された新しいRFC 7049で2013年10月にIETFによって公式に発表されました。 最初の著者の名前を見ると、形式の名前の略語の起源の別の理由を推測できますが、それは単なる偶然かもしれません。 CBOR形式は、MIMEタイプapplication / cborを受け取りました。



現時点では、おそらく構造化データを表現するためのあらゆる種類のバイナリ形式が数百種類あり、その一部は標準化され、人気があり、広く使用されています（たとえば、ASN.1のBERおよびDER、MessagePackおよびBSON）。 既存の標準はすべてそのタスクを解決し、CBORも例外ではありません。 このフォーマットには7つの重要な要件が提示されましたが、既存のフォーマットはどれもそれらを完全に満たすことができなかったため、新しいフォーマットが作成されました（はい、これは画像を頼みます ）

新しいバイナリ形式の要件

1. インターネットで人気のあるほとんどのデータ型標準の明確なコーディング。
   
   この形式は、バイナリ表現を使用して基本的なデータ型と構造をエンコードできる必要があります。 同時に、絶対にすべてのデータ型に対して一意のコーディングを行う必要はありません。たとえば、数字7は文字列としても全体としても表現できます。
2. エンコーダ/デコーダのコンパクトな実装。これにより、プロセッサの機能と利用可能なメモリサイズを必要としない実装を作成できます。
   
   この形式では、お馴染みの形式の機械実装を使用する必要があります（たとえば、整数または浮動小数点数-IEEE 754）
3. 説明スキームの欠如。
   
   また、JSON形式は提示されたデータ（オブジェクト、配列、文​​字列など）を自己記述します。 記述スキームがないため、シンプルで汎用的なデコーダーを作成できます。
4. データのシリアル化は可能な限りコンパクトにする必要がありますが、（de）エンコーダーの作成が簡単になるという犠牲はありません。
   
   エンコードされたデータのボリュームの上のバーについては、JSON形式のプレゼンテーションボリュームが使用されます。
5. この形式は、リソースが限られているアプリケーションと大量のデータを扱うアプリケーションの両方に等しく適用できるはずです。
   
   これは、データをエンコードおよびデコードするときに、実装がCPUに対して同様に節約する必要があることを意味します。
6. JSONとの間でデータを変換するには、形式がJSONのすべての既存のタイプをサポートする必要があります。
7. 形式は拡張可能である必要があり、高度な形式は以前のバージョンのデコーダーで正常にデコードされている必要があります。
   
   このフォーマットは何十年も使用され、同時に下位互換性を維持するため、フォーマット標準の将来のバージョンは、以前のバージョンのデコーダーで通常処理できると想定されています。 そのため、未知の拡張子が見つかった場合でも、メッセージをデコードできます。

要件からわかるように、CBORはJSONデータモデルに焦点を当てていますが、これに限定されず、一般的なデータ型を追加し、将来的にフォーマットを拡張できます。

CBOR仕様

形式がタスクをどの程度うまく解決するかを理解し、それを他の形式と比較できるようにするために、CBOR形式でデータをエンコードするプロセスを検討してください。



各データ項目は、データの主要なタイプの説明と追加情報を含むバイトで始まります。 メインタイプは3つの最上位ビットを占有し、0〜7の値を持つことができます。追加情報は0〜31の値を受け取ることができます。







図からわかるように、追加情報の値で3つの条件範囲が強調表示されています。

1. 値が0〜23の場合、この値は整数として直接使用されます。 たとえば、メインタイプが整数の場合、追加情報の値は要素の値です。 メインタイプが文字列の場合、この数値は文字列の長さを示します。
2. 値が24〜27の場合、後続のバイトには可変長の整数が含まれ、それぞれ1バイト、2バイト、4バイト、および8バイトの非負整数です。 たとえば、メインタイプが整数の場合、次のバイトにはその値が含まれ、文字列の場合には-その長さが含まれます。
3. 値31は特別であり、要素の長さが定義されていないことを示します。 たとえば、文字列の場合、これは文字列の長さが不明であることを意味します。

値28〜30は、標準の将来のバージョン用に予約されています。



例で既に示したように、メインタイプの値に応じて、追加情報の意味は異なる意味を取ります。 基本的なデータ型を検討してください。

タイプ0：非負整数

追加情報には数値の値が含まれます（24未満の場合）。その他の場合、追加情報に続く整数のサイズが示されます。 24がuint8_t



、25がuint16_t



、26がuint32_t



、27がuint64_t



。



たとえば、数値16は0x10



でエンコードされ、数値500は3バイトのシーケンス0x01f4



（500）でエンコードされます

タイプ1：負の整数

値はタイプ0との類推によってエンコードされますが、唯一の違いは絶対値から1を引くことです。 たとえば、-16は0x2F



でエンコードされ、数値-500は0x01f3



（499）です

タイプ2：バイト文字列

バイト文字列の場合、追加情報は文字列の長さをバイト単位でエンコードします。 たとえば、16バイトのバイト文字列の場合、 0x50



（タイプ2、値16）でエンコードされ、その後にバイト文字列を含む16バイトが続きます。 また、500バイトの文字列の場合、3バイトのヘッダー： 0x59



（タイプ2、値25）、 0x01f4



（500）、その後に続く500バイトの文字列データ。

タイプ3：テキスト文字列

テキスト文字列は、UTF-8でエンコードされたUnicode文字列です。 バイト文字列と同様に、追加情報は文字列の長さをバイト単位でエンコードします。 JSON形式とは異なり、テキスト文字列には\n



や\u000a



などの形式のシンク転送文字をエスケープする必要はありません。

タイプ4：要素の配列

文字列のタイプと同様に、追加情報は配列の長さを示しますが、バイト単位ではなく要素数で示します。 配列内の要素は同じ型である必要はなく、文字列、数値などのセットにすることができます。 ヘッダーの後、配列の要素がすぐに続きます。 たとえば、配列[0,"A"]



は次のようにエンコードされます。

 82 -   2- , 00 -   0, 61 -    1 , 41 - "A"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タイプ5：ペアマップ（連想配列、ハッシュ、辞書、JSONオブジェクト...）

このタイプは、「キー」-「値」のペアで構成されるカードを定義します。 追加情報により、このようなペアの数が決まります。 たとえば、9ペアのカードは0xa9



（タイプ5 +値9）としてエンコードされ、その後に9ペアの要素（最初のキー、最初の値、2番目のキーなど）が続きます。 キーにはさまざまなタイプがありますが、原則として、これが要求されることはほとんどありません。

タイプ6：他の基本タイプのセマンティックタグ付け

このタイプは、標準を拡張するための幅広い可能性を開きます。 追加情報は、0〜18446744073709551615のタグの範囲を定義する整数タグ番号を設定します。タグは、基本タイプの特定の表現を参照し、サポートされるデータタイプを無制限に拡張できます。



たとえば、標準では、タグ0がRFC 3339（RFC 4287で修正された）で説明されている形式で日時テキスト文字列を定義することを明確に規定しています。 たとえば、時刻1970-01-01T00:00Z



をエンコードすると、 1970-01-01T00:00Z



になります。

 0 -    0 71 -    17  31 39 37 30 2d 30 31 2d 30 31 54 30 30 3a 30 30 5a -   1970-01-01T00:00Z
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タグ0の意味が分からなくても、タグの後に基本タイプ3の要素（テキスト文字列）が続くため、データをデコードできることに注意してください。



現時点では、標準によっていくつかのタグが定義されており、IANAはタグのリストのメンテナンスを行っています。現在の分布はここで確認できます



タグ55799を個別に注目する価値があります。つまり、CBOR形式のデータはさらに進んでいます。 実際、ペイロードを運んでいませんが、たとえば、データをCBOR形式でファイルに保存する場合、このタグは最初にシーケンス0xd9d9f7



を形成します。これは、ファイルタイプを判断するためのマジック値としてユーティリティによって使用できます。 さらに、このシーケンスは既存のUnicodeエンコーディングには見られないため、CBORとテキストデータをすばやく区別できます。

タイプ7：浮動小数点数およびその他の単純なデータ型

このタイプでは、単純な値と浮動小数点数を記述することができます。 追加情報には、次の意味上の意味があります。

• 0..23-単純な値（0〜23のコード）
• 24-単純な値（コード24〜255）
• 25-IEEE 754半精度浮動小数点数（16ビット）
• 26-IEEE 754単精度浮動小数点数（32ビット）
• 27-IEEE 754倍精度浮動小数点数（64ビット）
• 28-30-未定義
• 31-長さが不定の要素の停止コードブレーク（ブレーク）

この規格は、単純な値のいくつかのコードを定義しています。

• 20-偽
• 21-真
• 22-ヌル
• 23-未定義

他の単純な値もIANAによって登録されています 。現在、単純な値のリストはここで入手できます 。

一部の基本型の未定義の要素の長さ

4つの基本タイプ：配列、マップ、バイト、およびテキスト文字列には、要素の未定義の値（追加情報で31の値で指定される）を含めることができます。 これにより、番号がまだ不明な要素のエンコードを開始できます。 これは、データをストリーミングするアプリケーションで必要になる場合があります。



配列とマップの場合、要素は次々に続き、割り込み停止コードを使用して完了を示します。 配列またはマップの最後の要素の直後に、タイプ7の要素に追加情報31が続きます-これはバイト0xFF



です。



文字列の場合、別のアプローチが使用されます。 文字列は有限長の部分で送信され、後で1行に結合されます（これはデコーダーと最終アプリケーションの両方で実行できます）。 行の部分のシーケンスの完了のインジケータは、割り込み0xFF



です。 テキスト文字列の場合、フラグメントを転送するとき、Unicode文字コードシーケンス内で行分割が発生しないことが重要です。 文字列のすべての部分には、有効なUnicode文字シーケンスが含まれている必要があります。



例：

 5F --      44 --    4  aabbccdd --    43 --    3  eeff99 --    FF -- "break"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デコード後、すべてのフラグメントは1行に結合されます： aabbccddeeff99

正規形式の実装

CBOR標準では、同じ入力で異なる実装が同じ出力を生成できるようにするいくつかのルールを定義しています。 ただし、アプリケーションの特定の要件がある場合、標準からの逸脱を許可することは許可されますが、これが作成されるドキュメントの有効性に通常違反しない場合は許可されます。

• エンコードされたデータに最も簡潔な表現を使用します。 たとえば、整数500がエンコードされている場合、たとえばuint16_t
  
  
  
  ではなく、 uint16_t
  
  
  
  の表現をuint16_t
  
  
  
  必要があります。 数値0.0
  
  
  
  エンコードする場合0.0
  
  
  
  エンコーダは整数型に変換する必要があります。これにより、より簡潔な表現が得られます。 浮動小数点数を有効ビットを失うことなく単精度で表現できる場合、エンコーダは倍精度などを使用しないでください。
• 連想配列のキーは昇順でソートする必要があります（バイトソート、短いキーが最初になります）
• 可能であれば、不定長の要素は固定長に置き換えられます。
• 正規の実装ではタグを使用すべきではありませんが、タグを使用してデータを処理する場合は、タグを保存する必要があります

エラー処理

CBOR規格では、形式のエラーを処理するための異なるアプローチが許可されています。 エラーは、形式自体（追加情報の不明な値、単純な値、配列要素の不正な数など）と値（たとえば、テキスト文字列の無効なUTF-8コードまたは連想配列の重複キー）の両方に関連付けることができます。 ）



デコーダは、不正なデータに対して警告を発行したり、変換を行ってエラーを修正したり、エラーを無視したり、最初のエラーが検出されたときに処理を直ちに停止したりできます。 規格では、データが信頼できないソースからのものである場合に、厳密（ strict ）モードの使用を提案しています。その場合、デコーダは、検証に合格しなかった、または異なるデコーダによって異なる解釈が可能なすべてのデータを拒否する必要があります。 ルースモードは、信頼できるソースからのデータと処理速度がより重要な場合に使用されます（たとえば、UTF-8行の有効性を確認しないでください）。

他のバイナリ形式との比較

標準のテキストは、配列がさまざまな既存の形式でエンコードされる方法に関する比較表を提供します。 最初の配列は、ネストされた配列を持つ2つの要素で構成されます。 不定長の2番目の配列（これには条件シンボル_



使用されます）には、（有限長の）ネストされた配列も含まれます。

 +---------------+-------------------------+-------------------------+ | Format | [1, [2, 3]] | [_ 1, [2, 3]] | +---------------+-------------------------+-------------------------+ | RFC 713 | c2 05 81 c2 02 82 83 | | | | | | | ASN.1 BER | 30 0b 02 01 01 30 06 02 | 30 80 02 01 01 30 06 02 | | | 01 02 02 01 03 | 01 02 02 01 03 00 00 | | | | | | MessagePack | 92 01 92 02 03 | | | | | | | BSON | 22 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 | | | | | | | UBJSON | 61 02 42 01 61 02 42 02 | 61 ff 42 01 61 02 42 02 | | | 42 03 | 42 03 45 | | | | | | CBOR | 82 01 82 02 03 | 9f 01 82 02 03 ff | +---------------+-------------------------+-------------------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、MessagePackとCBORは最もコンパクトな表現ですが、BER、UBJSON、CBORのみが無限シーケンスをエンコードする機能を持っています。

既存のCBOR実装

標準のリリース直後に、さまざまなプログラミング言語での（de）エンコーダーの最初の実装が登場し始めました。 たとえば、 C 、 Perl 、 Ruby 、 Python 、 Java 、 Go、およびその他の多く（githubをすぐに見て、JavaScriptの実装はまだ見つかりませんでしたが...）



これらの実装のすべてが標準を完全にサポートしているわけではなく、おそらくもっと多くの実装が存在するか、今後登場します。 これにより、標準の主な目標が達成されたことを完全に確認できます。（de）エンコーダーの実装は、それほど複雑ではありません。 インタビューですぐに、プログラマーはテストタスクとして緩いCBORデコーダーを実装するように求め始めるでしょう。



PSテキストに誤り、タイプミス、または不正確を見つけた場合、私に知らせてください、私はそれを修正します。