2010-06-20 35 views
2

我需要一個庫/工具/函數,將50-60個字符長的字符串壓縮爲較小。使字符串變小c#

你知道嗎?

+1

加密通常不會使數據變小。你是說壓縮? – 2010-06-20 18:36:17

+4

由於鴿子的原理(http://en.wikipedia.org/wiki/Pigeonhole_principle),對於所有琴絃都是不可能的。 – Eilon 2010-06-20 18:40:30

+2

你能告訴我們這些字符串是什麼樣子嗎?他們將包含哪些字符?幾個樣本應該是好的 – mpen 2010-06-20 18:40:57

回答

0
+3

考慮到GZip需要最小10字節的頁眉和8字節的頁腳,這種解決方案不適用於50-60個字符的字符串。 – 2010-06-20 18:38:17

+0

我同意大衛...我測試了100個字符,然後結果出來了170個字符.. – Kaan 2010-06-21 15:19:13

5

這種規模的有效壓縮將是困難的。你可能會考慮Huffman coding。這可能會給你比gzip更小的壓縮(因爲它會導致二進制代碼而不是基本-85序列)。

+0

好了,然後,我需要一些測試類:) – Kaan 2010-06-21 15:08:33

+0

@Kaan,我很高興花幾分鐘放在一起但是,正如其他人所說的,除非你能提供你正在使用的字符串的一些例子,否則它們將不會有用。 – 2010-06-21 15:22:21

+0

這裏是例子:http:// localhost:52294/Default.html?LA = 40,9305222197136&LO = 29,8102416992188&N = t%FCrkiye%20denemE&D = kaan&M = r&Z = 4,謝謝大衛:) – Kaan 2010-06-21 15:46:19

1

該框架包括GZipStreamDeflateStream類。但是這可能不是你想要的 - 什麼輸入字符串必須被壓縮?只有ASCII碼?只有信件?字母數字字符串?完整的Unicode?什麼是允許的輸出字符串?

從算法的角度來看,如果沒有對可能輸入空間的進一步瞭解,我建議使用arithmetic coding。與Huffman coding相比,這可能會將壓縮後的尺寸縮小几個附加位,因爲它不限於每個符號的整數位數 - 這在處理這種小型輸入時可能變得很重要。

+0

GZip需要最少18個字節的開銷,這會在這個規模上喪失其效力。 – 2010-06-20 18:40:06

1

您是否想過使用加密哈希?例如,SHA-1(http://en.wikipedia.org/wiki/SHA-1)可用於輸入字符串以產生20字節的摘要。當然,摘要總是20個字節 - 即使輸入字符串比20個字節短。

+3

散列不是壓縮也不是加密 – jdehaan 2010-06-20 18:42:20

+2

考慮到原始問題的含糊性,這可能是最好的答案。 – EricLaw 2010-06-20 19:09:20

0

我會使用一些基本的,如RLE或基於共享字典的壓縮,然後是block cipher,保持大小不變​​。

也許smaz對你而言也很有意思。的基本壓縮算法

實例:

  • RLE(修改或不)
  • 霍夫曼編碼
  • 挖洞輪車變換塊密碼( 「位twiddlers」)的

實例:

  • AES
  • 河豚
  • DES
  • 三重DES
  • Twofish的

你將能夠找出使用(以上鍊接)維基百科是什麼fullfills您的需求。

+1

如果輸入數據預計會有許多相同數據的內部運行,那麼這並不是一個壞建議。典型的文本數據不符合該要求。 – 2010-06-20 18:44:55

1

如果您的字符串只包含a-z和0-9之間的小寫字符,您可以將它編碼爲7位。

這會將60個字符串壓縮爲53個字節。如果你不需要數字,你可以使用6位數字,把它減少到45個字節。

因此,選擇正確的壓縮方法取決於您的字符串包含的數據。