Kaitai Structで私の最初のステップを踏んで、私はエクササイズとしてBSONパーサーをやろうとしていました。 BSON要素を解析する私の.ksyコードは、次のようになります。Kaitai Structでオペコードを解析する
element:
seq:
- id: el_type
type: u1
enum: bson_type
- id: el_name
type: strz
encoding: UTF-8
if: el_type != bson_type::end_of_document
- id: el_string
type: bson_string
if: el_type == bson_type::string
- id: el_document
type: bson_document
if: el_type == bson_type::document
- id: el_boolean
type: u1
if: el_type == bson_type::boolean
- id: el_int32
type: s4
if: el_type == bson_type::int32
- id: el_int64
type: s4
if: el_type == bson_type::int64
enums:
bson_type:
0: end_of_document
1: double
2: string
3: document
8: boolean
0x10: int32
0x12: int64
気付いたことがあるように、繰り返しがたくさんあります。 1つは、追加の要素タイプを実行するたびにブロックif
をブロックするだけです。さらに悪いことに、基本的には、このようなフィールドに3回物を複製する必要があります。
- id: el_string # <= string!
type: bson_string # <= string!
if: el_type == bson_type::string # <= string!
私のターゲット言語はJavaです。あなたは、自動的に「接頭辞」の値に基づいて、これら2つの要素を取得
あり@Choices(prefixSize = 8, alternatives = {
@Choice(condition = "prefix==0x01", type = FloatNamedElement.class),
@Choice(condition = "prefix==0x02", type = UTF8NamedElement.class)
}
private NamedElement elements;
:解体する前に、私は唯一のPreonを試みたが、そこにきた私たちは、次のような条項を持っていました。 Kaitaiでそれをすることは可能ですか?
興味深いことに、Preonは、出荷時に出荷されているコーデックを検討している場合を除き、すべてが限定されています。拡張性は、実際にはPreonが作成された主な理由の1つです。既存のフレームワークのどれも、私たちが実行していたすべてのユースケースに適合するほど拡張性がないためです。あなたが取り組もうとしている問題が何であれ、私はあなたが 'Codec'、' CodecFactory'、おそらくそれを可能にするいくつかの注釈を加えることによってPreonを拡張できると確信しています。 –
こんにちは、@ WilfredSpringer、お会いしてうれしい!自分の「コーデック」とそれに似たクラスをPreonに書き込むことは技術的に「宣言的」な土地から「命令的な」土地に移動させます。文字通り手書きでストリームを読み書きするコードを書いています。 Preonを「限定」と呼んでいるのは、私のここの唯一のポイントでした。それがあなたを怒らせたら、すみません、申し訳ありません。一方、Kaitai Structには、このような質問が出されてから多くの時間が経過しました。 – GreyCat
心配はありません。 ;-)私はPreonが宣言的能力を拡張できると思う。単一のインタフェースを実装することでPreonの新しいバージョンを作成し、将来のユーザーが宣言的な方法でその新しい機能を活用できるようにします。 –