代碼解壓縮

① 怎樣使用壓縮文件代碼

我在使用這個組件行，遇到了一個問題。
當壓縮小文件時沒有什麼錯誤，一旦源文件達到150M時，它會讓你的機器垮掉。(至少是我的機器)
為什麼會這樣，因為如果源文件是150M時，你就需要在內存申請一個150M大小的位元組數組。好點的機器還沒問題，一般的機器可就慘了。如果文件在大的話，好機器也受不了的。
為了解決大文件壓縮的問題，可以使用分段壓縮的方法。
private string CreateZIPFile(string path,int M)
{
try
{
Crc32 crc = new Crc32();
ICSharpCode.SharpZipLib.Zip.ZipOutputStream zipout=new ICSharpCode.SharpZipLib.Zip.ZipOutputStream(System.IO.File.Create(path+".zip"));
System.IO.FileStream fs=System.IO.File.OpenRead(path);
long pai=1024*1024*M;//每M兆寫一次
long forint=fs.Length/pai+1;
byte[] buffer=null;
ZipEntry entry = new ZipEntry(System.IO.Path.GetFileName(path));
entry.Size = fs.Length;
entry.DateTime = DateTime.Now;
zipout.PutNextEntry(entry);
for(long i=1;i<=forint;i++)
{
if(pai*i<fs.Length)
{
buffer = new byte[pai];
fs.Seek(pai*(i-1),System.IO.SeekOrigin.Begin);
}
else
{
if(fs.Length<pai)
{
buffer = new byte[fs.Length];
}
else
{
buffer = new byte[fs.Length-pai*(i-1)];
fs.Seek(pai*(i-1),System.IO.SeekOrigin.Begin);
}
}
fs.Read(buffer,0,buffer.Length);
crc.Reset();
crc.Update(buffer);
zipout.Write(buffer,0, buffer.Length);
zipout.Flush();
}
fs.Close();
zipout.Finish();
zipout.Close();
System.IO.File.Delete(path);
return path+".zip";
}
catch(Exception ex)
{
string str=ex.Message;
return path;
}
}

② 壓縮後的JS代碼怎樣解壓縮

一般壓縮都經過混淆，如果你看到變數名都是A,B,C,D之類的無規則的命名，那就是被混淆過的，一般來說也很難閱讀，就算你 還原了格式。

如果是沒有混淆的，你可以試試用js的格式化工具來重新格式化一下的，比如：
/* 美化：格式化代碼，使之容易閱讀 */
/* 凈化：去掉代碼中多餘的注釋、換行、空格等 */
/* 壓縮：將代碼壓縮為更小體積，便於傳輸 */
/* 解壓：將壓縮後的代碼轉換為人可以閱讀的格式 */
/* 混淆：將代碼的中變數名簡短化以減小體積，但可讀性差，經混淆後的代碼無法還原 */

/* 如果有用，請別忘了推薦給你的朋友： */
/* javascript在線美化、凈化、壓縮、解壓：http://tool.lu/js */

/* 以下是演示代碼 */
var Inote = {};
Inote.JSTool = function(options) {
this.options = options || {};
};
Inote.JSTool.prototype = {
_name: 'Javascript工具',
_history: {
'v1.0': ['2011-01-18', 'javascript工具上線'],
'v1.1': ['2012-03-23', '增加混淆功能'],
'v1.2': ['2012-07-21', '升級美化功能引擎'],
'v1.3': ['2014-03-01', '升級解密功能，支持eval,window.eval,window["eval"]等的解密'],
'v1.4': ['2014-08-05', '升級混淆功能引擎'],
'v1.5': ['2014-08-09', '升級js壓縮引擎'],
'v1.6': ['2015-04-11', '升級js混淆引擎']
},
options: {},
getName: function() {return this._name;},
getHistory: function() {
return this._history;}
};
var jstool = new Inote.JSTool();

③ 求助壓縮解壓縮程序源代碼

壓縮文件的基本原理是查找文件內的重復位元組,並建立一個相同位元組的"詞典"文件,並用一個代碼表示,比如在文件里有幾處有一個相同的詞"中華人民共和國"用一個代碼表示並寫入"詞典"文件,這樣就可以達到縮小文件的目的.
由於計算機處理的信息是以二進制數的形式表示的，因此壓縮軟體就是把二進制信息中相同的字元串以特殊字元標記來達到壓縮的目的。為了有助於理解文件壓縮，請您在腦海里想像一幅藍天白雲的圖片。對於成千上萬單調重復的藍色像點而言，與其一個一個定義「藍、藍、藍……」長長的一串顏色，還不如告訴電腦：「從這個位置開始存儲1117個藍色像點」來得簡潔，而且還能大大節約存儲空間。這是一個非常簡單的圖像壓縮的例子。其實，所有的計算機文件歸根結底都是以「1」和「0」的形式存儲的，和藍色像點一樣，只要通過合理的數學計算公式，文件的體積都能夠被大大壓縮以達到「數據無損稠密」的效果。總的來說，壓縮可以分為有損和無損壓縮兩種。如果丟失個別的數據不會造成太大的影響，這時忽略它們是個好主意，這就是有損壓縮。有損壓縮廣泛應用於動畫、聲音和圖像文件中，典型的代表就是影碟文件格式mpeg、音樂文件格式mp3和圖像文件格式jpg。但是更多情況下壓縮數據必須准確無誤，人們便設計出了無損壓縮格式，比如常見的zip、rar等。壓縮軟體（compression software）自然就是利用壓縮原理壓縮數據的工具，壓縮後所生成的文件稱為壓縮包（archive），體積只有原來的幾分之一甚至更小。當然，壓縮包已經是另一種文件格式了，如果你想使用其中的數據，首先得用壓縮軟體把數據還原，這個過程稱作解壓縮。常見的壓縮軟體有winzip、winrar等。
有兩種形式的重復存在於計算機數據中，zip就是對這兩種重復進行了壓縮。
一種是短語形式的重復，即三個位元組以上的重復，對於這種重復，zip用兩個數字：1.重復位置距當前壓縮位置的距離；2.重復的長度，來表示這個重復，假設這兩個數字各佔一個位元組，於是數據便得到了壓縮，這很容易理解。
一個位元組有 0 - 255 共 256 種可能的取值，三個位元組有 256 * 256 * 256 共一千六百多萬種可能的情況，更長的短語取值的可能情況以指數方式增長，出現重復的概率似乎極低，實則不然，各種類型的數據都有出現重復的傾向，一篇論文中，為數不多的術語傾向於重復出現；一篇小說，人名和地名會重復出現；一張上下漸變的背景圖片，水平方向上的像素會重復出現；程序的源文件中，語法關鍵字會重復出現（我們寫程序時，多少次前後、paste？），以幾十 K 為單位的非壓縮格式的數據中，傾向於大量出現短語式的重復。經過上面提到的方式進行壓縮後，短語式重復的傾向被完全破壞，所以在壓縮的結果上進行第二次短語式壓縮一般是沒有效果的。
第二種重復為單位元組的重復，一個位元組只有256種可能的取值，所以這種重復是必然的。其中，某些位元組出現次數可能較多，另一些則較少，在統計上有分布不均勻的傾向，這是容易理解的，比如一個 ASCII 文本文件中，某些符號可能很少用到，而字母和數字則使用較多，各字母的使用頻率也是不一樣的，據說字母 e 的使用概率最高；許多圖片呈現深色調或淺色調，深色（或淺色）的像素使用較多（這里順便提一下：png 圖片格式是一種無損壓縮，其核心演算法就是 zip 演算法，它和 zip 格式的文件的主要區別在於：作為一種圖片格式，它在文件頭處存放了圖片的大小、使用的顏色數等信息）；上面提到的短語式壓縮的結果也有這種傾向：重復傾向於出現在離當前壓縮位置較近的地方，重復長度傾向於比較短（20位元組以內）。這樣，就有了壓縮的可能：給 256 種位元組取值重新編碼，使出現較多的位元組使用較短的編碼，出現較少的位元組使用較長的編碼，這樣一來，變短的位元組相對於變長的位元組更多，文件的總長度就會減少，並且，位元組使用比例越不均勻，壓縮比例就越大。

④ 如何用C語言解壓縮文件

如果你自己設計演算法,就另當別論,如果想利用第3方的演算法,我推薦用zlib,生成的壓縮包是流行的zip格式.源代碼很好找(www.zlib.net)

⑤ 如何用C語言編寫暴力破解壓縮文件解壓密碼的程序

由於有一個重要的Rar文件，極需解開，首先試用了ARPC，但是解壓的速度極慢，每秒只有30個左右，所以斷了窮舉破解的念頭，卻仍不死心，因為我從不崇尚窮舉破解的方法，除非每秒可以跑幾千萬次的，我或許可以一試，所以決定研究一下Winrar3.x密碼演算法，以期是否可以破解該密碼。查看了網路上的資料，包括看雪FAQ里的回答，都聲稱只能用窮舉法破解，起先並不理解，但通過研究，我理解了看雪前輩們在FAQ里所說的原因，不禁讓我佩服

Winrar加密思路的成熟。雖然研究的結果沒有什麼新意，但我還是決定把我的研究結果與大家一起分享，為那些仍然以為winrar密碼可以象破解注冊碼一樣的，通過修改winrar彈出框之類的更改文件流程指向可以達到跳過密碼檢驗的朋友，做一個簡要的說明。

一、Rar文件生成的流程。
Winrar加密文件時，總的分兩個步驟：
1：先把源文件壓縮，壓成一段數據段。
2：再將壓縮完的數據段加密。
對於同一個源文件來說，不進行加密，壓縮完，其rar文件中的數據段是一模一樣的。但是如果對同一個源文件來說，即使使用同一個密碼，加密完rar文件中的數據段是不一樣的，這是由於加密的密鑰是依賴於一個Salt(8個位元組的密鑰，用來加密時使用，存放在rar文件頭中里）
所以要解密rar加密文件關鍵在於數據解密這一步，那我們接下來研究一下如何加密的。
二、加密「壓縮完的數據段」的流程
1、獲取密鑰：
將明文的密碼與Salt一起，通過HASH演算法，生成兩個16位元組的密鑰。（一個是KEY(AES演算法的參數)，一個是initVector）
2、以Key和initVector來加密壓縮數據：
這里，是一個循環加密的結構，每16位元組作為一個塊，進行加密（這可能正是為什麼加密完的文件長度總為16倍數的原因）。加密採用AES演算法（RAR採用的是AES的rijndael的標准應用）。這里注意：AES加密前，有一個異或運算，是先將每16位元組塊與上一個16位元組塊加密結果進行異或，然後再進行AES演算法的。我用一個簡單的示意代碼看說明：
;===============================================
packblock[0]=packblock[i]^initVector
encryptBlock[0]=AES(packblock[0]) ；（KEY為AES的密鑰）
for i=1to 塊數量-1
packblock[i]=packblock[i]^encryptBlock[i-1]
encryptBlock[i]=AES(packblock[i])；（KEY為AES的密鑰）
next
;packblock[i]表示壓縮完的每16位元組數據
;encryptBlock[i]表示加密完的每16位元組數據
;===============================================
三、解密的過程
由於AES演算法是對稱的，所以解密的過程，是加密過程的逆運算。但解密時AES演算法過程與加密所用的不一樣（是因為解密過程中由KEY生成的子密鑰表不一樣）。仍然需要我們將密碼輸入，與salt一起生成兩個16位元組密鑰，KEY和initVector。

;===============================================
packblock[0]=AES1(encryptBlock[0]) ；（KEY為AES的密鑰）
packblock[0]=packblock[i]^initVector
for i=1to 塊數量-1
packblock[i]=AES1(encryptBlock[i]) ；（KEY為AES的密鑰）
packblock[i]=packblock[i]^encryptBlock[i-1]

next
;===============================================
那判斷密碼是否正確的在什麼地方呢？
解密的過程是解密後的數據塊進行解壓縮，然後解成源文件，對該文件進行CRC校驗，存在RAR文件中的源文件CRC校驗碼比較，相同則密碼正確，不相同則密碼錯誤。

四、無法秒破的原因
從上面，我們了解了RAR文件的整體思路。地球人都知道，解密時，肯定有個步驟是來判斷密碼的正確與否。而且，依據以往的經驗，我們也許可以將某些判斷的點移動，那樣可以縮減破解的流程思路。那RAR的這一步在哪裡？它把校驗放在了最後的一步。如果要秒破，我們該怎麼做泥？至少我認為目前是不可能的。
我們從解密過程逆反過來看看：
1、CRC檢驗這一塊修改跳轉？根本毫無意義，因為它已經是最後一步了。你可以修改RAR文件頭的CRC值，你可以將它改得和你用任意密碼解壓出來的文件CRC值一樣，但你的文件根本就不是原來的文件了。可能已經完全面目全非了。所以，對這一過程不可行。CRC校驗本身是不可逆的
2、那麼把判斷提前到壓縮完的數據？
解壓的時候，有沒有什麼來判斷壓縮數據是否正確？壓縮完的數據，有沒有固定的特徵，是否可以做為解壓的判斷，在這一步里，我們也無法找到有效的可用的固定特徵。因為這一步涉及到RAR的壓縮演算法。即使一個源文件，即使你的文件前一部分是完全相同的，只對後面的部分進行改過，那麼壓縮完，數據也是完全一樣的。因為壓縮完的數據首先是一個壓縮表，後面是編碼。文件不一樣，掃描完的壓縮表也不一樣，編碼又是依賴於壓縮表，所以，這里頭找不到壓縮完的數據有任何的固定特徵可以用來判斷的。
不管壓縮數據是什麼樣的，Winrar都一如既往地進行解壓，沒有進行壓縮數據是否有效的判斷。
3、那假如我們破解了AES了泥？
由於AES只依賴於KEY，如果AES演算法被破解了，我們知道了KEY，我們可以解出壓縮完的數據，但是這里有一個問題，還有一個initVector密鑰，用來第一個16位元組塊的異或，你沒有initVector參數，你第一個16位元組塊的數據便無法解得出來。
4、那就只能從第一步Hash的演算法入手
即使你能破解hash，但hash後的結果泥？沒有結果，你怎麼返推密碼。

所以綜上，我發現rar的加密是由hash和AES兩種演算法互相牽制，而兩種演算法當前都無法破解，至少目前還沒有辦法秒破，也理解了看雪高手講的道理。
五、對窮舉提高演算法效率的一些設想。
我用匯編寫完了RAR窮舉解密的演算法模塊，但是如何提高效率，優化窮舉的速度泥？我有如下的想法：
1、從壓縮數據里找尋特徵，省掉解壓縮、CRC檢驗代碼和生成initVector生成代碼。目前，通過多次實驗，我找到的一個特徵（不知道這個是否正確），即解密完的最後一個16位元組塊的最後一個位元組必須為0。因為經過多次的試驗，我發現有加密的數據段長度都會比未加密前的數據長，那麼，最後一個

16個位元組的數據塊解密完，多出的部分就都為0，但多出幾個位元組泥？多次實驗，長度不一，我試想著從加密數據段最後一個16個位元組塊著手，只解這一塊，看是否一個位元組為0，這樣，只解密16個位元組的數據，來大大提高效率？如果能進行到這一步了，再通過解全部數據，進行CRC校驗的判斷。
2、如果第一個特徵不成立的話，針對特定格式的壓縮文件，比如doc、jpg等，部分數據固定，壓縮完的數據是否存在相互牽制的數據？從而把判斷提前，這一步，我不知道如何找到壓縮完的數據是否存在相互牽制的數據。

⑥ win10 在解壓縮文件時出現錯誤代碼0x80004005：未指定的錯誤怎麼恢復

可能是壓縮包被加密，嘗試使用其他解壓軟體輸入密碼解壓。

⑦ 解開rar密碼的vb代碼

在一些批處理任務的應用程序如安裝程序中，需要對壓縮文件進行解壓縮處理。VB來實現對壓縮文件格式，如RAR、Zip等文件的解壓縮，總的來說，有以下兩種方法：
一、 採用winrar命令行
一般來說，安裝好winrar後，在安裝目錄中，有個名為rar.txt的文件。其實該文件就是Winrar的控制台（命令行）中文手冊。下面我們一起來學習一下，和解壓縮文件有關的命令行。
Winrar命令行的通用格式是：
RAR <命令> [ -<開關> ] <壓縮文件> [ <@列表文件...> ]
[ <文件...> ] [ <解壓路徑\> ]
舉 例來說 ，<命令>為a時，表示添加文件到壓縮文件中，其中需壓縮的文件由列表文件指定。當<命令>為e的時候，就表示解壓文件到當前目錄。如果需要將壓縮文件解壓縮 到自定義目錄，則通常使用x命令，該命令表示帶絕對路徑進行解壓縮。 -<開關>為-y，表示對於所有詢問全部回答是。如果rar文件包含密碼，則需要添加開關為"-p密碼字元串"，否則不能正常解壓縮。
如果要判斷是否winrar命令行是否執行成功，可以通過該命令行的返回值來判斷。如果返回值為0，則成功執行。如果不為0，則執行過程中出現錯誤。錯誤代碼rar.txt中有詳細定義。請仔細研讀該文件。
在有了上述理論作為基礎之後，接下來，我們用VB來實現創建和解壓縮一個帶密碼的壓縮文件。
打開VB6，新建一個標準的Exe工程文件，界面設計如下圖所示，控制項的名稱採用默認的名稱。
圖 解壓縮界面
程 序首先要獲得Winrar的安裝路徑，一般來說，安裝好了Winrar後，會在注冊表的HKEY_LOCAL_MACHINE\Software \Microsoft\Windows\CurrentVersion\AppPaths\創建一個winrar.exe的路徑，該路徑下有一個名為Path的字元串項，該項的值保存的就是Winrar的安裝路徑。本例中，引用 Registry Access Functions對象來實現對注冊表的操作。

⑧ 關於Java的解壓縮的代碼

packagecom.javatest.techzero.gui;
importjava.io.File;
importjava.io.FileInputStream;
importjava.io.FileOutputStream;
importjava.io.InputStream;
importjava.io.OutputStream;
importjava.util.zip.ZipEntry;
importjava.util.zip.ZipFile;
importjava.util.zip.ZipInputStream;
publicclassZipFileDemo{
@SuppressWarnings("resource")
publicstaticvoidmain(Stringargs[])throwsException{
Filefile=newFile("d:"+File.separator+"test.zip");
FileoutFile=null;
ZipFilezipFile=newZipFile(file);
ZipInputStreamzipInput=newZipInputStream(newFileInputStream(file));
ZipEntryentry=null;
InputStreaminput=null;
OutputStreamout=null;
while((entry=zipInput.getNextEntry())!=null){
System.out.println("開始解壓縮"+entry.getName()+"文件。。。");
outFile=newFile("d:"+File.separator+entry.getName());
if(!outFile.getParentFile().exists()){
outFile.getParentFile().mkdir();
}
if(!outFile.exists()){
outFile.createNewFile();
}
input=zipFile.getInputStream(entry);
out=newFileOutputStream(outFile);
inttemp=0;
while((temp=input.read())!=-1){
<SPANstyle="WHITE-SPACE:pre"></SPAN>//System.out.println(temp);
out.write(temp);
}
input.close();
out.close();
}
System.out.println("Done!");
}
}

僅供參考

⑨ bat批處理解壓縮文件

這個比較簡單。參考如下步驟：

1.首先，右鍵單擊壓縮機圖標並選擇open properties。