ファイルは何回圧縮できますか？
私は圧縮について考えていましたが、適用できる圧縮には何らかの制限が必要であるように思われます。そうでない場合は、1バイトになります。
だから私の質問は、何回ファイルを圧縮することができますか：
- それは小さくなりませんか？
- ファイルが破損しますか？
これらの2つのポイントは同じですか、または異なりますか？
収益が減少するポイントはどこに表示されますか？
これらのポイントはどのようにして見つけることができますか？
特定のアルゴリズムや特定のファイルについては、単に一般的な話ではありません。
ロスレス圧縮の場合、ファイルを再圧縮することで得られる回数を知る唯一の方法は、試してみることです。圧縮アルゴリズムと圧縮するファイルに依存します。
2つのファイルを同じ出力に圧縮することはできないため、1バイトに減らすことはできません。 1バイトで圧縮解除できるすべてのファイルをどのように表現できますか？
2番目の圧縮が時々機能する理由は、圧縮アルゴリズムでは全知全能の圧縮ができないためです。それがしなければならない仕事とそれをするのにかかる時間の間にはトレードオフがあります。ファイルは、すべてのデータから、データとデータ自体に関するデータの組み合わせに変更されています。
例
ランレングスエンコーディング（おそらく最も簡単で便利な圧縮）を例として取り上げます。
04 04 04 04 43 43 43 43 51 5211バイト
その一連のバイトは、次のように圧縮できます。
[4] 04 [4] 43 [-2] 51 527バイト（メタデータを括弧に入れています）
カッコ内の正の数は繰り返しカウントであり、カッコ内の負の数は次の-n文字が見つかったときにそれを出力するコマンドです。
この場合、もう1つ圧縮を試すことができます。
[3] 04 [-4] 43 fe 51 527バイト（feは2の補数データとして見られる-2）
何も得られず、次の反復で成長を開始します。
[-7] 03 04 fc 43 fe 51 528バイト
繰り返しごとに1バイトずつ成長しますが、実際にはさらに悪化します。 1バイトには、-128までの負の数しか保持できません。ファイルの長さが128バイトを超えると、2バイト増加し始めます。ファイルが大きくなるにつれて、成長はさらに悪化します。
圧縮プログラム（メタデータ）に逆風が吹いています。また、realコンプレッサーでは、ヘッダーがファイルの先頭に追加されました。これは、圧縮が追加されるたびにファイルが最終的に成長し始めることを意味します。
RLEは出発点です。詳細については、 LZ77 （パターンを見つけるためにファイルを振り返る）および LZ78 （辞書を作成する）を参照してください。 Zipなどのコンプレッサーは、多くの場合、複数のアルゴリズムを試し、最適なアルゴリズムを使用します。
ここで、複数の圧縮が機能した場所を考えることができます。
- 私はディスク付きのAmiga雑誌で働いていました。当然、ディスクをエラに詰めました。使用したツールの1つを使用すると、実行可能ファイルをパックして、実行時に圧縮解除して実行することができました。解凍アルゴリズムはすべての実行可能ファイルに含まれている必要があったため、小さくてシンプルでなければなりませんでした。 2回圧縮することで、余分なゲインが得られることがよくありました。解凍はRAMで行われました。フロッピーの読み取りが遅いため、多くの場合、速度も向上しました。
- Microsoftは、bmpファイルのRLE圧縮をサポートしていました。また、多くのWordプロセッサでRLEエンコードが行われました。 RLEファイルは、ほとんどの場合、より優れたコンプレッサーによって大幅に圧縮可能です。
- 私が取り組んだゲームの多くは、小さくて高速なLZ77解凍プログラムを使用していました。ピクセルの大きな長方形を圧縮する場合（特に、背景色が多い場合、またはアニメーションの場合）、2回圧縮すると非常に良い結果が得られます。 （理由は、ルックバック距離と長さを指定するビット数が非常に多いため、単一の大きな繰り返しパターンが複数の断片にエンコードされ、それらの断片は高度に圧縮可能であることです。）
通常、制限は1回の圧縮です。一部のアルゴリズムでは圧縮率が高くなり、貧弱なアルゴリズムに続いて良好なアルゴリズムを使用すると、多くの場合改善されます。しかし、そもそも適切なアルゴリズムを使用するのは適切なことです。
特定のデータセットを圧縮できる量には理論的な制限があります。これについてさらに学ぶには、 情報理論 を勉強する必要があります。
一般に、ほとんどのアルゴリズムでは、複数回圧縮することは役に立ちません。ただし、特別なケースがあります。
多数の重複ファイルがある場合、Zip形式はそれぞれ独立してZip処理を行い、最初のZipファイルをZip処理して重複するZip情報を削除できます。具体的には、108kbのサイズの7つの同一のExcelファイルの場合、7-Zipで圧縮すると120kbのアーカイブになります。再び圧縮すると、18kbのアーカイブになります。収益が減少することを過ぎて行きます。
Nビット長のファイルがあり、元のファイルを復元できるように、無損失で圧縮したいとします。 Nビット長の2 ^ N個の可能なファイルがあるため、圧縮アルゴリズムはこれらのファイルの1つを2 ^ N個の可能な他のファイルに変更する必要があります。ただし、2 ^ N個の異なるファイルをNビット未満で表現することはできません。
したがって、いくつかのファイルを取得して圧縮できる場合、圧縮されたファイルの長さを圧縮して、短縮されたファイルのバランスをとる必要があります。
つまり、圧縮アルゴリズムは特定のファイルのみを圧縮でき、実際にはいくつかのファイルを長くする必要があります。これは、平均して、ランダムファイルを圧縮しても短くすることはできませんが、長くなる可能性があることを意味します。
通常、ランダムファイルを使用しないため、実用的な圧縮アルゴリズムが機能します。使用するファイルのほとんどは、テキストまたはプログラム実行可能ファイル、または意味のある画像であるかに関係なく、何らかの構造またはその他のプロパティを持っています。適切な圧縮アルゴリズムを使用することにより、通常使用する種類のファイルを大幅に短縮できます。
ただし、圧縮ファイルはこれらのタイプの1つではありません。圧縮アルゴリズムが適切な場合、構造と冗長性のほとんどが絞り出されており、残っているものはランダム性に非常に似ています。
これまで見てきたように、ランダムファイルを効果的に圧縮できる圧縮アルゴリズムはありません。これはランダムに見えるファイルにも適用されます。したがって、圧縮ファイルを再圧縮しようとしても大幅に短縮されることはなく、ある程度長くなる可能性があります。
そのため、圧縮アルゴリズムを有効に実行できる通常の回数は1回です。
破損は、非可逆圧縮について話している場合にのみ発生します。たとえば、JPEGファイルから画像を正確に回復できるとは限りません。これは、JPEGコンプレッサーが確実に画像ファイルを短縮できることを意味しますが、正確に回復できないという犠牲が伴います。多くの場合、画像に対してこれを行いますが、テキスト、特に実行可能ファイルに対しては行いません。
この場合、破損が始まる段階はありません。圧縮を開始すると開始し、さらに圧縮すると悪化します。そのため、優れた画像処理プログラムでは、JPEGを作成するときに必要な圧縮の程度を指定できるため、画像の品質とファイルサイズのバランスを取ることができます。停止点を見つけるには、ファイルサイズのコスト（一般にストレージよりもネット接続の方が重要）と品質の低下のコストを考慮します。明らかな正しい答えはありません。
通常、アルゴリズムが適切であれば、1回の圧縮で十分です。
実際、複数回圧縮するとサイズが大きくなる可能性があります
あなたの2つのポイントは異なります。
- 圧縮は繰り返し行われ、達成サイズ縮小の改善なし
は予想される理論的条件です - 繰り返し圧縮破損の原因
は実装のエラーである可能性が高い（またはアルゴリズム自体である可能性が高い）
次に、いくつかの例外またはバリエーションを見てみましょう。
- 暗号化は繰り返し適用サイズを縮小せずに
（実際にはサイズが大きくなる場合があります）セキュリティ強化のため - 画像、ビデオ、または音声ファイル圧縮率が増加
データを失う（ある意味で「破損」している）
無限に圧縮できます。ただし、通常、2回目以降の圧縮では、前のファイルよりも大きいファイルのみが生成されます。したがって、2回以上圧縮しても意味がありません。
ファイルは何度でも圧縮できます。ただし、ほとんどの圧縮アルゴリズムでは、2回目以降の圧縮は無視できます。
ファイルが小さくならないうちに何回圧縮できますか？
一般的に、1つでもない。使用する圧縮アルゴリズムが何であれ、always常に圧縮されていないファイルが存在する必要があります。そうでない場合は always同じ引数で、1バイトに達するまで繰り返し圧縮します。
ファイルが破損するまでに何回圧縮できますか？
ファイルの圧縮に使用するプログラムが機能する場合、ファイルが破損することはありません（もちろん、lossless圧縮を考えています）。
圧縮（ロスレスと考えています）は、基本的に何かをより簡潔に表現することを意味します。例えば
111111111111111
より簡潔に表現できる
15 X '1'
これは、ランレングスエンコーディングと呼ばれます。コンピューターが使用できる別の方法は、ファイル内で定期的に繰り返されるパターンを見つけることです。
これらの手法を使用できる量には明らかに制限があります。たとえば、ランレングスエンコーディングは、
15 X '1'
繰り返しパターンがないためです。同様に、パターン置換メソッドが長いパターンを3文字のパターンに変換する場合、残りの繰り返しパターンは3文字以下になるため、再適用してもほとんど効果がありません。一般に、すでに圧縮されたファイルに圧縮を適用すると、さまざまなオーバーヘッドのために、わずかに大きくなります。圧縮率の低いファイルに適切な圧縮を適用することは、通常、適切な圧縮のみを適用するよりも効果が低くなります。
これは、繰り返し使用することにより、任意の数字列をサイズ0に圧縮する究極の圧縮アルゴリズム（Python）です（これを読者にこれをバイト文字列に適用する方法として残しておきます）。
def compress(digitString):
if digitString=="":
raise "already as small as possible"
currentLen=len(digitString)
if digitString=="0"*currentLen:
return "9"*(currentLen-1)
n=str(long(digitString)-1); #convert to number and decrement
newLen=len(n);
return ("0"*(currentLen-newLen))+n; # add zeros to keep same length
#test it
x="12";
while not x=="":
print x;
x=compress(x)
プログラムは、12 11 10 09 08 07 06 05 04 03 02 01 00 9 8 7 6 5 4 3 2 1 0を出力してから、空の文字列を出力します。各パスで文字列を圧縮しませんが、十分なパスで任意の数字文字列を長さゼロの文字列に圧縮します。コンプレッサーを介して送信した回数を書き留めてください。そうしないと、元に戻すことができません。
とてもいい質問です。別の視点からファイルを表示できます。このファイルに算術級数が含まれていることをアプリオリに知っているかもしれません。 「バイト」、「シンボル」、または「サンプル」のデータストリームとして表示できます。
いくつかの答えはあなたに「情報理論」と「数学統計」を与えます。完全な理解のためにその研究者のモノグラフィーをチェックしてください：
情報理論の主な概念の1つは、 エントロピー です。 「バイト」のストリームがある場合....そのバイトのエントロピーは、「バイト」または「サンプル」の値に依存しません...バイトが異なる値を取得する頻度によってのみ定義された場合。最大のエントロピーは、完全なランダムデータストリーム用です。ゼロに等しい最小エントロピーは、「バイト」の値が同じ場合に備えて用意されています。
それは小さくなりませんか？
したがって、エントロピーは「バイト」あたりの最小ビット数であり、ディスクに情報を書き込むときに使用する必要があります。もちろん、神のアルゴリズムを使用する場合はそうです。実際の圧縮ロスレスヒューリスティックアルゴリズムはそうではありません。
ファイルが破損しますか？
質問の意味がわかりません。ディスクにビットを書き込むことはできません。サイズが0ビットの破損したファイルをディスクに書き込みます。もちろん破損していますが、彼のサイズはゼロビットです。
「ダブルテーブル、またはクロスマトリックス」を使用した、より高度な圧縮手法の例また、アルゴリズム内の無秩序な非本質的シンボルを排除します
[前例]ランレングスエンコーディング（おそらく最も単純で便利な圧縮）を例にとります。
04 04 04 04 43 43 43 43 51 52 11バイト
その一連のバイトは、次のように圧縮できます。
[4] 04 [4] 43 [-2] 51 52 7バイト（メタデータを括弧に入れています）
[次へ] 04.43.51.52値4.4。**-2圧縮
代替値として追加シンボルを使用したさらなる圧縮
04.A.B.Cの値4.4。**-2圧縮
理論的には、私たちは決して知ることはありません、それは終わりのないことです：
コンピュータサイエンスと数学では、完全雇用定理という用語は、あるクラスの専門家が行う特定のタスクをアルゴリズムが最適に実行できないことを示す定理を指すために使用されています。このような定理により、少なくとも特定のタスクの実行方法を改善するための新しい手法を発見し続ける無限の範囲が確保されるため、名前が付けられています。たとえば、コンパイラライターの完全雇用定理は、証明可能な完璧なサイズ最適化コンパイラのようなものは存在しないと述べています。そのようなコンパイラの証明は、終了しない計算を検出し、それらを1命令無限に減らす必要があるループ。 したがって、証明可能な完璧なサイズ最適化コンパイラの存在は、存在できない停止問題の解決策を意味し、証明自体を決定不可能な問題にします。