Visual FoxPro Compact Index File Format

Question

Estou tentando entender o formato de arquivo de um índice visual da FoxPro Compact (*.idx). Atualmente estou me referindo a Documentação da Microsoft para orientação.

O índice é uma árvore B de nós de 512 bytes. Cada nó da folha ("Exterior") contém várias entradas. Cada entrada consiste em quatro dados:

• Número da linha [comprimento fixo
• Contagem de bytes duplicados (documentação não explica isso) [comprimento fixo
• Contagem de bytes à direita (a documentação não explica isso) [comprimento fixo
• Chave [comprimento variável

As entradas (sem as teclas) são armazenadas no início do nó, imediatamente após o cabeçalho de 24 bytes do nó. Suas teclas não estão incluídas neste local, porque as teclas variam em comprimento, enquanto o número da linha, a contagem de bytes duplicados e a contagem de bytes à direita são fixadas em comprimento. As chaves são armazenadas no final do nó e andam para trás. Por exemplo:

• Cabeçalho de 24 bytes
• Número da linha, contagem de bytes duplicados, contagem de bytes à direita (entrada nº 1)
• Número da linha, contagem de bytes duplicados, contagem de bytes à direita (entrada nº 2)
• Número da linha, contagem de bytes duplicados, contagem de bytes à direita (entrada nº 3)
• ...
• chave (entrada nº 3)
• chave (entrada nº 2)
• chave (entrada nº 1)

Como faço para determinar os comprimentos individuais das chaves? A documentação não parece especificar isso. Eles são perfeitamente contíguos (sem separadores de bytes nulos).

Eu posso isolar as chaves manualmente por inspeção visual. Eu suspeitava que a contagem de bytes à direita representava o comprimento da chave. No entanto, não se correlacionou com os comprimentos determinados por essa inspeção.

Acredito que os formatos de arquivo FoxPro são derivados do padrão XBase. Talvez isso soe um sino?

Answer 1

Depois de descobrir o módulo Xbase :: Index Perl, determinei que as teclas no nó externo são efetivamente o mesmo comprimento que as teclas de comprimento fixo encontradas nos nós interiores, exceto que quaisquer espaços à direita são removidos. É disso que a "contagem de bytes à direita" mencionou na documentação (quantos espaços à direita foram truncados no final da chave). Ainda não determinei qual é a "contagem de bytes duplicados", mas o módulo pelo menos esclareceu seu relacionamento:

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

Por exemplo, suponha que o comprimento da chave fixo para este índice tenha 10 bytes. Agora, suponha que a chave "cachorro" tenha sido armazenada em um nó externo. Sua contagem duplicada de bytes (de acordo com o que observei) provavelmente será zero, enquanto sua contagem de bytes à direita será 7 (o número de espaços truncados). Portanto, apenas os três bytes representando "cachorro" seriam armazenados.

Answer 2

Sobre contagem de bytes duplicados: isso significa o número de primeiros bytes, que são os mesmos na chave atual e na chave anterior. A primeira entrada -chave armazenada no final do nó tem um comprimento total, exceto em espaços em branco à direita; A entrada de chave sucessiva possui apenas símbolos diferentes da entrada de chave anterior.

Answer 3

Na indexação Xbase, raramente excede 10 caracteres ou 15 (raros) ao usar índices (índice discutindo textos).

De qualquer forma, se você souber qual é o número de chaves divide proporcionalmente a parte binária. Quando você cria um algoritmo que armazena dados ou armazena os dados usando: marcadores ou guias iniciais ou finais ou deixa um tamanho estático para não usar o espaço em branco esquerdo. O formato estático é menos eficiente, mas fornece maior velocidade na leitura e obviamente gera estruturas mais previsíveis.

Answer 4

Microsoft diz Isso sobre a estrutura do arquivo IDX (e na parte inferior da página, existem links para todos os outros como o Formato de índice compacto.)