使用膨脹算法掙扎

即使在閱讀RFC並查看c和javascript實現後，我也很難理解膨脹算法是如何工作的。我用文本「TestingTesting」壓縮了一個文件，並以十六進制得到了如下結果：0B 49 2D 2E C9 CC 4B 0F 81 50 00使用膨脹算法掙扎

我試過讀取16位和32位endian交換後的數據，前三位我無法再進一步了，因爲接下來的5位沒有意義。我在做什麼錯，怎麼解析？

參考我使用： RFC 1951 Javascript C

2011-09-12 ItsJustMe

請發佈您的代碼，以便我們可以幫助您。我們無法讀懂頭腦，因此很難說明問題的出處在哪裏。 – sbtkd85

我還沒有寫任何代碼，因爲我仍然試圖理解如何正確解析這些位。在理解了算法之後，編碼和驗證將變得更容易。我希望有人能夠幫助我分解並解析前幾個代碼示例中的位。 – ItsJustMe

「16位和32位endian交換後讀取數據」和「在讀取前3位後，我無法再進一步了，因爲接下來的5位沒有意義」，這是怎麼回事？ – sbtkd85

從壓縮機的輸出是一個字節流。你爲什麼要做endian swap？

綜觀前幾個字節，爲二進制：

0B = 00001011 
49 = 01001001 
2D = 00101101 
2E = 00101110 
...

從RFC 3.1.1節：

位從右向左讀的，所以第一位頭，BFINAL，是1：
```
00001011 
     ^
```
麻木ERS都擠滿LSB首先，我們從右到左，所以BTYPE是01閱讀：
```
00001011 
     ^^ 
```
這是固定的Huffman編碼塊類型，因此我們預計未來霍夫曼碼。霍夫曼碼第一打包MSB，所以第一個代碼是10000100（我們繼續到下一個字節這裏）：
```
00001011 
^^^^^ 
01001001 
     ^^^ 
```
在第3.2.6節在表中查找，00110000到10111111表示文本的字節0 - 143，所以10000100（= 0x84）是文字值0x54，它是「T」的ASCII碼。
繼續，下一個代碼是10010101（= 0x95），這是文字值0x65這是「e」。

...等等。

2011-09-12 20:32:51

+1簡潔明瞭的答案 - 它讓我讀了半天RFC1951來正確地理解你在這裏總結的四個要點。 –

回答