什麼是良好的面向壓縮的應用程序編程接口（API）？

什麼是良好的面向壓縮的應用程序編程接口（API）？什麼是良好的面向壓縮的應用程序編程接口（API）？

人們仍然使用1991年的「數據壓縮接口」草案標準，以及1991年的「流轉換算法接口」草案標準。（均爲draft standards by Ross Williams）？這些標準草案有沒有其他選擇？（我特別在尋找C API，但也讚賞C++和其他語言中面向壓縮的API的鏈接）。

我正在試驗一些數據壓縮算法。通常，我正在生成的壓縮文件由一系列塊組成，其中一個塊標題指示需要使用哪個壓縮算法來解壓縮該塊中的其餘數據 - Huffman，LZW，LZP，「存儲未壓縮」等。

塊頭還指示需要使用哪個過濾器來將來自解壓縮器的數據的中間流或緩衝器轉換爲原始明文的無損副本--Burrows-Wheeler變換，增量編碼，XML結束標記恢復，「不變」複製等。

而不是使用巨大的switch語句來選擇基於「壓縮類型」，它調用所選的解壓縮算法或過濾算法，ea ch程序具有其自己的特殊號碼和參數順序，它簡化了我的代碼，如果每個算法具有完全相同的API - 相同的參數數量和順序等。

而不是等待解壓縮器運行整個輸入流在將其輸出傳遞給第一個濾波器之前，如果API支持的解壓縮輸出數據在相對較少的壓縮數據饋入初始化後「相對快速」（低延遲）地出現在最終濾波器上解壓縮。如果可以在只有一個線程或進程的系統中使用API，那就太好了。

目前我通過 kludging在一起，我自己的內部API，重新使用現有的壓縮算法的實現編寫短的包裝功能，以我的內部API和特殊號碼以及每個執行的參數順序之間的轉換。

是否有我可以使用的已有API，而不是從頭開始設計自己的API？我在哪裏可以找到這樣的API？

來源

2011-07-14 David Cary

有趣的問題。 –

我擔心這樣的「API」不存在。特別是，「開始第二階段，第一階段正在進行和未完成」等要求完全取決於實施;並且不能在以後由API層添加。

順便說一句，Maciej Adamczyk剛剛和你一樣。他做了一個開源的基準測試，比較了塊壓縮場景下的多種壓縮算法。代碼可以在這裏查閱： http://encode.ru/threads/1371-Filesystem-benchmark?p=26630&viewfull=1#post26630

他已經被迫「封裝」所有這些不同的壓縮機接口，以應付差異。現在是好事：大多數壓縮機在涉及壓縮數據塊時傾向於具有相對類似的C接口。作爲一個例子，它們可以像這樣簡單： http://code.google.com/p/lz4/source/browse/trunk/lz4.h 因此，最終，適配層並不那麼重。

來源

2011-10-20 15:35:45 Cyan

儘管我同意API層不能向尚不支持它的算法添加部分處理，但我希望找到一個API，就像我鏈接到的Ross Williams API一樣，它允許對那些支持的算法進行部分處理它，即使API被強制爲那些沒有的算法使用塊處理。 –

感謝您提供有趣的鏈接。我有點失望，因爲還沒有一個標準的API。好吧，我想我會繼續拼湊我自己的內部API。 –

歡迎你。祝你在這個項目中取得成功。 – Cyan

什麼是良好的面向壓縮的應用程序編程接口（API）？

回答

相關問題