このアイデアは私の頭の中に3年間流れていましたが、それを適用するのに問題があります。ファイルサイズを半分に削減する圧縮アルゴリズムを作成したかったのです。
例：8 mb〜4 mb
プログラミングの検索と経験を積んで、私は次のことを理解しました。
文字（a、b、c、d）を含む.txtファイルを見てみましょう
IO.File.ReadAllBytes関数を使用すると、次のバイト配列が得られます：（97 | 98 | 99 | 100）、これによると：https：//en.wikipedia.org/wiki/ASCII#ASCII_control_code_chartは文字の10進値です。
私が考えたのは、2つのメンバーをそれぞれ1つのメンバーに結合することによって、この4メンバー配列を2メンバー配列のみに数学的にカットする方法ですが、2つの数値を数学的に組み合わせて、単純に元に戻すことはできません。多くの可能性、例えば
80 | 90：90 + 80 = 170ですが、170が100 +70や110 + 60とは異なり80 + 90の結果であったことを知る方法はありません。
そして、それを克服できたとしても、配列の1つのメンバーのバイトの最大値（255バイト）によって制限されます。
ほとんどの圧縮アルゴリズムがバイナリ圧縮を使用していて成功したことは理解していますが、ファイルサイズを半分に削減することを想像してみてください。これについてのあなたの考えを聞きたいと思います。
宜しくお願いします。
すべてのファイルを短くする圧縮アルゴリズムを作成することは不可能です。証明は「カウント引数」と呼ばれ、簡単です。
長さLの256 ^ Lの可能なファイルがあります。
長さがL未満のN（L）個の可能なファイルがあるとしましょう。
計算すると、256 ^ L = 255 * N（L）+1であることがわかります。
そう。長さLのすべてのファイルを圧縮することはできません。これは、ファイルを一意に保持するのに十分な短いファイルがないためです。常に長さLのファイルを短縮するコンプレッサーを作成した場合、多くのファイルを同じ短いファイルに圧縮する必要があります。もちろん、解凍時に元に戻すことができるのはそのうちの1つだけです。
実際、長さLのファイルの数は短いファイルの255倍を超えるため、長さLのほとんどのファイルを圧縮することさえできません。実際に短くなるのはごく一部です。
これは、comp.compression FAQで（再び）かなりよく説明されています：http：//www.faqs.org/faqs/compression-faq/part1/section-8.html
編集：それで、あなたは今、この圧縮のものがすべてについて何であるか疑問に思っているかもしれません...
さて、それらの「長さLのすべての可能なファイル」の大部分はランダムなゴミです。ロスレスデータ圧縮は、実際に使用するファイルに短い表現（出力ファイル）を割り当てることで機能します。
たとえば、ハフマンエンコーディングは文字ごとに機能し、最も一般的な文字を書き込むために使用するビット数が少なくなります。たとえば、「e」は「q」よりもテキストで頻繁に発生するため、「e」の書き込みには3ビットしか費やさないが、「q」の書き込みには7ビットを費やす可能性があります。文字131のように、ほとんど発生しないバイトは、元の8ビットバイトよりも長い9ビットまたは10ビットで書き込まれる場合があります。平均して、この方法で簡単な英語のテキストをほぼ半分に圧縮できます。
LZおよび同様のコンプレッサー（PKZIPなど）は、ファイル内で発生するすべての文字列を記憶し、既に発生している文字列には短いエンコーディングを割り当て、まだ表示されていない文字列には長いエンコーディングを割り当てます。これは、エンコードされたすべての文字のコンテキストに関するより多くの情報を考慮に入れるため、さらにうまく機能します。「e」は「y」よりも一般的ですが、「boy」はより頻繁に発生するため、平均して、「boe」よりも「boy」を書き込むのに必要なビット数は少なくなります。
実際に使用するファイルの特性を予測することがすべてであるため、これは少しブラックアートであり、さまざまな種類のコンプレッサーがさまざまな種類のデータに対して良くも悪くも機能します。そのため、非常に多くの異なるアルゴリズムがあります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加