長さが約 255 文字までの文字列を圧縮する本当に簡単な方法はありますか (はい、URLを圧縮しています)。
圧縮の強さには関心がありません。パフォーマンスが非常に高く、すぐに実装できるものを探しています。SharpZipLibよりも単純なもの、つまりいくつかの短いメソッドで実装できるものが欲しいです。
長さが約 255 文字までの文字列を圧縮する本当に簡単な方法はありますか (はい、URLを圧縮しています)。
圧縮の強さには関心がありません。パフォーマンスが非常に高く、すぐに実装できるものを探しています。SharpZipLibよりも単純なもの、つまりいくつかの短いメソッドで実装できるものが欲しいです。
ここでの重要な質問は、「なぜ URL を圧縮したいのか?」ということだと思います。
アドレスバーの長い URL を短縮しようとしていますか?
元の URL をどこかに (データベース、テキスト ファイルなど) 保存し、ドメイン以外の部分のハッシュコード (MD5 は問題ありません) と一緒に保存することをお勧めします。次に、MD5 を読み取って実際の URL を検索するための単純なページ (または派手な場合は HTTPModule) を作成できます。これが TinyURL などの仕組みです。
例えば:
http://mydomain.com/folder1/folder2/page1.aspx
次のように短縮できます。
http://mydomain.com/2d4f1c8a
これに圧縮ライブラリを使用してもうまくいきません。文字列はより短いバイナリ表現に圧縮されますが、これを URL の一部として有効である必要がある文字列 (Base64 など) に変換すると、圧縮によって得られた利点がすべて無効になります。
メモリまたはディスクに多数の URL を保存していますか?
System.IO.Compression 内の組み込みの圧縮ライブラリ、またはシンプルで信じられないほど優れた ZLib ライブラリを使用します。バイナリデータを保存するので、圧縮された出力はそのままで問題ありません。URL として使用するには、圧縮を解除する必要があります。
受け入れられた回答で示唆されているように、データ圧縮を使用しても、すでにかなり短い URL パスを短縮することはできません。
DotNetZipには、静的 (VB で共有) CompressStringメソッドを公開する DeflateStream クラスがあります。DEFLATE ( RFC 1951 ) を使用して文字列を圧縮する 1 行の方法です。DEFLATE 実装はSystem.IO.Compression.DeflateStreamと完全に互換性がありますが、DotNetZip の方が圧縮率が高くなります。使用方法は次のとおりです。
string[] orig = {
"folder1/folder2/page1.aspx",
"folderBB/folderAA/page2.aspx",
};
public void Run()
{
foreach (string s in orig)
{
System.Console.WriteLine("original : {0}", s);
byte[] compressed = DeflateStream.CompressString(s);
System.Console.WriteLine("compressed : {0}", ByteArrayToHexString(compressed));
string uncompressed = DeflateStream.UncompressString(compressed);
System.Console.WriteLine("uncompressed: {0}\n", uncompressed);
}
}
そのコードを使用して、ここに私のテスト結果があります:
original : folder1/folder2/page1.aspx
compressed : 4bcbcf49492d32d44f03d346fa0589e9a9867a89c5051500
uncompressed: folder1/folder2/page1.aspx
original : folderBB/folderAA/page2.aspx
compressed : 4bcbcf49492d7272d24f03331c1df50b12d3538df4128b0b2a00
uncompressed: folderBB/folderAA/page2.aspx
したがって、「圧縮された」バイト配列は、16 進数で表すと元の配列よりも長く、約 2 倍の長さです。その理由は、16 進バイトが実際には 2 つの ASCII 文字であるためです。
基数 16 (16 進数) の代わりに基数 62 を使用して数値を表すことで、これをある程度補正できます。その場合、az と AZ も数字であり、0-9 (10) + az (+26) + AZ (+26) = 合計 62 桁になります。これにより、出力が大幅に短縮されます。私はそれを試していません。まだ。
EDITOK
Base-62エンコーダーをテストしました。六角ストリングを約半分に短縮します。25% (62/16 =~ 4) に削減されると考えましたが、離散化で何かを失っていると思います。私のテストでは、base-62 でエンコードされた結果の文字列は、元の URL とほぼ同じ長さです。いいえ、圧縮を使用してから base-62 エンコーディングを使用することは、まだ適切な方法ではありません。あなたは本当にハッシュ値が欲しいです。
System.IO.Compression名前空間を調べることをお勧めします。役立つかもしれないCodeProjectに関する記事があります。
あなたの目標は何ですか?
この質問で説明されているように、ヘッダー チェックサムやフッターなしで、デフレート アルゴリズムを直接使用できます: Python: Inflate and Deflate implementations
私のテストでは、これにより 4100 文字の URL が 1270 base64 文字に削減され、IE の 2000 制限内に収まるようになりました。
これは4000 文字の URLの例です。アプレットは任意のサーバーに存在する可能性があるため、ハッシュテーブルでは解決できません。
まず、既存の(無料またはオープンソースの)zipライブラリの1つを試してみます。たとえば、http ://www.icsharpcode.net/OpenSource/SharpZipLib/
Zipはテキスト文字列に対して適切に機能するはずですが、圧縮アルゴリズムyourserlfを実装する価値があるかどうかはわかりません。
gzipを使ってみましたか?
このような短い文字列で効果的に機能するかどうかはわかりませんが、おそらく最善の策だと思います。
オープンソースライブラリSharpZipLibは使いやすく、圧縮ツールを提供します