Formato di file indice di Visual FoxPro Compact

Question

Sto cercando di capire il formato del file di un indice compatto di Visual FoxPro (* .IDX). Attualmente mi riferisco alla la documentazione di Microsoft come guida .

L'indice è un albero B di nodi da 512 byte. Ogni nodo foglia ("esterno") contiene più voci. Ogni voce è composta da quattro parti di dati:

• Numero riga [LUNGHEZZA FISSA]
• Numero di byte duplicati (la documentazione non spiega questo) [LUNGHEZZA FISSA]
• Conteggio byte finali (la documentazione non spiega questo) [LUNGHEZZA FISSA]
• Chiave [LUNGHEZZA VARIABILE]

Le voci (senza le loro chiavi) sono memorizzate all'inizio del nodo, immediatamente dopo l'intestazione a 24 byte del nodo. Le loro chiavi non sono incluse in questa posizione perché le chiavi variano in lunghezza, mentre il numero di riga, il numero di byte duplicati e il numero di byte finali sono fissi in lunghezza. Le chiavi sono memorizzate alla fine del nodo e procedono all'indietro. Ad esempio:

• intestazione a 24 byte
• numero di riga, numero di byte duplicati, numero di byte finali (voce # 1)
• numero di riga, numero di byte duplicati, numero di byte finali (voce # 2)
• numero di riga, numero di byte duplicati, numero di byte finali (voce # 3)
• ...
• key (entry # 3)
• key (entry # 2)
• key (entry # 1)

Come posso determinare le singole lunghezze delle chiavi? La documentazione non sembra specificare questo. Sono perfettamente contigui (senza separatori null-byte).

Posso isolare le chiavi manualmente tramite ispezione visiva. Sospettavo che il conteggio dei byte finali rappresentasse la lunghezza della chiave. Tuttavia, non era correlato alle lunghezze determinate da questa ispezione.

Credo che i formati di file FoxPro siano derivati ??dallo standard xBase. Forse questo suona un campanello?

Answer 1

Dopo aver scoperto il modulo Perl XBase :: Index, ho determinato che le chiavi nel nodo esterno hanno effettivamente la stessa lunghezza delle chiavi a lunghezza fissa che si trovano nei nodi interni, ad eccezione di eventuali spazi finali rimossi. Questo è ciò che il "conteggio dei byte finali" menzionato nella documentazione si riferisce a (quanti spazi finali sono stati troncati dalla fine della chiave). Non ho ancora determinato quale sia il conteggio dei byte duplicati " è, ma almeno il modulo ha chiarito la sua relazione:

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

Ad esempio, supponiamo che la lunghezza della chiave fissa per questo indice fosse di 10 byte. Supponiamo ora che la chiave "DOG" è stato memorizzato in un nodo esterno. Il conteggio dei byte duplicati (secondo quanto ho osservato) sarà molto probabilmente zero, mentre il conteggio dei byte finali sarà 7 (il numero di spazi troncati). Pertanto, solo i tre byte che rappresentano "DOG" sarebbe memorizzato.

Answer 2

Informazioni sul conteggio di byte duplicati: significa il numero di primi byte, che sono gli stessi nella chiave corrente e nella chiave precedente. La prima voce chiave memorizzata alla fine del nodo ha una lunghezza intera, tranne gli spazi vuoti finali; l'inserimento chiave successivo ha solo simboli diversi dall'inserimento chiave precedente.

Answer 3

In Xbase l'indicizzazione supera raramente 10 caratteri o 15 (rari) quando si usano gli indici (indice che discute i testi).

In ogni caso, se sai qual è il numero di chiavi divide in modo proporzionale la parte binaria. Quando crei un algoritmo che memorizza i dati o li memorizzi utilizzando: marcatori o schede di inizio o fine, oppure lasci una dimensione statica in modo da non utilizzare lo spazio vuoto. Il formato statico è meno efficiente ma offre una maggiore velocità di lettura e ovviamente genera strutture più prevedibili.

Answer 4

Microsoft dice questo sull'IDX struttura dei file (e nella parte inferiore della pagina ci sono collegamenti a tutti gli altri come formato indice compatto .)