21 个版本 (5 个破坏性更新)
0.6.3 | 2024年2月14日 |
---|---|
0.6.1 | 2024年1月28日 |
0.5.4 | 2024年1月13日 |
0.4.2 | 2024年1月8日 |
0.1.0 | 2023年12月17日 |
#200 in 压缩
160KB
3.5K SLoC
HFF
另一种文件格式。这种格式的目的是介于 IFF/RIFF 格式和具有一些独特添加的 zip 类型存档之间。不同之处在于,与 IFF/RIFF 不同,结构被移至前面以供发现,无需扫描,并且结构在本质上类似于 ZIP。事实上,主要测试平台/工具 ('hff') 实现了一个简单的打包/解包子命令,该命令可以将目录内容打包成一个单一的 hff 文件,然后可以解包到不同的位置。该命令支持过程中的可选 LZMA 压缩。
整体容器格式旨在尽可能保持非意见化,与用于许多不同文件格式的 IFF/RIFF 格式保持一致。该格式的其他目的可能满足作者的特定需求,可能或可能不适用于一般用途,但不应对此容器造成影响,而应使其对他人更加功能完善。
结构
HFF 的结构分为三部分
头部
描述基本容器的固定大小结构。此头部能够识别数据为 HFF,以及包含的容器格式的版本。此外,HFF 头部用于检测整体结构的端序。文件端序仅适用于结构描述,并不会导致块数据的改变,如何编码/解码块留给用户决定,因为 HFF 没有对内容进行规定。
描述
HFF 容器的第二部分由两个数组组成。第一个数组是一个分层的 '表格' 结构,可以将其视为磁盘上的目录。每个表格可以附加可选的元数据、可选的子表格(子目录)和可选的块(目录中的文件)。第二个数组由表格引用,包含有关每个块的信息。块(和元数据)由容器定义为具有给定长度的字节集,它不指定内容或以任何方式解释它。提供的唯一规范是数据偏移和数据长度都是完整的 64 位值,如果需要,允许达到太字节级别的存储。
主体
文件中实际存储的元数据和块数据。唯一提供的规范是每个块将从文件开始的16字节倍数处开始。
标识
HFF自身、表格和块的标识对于许多用途来说有点过度。HFF自身可以指定一个64位唯一ID,该ID可以用来确定如何解释整个HFF的内容。此ID位于头部,以便快速访问,而无需扫描容器的内容。适用于表格和块的第二种ID是一个完整的128位ID,基本上可以是所需的任意值。目前有几个默认格式,但尚未完全完善。目前,目的是支持几个组合;UUID、双八位字符码、固定16字节字符串以及其他所需的内容。UUID和双ECC将是主要的初始实现。
注意:任意ID仍在实现中。目前API期望两个ECC,类似于IFF/RIFF的四位字符码,只是每个8个字符。
HFF命令行工具
hff命令行工具目前是一个既作为测试平台又是使用该格式的示例而编写的实用程序。它提供了以下3个子命令(使用hff --help获取更多信息)
hff dump [输入]
hff dump子命令用于检查HFF容器的结构。默认情况下,它将简单地按深度优先顺序打印出表格及其详细信息。还可以选择输出每个表格的元数据和块信息。在元数据的情况下,还可以选择尝试将内容解释为两个实用结构:Ksv和StringVec。
hff pack [输入] [输出]
类似于zip的原始变体,用于扫描目录的内容并将其打包成一个单独的HFF容器。
hff unpack [输入] [输出]
反转pack命令,并将HFF容器的原始内容写回到磁盘。
状态
当前状态仍然非常处于alpha阶段,尽管目前可能处于beta状态。std::io实现是主要关注点,似乎正在正常工作。tokio/async-std实现目前只支持异步读取,但它们“似乎”也正常工作,尽管目前没有进行大规模测试。所有测试目前都由开发驱动,相当糟糕,需要更多的测试。
依赖关系
~2–12MB
~143K SLoC