問題タブ [data-compression]

私は単一のgzip圧縮ファイルを持っています（100GBの非圧縮、40GBの圧縮）。ここで、いくつかのバイト/バイト範囲を変更したいと思います-ファイルサイズを変更したくありません。

たとえば、バイト 8 + 10 およびバイト 5000 ～ 40000

ファイル全体を再圧縮せずにこれは可能ですか?

ステファン

各 URL リストに最大 50 個の URL が含まれる、1 兆個の URL リストを保存する必要があります。それらをディスク上のストレージ用に圧縮する最もスペース効率の良い方法は何でしょうか。

最初に「http://」のような役に立たない情報を削除してから、最小限の有限状態オートマトンを構築してこれを保存することを考えていました。

もう 1 つのオプションは、カンマ区切りの URL の文字列を作成し、GZIP や BZ2 などの通常の圧縮を使用してこの文字列を圧縮することです。

速度を気にしない場合、どのソリューションが最適な圧縮になります。

アプリケーションで 7zip を使用する必要があり、LZMA SDK のラッパーを探しています。Chadwick McNab によって開発された興味深いもの SevenZip++ ( https://bitbucket.org/cmcnab/sevenzip/overview ) を見つけました。問題は、このラッパーが 7za.dll を使用していることです。

7za.dll なしでアプリケーションで 7zip を使用することは可能ですか? 7za.dll を使用しない LZMA SDK のラッパーはありますか?

3,000 万から 5,000 万のデータ オブジェクトを含むことができる JSON ファイルがあります。以下を実現したい...

• ディスク上の JSON ファイルのサイズを縮小するための可能な限り最適なデータ圧縮。
• ac# アプリケーションで効率的なデータ クエリ ルーチンを開発し、フィルタリングされたデータをオンデマンドでメモリにロードします。

これはローカル マシンで行う必要があり、サーバーは関与しないことに注意してください。

これらの目標を達成するには、あなたの専門家の意見が必要です。

ありがとう！

ロスレス データ圧縮をどこまで行うことができるか疑問に思っていました。経験的なテストを実行するためのロスレス アルゴリズムのオンライン シミュレーターを見つけることができませんでした。自分で作ることもできましたが、残念ながらこの期間に十分な時間がありません。それでも、私が持っていた直感に興味があります。それについて説明します。

より一般的なアルゴリズムの 2 つだけを取ってみましょう:Huffman CodingとRun-lenght Enconding.

数字A記号のアルファベットと、そのアルファベットからの記号の任意の長いシーケンスがあるとします。たとえば、次のようになります。

ここで、各シンボルをビットの固定長ワードでコーディングするとn、圧縮されていないシーケンス、つまり長いNビットが得られます。

ハフマンを使用してシーケンスをコーディングする場合、Hビットの代わりにNビットを使用して、ビットのスペースを節約(1-H/N)*100%します。

RLE を使用して同じシーケンスをコーディングすると、Rビットを使用して を節約でき(1-R/N)*100%ます。

1つだけ使用するよりも省スペースを実現できるRLE + Huffmanか、適用するとどうなるでしょうか。Huffman + RLE

私にはかなり基本的なアイデアのように思えますが、グーグルで検索しても、このトピックに関する興味深いものは見つかりませんでした。

EDIT：うーん、最初にRLEを使用すると、単一シンボルの固定長コードとの対応が失われるため、ハフマンを使用できなくなるとはおそらく考えていませんでした。ただし、最初に Huffman を使用し、その後で RLE を使用することも可能です。

ところで、私はそのロジックに興味があります。つまり、複数の可逆圧縮アルゴリズムを連続して使用するということです。

編集 2: Mark Adler の返信にコメントしているときに、自分の質問に対する答えを見つけた可能性があることに気付きました。これです：

シンボルからシンボルへのコードであるハフマンは、検出にどのように影響しますか?

次のコードがあるとしましょう: AABCABAAB. プレーン バイナリでは、次のようにエンコードされます00 00 01 10 00 01 00 00 01(obv スペースは読みやすさのためだけです)。ハフマンはそれを次のようにコーディングします0 0 11 10 0 11 0 0 11。スペースは、文字列が変更されていないことをさらに示しているため、このスコープ (シンボル単位) でコードに近づいていると仮定すると、まったく同じ量の繰り返しを検出することができます。

これにより、コードをビット単位で分析するという別のポイント (これはすでに非常に長いコメントになっているため、ここでは説明しません) にたどり着きました。

だから、私は実際に結論に達したと思います: 私たちが知っているように、辞書 (または置換ベース) エンコーダーは可変数のシンボルを固定長コードワードにグループ化しますが、ハフマン (または他のエントロピーエンコーダー) は固定長シンボルをコード化します可変数のビットに変換し、エントロピーを最小に近似します。したがって、Huffman を最初に実行させるのは無意味です (計算の無駄でしかありません)。なぜなら、他のアルゴリズムは、 Huffman が減らすことができるより多くの冗長性を導入する可能性が高いからです。

もちろん、これは理論的な論文にすぎません。実際には、他の要因 (計算時間など) を考慮に入れることができるからです... コーディングされる文字列の構成が異なると、異なる結果が生じる可能性があるという事実は言うまでもありません。しかし、まあ... それは私には理にかなっています。:)

圧縮後のファイル、ファイル、またはファイルのディレクトリの最終的なサイズを見積もりたいと思います。これを推定/計算できるプログラムまたはスクリプトを探しています。

何か案は？

このようなツールは、コマンド ラインからアクセスできる必要があります (Linux/Mac の場合)。gz一般的に使用されるロスレス圧縮アルゴリズム ( 、bzip2、zipなど)のすべてまたはほとんどで動作する場合、最も便利です。さまざまな方法の圧縮率（または同等の用途の結果のファイルサイズ）がリストされていれば、ボーナスポイントです。このようなツールは、出力を生成する前にファイルをスキャンすることを十分に期待していますが、可能であれば、実際の圧縮は避けたいと考えています。

問題がある場合は、これを汎用にすることをお勧めします。

• 簡単に圧縮できるASCIIテキストファイル、バイナリデータ、およびその間のすべてを含む、あらゆる種類のファイルでうまく機能するはずです。(もちろん、これは圧縮アルゴリズム/ツールに大きく依存します。)
• さまざまな圧縮アルゴリズム/ツールで動作するはずです

次の BASH スクリプトは、1種類の圧縮アルゴリズムに対して必要なことを実行しますが、カウントされません (見積もりが必要です)。

私は主にこれをより大きなファイル (ギガバイトより大きい) に使用します。そのため、実際の圧縮ではなく、推定値のみが必要です。