3

Visual FoxProコンパクトインデックス（* .IDX）のファイル形式を理解しようとしています。現在、ガイダンスとしてMicrosoftのドキュメントを参照しています。

インデックスは512バイトノードのBツリーです。各リーフ（「外部」）ノードには、複数のエントリが含まれています。各エントリは、次の4つのデータで構成されています。

  • 行番号[固定長]
  • 重複するバイト数（ドキュメントではこれを説明していません）[固定長]
  • 末尾のバイト数（ドキュメントではこれを説明していません）[固定長]
  • キー[可変長]

エントリ（キーなし）は、ノードの先頭、ノードの24バイトヘッダーの直後に格納されます。キーの長さが異なるため、これらのキーはこの場所に含まれていませんが、行番号、重複バイト数、および後続バイト数は長さが固定されています。キーはノードの最後に保存され、逆方向に機能します。例えば：

  • 24バイトのヘッダー
  • 行番号、重複バイト数、後続バイト数（エントリー＃1）
  • 行番号、重複バイト数、後続バイト数（エントリー＃2）
  • 行番号、重複バイト数、後続バイト数（エントリー＃3）
  • ..。
  • キー（エントリ＃3）
  • キー（エントリ＃2）
  • キー（エントリ＃1）

キーの個々の長さを決定するにはどうすればよいですか？ドキュメントにはこれを指定していないようです。それらは完全に隣接しています（ヌルバイト区切り文字はありません）。

目視検査で手動でキーを分離できます。末尾のバイト数がキーの長さを表しているのではないかと思いました。ただし、この検査で決定された長さとは相関していませんでした。

FoxProのファイル形式はxBase標準から派生していると思います。おそらくこれはベルを鳴らしますか？

4

4 に答える 4

4

XBase::Index Perl モジュールを発見した後、外部ノードのキーは、末尾のスペースが削除されていることを除いて、内部ノードにある固定長キーと実質的に同じ長さであることがわかりました。これは、ドキュメントで言及されている「末尾のバイト数」が指すものです (キーの末尾から切り捨てられた末尾のスペースの数)。「重複バイト数」が何であるかはまだわかりませんが、モジュールは少なくともその関係を明確にしました：

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

たとえば、このインデックスの固定キー長が 10 バイトであるとします。ここで、キー「DOG」が外部ノードに格納されたとします。その重複バイト数 (私が観察したところによると) はほとんどの場合 0 ですが、末尾のバイト数は 7 (切り捨てられたスペースの数) になります。したがって、「DOG」を表す 3 バイトのみが格納されます。

于 2009-01-02T13:23:42.737 に答える
1

Xbase では、インデックス (テキストを説明するインデックス) を使用する場合、インデックス作成が 10 文字または 15 (まれ) を超えることはめったにありません。

いずれにせよ、キーの数がわかっている場合は、バイナリ部分を比例して分割します。データを保存するアルゴリズムを作成する場合、または開始マーカーまたは終了マーカーまたはタブを使用してデータを保存する場合、または空白のままにしないように静的サイズのままにします。静的フォーマットは効率は劣りますが、読み取り速度が向上し、明らかにより予測可能な構造を生成します。

于 2011-06-17T21:20:16.553 に答える
1

重複バイト数について: これは、現在のキーと前のキーで同じである最初のバイト数を意味します。ノードの最後に格納された最初のキー エントリは、末尾の空白を除いて完全な長さです。連続するキー入力には、前のキー入力と異なる記号のみがあります。

于 2009-10-22T06:00:16.397 に答える
0

Microsoft は、IDX ファイル構造について次のように述べています (ページの下部には、 Compact Index 形式など、他のすべてへのリンクがあります)。

于 2009-01-01T03:50:40.237 に答える