api - 什么是好的面向压缩的应用程序编程接口(interface) (API)？

Question

什么是好的面向压缩的应用程序编程接口(interface) (API)？

人们还在使用1991年《数据压缩接口(interface)》标准草案，并1991年《流变换算法接口(interface)》标准草案。(两者draft standards by Ross Williams)？这些标准草案有其他选择吗？

(我特别寻找 C API，但也希望提供 C++ 和其他语言中面向压缩的 API 的链接)。

我正在尝试一些数据压缩算法。通常，我生成的压缩文件由一系列 block 组成， block 头指示需要使用哪种压缩算法来解压缩该 block 中的剩余数据 - Huffman、LZW、LZP、“存储未压缩”等。

block 头还指示需要使用哪些过滤器将来自解压缩器的数据的中间流或缓冲区转换为原始明文的无损副本——Burrows–Wheeler 变换、增量编码、XML 结尾——标签恢复、“复制不变”等

而不是使用一个巨大的switch语句，根据“压缩类型”进行选择，调用所选的解压算法或过滤算法，每个过程都有自己特殊的参数数量和顺序，如果每个算法都具有完全相同的 API(相同的参数数量和顺序等)，那么它会简化我的代码。

不是等待解压缩器运行完整个输入流，然后再将其输出传递给第一个过滤器，如果 API 支持在相对较少的压缩数据被输入到初始解压缩器之后“相对快速”(低延迟)地从最终过滤器中输出解压缩的输出数据，那就太好了。如果该 API 可以在只有一个线程或进程的系统中使用，那就太好了。

目前我正在拼凑我自己的内部 API，重新使用现有的压缩算法实现编写简短的包装函数来在我的内部 API 和每个实现使用的参数的特殊数量和顺序之间进行转换。

是否有一个已经存在的 API 可供我使用，而不是从头开始设计自己的 API？我在哪里可以找到这样的 API？

Answer 1

我担心这样的“API”不存在。特别是，诸如“在第一阶段正在进行且未完成时开始第二阶段”之类的要求完全依赖于实现；并且以后无法通过 API 层添加。

顺便说一句，Maciej Adamczyk 刚刚尝试了和你一样的方法。他制定了一个开源基准测试，比较 block 压缩场景中的多种压缩算法。代码可以在这里查阅: http://encode.ru/threads/1371-Filesystem-benchmark?p=26630&viewfull=1#post26630

他不得不“封装”所有这些不同的压缩机接口(interface)，以应对差异。现在说点好事:大多数压缩器在压缩数据 block 时往往具有相对相似的 C 接口(interface)。举个例子，它们可以像这样简单: http://code.google.com/p/lz4/source/browse/trunk/lz4.h所以，归根结底，适配层并没有那么重。