Format de fichier d'index Visual FoxPro Compact

Question

J'essaie de comprendre le format de fichier d'un index compact Visual FoxPro (* .IDX). Je fais actuellement référence à la documentation de Microsoft pour obtenir des conseils. .

L'index est un arbre B de nœuds de 512 octets. Chaque nœud feuille ("extérieur") contient plusieurs entrées. Chaque entrée comprend quatre données:

• Numéro de ligne [LONGUEUR FIXE]
• Nombre d'octets en double (la documentation ne l'explique pas) [FIXED LENGTH]
• Compte d'octets de fin (la documentation n'explique pas cela) [LONGUEUR FIXE]
• Touche [LONGUEUR VARIABLE]

Les entrées (sans leurs clés) sont stockées au début du nœud, immédiatement après l'en-tête de 24 octets du nœud. Leurs clés ne sont pas incluses à cet emplacement car leur longueur varie, tandis que le nombre de lignes, le nombre d'octets dupliqués et le nombre d'octets de fin sont de longueur fixe. Les clés sont stockées à la fin du nœud et retournent en arrière. Par exemple:

• en-tête de 24 octets
• numéro de ligne, nombre d'octets dupliqués, nombre d'octets de fin (entrée n ° 1)
• numéro de ligne, nombre d'octets dupliqués, nombre d'octets de fin (entrée n ° 2)
• numéro de ligne, nombre d'octets en double, nombre d'octets de fin (entrée n ° 3)
• ...
• clé (entrée n ° 3)
• clé (entrée n ° 2)
• clé (entrée n ° 1)

Comment puis-je déterminer la longueur individuelle des clés? La documentation ne semble pas le spécifier. Ils sont parfaitement contigus (pas de séparateurs nuls octets).

Je peux isoler les clés manuellement par inspection visuelle. Je soupçonnais que le compte d'octets final représentait la longueur de la clé. Cependant, cela n’a pas été corrélé aux longueurs déterminées par cette inspection.

Je pense que les formats de fichier FoxPro sont dérivés du standard xBase. Peut-être que cela vous dit quelque chose?

Answer 1

Après avoir découvert le module XBase :: Index Perl, j’ai déterminé que les clés du nœud extérieur ont en réalité la même longueur que les clés de longueur fixe trouvées dans les nœuds intérieurs, à l’exception des espaces supprimés. C’est ce que le "nombre d’octets en fin de chaîne" mentionné dans la documentation fait référence à (combien d'espaces de fin ont été tronqués à la fin de la clé). Je n'ai toujours pas déterminé le "nombre d'octets dupliqués". est, mais le module a au moins clarifié sa relation:

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

Par exemple, supposons que la longueur de clé fixe pour cet index soit de 10 octets. Supposons maintenant que la touche "DOG" a été stocké dans un noeud externe. Le nombre d'octets dupliqués (d'après ce que j'ai observé) sera probablement égal à zéro, tandis que le nombre d'octets suivants sera de 7 (nombre d'espaces tronqués). Par conséquent, seuls les trois octets représentant le symbole "DOG". serait stocké.

Answer 2

À propos du nombre d’octets en double: il s’agit du nombre de premiers octets, identiques dans la clé actuelle et dans la clé précédente. La première entrée de clé stockée à la fin du nœud a une longueur complète, à l'exception des espaces en fin de chaîne; Les entrées successives ne comportent que des symboles différents des entrées précédentes.

Answer 3

Sous Xbase, l’indexation dépasse rarement 10 caractères ou 15 (rare) lorsqu’on utilise des index (index discutant des textes).

Dans tous les cas, si vous savez quel est le nombre de clés divise proportionnellement la partie binaire. Lorsque vous créez un algorithme qui stocke des données, ou stockez les données en utilisant: des marqueurs de début ou de fin ou des onglets, ou laissez-vous une taille statique pour ne pas utiliser vide. Le format statique est moins efficace mais permet une lecture plus rapide et génère évidemment des structures plus prévisibles.

Answer 4

Microsoft déclare ce qui suit à propos de l'IDX structure de fichier (et au bas de la page, il y a des liens vers tous les autres, comme Format d'index compact .)