つまり、バイナリデータシリアライザーを備えたマイクロコンピューター用のミニチュアライブラリと、それに続く低速通信回線を介したこれらのメッセージの送信が必要でしたが、通常の形式はxml、json、bson、yaml、protobuf、Thrift、ASN.1などです。さまざまな理由で適合しませんでした。
予想通り、解決策はバイク以上のものであることが判明しましたが、それでも、ハブレに関する記事の公開自体が私を大いに助けてくれました。事実、可能なライブラリの初期分析中に、何らかの理由で、MessagePack、CBOR、およびUBJSONシリアライザーを見落としていました。
それらへのリンクは、記事の公開後のコメントで私に書かれました。そして、私はすぐに、おそらく CBOR、 UBJSONが目の前の問題を簡単に解決できることに気づきました。そして、彼らは私自身の開発よりもはるかにうまくやっています。
その後、（ソースを押しつぶさないように）CBORライブラリへのインターフェイスをねじ込み 、...メッセージパックを優先してこの形式を放棄することにしました :-)
CBOR対。MessagePack
実際、 CBOR形式と MessagePack形式は、同じ原理のデータシリアル化を使用します。これらは執筆の実用的な方法に基づいている TLVを古典的な形で、TLVは、常にタグフィールドとデータ長フィールドが含まれていることを唯一の例外で、。ただし、データ自体を含むフィールドが存在しない場合があります（データサイズがゼロの場合）。
そして、これらのシリアライザーでは、開発者はさらに進んで、データサイズのフィールドの存在がデータタイプに依存し、固定サイズのフィールドには必要ない、ほぼ独創的なフォーマットを作成しました。最初のバイトには、データサイズのフィールドのタイプとその直接の両方が格納されます。値（もちろん、ビットの深さが許せば）。
元の 記事では、バイナリデータを最大限にパッキングする必要があるという事実について書きましたが、これらの形式はどちらもこのタスクに大いに対処します。それらは互いに非常に似ており、フィールドタイプの値が格納されているビット数のみが異なります。
CBOR形式では、各フィールドの最小ストレージオーバーヘッドは3ビットです。各フィールドの最初のバイトでは、最初の3ビットがコンテンツタイプを担当し、それに応じて、他のフィールドの存在とサイズが解釈され、残りの5ビットにはすでにフィールド値自体が含まれている場合があります。
しかし、MessagePackはさらに進んだ！この形式では、値の最小ストレージオーバーヘッドはわずか 1（ONE！）です。ちょっとした情報。したがって、7ビットを使用して追加情報を格納でき、最上位ビットが設定された値を使用して、フィールドタイプに関する追加情報を示します。
このエンコード方法では、正の数が原因で負の値の表現範囲が狭くなることは明らかです（1バイトに格納できる負の数は32個のみで、他の値には2番目のバイトが必要です）。しかし、これは正しい不均衡であり、正しい方向にシフトしているためです。実際には、正の数は負の数よりもはるかに頻繁に使用されます。
言い換えれば、CBOR形式の1バイトでは、0から23までの整数値が適合し、MessagePack形式では0から127までです！
この瞬間と、12の異なる言語でフォーマットが実装された通常のライブラリが、MessagePackフォーマットを支持する最終的な選択を決定しました。これらのフォーマットの実装の詳細に興味を持っているのは私だけではないと思うので、この情報を共有するのは正しいと思います。
その結果、シリアライザーの元の形式は、いくつかの規則（たとえば、エンコードされたデータの構造をフラットリストのみに制限し、要求されていないタイプの使用を拒否する必要があるなど）を含めて、さらにコンパクトになり、私の睡眠は落ち着きました。デバイス間で転送されるメッセージのフォーマットレベルでの互換性に関する問題はなくなりました。
Habraユーザーに感謝します スピム そして edo1hそれは前の投稿に応答し、したがって、そのような小さな努力で本当に深刻な問題の解決策を見つけるのに役立ちました！
一次情報源：
CBOR仕様 。Habréに関する説明のある良い記事があり ます。
MessagePack仕様はドキュメントで非常に読みやすく 、翻訳や追加の説明は必要ありません。