バイナリ形式をどのようにデバッグしますか？

バイナリビルダーのビルドをデバッグできるようにしたいと思います。現在、私は基本的に入力データをバイナリパーサーに出力し、次にコードを深く掘り下げて、入力から出力へのマッピングを出力し、出力マッピング（整数）を取得して、それを使用して対応する整数を見つけますバイナリで。かなり不格好で、入力と出力の間のマッピングを取得するには、ソースコードを深く変更する必要があります。

さまざまなバリアントでバイナリを表示できるようです（私の場合、入力にかなり近いため、8ビットチャンクで10進数として表示したいと思います）。実際、いくつかの数値は16ビット、いくつかの8、いくつかの32などです。したがって、これらの異なる数値のそれぞれが何らかの方法でメモリ内で強調表示された状態でバイナリを表示する方法があります。

可能なことを確認できる唯一の方法は、実際のバイナリ形式/レイアウトに固有のビジュアライザーを実際に構築する場合です。そのため、32ビット番号がシーケンスのどこにあるべきか、8ビット番号がどこにあるべきかなどを知っています。これは多くの作業であり、状況によっては注意が必要です。だからそれを行う一般的な方法があるのだろうか。

また、現在このタイプのことをデバッグする一般的な方法が何であるか疑問に思っているので、それから何を試すべきかについてのアイデアを得ることができるかもしれません。

アドホックチェックの場合は、標準のhexdumpを使用して、目で見て確認するだけです。

適切な調査のために準備したい場合、私は通常、Pythonのようなもので別のデコーダーを作成します-理想的には、これはメッセージ仕様文書またはIDLから直接駆動され、可能な限り自動化されます（したがって、手動で導入する機会はありません両方のデコーダで同じバグ）。

最後に、既知の正しい定型入力を使用して、デコーダーの単体テストを作成することを忘れないでください。

これを行うための最初のステップは、データの構造、つまりスキーマを記述する文法を検索または定義する方法が必要であることです。

この例は、コピーブックとして非公式に知られているCOBOLの言語機能です。COBOLプログラムでは、メモリ内のデータの構造を定義します。この構造は、バイトの格納方法に直接マップされました。これは、メモリの物理的なレイアウトが開発者から引き離された実装の懸念事項である一般的な現代言語とは対照的に、その時代の言語に共通です。

バイナリデータスキーマ言語を Googleで検索すると、多くのツールが見つかります。例はApache DFDLです。このためのUIもすでに存在する可能性があります。

ASN.1、抽象構文表記法1は、バイナリ形式を指定する方法を提供します。

• DDT-サンプルデータと単体テストを使用して開発します。
• テキストダンプが役立つ場合があります。XMLの場合、サブ階層を折りたたみ/展開できます。
• ASN.1は実際には必要ありませんが、文法ベースのより宣言的なファイル仕様の方が簡単です。

他の回答では、16進ダンプの表示、またはJSONでのオブジェクト構造の書き出しについて説明しています。これらの両方を組み合わせることは非常に役立つと思います。

16進ダンプの上にJSONをレンダリングできるツールを使用すると非常に便利です。dotNetBytesと呼ばれる.NETバイナリを解析するオープンソースツールを作成しました。ここにサンプルDLLのビューがあります。

完全に理解しているとは思いませんが、このバイナリ形式用のパーサーがあり、コードを制御しているようです。したがって、この答えはその前提に基づいています。

パーサーは何らかの方法で、構造体、クラス、または言語のデータ構造を埋めます。ToString解析されるすべてに対してfor を実装すると、そのバイナリデータを人間が読める形式で表示する、非常に使いやすく保守が簡単な方法になります。

基本的に次のものがあります。

byte[] arrayOfBytes; // initialized somehow
Object obj = Parser.parse(arrayOfBytes);
Logger.log(obj.ToString());

そして、それを使用するという見地からです。もちろん、これにはクラス/構造/なんでもToString関数を実装/オーバーライドするObject必要があり、ネストされたクラス/構造/なんでも実装する必要があります。

さらに、条件付きステートメントを使用してToString、リリースコードで関数が呼び出されないようにして、デバッグモード以外でログに記録されないものに時間を浪費しないようにすることができます。

次のToStringようになります。

return String.Format("%d,%d,%d,%d", int32var, int16var, int8var, int32var2);

// OR

return String.Format("%s:%d,%s:%d,%s:%d,%s:%d", varName1, int32var, varName2, int16var, varName3, int8var, varName4, int32var2);

あなたの元の質問は、あなたがこれをやろうと試みたように聞こえますが、この方法は面倒だと思いますが、ある時点でバイナリ形式の解析を実装し、そのデータを保存する変数を作成しました。したがって、必要なことは、適切な抽象化レベル（変数が含まれるクラス/構造）で既存の変数を出力することだけです。

これは、一度だけ行う必要があるものであり、パーサーの構築中に行うことができます。また、バイナリ形式が変更されたときにのみ変更されます（とにかくパーサーへの変更を既に促します）。

同様に、一部の言語には、クラスをXMLまたはJSONに変換するための堅牢な機能があります。C＃はこれが特に得意です。バイナリ形式を放棄する必要はありません。デバッグロギングステートメントでXMLまたはJSONを実行し、リリースコードをそのままにしておきます。

エラーが発生する可能性があるため、16進ダンプルートを使用しないことを個人的にお勧めします（正しいバイトから開始したのか、左から右に読んでいるときに正しいエンディアンを「見ている」など） 。

例：ToStrings吐き出す変数を言いますa,b,c,d,e,f,g,h。プログラムを実行し、でバグに気付きますgが、問題は実際に始まりましたc（しかし、デバッグしているので、まだ理解できていません）。入力値がわかっていれば（そうすべきです）、すぐcに問題が始まることがわかります。

単にあなたに伝える16進ダンプと比較して338E 8455 0000 FF76 0000 E444 ....。フィールドがさまざまなサイズで、どこcから始まり、何が値であるか-16進エディターが教えてくれますが、これはエラーが発生しやすく、時間がかかります。それだけでなく、16進ビューアでテストを簡単/迅速に自動化することはできません。データを解析した後に文字列を印刷すると、プログラムが何を「考えている」かが正確にわかり、自動テストのパスに沿った一歩になります。