我试图了解 Visual FoxPro 紧凑索引 (*.IDX) 的文件格式。我目前指的是 微软的文档 以获得指导。

该索引是 512 字节节点的 B 树。每个叶(“外部”)节点包含多个条目。每个条目由四部分数据组成:

  • 行号[固定长度]
  • 重复字节计数(文档没有解释这一点)[固定长度]
  • 尾随字节计数(文档没有解释这一点)[固定长度]
  • 键[可变长度]

条目(不带键)存储在节点的开头,紧接在节点的 24 字节标头之后。它们的键不包含在此位置,因为键的长度不同,而行号、重复字节计数和尾随字节计数的长度是固定的。密钥存储在节点的末尾并向后运行。例如:

  • 24字节头
  • 行号、重复字节计数、尾随字节计数(条目 #1)
  • 行号、重复字节计数、尾随字节计数(条目 #2)
  • 行号、重复字节计数、尾随字节计数(条目 #3)
  • ...
  • 密钥(条目#3)
  • 密钥(条目#2)
  • 密钥(条目#1)

如何确定各个按键的长度?文档似乎没有指定这一点。它们是完全连续的(没有空字节分隔符)。

我可以通过目视检查手动隔离按键。我怀疑尾随字节计数代表了密钥的长度。然而,它与本次检查确定的长度无关。

我相信 FoxPro 文件格式源自 xBase 标准。也许这敲响了警钟?

有帮助吗?

解决方案

发现 XBase::Index Perl 模块后,我确定外部节点中的键实际上与内部节点中找到的固定长度键的长度相同,只是删除了所有尾随空格。这就是文档中提到的“尾随字节数”所指的(有多少尾随空格被从键的末尾截断)。我还没有确定“重复字节数”是什么,但该模块至少澄清了它的关系:

variable_key_length = fixed_key_length - duplicate_byte_count - trailing_byte_count

例如,假设该索引的固定密钥长度为 10 字节。现在假设密钥“DOG”存储在外部节点中。它的重复字节计数(根据我的观察)很可能为零,而其尾随字节计数将为 7(被截断的空格数)。因此,仅存储代表“DOG”的三个字节。

其他提示

关于重复字节数:这意味着当前密钥和前一个密钥中的第一个字节的数量相同。存储在节点末尾的第一个键条目具有完整长度,尾随空白除外;连续的按键输入仅具有与先前的按键输入不同的符号。

在 Xbase 中,当使用索引(讨论文本的索引)时,索引很少超过 10 个字符或 15 个(罕见)。

无论如何,如果您知道键的数量按比例划分二进制部分是多少。当您制定存储数据的算法或使用以下方式存储数据时:开始或结束标记或选项卡,或者保留静态大小,以便不使用留空。静态格式效率较低,但读取速度更快,并且显然会生成更可预测的结构。

微软说 这是关于 IDX 文件结构的(在页面底部有指向所有其他文件的链接,例如 紧凑索引格式.)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top