Visual FoxPro-Compact-Index-Dateiformat

Question

Ich versuche, das Dateiformat eines Visual FoxPro-Compact-Index (* .IDX) zu verstehen. Ich beziehe mich derzeit auf Microsoft-Dokumentation zur Führung .

Der Index ist ein B-Baum von 512-Byte-Knoten. Jedes Blatt ( „äußere“) Knoten enthält mehrere Einträge. Jeder Eintrag besteht aus vier Teilen von Daten:

• Zeilennummer [FIXED LENGTH]
• Duplizieren Byteanzahl (Dokumentation dies nicht erklären) [FIXED LENGTH]
• Nachgestellte Byteanzahl (Dokumentation dies nicht erklären) [FIXED LENGTH]
• Taste [variabler Länge]

Die Einträge (ohne ihre Schlüssel) werden zu Beginn des Knotens gespeichert, unmittelbar nach dem 24-Byte-Header des Knotens. Die Tasten sind nicht an dieser Stelle enthalten, da die Schlüssel in der Länge variieren, während die Zeilennummer, doppelte Byte-Anzahl und Hinter Bytezählwerte Länge fixiert sind. Die Tasten sind an dem Ende des Knotens gespeichert und ihren Weg nach hinten. Zum Beispiel:

• 24 Byte-Header
• Zeilennummer, doppelte Byte-Anzahl, Hinter Byteanzahl (Eintrag # 1)
• Zeilennummer, doppelte Byte-Anzahl, Hinter Byteanzahl (Eintrag # 2)
• Zeilennummer, doppelte Byte-Anzahl, Hinter Byteanzahl (Eintrag # 3)
• ...
• -Taste (Eintrag # 3)
• -Taste (Eintrag # 2)
• -Taste (Eintrag # 1)

Wie ermittle ich die einzelnen Längen der Schlüssel? Die Dokumentation erscheint nicht diese zu spezifizieren. Sie sind perfekt zusammenhängend (keine Null-Byte-Separatoren).

kann ich die Schlüssel manuell durch visuelle Inspektion isolieren. Ich vermutete, dass der hintere Byteanzahl die Länge des Schlüssels dargestellt. Es ist jedoch korrelierte nicht mit den in dieser Untersuchung bestimmt Längen.

Ich glaube, dass die FoxPro-Dateiformate aus dem xBase Standard abgeleitet sind. Vielleicht klingt dies eine Glocke?

Answer 1

XBase :: Index Perlmodul Nach der Entdeckung, habe ich festgestellt, dass die Schlüssel in dem Außenknoten effektiv die gleiche Länge wie die festen Länge gefunden Schlüssel in dem inneren Knoten, mit Ausnahme irgend Leerzeichen entfernt werden. Das ist, was das „trailing Byteanzahl“ in der Dokumentation erwähnt bezieht sich auf (wie viele Leerzeichen am Ende wurden das Ende des Schlüssels abgeschnitten off). Ich habe noch nicht bestimmt, was die „doppelte Byte-Zählung“ ist, aber das Modul zumindest seine Beziehung geklärt:

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

Angenommen, die feste Schlüssellänge für diesen Index 10 Byte war. Nehmen wir nun an, dass der Schlüssel „DOG“ wurde in einem externen Knoten gespeichert. Seine doppelte Byteanzahl (nach dem, was ich beobachtet habe) wird höchstwahrscheinlich null sein, während sein hinteres Byteanzahl 7 sein wird (die Anzahl der Leerzeichen abgeschnitten). Daher werden nur die drei Bytes „DOG“ gespeichert würden darstellt.

Answer 2

Über doppelte Byte-Anzahl: Dies ist die Anzahl der ersten Bytes bedeuten, die in aktuellen Schlüssel gleich sind und in vorherigen Schlüssel. Die erste Tasteneingabe am Ende des Knotens gespeichert hat eine volle Länge, mit der Ausnahme Rohlingen nachlauf; aufeinanderfolgende Tasteneingabe nur Symbole unterscheidet sich von früheren Tasteneingabe.

Answer 3

In Xbase Indizierung überschreitet selten 10 Zeichen oder 15 (selten), wenn Indizes mit (Index diskutieren Texte).

Auf jeden Fall, wenn Sie wissen, was die Anzahl der Tasten ist proportional den binären Teil trennt. Wenn Sie einen Algorithmus zu machen, die Daten gespeichert werden, oder die Daten speichern, mit: Starten oder Endmarkierungen oder Tabs, oder tun lassen Sie eine statische Größe, so dass Sie BLANK nicht verlassen. Das statische Format ist weniger effizient, sondern bietet eine höhere Geschwindigkeit beim Lesen und natürlich erzeugt berechenbare Strukturen.

Answer 4

Microsoft sagt diese über die IDX Dateistruktur (und am unteren Rand der Seite gibt es Links zu allen anderen, wie die Compact-Index Format .)