Visual FoxProコンパクトインデックスファイル形式

Question

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

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

• 行番号[固定長]
• 重複バイト数（ドキュメントでは説明されていません）[修正された長さ]
• 末尾のバイトカウント（ドキュメントでは説明されていません）[固定長]
• キー[可変長]

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

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

キーの個々の長さを確認するにはどうすればよいですか？これを指定するドキュメントは表示されません。それらは完全に連続しています（nullバイトの区切り文字はありません）。

キーを目視で手動で分離できます。後続のバイトカウントがキーの長さを表していると思われました。ただし、この検査で決定された長さとは相関しませんでした。

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

Answer 1

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

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

たとえば、このインデックスの固定キー長が10バイトだったとします。ここで、キー＆quot; DOG＆quot;が外部ノードに保存されました。その重複したバイトカウント（私が観察したものによると）は、ほとんどの場合ゼロになりますが、後続のバイトカウントは7（切り捨てられたスペースの数）になります。したがって、「DOG」を表す3バイトのみが格納されます。

Answer 2

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

Answer 3

Xbaseでは、インデックスを使用するときにインデックスが10文字または15（まれ）を超えることはめったにありません（テキストについて説明するインデックス）。

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

Answer 4

Microsoftによると、IDXについてファイル構造（およびページの下部には、コンパクトインデックス形式。