引言

今天在使用 node 腳本對文件處理時(shí)，需要實(shí)現(xiàn)一個(gè)功能，要對一個(gè) zip 壓縮包解壓出來，修改里面的文件后，重新打包成zip包。node 解壓縮文件的場景在實(shí)際應(yīng)用中還是比較常見，下面介紹幾個(gè)用來解壓縮文件的庫和使用方法。

compressing

compressing 是一個(gè)使用起來方便、功能非常強(qiáng)大的node庫，它可以對文件、文件夾進(jìn)行解壓或壓縮，支持tar、gzip、tgz、zip等多種格式。

簡單安裝之后 npm install compressing，以 zip 壓縮包為例

解壓

解壓比較簡單，tar、gzip、zip 都是同個(gè) API

const compressing = require('compressing');
// 將壓縮包解壓到 test 文件夾中
compressing.zip.uncompress('./test.zip','./test').then(() => {
	console.log('解壓完成')
}).catch(() => {
	console.log('解壓失敗')
})
// 將壓縮包解壓到當(dāng)前文件夾中
compressing.zip.uncompress('./test.zip','./')

壓縮

const compressing = require('compressing');
// 壓縮一個(gè)文件
compressing.zip.compressFile('E:/1.txt','E:/1.zip').then(() => {
	console.log('壓縮完成')
}).catch(() => {
	console.log('壓縮失敗')
})
// 壓縮一個(gè)文件夾
compressing.zip.compressDir('E:/test', 'E:/test.zip').then(func1).catch(func2);
// 同時(shí)壓縮多個(gè)文件和文件夾，采用 stream 的方式
const zipStream = new compressing.zip.Stream();
zipStream.addEntry('./test');
zipStream.addEntry('./1.txt');
zipStream.pipe(fs.createWriteStream('./test1.zip')).on('finish', ()=>{
	console.log('壓縮完成')
}).on('error', ()=>{
	console.log('壓縮失敗')
})

在使用compressing.zip.compressDir壓縮整個(gè)文件夾的時(shí)候，會把最外層的文件夾也一起壓縮，解壓出來又是一個(gè)完整的文件夾。但是我的需求時(shí)只想把這個(gè)文件夾下的所有文件打包，直接解壓出來得到零散的很多個(gè)文件。

最初的想法呢是通過 fs的API對文件夾進(jìn)行遍歷，用 addEntry 的方式打包，后來發(fā)現(xiàn)原來是可以設(shè)置參數(shù)的，只是文檔中沒有表現(xiàn)出來，而且寫著：usually you don't need it ，導(dǎo)致我走了很多彎路。

后面在 addEntry 的接口文檔中看到了有個(gè) opt.ignoreBase 的參數(shù)，才想到 compressDir 是不是也可以用。于是嘗試了一下，的確滿足了我的需求，含淚刪掉遍歷文件夾的代碼。

compressing.zip.compressDir('E:/test', 'E:/test.zip', {
	ignoreBase: true
})

基本上，一個(gè)解壓和壓縮的需求就可以完成了?？善陀龅搅藗€(gè)問題，在用 compressing 壓縮成一個(gè)zip包之后，在某個(gè)特殊的系統(tǒng)中，用系統(tǒng)自帶的解壓出來，文件都變成文件夾了，比如 app.js 是個(gè)js文件，解壓后變成一個(gè)名為 app.js 的文件夾。這就很尷尬了。

我嘗試了compressDir和addEntry的方式，最終得到的結(jié)果都一樣。于是乎，為了驗(yàn)證是這個(gè)系統(tǒng)本身解壓算法的問題，我又找了另外一個(gè)壓縮庫。

archiver

archiver是一個(gè)在nodejs中能跨平臺實(shí)現(xiàn)打包功能的模塊，通過 stream 的方式，可以打zip和tar包。如果連這個(gè)打包之后在這個(gè)系統(tǒng)中解壓出來的文件還是有問題的話，那我就可以認(rèn)為是這個(gè)系統(tǒng)的問題，而不是我代碼的問題。

const output = fs.createWriteStream('./test.zip');
const archive = archiver('zip', {zlib: {
	level: 9 // 設(shè)置壓縮等級
}});
archive.pipe(output);
archive.directory('./test', false); // 這里false參數(shù)和上面的ignoreBase為true效果一樣
archive.finalize();	// 完成壓縮
archive.on('end', () => {	// 壓縮結(jié)束時(shí)觸發(fā)
	console.log('壓縮完成');
});

本來想證明是這個(gè)系統(tǒng)本身存在問題，結(jié)果卻狠狠打臉了。用 archiver 壓縮后的 zip 包在這個(gè)系統(tǒng)中解壓出來是正常的文件，那么真相就是 compressing 的壓縮算法有點(diǎn)問題，只不過這個(gè)問題復(fù)現(xiàn)的場景很不一般，在正常的系統(tǒng)中都不會遇到。

不過呢，我想了又想，現(xiàn)在也只能算是一比一打平，為了科學(xué)的嚴(yán)謹(jǐn)性，我決定再找一個(gè)壓縮庫進(jìn)行驗(yàn)證。

adm-zip

adm-zip 是一個(gè)支持zip壓縮和解壓縮的庫，而我也只需要壓縮zip格式包，剛好可以滿足我的需求。

壓縮

const admzip = new AdmZip();
// 壓縮文件夾
admzip.addLocalFolder('./test');
// 壓縮文件
admzip.addLocalFile('./1.txt');
admzip.writeZip('./test.zip');

addLocalFolder 壓縮整個(gè)文件夾的時(shí)候，會把這個(gè)文件夾下的所有文件打包，直接解壓出來得到零散的很多個(gè)文件，效果和compressDir設(shè)置參數(shù)ignoreBase為true一樣。

addLocalFolder 支持第二個(gè)參數(shù)，可以將要壓縮的文件，壓縮進(jìn)壓縮包的某個(gè)路徑下。

admzip.addLocalFolder('./test','aaa');
admzip.addLocalFolder('./test','aaa/bbb');

可以設(shè)置多級目錄，解壓出來后的文件就在這個(gè)目錄里。

writeZip 是一個(gè)同步的方法，而上面兩個(gè)庫壓縮都是異步的。在使用 adm-zip 打包之后，驗(yàn)證出來的效果和 archiver 是一樣的，在那個(gè)特殊的系統(tǒng)上，解壓都沒有問題。這就真的證明了 compressing 真的存在小問題，不過在正常場景中應(yīng)該都可以忽略不計(jì)。

解壓縮

adm-zip 也支持解壓縮。

const admzip = new AdmZip('./test.zip');
admzip.extractAllTo('./test'); // 把整個(gè)壓縮包完全解壓到 test 目錄中

除了解壓整個(gè)壓縮包，還支持單獨(dú)解壓某個(gè)文件

const admzip = new AdmZip('./test.zip');
const entry = zip.getEntry('1.txt');
admzip.extractEntryTo(entry, './test2', true, true);

extractEntryTo 支持4個(gè)參數(shù)，第三個(gè)參數(shù)表示是否需要?jiǎng)?chuàng)建父文件夾，第四個(gè)參數(shù)表示是否要覆蓋。

總結(jié)

經(jīng)過多個(gè)庫的使用和對比，發(fā)現(xiàn) adm-zip 可以完美的解決我的需求，同時(shí)打包之后，體積也是最小的。在大部分的開發(fā)場景中，用哪個(gè)庫其實(shí)都不會有問題的。compressing 可以支持更多的壓縮格式，adm-zip只支持zip格式，archiver 卻不支持解壓縮，因此根據(jù)自己的應(yīng)用場景選擇最合適的庫吧。

以上就是Node.js 應(yīng)用探索文件解壓縮示例詳解的詳細(xì)內(nèi)容，更多關(guān)于Node.js 文件解壓縮的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論