Компактный Индексный формат файла Visual FoxPro

Question

Я пытаюсь понять формат файла Visual FoxPro compact index (*.IDX).В настоящее время я имею в виду Документация Корпорации Майкрософт для руководства.

Индекс представляет собой B-дерево из 512-байтовых узлов.Каждый конечный ("внешний") узел содержит несколько записей.Каждая запись состоит из четырех фрагментов данных:

• Номер строки [ФИКСИРОВАННАЯ ДЛИНА]
• Количество повторяющихся байтов (документация этого не объясняет) [ФИКСИРОВАННАЯ ДЛИНА]
• Количество конечных байтов (документация этого не объясняет) [ФИКСИРОВАННАЯ ДЛИНА]
• Клавиша [ПЕРЕМЕННОЙ ДЛИНЫ]

Записи (без их ключей) хранятся в начале узла, сразу после 24-байтового заголовка узла.Их ключи не включены в это расположение, поскольку ключи различаются по длине, в то время как номер строки, количество повторяющихся байтов и количество завершающих байтов фиксированы по длине.Ключи хранятся в конце узла и проходят свой путь в обратном направлении.Например:

• 24 -байтовый заголовок
• номер строки, количество повторяющихся байтов, количество завершающих байтов (запись №1)
• номер строки, количество повторяющихся байтов, количество завершающих байтов (запись №2)
• номер строки, количество повторяющихся байтов, количество завершающих байтов (запись №3)
• ...
• ключ (запись №3)
• ключ (запись №2)
• ключ (запись №1)

Как мне определить индивидуальную длину ключей?В документации, по-видимому, это не указано.Они абсолютно непрерывны (без разделителей нулевых байтов).

Я могу изолировать ключи вручную путем визуального осмотра.Я подозревал, что количество завершающих байтов представляет собой длину ключа.Однако это не соответствовало длинам, определенным в ходе этой проверки.

Я считаю, что форматы файлов FoxPro являются производными от стандарта xBase.Возможно, это о чем-то говорит?

Answer 1

После обнаружения модуля xBase::Index Perl я определил, что ключи во внешнем узле фактически имеют ту же длину, что и ключи фиксированной длины, найденные во внутренних узлах, за исключением того, что все конечные пробелы удалены.Это то, к чему относится "количество завершающих байтов", упомянутое в документации (сколько завершающих пробелов было усечено в конце ключа).Я до сих пор не определил, что такое "количество повторяющихся байтов", но модуль, по крайней мере, прояснил свою взаимосвязь:

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

Например, предположим, что фиксированная длина ключа для этого индекса составляла 10 байт.Теперь предположим, что ключ "DOG" был сохранен во внешнем узле.Его количество повторяющихся байтов (согласно тому, что я наблюдал), скорее всего, будет равно нулю, в то время как количество завершающих байтов будет равно 7 (количество усеченных пробелов).Следовательно, будут сохранены только три байта, представляющие "СОБАКУ".

Answer 2

О количестве повторяющихся байтов:это означает количество первых байтов, которые одинаковы в текущем ключе и в предыдущем ключе.Первая запись ключа, хранящаяся в конце узла, имеет полную длину, за исключением конечных пробелов;последующий ввод ключа содержит только символы, отличные от предыдущего ввода ключа.

Answer 3

В Xbase индексация редко превышает 10 символов или 15 (редко) при использовании индексов (индексирование текстов, обсуждающих индексы).

В любом случае, если вы знаете, какое количество ключей пропорционально делит двоичную часть.Когда вы создаете алгоритм, который хранит данные, или сохраняете данные с помощью:начальные или конечные маркеры или вкладки, или вы оставляете статический размер, чтобы не использовать оставленный пробел.Статический формат менее эффективен, но обеспечивает большую скорость чтения и, очевидно, генерирует более предсказуемые структуры.

Answer 4

Microsoft говорит это касается файловой структуры IDX (а в нижней части страницы есть ссылки на все остальные, такие как Компактный формат индекса.)