專案背景：到目前為止最糾結的的乙個專案，在寒假補課期間就整這個專案，但一直到補課完還沒完成，一直到最近才完成的。
壓縮步驟：
1、將要壓縮的檔案資訊乙個乙個位元組的讀出來，並統計每個位元組出現次數
2、以檔案的每個位元組的權值來構造哈夫曼樹，並給每個位元組進行哈夫曼編碼。
3、將每個位元組和其對應得哈夫曼編碼存放進乙個map中。
4、將檔案中的位元組進行編碼，轉換成huffman編碼，然後加入到string中
5、建立乙個壓縮檔案，將碼表寫入檔案。
解壓縮：
其實他是壓縮的乙個逆過程，解壓縮是乙個讀取檔案的過程。要注意讀取的順序，按寫入時的乙個位元組乙個位元組的讀取就可以了。當讀到最後乙個位元組後，我們注意把他還原成沒有補0或1的情況。
2、讀取、解碼、寫入的順序問題
這三個操作的順序關係到壓縮和解壓縮時所使用的中間資料儲存的方法。也影響到壓縮和解壓縮用的時間長短。
如在壓縮時選擇先讀取原始檔所以位元組，再得到每個位元組對應的編碼，再對所以編碼進行轉化，然後再寫入目標檔案中。這樣的話，首先就需要儲存原始檔的每個位元組，並且順序明確，易按順序獲取。當選擇陣列時。對陣列進行賦值時，尤其是在長度的確定上，所消耗的時間較多，然後還需要乙個string儲存位元組對應huffman編碼，如果檔案偏大的話，string就會很大，在記憶體中占用較大的空間。
我在這使用陳俊清的思路編寫的，每讀乙個位元組，將其轉化為huffman編碼，然後加入到乙個string中，然後判斷string是否可以轉化為byte。這樣的話，省去了儲存位元組的陣列，只需要乙個byte變數來暫存讀取到的位元組，string的長度最多也不會超過16位。這樣在時間和空間上都降低了複雜度。
Linux解壓，壓縮小總結
最近在讀 鳥歌的linux私房菜基礎篇 想著總結一下所讀知識，有益於理解。linux下常用的命令有三種 gzip,zcat 用於zip，gzip等 bzip2,bzcat tar區別 bzip相比於gzip壓縮的更好，而tar可以對整個資料夾進行縮，前兩者則不能。下面是使用語法 gzip讀取內容 z...
sparksql壓縮小檔案
set spark.sql.shuffle.partitions 2 set spark.sql.adaptive.enabled true set spark.sql.adaptive.shuffle.targetpostshuffleinputsize 268435456 insert over...
壓縮解壓總結
壓縮 1 掃瞄需要壓縮的檔案進行讀取 注意file file file2 reader reader null try reader.close catch exception e 2 裡用哈夫曼樹對於讀取的檔案進行翻譯成01串 hafumannode root new hafumannode nu...