2012-06-04 32 views
5

我想壓縮很多小字符串(大約75-100長度的c#字符串)。 當字典被創建時,我已經知道所有的短字符串(接近1萬億)。未來不會有額外的短串。 我需要額外的一個字符串,而不需要解壓縮其他字符串。壓縮小字符串,用什麼來創建外部字典?

現在我正在尋找一個圖書館或做以下的最佳方式:

  1. 創建字典使用我
  2. 所有字符串使用該字典
  3. 的方式壓縮每串使用從1的字典壓縮一個字符串。

我發現一個good related question,但這不是c#特定的。也許有些東西是我不知道的c#,或者一個花哨的圖書館或者某個人已經完成了。這就是我問這個問題的原因。

編輯:

隨着字典,我在談論這樣的事情:http://en.wikipedia.org/wiki/Dictionary_coder 但是,一切都有助於獲得字符串短。字符串是各種語言和URL(30%/ 70%)的簡短文本消息。壓縮的字符串不需要人類可讀。它將被存儲在二進制文件中。

+0

字符串中的數據類型是什麼? (主要是ASCII?隨機字母?GUID?) – Cameron

+0

通過詞典,你的意思是存儲鍵值對的.NET Dictionary類嗎?這些字符串是否會用作字典中的鍵或值?如果字符串只是值,那麼鍵是什麼? –

+0

主要是ascii,而不是隨機的。像簡短的短信,句子和網址。 – Chris

回答

1

如果有一萬億字符串且不再有,則每個字符都可以用40位(5個字節)表示。所有你需要的是一種使用5字節作爲萬億字符串索引的方法。

你怎麼知道萬億字符串?如果壓縮器和解壓縮器都可以訪問所有萬億字符串,或者如果有方法來訂購和重新創建字符串,那麼您所需要的只是索引。

如果找不到索引字符串的方法,則可以取一部分字符串並將它們用作壓縮器的字典。只要拿出最有代表性的樣本(你需要弄清楚什麼可能會使某些字符串比其他字符串更常見或更具代表性),並將它們連接成32K字典。你的萬億字符串中有大約400個。然後,zlib的compress端的deflateSetDictionary和解壓端的inflateSetDictionary都使用完全相同的32K字典。這將在短弦上提供良好的壓縮。

+0

第一個不適用於特殊領域。但第二個(deflateSetDictionary)聽起來很有希望。我有一個關於字典的問題:假設我在字典中有以下值:「CDEFGHIJK」和「ABC」等。當我壓縮字符串「ABCDEFGHIJK」時,它會使用值「ABC」,然後不是我的字典中的「CDEFGHIJK」,還是不會使用「ABC」,但會使用「CDEFGHIJK」(哪種更好)? – Chris

+0

另外一個問題:你寫了我應該使用我的萬億字符串中的400。 32K是字典的大小還是數值?看起來它是一個字節數組,它將以null結尾的字符串,在最後有最可能的字符串。 – Chris

+0

放氣會找到並使用較長的字符串進行匹配。這通常更好。如果您知道哪些字符串可能更常見,那麼您應該將這些字符串放在字典的末尾,並且在開始時不太常見。 (這導致距離編碼的平均比特數較少)。32K是字典的大小。所以400根琴絃僅僅是從你的「75-100」中粗略估計有多少適合。 –

1

我還沒有使用它,但Smaz聽起來有希望爲這個...

Smaz適用於壓縮非常 短串簡單的壓縮庫。通用壓縮庫將構建動態壓縮數據所需的 狀態,以便能夠對每種數據進行壓縮。這是一個非常好的主意,但不適用於 特定問題:壓縮小字符串將不起作用。

Smaz反而不利於壓縮通用數據,但在一般情況下,40-50%可以 壓縮文本(與 英語工作得更好),並且能夠進行位壓縮的HTML和 網址也是如此。重要的一點是,Smaz能夠壓縮即使是兩個或三個字節的字符串也可以壓縮 !

例如,字符串「the」被壓縮爲單個字節。

由於它是用C編寫的,請查看Bart De Smet's example for interoping with C through C#

+0

如果他們是一個已知語言的短文本字符串; smaz聽起來很理想;它會將簡短的普通動詞(即,他,她,她,我等)壓縮成非常短的字節序列。如果字符串失去了這種模式,你甚至可能會看到你的壓縮字符串更長! –

+0

你可以嘗試翻譯它,或使用interop(請參閱我的更新答案)。 –

+0

C#版本在這裏:https://github.com/poulfoged/SentenceCompression – gameweld