DDR爱好者之家 Design By 杰米

前几天在维护一个nodejs写的命令行工具,要增加一个压缩zip文件时加密码功能。压缩文件时使用了 archiver 库,加密码使用了 archiver-zip-encrypted 库。在windows系统上测试时,发现会概率的出现以下异常:

events.js:174 
throw er; // Unhandled 'error' event 
^
Error: file data stream has unexpected number of bytes 
at ByteCounter. (
xxx\node_modules\yazl\index.js:162:99) 
at ByteCounter.emit (events.js:194:15) 
at endReadableNT (_stream_readable.js:1103:12) 
at process._tickCallback (internal/process/next_tick.js:63:19) 
Emitted 'error' event at: 
at ByteCounter. (xxx\node_modules\yazl\index.js:162:85) 
at ByteCounter.emit (events.js:194:15) 
at endReadableNT (_stream_readable.js:1103:12) 
at process._tickCallback (internal/process/next_t

我的本机环境是:

npm:6.9.0
node: v10.16.3

在另外一个同事的windows系统上测试,他那边是上面异常必现,对应的node版本是v10.15。

具体使用的代码不贴了,基本上是参照官方 demo 来写的,压缩完成最后调用代码如下所示:

archive.finalize().then(() => {
  // 到这里认为是压缩完成,进行后续处理,实际并没有,参照后面分析
  anotherProcess();
}).catch(err => {
  // 压缩出现异常处理...
});

出现异常后一一检查代码和官方demo不一样的地方,并没有发现什么异常之处,网上搜索也没有发现这种异常记录。由于刚接触JS,不是很熟,就从问题开始下手,找到出现问题的代码,开始调试。

错误日志中提示是在 yzal/index.js 文件中发生异常,找到出现异常的代码如下所示:

function pumpFileDataReadStream(self, entry, readStream) {
 var crc32Watcher = new Crc32Watcher();
 var uncompressedSizeCounter = new ByteCounter();
 var compressor = entry.compress "end", function() {
  entry.crc32 = crc32Watcher.crc32;
  if (entry.uncompressedSize == null) {
   entry.uncompressedSize = uncompressedSizeCounter.byteCount;
  } else {
   // 异常从这里抛出来的
   if (entry.uncompressedSize !== uncompressedSizeCounter.byteCount) return self.emit("error", new Error("file data stream has unexpected number of bytes"));
  }
  entry.compressedSize = compressedSizeCounter.byteCount;
  self.outputStreamCursor += entry.compressedSize;
  writeToOutputStream(self, entry.getDataDescriptor());
  entry.state = Entry.FILE_DATA_DONE;
  pumpEntries(self);
 });
}

从上面代码可以看出来: uncompressedSizeCounter.byteCount 是从 pumpFileDataReadStream() 函数 readStream 参数中获取的属性值,而 entry.uncompressedSize 也是函数的 entry 参数中获取的属性。接着找 pumpFileDataReadStream() 函数是从哪里调用的。

通过输出日志得出 pumpFileDataReadStream() 函数是在以下面的代码中被调用的:

ZipFile.prototype.addFile = function(realPath, metadataPath, options) {
 var self = this;
 metadataPath = validateMetadataPath(metadataPath, false);
 if (options == null) options = {};
 var entry = new Entry(metadataPath, false, options);
 self.entries.push(entry);
 fs.stat(realPath, function(err, stats) {
  if (err) return self.emit("error", err);
  if (!stats.isFile()) return self.emit("error", new Error("not a file: " + realPath));
  // 这里是文件的大小
  entry.uncompressedSize = stats.size;
  if (options.mtime == null) entry.setLastModDate(stats.mtime);
  if (options.mode == null) entry.setFileAttributesMode(stats.mode);
  entry.setFileDataPumpFunction(function() {
   // readStream在这里创建的
   var readStream = fs.createReadStream(realPath);
   entry.state = Entry.FILE_DATA_IN_PROGRESS;
   readStream.on("error", function(err) {
    self.emit("error", err);
   });
   // 在这里被调用
   pumpFileDataReadStream(self, entry, readStream);
  });
  pumpEntries(self);
 });
};

从上面代码可以看出来 entry.uncompressedSize 是stats.size,即文件的大小, readStream 是创建的文件流。但是在什么情况下两者会不一样呢?感觉只可能在文件还没有读取完,但是是什么原因导致这种情况发生?由于对JS接触的时间不长,没有进行深入分析。最后在抛出异常的上面一行用 console.log 将两个属性的大小值都输出,代码如下所示:

if (entry.uncompressedSize == null) {
   entry.uncompressedSize = uncompressedSizeCounter.byteCount;
} else {
 // 增加日志输出
 console.log("entry size: " + entry.uncompressedSize + ", uncompressedSize: " + uncompressedSizeCounter.byteCount);
 if (entry.uncompressedSize !== uncompressedSizeCounter.byteCount) return self.emit("error", new Error("file data stream has unexpected number of bytes"));
}

在 archive.finalize() 时和 output 写入流的 close 事件时(详细参照官方的示例代码),分别加上日志输出,代码如下所示:

archive.finalize().then(() => {
 // 到这里认为是压缩完成,进行后续处理,实际并没有,参照后面分析
 console.log("finalize");
 // anotherProcess();
}).catch(err => {
  // 压缩出现异常
});
output.on('close', function() {
 console.log('close');
 // 这个业务函数与上面finalize函数中的是互斥,不会同时存在
 anotherProcess();
});

最后分别将 anotherProcess() 函数加到两个异步回调中执行,发现在 close 事件执行时,两个size输出的大小一致,都是文件的大小。而在 finalize 场景测试发现 uncompressedSize 要小于文件的大小。最后将 anotherProcess() 函数放在 close 事件回调函数中执行,问题解决。

总结

以上所述是小编给大家介绍的Nodejs使用archiver-zip-encrypted库加密压缩文件时报错,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对网站的支持!
如果你觉得本文对你有帮助,欢迎转载,烦请注明出处,谢谢!

DDR爱好者之家 Design By 杰米
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
DDR爱好者之家 Design By 杰米

《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。

《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。