短いテキスト文字列の効率的な圧縮アルゴリズム[終了]

小さなテキスト文字列を圧縮するアルゴリズムを探しています：50〜1000バイト（つまり、URL）。これに最適なアルゴリズムはどれですか？

Smazをチェックしてください。

Smazは、非常に短い文字列の圧縮に適したシンプルな圧縮ライブラリです。

ハフマンには静的コスト、ハフマンテーブルがあるので、それは良い選択ではないことに同意します。

これを廃止する適応バージョンがありますが、圧縮率が低下する可能性があります。実際、あなたが尋ねるべき質問は、「これらの特性を持つテキスト文字列を圧縮するためのアルゴリズム」です。たとえば、長い繰り返しが予想される場合、単純なRun-Lenghエンコーディングで十分な場合があります。英語の単語、スペース、句読点および時折の数字のみが存在することを保証できる場合は、事前定義されたハフマンテーブルを備えたハフマンが良い結果をもたらす可能性があります。

一般に、Lempel-Zivファミリーのアルゴリズムは非常に優れた圧縮とパフォーマンスを備えており、それらのライブラリは豊富です。私はそれで行きます。

圧縮されるのはURLであるという情報があれば、圧縮する前に（簡単に利用できるアルゴリズムで）、それらをCODIFYすることをお勧めします。URLは明確に定義されたパターンに従っており、その一部は非常に予測可能です。この知識を利用することで、URLを最初はより小さなものに体系化でき、ハフマンエンコーディングの背後にあるアイデアがここで役立ちます。

たとえば、URLをビットストリームに変換する場合、「http」をビット1に置き換え、それ以外をビット「0」で置き換えた後に実際のプロトコルを続けることができます（またはテーブルを使用して、httpsなどの他の一般的なプロトコルを取得します。 ftp、ファイル）。プロトコルの終わりをマークできる限り、「：//」は完全に削除できます。等URL形式について読み、それらをどのようにコード化してより少ないスペースを取ることができるかを考えてください。

渡すコードはありませんが、サイズが256 * 256文字の2Dルックアップテーブルを作成するアプローチは常に気に入っていました（RFC 1978、PPP Predictor Compression Protocol）。文字列を圧縮するには、各文字をループし、ルックアップテーブルを使用して、現在および以前の文字をテーブルのインデックスとして使用して、「予測された」次の文字を取得します。一致がある場合は1ビットを1つ書き込み、それ以外の場合は0を書き込み、charを指定して、現在のcharでルックアップテーブルを更新します。このアプローチは基本的に、データストリーム内の最も可能性の高い次の文字の動的（かつ大雑把な）ルックアップテーブルを維持します。

ゼロ化されたルックアップテーブルから始めることもできますが、英語などの各文字ペアの最も可能性の高い文字で初期化されている場合は、非常に短い文字列で最も効果的に機能します。初期ルックアップテーブルが圧縮と解凍で同じである限り、圧縮されたデータに出力する必要はありません。

このアルゴリズムは優れた圧縮率を提供しませんが、メモリとCPUリソースを非常に節約し、データの連続ストリームで動作することもできます-解凍器は解凍するときにルックアップテーブルの独自のコピーを保持するため、ルックアップテーブル圧縮されるデータのタイプに調整します。

プリセット辞書をサポートする任意のアルゴリズム/ライブラリー、例えばzlib。

このようにして、入力に現れる可能性のある同じ種類のテキストでコンプレッサーを準備できます。ファイルが何らかの形で類似している場合（たとえば、すべてのURL、すべてのCプログラム、すべてのStackOverflowポスト、すべてのASCIIアート図面）、特定の部分文字列がほとんどまたはすべての入力ファイルに表示されます。

1つの入力ファイルで同じ部分文字列が複数回繰り返される場合、すべての圧縮アルゴリズムはスペースを節約します（たとえば、英語のテキストの「the」またはCコードの「int」）。

ただし、URLの場合、特定の文字列（「http：// www。」、「。com」、「。html」、「。aspx」は通常、各入力ファイルに一度だけ表示されます。したがって、ファイル間で共有する必要がありますファイルごとに1つの圧縮オカレンスを持つのではなく、プリセット辞書に配置することでこれを実現できます。

ハフマンコーディングは通常、これで問題なく動作します。

単に短縮するだけでなく、Deflate / gzip（gzipのラッパー）ではなく実際にテキストを圧縮することについて話している場合、zipは小さいファイルやテキストに適しています。その他のアルゴリズムは、bzip2などの大きなファイルに対して非常に効率的です。

ウィキペディアには、圧縮時間のリストがあります。（効率の比較を探す）

Name       | Text         | Binaries      | Raw images
-----------+--------------+---------------+-------------
7-zip      | 19% in 18.8s | 27% in  59.6s | 50% in 36.4s
bzip2      | 20% in  4.7s | 37% in  32.8s | 51% in 20.0s
rar (2.01) | 23% in 30.0s | 36% in 275.4s | 58% in 52.7s
advzip     | 24% in 21.1s | 37% in  70.6s | 57& in 41.6s
gzip       | 25% in  4.2s | 39% in  23.1s | 60% in  5.4s
zip        | 25% in  4.3s | 39% in  23.3s | 60% in  5.7s

あなたは見てとることもできますUnicodeの標準圧縮スキーム。

SQL Server 2008 R2はこれを内部で使用し、最大50％の圧縮を実現できます。