テクニック。識別データ数を減らす!
今までのデータ作成では、1つのヘッダーに対して、それぞれ1つずつ
それに対応するヘッダー定義を作成しました。
しかし、たとえば「CAB」「GCA」などはどちらもヘッダー領域がファイルの
先頭0バイト目から3バイトです。
このような場合は、ヘッダー定義を1つだけ作成し、どちらの識別にも同じヘッダー定義
を利用することが出来ます。
これをすることによって、識別データセットのサイズをヘッダー定義1つ分に節約出来ます。
ダイノロジカルでファイルとそのヘッダー情報を直接結び付けないのは、
このようにして、ヘッダー情報を再利用しファイルサイズを節約するためです。
しかし、説明した「CAB」と「GCA」の例のように、ヘッダー領域が完全に一致しないまでも
似ているという場合があります。
たとえばそれは、「ZIP」と「PDF」です。
ZIPのバイナリデータは、ファイルの先頭から「PK.....」となっています。
PDFのバイナリデータは、ファイルの先頭から「%PDF-1.2」となっています。
それぞれ、ヘッダー領域は「PK」と「PDF」であることが推測できます。
ですが、ヘッダーの場所が違います。
しかし、ここでそれぞれ別のヘッダー定義を作成してしまわないで、
バイナリモードのフィルタリング機能を使うことによって、どちらも1つのヘッダー定義で
場所を指定することが出来ます。
"バイナリモード編"で説明したように、バイナリモードのフィルタリング機能を用いることによって
指定領域内から取得したい文字の種類(ローマ字、数字など・・)を選ぶことが出来ます。
つまり、この例の場合は「取得するヘッダー領域を"HOF"の"0"バイト目から"7"バイト」ぐらいの場所に
置き、このままだとZIP,PDFそれぞれのヘッダー位置を指定していないので、「ローマ字」のみフィルタリング
する機能をチェックすることによって、1つのヘッダー定義で両方のファイル形式に対応することが出来ます。
また、これとは別に
ダイノロジカル本体側の機能ですが、識別処理(識別ベースライン)で連続して同じヘッダー定義
を使用した場合、1つめの処理以降はほとんどの処理が同じものとして省略されます。
これは、少しでも効率化・高速化するための機能ですが、これにより他のファイルと同様なファイル識別でも、
殆どメモリアクセスぐらいの処理速度だけで識別できる場合があります。