壓縮哈夫曼演算法

A. 哈夫曼編碼的壓縮率怎麼算

哈夫曼編碼壓縮率很低的
舉個例子：用三位二進行數進行的等長編碼平均長度為3，而根據哈夫曼樹編碼的平均碼長為：
4*0.07+2*0.19+5*0.02+4*0.06+2*0.32+5*0.03+2*0.21+4*0.10=2.61
2.61/3=0.87=87%
其平均碼長是等長碼的87%。
所以平均壓縮率為13%。
所以應該是你演算法有問題……

B. 用huffman演算法實現「文件的壓縮與解壓」怎麼做啊

我寫過一個Huffman編碼，但只是生成了編碼表，沒做成壓縮，但可以利用查表做成文件壓縮，另外用的是C++，改成C的話比較容易，只要把動下內存分配就行了，想要的話,msn:[email protected]

C. 基於哈夫曼樹的文件壓縮與解壓演算法（C++版）

static unsigned int out = 0x01;

void write_bit(bool bit)
{
out <<= 1; // shift byte to make room
if (bit) out |= 0x01; // set lowest bit id desired

if (out & 0x100) { // was the sentinel bit shifted out?
write_byte(out & 0xff); // final output of 8-bit chunk
out = 0x01; // reset to sentinel vylue
}
}

void flush_bit()
{
while (out != 0x01) write_bit(false);
}

int main()
{
write_bit(1);
write_bit(0);
write_bit(1);
// ...
flush_bit();

return 0;
}

D. 求助：用java實現哈夫曼編碼壓縮與解壓縮演算法。

你好，由於內容比較多，先概述一下先。如圖所示，為我寫的一個壓縮軟體，原理是利用哈弗曼演算法實現的。我將資料整理好稍後就發到你郵箱，但在這里簡要說明一下代碼。

請看我的空間

http://hi..com/%D2%B6%BF%C6%C1%BC/blog

中的文章共5篇（太長了）

http://hi..com/%D2%B6%BF%C6%C1%BC/blog/item/93c35517bb528146f2de32fd.html

1.HuffmanTextEncoder類完成壓縮功能，可直接運行，壓縮測試用文本文件。

2.HuffmanTextDecoder類完成解壓縮功能，可直接運行，解壓縮壓縮後的文本文件。

3.BitReader,工具類，實現對BufferedInputStream的按位讀取。

4.BitWriter,工具類，實現按位寫入的功能。該類來自網路。

5.MinHeap<T>,模板工具類，實現了一個最小堆。生成Huffman樹時使用。

E. 請專家解釋:WinRAR的壓縮演算法是基於哈夫曼演算法的嗎

注:哈夫曼和LZSS演算法不是同一種演算法,先用哈夫曼再用LZSS演算法壓縮後會發現經哈夫曼壓縮後再用LZSS壓縮文件會變大,具體原因不明
LZSS原理:
把編碼位置置於輸入數據流的開始位置。
在前向緩沖器中查找窗口中最長的匹配串
① Pointer ：=匹配串指針。
② Length ：=匹配串長度。
判斷匹配串長度Length是否大於等於最小匹配串長度(MIN_LENGTH) ，
如果「是」：輸出指針，然後把編碼位置向前移動Length個字元。
如果「否」：輸出前向緩沖存儲器中的第1個字元，然後把編碼位置向前移動一個字元。
如果前向緩沖器不是空的，就返回到步驟2。
例：編碼字元串如表03-05-3所示，編碼過程如表03-05-4所示。現說明如下：
「步驟」欄表示編碼步驟。
「位置」欄表示編碼位置，輸入數據流中的第1個字元為編碼位置1。
「匹配」欄表示窗口中找到的最長的匹配串。
「字元」欄表示匹配之後在前向緩沖存儲器中的第1個字元。
「輸出」欄的輸出為：
① 如果匹配串本身的長度Length >= MIN_LENGTH，輸出指向匹配串的指針，格式為(Back_chars， Chars_length)。該指針告訴解碼器「在這個窗口中向後退Back_chars個字元然後拷貝Chars_length個字元到輸出」。
② 如果匹配串本身的長度Length >= MIN_LENGTH，則輸出真實的匹配串。
表:輸入數據流
位置 1234567891011
字元 AABBCBBAABC
表:編碼過程(MIN_LENGTH = 2)
步驟位置匹配串輸出
11--A
22AA
33-- B
44BB
55--C
66B B(3,2)
78 A A B(7,3)
811CC

F. 用哈夫曼樹演算法設計對文件文件的壓縮和解壓縮的實驗程序解析

樓主可以去看看最優二叉樹的編碼問題。
1、哈夫曼編碼
在數據通信中，需要將傳送的文字轉換成二進制的字元串，用0，1碼的不同排列來表示字元。例如，需傳送的報文為「AFTER DATA EAR ARE ART AREA」，這里用到的字元集為「A，E，R，T，F，D」，各字母出現的次數為{8，4，5，3，1，1}。現要求為這些字母設計編碼。要區別6個字母，最簡單的二進制編碼方式是等長編碼，固定採用3位二進制，可分別用000、001、010、011、100、101對「A，E，R，T，F，D」進行編碼發送，當對方接收報文時再按照三位一分進行解碼。顯然編碼的長度取決報文中不同字元的個數。若報文中可能出現26個不同字元，則固定編碼長度為5。然而，傳送報文時總是希望總長度盡可能短。在實際應用中，各個字元的出現頻度或使用次數是不相同的，如A、B、C的使用頻率遠遠高於X、Y、Z，自然會想到設計編碼時，讓使用頻率高的用短碼，使用頻率低的用長碼，以優化整個報文編碼。
為使不等長編碼為前綴編碼，可用字元集中的每個字元作為葉子結點生成一棵編碼二叉樹，為了獲得傳送報文的最短長度，可將每個字元的出現頻率作為字元結點的權值賦予該結點上，求出此樹的最小帶權路徑長度就等於求出了傳送報文的最短長度。因此，求傳送報文的最短長度問題轉化為求由字元集中的所有字元作為葉子結點，由字元出現頻率作為其權值所產生的哈夫曼樹的問題。利用哈夫曼樹來設計二進制的前綴編碼，既滿足前綴編碼的條件，又保證報文編碼總長最短。
哈夫曼靜態編碼：它對需要編碼的數據進行兩遍掃描：第一遍統計原數據中各字元出現的頻率，利用得到的頻率值創建哈夫曼樹，並必須把樹的信息保存起來，即把字元0-255(2^8=256)的頻率值以2-4BYTES的長度順序存儲起來，（用4Bytes的長度存儲頻率值，頻率值的表示範圍為0--2^32-1，這已足夠表示大文件中字元出現的頻率了）以便解壓時創建同樣的哈夫曼樹進行解壓；第二遍則根據第一遍掃描得到的哈夫曼樹進行編碼，並把編碼後得到的碼字存儲起來。
哈夫曼動態編碼：動態哈夫曼編碼使用一棵動態變化的哈夫曼樹，對第t+1個字元的編碼是根據原始數據中前t個字元得到的哈夫曼樹來進行的，編碼和解碼使用相同的初始哈夫曼樹，每處理完一個字元，編碼和解碼使用相同的方法修改哈夫曼樹，所以沒有必要為解碼而保存哈夫曼樹的信息。編碼和解碼一個字元所需的時間與該字元的編碼長度成正比，所以動態哈夫曼編碼可實時進行。[3]
2、哈夫曼解碼
在通信中，若將字元用哈夫曼編碼形式發送出去，對方接收到編碼後，將編碼還原成字元的過程，稱為哈夫曼解碼。[4]

G. 如何用C語言編輯哈夫曼樹進行文件壓縮

http://hi..com/chzhn/blog/item/517798879fd3d029c75cc368.html
這是我很早以前的一篇文章,裡面有注釋,可以對照著看下,
希望樓主明白,完全聽別人講解不是一種好的學習方法,可以自己先看看,不懂的地方再問.

H. 哈夫曼壓縮演算法的內容是什麼

注:哈夫曼和lzss演算法不是同一種演算法,先用哈夫曼再用lzss演算法壓縮後會發現經哈夫曼壓縮後再用lzss壓縮文件會變大,具體原因不明
lzss原理:
把編碼位置置於輸入數據流的開始位置。
在前向緩沖器中查找窗口中最長的匹配串
①
pointer
：=匹配串指針。
②
length
：=匹配串長度。
判斷匹配串長度length是否大於等於最小匹配串長度(min_length)
，
如果「是」：輸出指針，然後把編碼位置向前移動length個字元。
如果「否」：輸出前向緩沖存儲器中的第1個字元，然後把編碼位置向前移動一個字元。
如果前向緩沖器不是空的，就返回到步驟2。
例：編碼字元串如表03-05-3所示，編碼過程如表03-05-4所示。現說明如下：
「步驟」欄表示編碼步驟。
「位置」欄表示編碼位置，輸入數據流中的第1個字元為編碼位置1。
「匹配」欄表示窗口中找到的最長的匹配串。
「字元」欄表示匹配之後在前向緩沖存儲器中的第1個字元。
「輸出」欄的輸出為：
①
如果匹配串本身的長度length
>=
min_length，輸出指向匹配串的指針，格式為(back_chars，
chars_length)。該指針告訴解碼器「在這個窗口中向後退back_chars個字元然後拷貝chars_length個字元到輸出」。
②
如果匹配串本身的長度length
>=
min_length，則輸出真實的匹配串。
表:輸入數據流
位置
1234567891011
字元
aabbcbbaabc
表:編碼過程(min_length
=
2)
步驟位置匹配串輸出
11--a
22aa
33--
b
44bb
55--c
66b
b(3,2)
78
a
a
b(7,3)
811cc

I. 跪求哈夫曼編碼壓縮與其它壓縮演算法的比較（復雜性和壓縮效果）

（1）所形成的Huffman編碼的碼字是不是唯一的，但是可以被指定為唯一的編碼效率為「1」大，小的是「0」時，兩個最小概率符號賦值。反之也可以。如果兩個符號的發生的概率是相等的，排列無論前面是可能的，所以霍夫曼碼字的結構不是唯一的，對於相同的信息源，不管如何在上述的順序安排的，它的平均碼字長度是不改變，因此，編碼效率是獨一無二的。
（2）只有當不均勻時，每個符號的信息源的發生的概率，霍夫曼編碼的效果是唯一明顯的。
（3）霍夫曼編碼必須是精確的原始文件中的各符號的發生頻率的統計數據，並且如果沒有準確的統計數據，壓縮將低於預期。 Huffman編碼通常必須經過兩道，第一遍統計的第二次產生編碼，編碼速度是比較慢的。電路的復雜性的另一種實現的各種長度的編碼，解碼處理是相對復雜的，因此，解壓縮處理是相對緩慢。
（4）Huffman編碼只能使用整數來表示一個符號，而不是使用小數，這在很大程度上限制了壓縮效果。
（5）霍夫曼是所有的位，如果改變其中一個可以使數據看起來完全不同