哈夫曼編碼的壓縮率

『壹』 哈夫曼編碼和行程編碼那個壓縮比例更大

哈夫曼編碼壓縮比例更大，相較於最基礎的行程編碼,哈夫曼編碼衡培在此攔慎森敬絕大多數條件下,都能成功的壓縮文件大小。

『貳』 Python演算法之哈夫曼編碼

問題: 哈夫曼編碼,英文名稱 Huffman Coding，有時也翻譯為霍夫曼編碼，在1952年提出的，是最好的編碼方式。哈夫曼編碼在電子通訊方面有著重要的應用，同時也廣泛應用於數據壓縮坦槐，其壓縮率通常在20% 90%之間 赫夫曼碼是可變字長編碼(VLC)的一種。哈夫曼樹是最優二叉樹， 帶權路徑長度最小的二叉樹。

原理:

假設有幾個數字40,10,20,16,14。

首先將這五個數字按照從小到大的順序排列：10, 14，16，20, 40。

構建哈夫曼樹：

1.首先選取10,14

2.重新排序：16,20,24,40

3.重新排序24,36,40,60

4.按照二叉羨信沖樹左0右1，構建哈兄殲夫曼樹

所以最終得到數字10的編碼為100，數字14的編碼為101，數字16的編碼為110，數字20的編碼為111，數字40的編碼為0。

代碼：

運行結果:

『叄』 哈夫曼編碼碼長怎麼算

假設用凳孫於通信的電文由字拆塵符集{a,b,c,d,e,f,g,h}中的字母構成，這8個字母在電文中出現的概率分別為{0.07,0.19,0.02,0.06,0.32,0.03,0.21,0.10}. (1)為這8個字母設計哈夫曼編碼。 (2)若用這三位二進制數(0…7)對這8個字母進行等長編碼，則哈夫曼編碼的平均碼長是等長編碼的百分之幾?它使電文總長平均壓縮棗御鏈多少? 解： (1)哈夫曼編碼 根據上圖可得編碼表： a:1001 b:01 c:10111 d:1010 e:11 f:10110 g:00 h:1000 (2)用三位二進行數進行的等長編碼平均長度為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%。 記得剛學哈夫曼樹的時候還做過一道簡單的題,好象是關於分數統計輸入的,找不到題目了. 參考資料： http://51zk.csai.cn/sjjg/200609041055411573.htm
求採納

『肆』 哈夫曼編碼的壓縮實現

壓縮代碼非常簡單，首先用ASCII值初始化511個哈夫曼節點：
CHuffmanNode nodes[511];
for(int nCount = 0; nCount < 256; nCount++)
nodes[nCount].byAscii = nCount;
其次，計算在輸入緩沖區數據中，每個ASCII碼出現的頻率：
for(nCount = 0; nCount < nSrcLen; nCount++)
nodes[pSrc[nCount]].nFrequency++;
然後，根據頻率進行排序：
qsort(nodes, 256, sizeof(CHuffmanNode), frequencyCompare);
哈夫曼樹，獲取每個ASCII碼對應的位序列：
int nNodeCount = GetHuffmanTree(nodes); 構造哈夫曼樹非常簡單，將所有的節點放到一個隊列中，用一個節點替換兩個頻率最低的節點，新節點的頻率就是這兩個節點的頻率之和。這樣，新節點就是兩個被替換節點的父節點了。如此循環，直到隊列中只剩一個節點（樹根）。
// parent node
pNode = &nodes[nParentNode++];
// pop first child
pNode->pLeft = PopNode(pNodes, nBackNode--, false);
// pop second child
pNode->pRight = PopNode(pNodes, nBackNode--, true);
// adjust parent of the two poped nodes
pNode->pLeft->pParent = pNode->pRight->pParent = pNode;
// adjust parent frequency
pNode->nFrequency = pNode->pLeft->nFrequency + pNode->pRight->nFrequency; 有一個好的訣竅來避免使用任何隊列組件。ASCII碼只有256個，但實際分配了511個(CHuffmanNode nodes[511])，前255個記錄ASCII碼，而用後255個記錄哈夫曼樹中的父節點。並且在構造樹的時候只使用一個指針數組(ChuffmanNode *pNodes[256])來指向這些節點。同樣使用兩個變數來操作隊列索引(int nParentNode = nNodeCount;nBackNode = nNodeCount –1)。
接著，壓縮的最後一步是將每個ASCII編碼寫入輸出緩沖區中：
int nDesIndex = 0;
// loop to write codes
for(nCount = 0; nCount < nSrcLen; nCount++)
{
*(DWORD*)(pDesPtr+(nDesIndex>>3)) |=
nodes[pSrc[nCount]].dwCode << (nDesIndex&7);
nDesIndex += nodes[pSrc[nCount]].nCodeLength;
}
(nDesIndex>>3): >>3 以8位為界限右移後到達右邊位元組的前面
(nDesIndex&7): &7 得到最高位.
此外，在壓縮緩沖區中，必須保存哈夫曼樹的節點以及位序列，這樣才能在解壓縮時重新構造哈夫曼樹（只需保存ASCII值和對應的位序列）。 解壓縮比構造哈夫曼樹要簡單的多，將輸入緩沖區中的每個編碼用對應的ASCII碼逐個替換就可以了。只要記住，這里的輸入緩沖區是一個包含每個ASCII值的編碼的位流。因此，為了用ASCII值替換編碼，我們必須用位流搜索哈夫曼樹，直到發現一個葉節點，然後將它的ASCII值添加到輸出緩沖區中：
int nDesIndex = 0;
DWORD nCode;
while(nDesIndex < nDesLen)
{
nCode = (*(DWORD*)(pSrc+(nSrcIndex>>3)))>>(nSrcIndex&7);
pNode = pRoot;
while(pNode->pLeft)
{
pNode = (nCode&1) ? pNode->pRight : pNode->pLeft;
nCode >>= 1;
nSrcIndex++;
}
pDes[nDesIndex++] = pNode->byAscii;
}

『伍』 為什麼說哈夫曼編碼是壓縮率最高的編碼

假設用於通信的電文由字元集{a,b,c,d,e,f,g,h}中的字母構成，這8個字母在電文中出現的概率分別為{0.07,0.19,0.02,0.06,0.32,0.03,0.21,0.10}。

哈夫曼編碼 根據上面可得編碼表： a:1001 b:01 c:10111 d:1010 e:11 f:10110 g:00 h:1000

用三位二進行數進行的等長編碼平均長度為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%。

因為定長編碼已經用相同的位數這個條件保證了任一個字元的編碼都不會成為其它編碼的前綴,所以這種情況只會出現在變長編碼當中，要想避免這種情況，

就必須用一個條件來制約定長編碼，這個條件就是要想成為壓縮編碼，變長編碼就必須是前綴編碼，所謂的前綴編碼就是任何一個字元的編碼都不能是另一個字元編碼的前綴。

(5)哈夫曼編碼的壓縮率擴展閱讀：

實際應用中，除採用定時清洗以消除誤差擴散和採用緩沖存儲以解決速率匹配以外，主要問題是解決小符號集合的統計匹配，

例如黑（1）、白（0）傳真信源的統計匹配，採用0和1不同長度遊程組成擴大的符號集合信源。遊程，指相同碼元的長度（如二進碼中連續的一串0或一串1的長度或個數）。按照CCITT標准，需要統計2×1728種遊程（長度），

這樣，實現時的存儲量太大。事實上長遊程的概率很小，故CCITT還規定：若l表示遊程長度，則l=64q+r。其中q稱主碼，r為基碼。編碼時，不小於64的遊程長度由主碼和基碼組成。而當l為64的整數倍時，只用主碼的代碼，已不存在基碼的代碼。

『陸』 哈夫曼字元編碼

每次合並二個最小物租的概率。一開始：c(0.02) . f(0.03) 最小，合並成一個。 cf (0.05) .並且，罩飢兆左肢旅邊先編 0，右邊編1。再繼續合並下去。

4,2,5,指1001，01，10111的個數。

『柒』 霍夫曼編碼的編碼效率怎麼求

求效率首先要求得信號的熵，也就是最小的編碼長度，比如是2.3，然後再求霍夫曼碼的平均編碼長度（各個概率和碼位相乘再求和）比如是2.7，那麼效率就是0.85。

霍夫曼編碼的編碼效率，我想可以用壓縮率來表示吧。隨機選取一段字元，租陵計算其編碼長度為 n。再對其用霍夫曼編碼，得到長度為 m。於是 m/n 就是壓縮率。

霍夫曼編碼是變長編碼，思路：對概率大的編的碼字短，概率小的編的碼字長，這樣一來所編的總碼長就小，這樣編碼效率就高。

(7)哈夫曼編碼的壓縮率擴展閱讀：

在計算機數據處理中，襪型虧霍夫曼編碼使用變長編碼表對源符號（如文件中的一個字母）進行編碼，其中變長編碼表是通過一種評估來源符號出現機率的方法得到的，出現機率高的字母使用較短的編碼，反之出現機率低的則使用較長的編碼，這便使編告神碼之後的字元串的平均長度、期望值降低，從而達到無損壓縮數據的目的。

『捌』 哈夫曼編碼（理論）

哈夫曼編碼是一種無損壓縮文件一種方法，他的思路很簡單，卻又十分經典，他利用的是無重復前綴這種思想，就是每個字元的前綴是唯一的，若a的編碼是001，那麼就不會存在另一個以001開頭的編碼了，因為，哈夫曼編碼是以二叉樹為基礎實現的，而二叉樹到每一個葉子節點的路徑是唯一的，那麼也就是說每一個字元的編碼也是唯一的。

哈夫曼編碼是一種變長編碼，比起定長編碼的ascii碼來說，哈夫曼編碼能節省很多的空間，因為每一個字元出現的頻率不是一致的，例如在英語中，『e』出現的次數是最高的，那麼如果我把『e』的編碼定義的短一點，那麼是不是比起定長編碼來說，空間就減少了？

基於這種思路，哈夫曼編碼的具體實現過程如下：
（1）首先統計文本中各字元出現的頻率（權重）。
（2）使用這些頻率（權重），構建出哈夫曼樹。
（3）規定從根節點開始，向葉子節點行走，經過左子樹，編碼為0，右子樹，編碼為1，這樣就能得到每一個葉子節點字元的編碼值了。

『玖』 利用huffman編碼對文件進行壓縮，不同文件類型壓縮率有差別的原因

怎麼沒人回答呢 我來回答吧 我想從壓縮文件的原理能得到你這個問題的答案（有點長，請耐心看，絕對長知識）： 壓縮文件的運行原理 如果您從互聯網上下載了許多程序和文件，可能會遇到很多ZIP文件。這種壓縮機制是一種很方便的發明，尤其是對網路用戶，因為它可以減小文件中的比特和位元組總數，使文件能夠通過較慢的互聯網連接實現更快傳輸，此外還可以減少文件的磁碟佔用空間。在下載了文件後，計算機可使用WinZip或Stuffit這樣的程序來展開文件，將其復原到原始大小。如果一切正常，展開的文件與壓縮前的原始文件將完全相同。
乍一聽好像很神秘：您是怎樣減少比特和位元組的數量並將它們原封不動地還原回去的呢？等一切水落石出之後，您會發現這個過程背後的基本理念其實非常簡單明了。在本文中，我們將討論這種通過簡單壓縮來明顯減小文件的方法。
大多數計算機文件類型都包含相當多的冗餘內容——它們會反復列出一些相同的信息。文件壓縮程序就是要消除這種冗餘現象。與反復列出某一塊信息不同，文件壓縮程序只列出該信息一次，然後當它在原始程序中出現時再重新引用它。
以我們熟悉的信息類型——單詞——為例子。
肯尼迪（John F. Kennedy）在1961年的就職演說中曾說過下面這段著名的話：
Ask not what your country can do for you——ask what you can do for your country.（不要問國家能為你做些什麼，而應該問自己能為國家做些什麼。）
這段話有17個單詞，包含61個字母、16個空格、1個破折號和1個句點。如果每個字母、空格或標點都佔用1個內存單元，那麼文件的總大小為79個單元。為了減小文件的大小，我們需要找出冗餘的部分。
我們立刻發現：
如果忽略大小寫字母間的區別，這個句子幾乎有一半是冗餘的。九個單詞（ask、not、what、your、country、can、do、for、you）幾乎提供了組成整句話所需的所有東西。為了構造出另一半句子，我們只需要拿出前半段句子中的單詞，然後加上空格和標點就行了。
大多數壓縮程序使用基於自適應字典的LZ演算法來縮小文件。「LZ」指的是此演算法的發明者Lempel和Ziv，「字典」指的是對數據塊進行歸類的方法。
排列字典的機制有很多種，它也可以像編號列表那樣簡單。在我們檢查肯尼迪這句著名講話時，可以挑出重復的單詞，並將它們放到編號索引中。然後，我們直接寫入編號而不是寫入整個單詞。
因此，如果我們的字典是：
ask
what
your
country
can
do
for
you
我們的句子現在就應該是這樣的：
1 not 2 3 4 5 6 7 8-- 1 2 8 5 6 7 3 4
如果您了解這種機制，那麼只需使用該字典和編號模式即可輕松重新構造出原始句子。這就是在展開某個下載文件時，計算機中的解壓縮程序所做的工作。你可能還遇到過能夠自行解壓縮的壓縮文件。若要創建這種文件，編程人員需要在被壓縮的文件中設置一個簡單的解壓縮程序。在下載完畢後，它可以自動重新構造出原始文件。
但是使用這種機制究竟能夠節省多少空間呢？「1 not 2 3 4 5 6 7 8——1 2 8 5 6 7 3 4」當然短於「Ask not what your country can do for you-- ask what you can do for your country.」，但應注意的是，我們需要隨文件一起保存這個字典。
在實際壓縮方案中，計算出各種文件需求是一個相當復雜的過程。讓我們回過頭考慮一下上面的例子。每個字元和空格都佔用1個內存單元，整個原句要佔用79個單元。壓縮後的句子（包括空格）佔用了37個單元，而字典（單詞和編號）也佔用了37個單元。也就是說，文件的大小為74個單元，因此我們並沒有把文件大小減少很多。
但這只是一個句子的情況！可以想像的是，如果用該壓縮程序處理完肯尼迪講話的其餘部分，我們會發現這些單詞以及其他單詞重復了更多次。而且，正如下一節所言，為了得到盡可能高的組織效率，可以對字典進行重寫。
在上一個的例子中，我們挑出了所有重復的單詞並將它們放在一個字典中。對於我們來說，這是最顯而易見的字典編寫方法。但是壓縮程序卻不這樣認為：它對單詞沒有概念——它只會尋找各個模式。為了盡可能減小文件的大小，它會仔細挑選出最優模式。
如果從這個角度處理該句子，我們最終會得到一個完全不同的字典。
如果壓縮程序掃描肯尼迪的這句話，它遇到的第一個冗餘部分只有幾個字母長。在ask not what your中，出現了一個重復的模式，即字母t後面跟一個空格——在not和what中。如果壓縮程序將此模式寫入字典，則每次出現「t」後面跟一個空格的情況時，它會寫入一個「1」。但是在這個短句中，此模式的出現次數不夠多，不足以將其保留為字典中的一個條目，因此程序最終會覆蓋它。
程序接下來注意到的內容是ou，在your和country中都出現了它。如果這是一篇較長的文檔，將此模式寫入字典會節省大量空間——在英語中ou是一個十分常見的字母組合。但是在壓縮程序看完整個句子後，它立即發現了一個更好的字典條目選擇：不僅ou發生了重復，而且your和country整個單詞都發生了重復，並且它們實際上是作為一個短語your country一起發生重復的。在本例中，程序會用your country條目覆蓋掉字典中的ou條目。
短語can do for也發生了重復，一次後面跟著your，另一次跟著you，因此我們又發現can do for you也是一種重復模式。這樣，我們可以用一個數字來代替15個字元（包含空格），而your country只允許我們用一個數字代替13個字元（包含空格），所以程序會用r country條目覆蓋your country條目，然後再寫入一個單獨的can do for you條目。程序通過這種方式繼續工作，挑出所有重復的信息，然後計算應該將哪一種模式寫入字典。基於自適應字典的LZ演算法中的「自適應」部分指的就是這種重寫字典的能力。程序執行此工作的過程實際上非常復雜。
無論使用什麼方法，這種深入搜索機制都能比僅僅挑出單詞這種方法更有效率地對文件進行壓縮。如果使用我們上面提取出的模式，然後用「__」代替空格，最終將得到下面這個更大的字典：
ask__
what__­
you
r__country
__can__do__for__you
而句子則較短：
「1not__2345__--__12354」
句子現在佔用18個內存單元，字典佔用41個單元。所以，我們將文件總大小從79個單元壓縮到了59個單元！這僅僅是壓縮句子的一種方法，而且不一定是最高效的方法。（看看您能找到更好的方法嗎！）
那麼這種機制到底有多好呢？文件壓縮率取決於多種因素，包括文件類型、文件大小和壓縮方案。
在世界上的大多數語言中，某些字母和單詞經常以相同的模式一起出現。正是由於這種高冗餘性，而導致文本文件的壓縮率會很高。通常大小合適的文本文件的壓縮率可以達到50%或更高。大多數編程語言的冗餘度也很高，因為它們的命令相對較少，並且命令經常採用一種設定的模式。對於包含大量不重復信息的文件（例如圖像或MP3文件），則不能使用這種機制來獲得很高的壓縮率，因為它們不包含重復多次的模式。
如果文件有大量重復模式，那麼壓縮率通常會隨著文件大小的增加而增加。從我們的例子中就可以看出這一點——如果我們摘錄的肯尼迪講話再長一些，您會發現又多次出現了我們字典中的模式，因此能夠通過每個字典條目節省更多的文件空間。此外，對於更大的文件，還可能出現具有更大普遍性的模式，從而能夠創建出效率更高的字典。
此外，文件壓縮效率還取決於壓縮程序使用的具體演算法。有些程序能夠在某些類型的文件中更好地尋找到模式，因此能更有效地壓縮這些類型的文件。其他一些壓縮程序在字典中又使用了字典，這使它們在壓縮大文件時表現很好，但是在壓縮較小的文件時效率不高。盡管這一類的所有壓縮程序都基於同一個基本理念，但是它們的執行方式卻各不相同。程序開發人員始終在嘗試建立更好的壓縮機制。
有損壓縮和無損壓縮
我們在上文中討論的壓縮類型稱為無損壓縮，因為您重新創建的文件與原始文件完全相同。所有無損壓縮都基於這樣一種理念：將文件變為「較小」的形式以利於傳輸或存儲，並在另一方收到它後復原以便重新使用它。
有損壓縮則與此大不相同。這些程序直接去除「不必要」的信息，對文件進行剪裁以使它變得更小。這種類型的壓縮大量應用於減小點陣圖圖像的文件大小，因為點陣圖圖像的體積通常非常龐大。為了了解有損壓縮的工作原理，讓我們看看你的計算機如何對一張掃描的照片進行壓縮。
對於此類文件，無損壓縮程序的壓縮率通常不高。盡管圖片的大部分看起來都是相同的——例如，整個天空都是藍色的——但是大部分像素之間都存在微小的差異。為了使圖片變得更小同時不降低其解析度，您必須更改某些像素的顏色值。如果圖片中包含大量的藍色天空，程序會挑選一種能夠用於所有像素的藍色。然後，程序重寫該文件，所有天空像素的值都使用此信息。如果壓縮方案選擇得當，您不會注意到任何變化，但是文件大小會顯著減小。
當然，對於有損壓縮，在文件壓縮後您無法將其復原成原始文件的樣子。您必須接受壓縮程序對原始文件的重新解釋。因此，如果需要完全重現原來的內容（例如軟體應用程序、資料庫和總統就職演說），則不應該使用這種壓縮形式。

『拾』 哈夫曼編碼碼長怎麼算

設某信源產生有五種符號u1、u2、u3、u4和u5，對應概率P1=0.4，P2=0.1，P3=P4=0.2，P5=0.1。

霍夫曼編碼是變長編碼，思路：對概率大的編的碼字短，概率小的編的碼字長，這樣一來所編的總碼長就小，這樣編碼效率就高。上面那樣求是不對的，除非你這6個碼字是等概率的，各佔1/6。應該用對應的概率*其對應得碼長，再求和。

實際應用中

除採用定時清洗以消除誤差擴散和採用緩沖存儲以解決速率匹配以外，主要問題是解決小符號集合的統計匹配，例如黑（1）、白（0）傳真信源的統計匹配，採用0和1不同長度遊程組成擴大的符號集合信源。遊程，指相同碼元的長度（如二進碼中連續的一串0或一串1的長度或個數）。

按照CCITT標准，需要統計2×1728種遊程（長度），這樣，實現時的存儲量太大。事實上長遊程的概率很小，故CCITT還規定：若l表示遊程長度，則l=64q+r。