Kısa metin dizeleri için etkili bir sıkıştırma algoritması [kapalı]

Küçük metin dizelerini sıkıştırmak için bir algoritma arıyorum: 50-1000 bayt (yani URL'ler). Bunun için hangi algoritma en iyi şekilde çalışır?

Smaz'a göz atın :

Smaz, çok kısa dizeleri sıkıştırmak için uygun basit bir sıkıştırma kitaplığıdır.

Huffman'ın Huffman masasının statik bir maliyeti var, bu yüzden bunun iyi bir seçim olduğuna katılmıyorum.

Bunu ortadan kaldıran uyarlanabilir sürümler vardır, ancak sıkıştırma oranı düşebilir. Aslında sormanız gereken soru, "bu özelliklere sahip metin dizelerini hangi algoritmanın sıkıştıracağıdır". Örneğin, uzun tekrarlar bekleniyorsa, basit Run-Lengh Encoding yeterli olabilir. Yalnızca İngilizce kelimelerin, boşlukların, noktalama işaretlerinin ve ara sıra rakamların bulunacağını garanti edebilirseniz, önceden tanımlanmış bir Huffman tablosu olan Huffman iyi sonuçlar verebilir.

Genel olarak, Lempel-Ziv ailesinin algoritmaları çok iyi sıkıştırma ve performansa sahiptir ve bunlar için bol miktarda kitaplık vardır. Ben onunla giderdim.

Sıkıştırılanın URL'ler olduğu bilgisiyle, sıkıştırmadan önce (hangi algoritma kolayca mevcutsa) onları KODLAYINIZ. URL'ler iyi tanımlanmış kalıpları izler ve bazı kısımları son derece tahmin edilebilirdir. Bu bilgiden yararlanarak, URL'leri başlangıçta daha küçük bir şeye kodlayabilirsiniz ve Huffman kodlamasının arkasındaki fikirler size burada yardımcı olabilir.

Örneğin, URL'yi bir bit akışına çevirirken, "http" yi bit 1 ile ve diğer her şeyi "0" biti ve ardından gerçek procotol ile değiştirebilirsiniz (veya https gibi diğer yaygın protokolleri almak için bir tablo kullanabilirsiniz. ftp, dosya). Protokolün sonunu işaretleyebildiğiniz sürece, ": //" tamamen kaldırılabilir. Vb URL formatı hakkında bilgi edinin ve daha az yer kaplamak için nasıl kodlanabileceklerini düşünün.

Elimde bir kod yok, ancak 256 * 256 karakter boyutunda bir 2D arama tablosu oluşturma yaklaşımını her zaman sevmişimdir ( RFC 1978 , PPP Predictor Compression Protocol ). Bir dizeyi sıkıştırmak için, her bir karakterin üzerinden dönersiniz ve geçerli ve önceki karakterleri tabloya dizinler olarak kullanarak 'tahmin edilen' sonraki karakteri almak için arama tablosunu kullanın. Bir eşleşme varsa tek bir 1 bit yazarsınız, aksi takdirde bir 0, karakter yazarsınız ve arama tablosunu geçerli karakterle güncellersiniz. Bu yaklaşım temelde veri akışındaki en olası sonraki karakterin dinamik (ve ham) bir arama tablosunu korur.

Sıfırlanmış bir arama tablosu ile başlayabilirsiniz, ancak en iyi sonucu, her karakter çifti için, örneğin İngilizce için en olası karakterle başlatılmışsa, çok kısa dizelerde en iyi şekilde çalışır. İlk arama tablosu sıkıştırma ve açma için aynı olduğu sürece, bunu sıkıştırılmış verilere yaymanıza gerek yoktur.

Bu algoritma mükemmel bir sıkıştırma oranı sağlamaz, ancak bellek ve CPU kaynakları açısından inanılmaz derecede tutumludur ve sürekli bir veri akışı üzerinde de çalışabilir - açıcı, açılırken arama tablosunun kendi kopyasını tutar, dolayısıyla arama tablosu sıkıştırılmakta olan verinin türünü ayarlar.

Önceden belirlenmiş bir sözlüğü destekleyen herhangi bir algoritma / kitaplık, örneğin zlib .

Bu şekilde, girişte görünmesi muhtemel olanla aynı türden bir metinle kompresörü hazırlayabilirsiniz. Dosyalar bir şekilde benzer ise (örneğin, tüm URL'ler, tüm C programları, tüm StackOverflow gönderileri, tüm ASCII-art çizimleri), giriş dosyalarının çoğunda veya tamamında belirli alt dizeler görünecektir.

Aynı alt dize bir girdi dosyasında birden çok kez tekrarlanırsa her sıkıştırma algoritması yerden tasarruf sağlar (örneğin, İngilizce metinde "the" veya C kodunda "int").

Ancak URL'ler söz konusu olduğunda belirli dizeler (ör. " Http: // www .", ".Com", ".html", ".aspx" genellikle her girdi dosyasında bir kez görünür. Bu nedenle, bunları dosyalar arasında paylaşmanız gerekir. her nasılsa dosya başına bir sıkıştırılmış oluşumdan ziyade, bunları önceden belirlenmiş bir sözlüğe yerleştirmek bunu başaracaktır.

Huffman kodlaması genellikle bunun için iyi çalışır.

Metni sadece kısaltmaktan değil, sıkıştırmaktan bahsediyorsanız, Deflate / gzip (gzip etrafında sarmalayıcı), zip daha küçük dosyalar ve metinler için iyi çalışır. Diğer algoritmalar, bzip2 gibi daha büyük dosyalar için oldukça etkilidir.

Wikipedia'da bir sıkıştırma süreleri listesi vardır. (verimlilik karşılaştırmasına bakın)

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 için Standart Sıkıştırma Şemasına bir göz atmak isteyebilirsiniz .

SQL Server 2008 R2 bunu dahili olarak kullanır ve% 50'ye kadar sıkıştırma sağlayabilir.