The yauzl npm package is a library for unzipping ZIP files in Node.js. It provides a low-level interface for reading and extracting ZIP file contents, allowing developers to handle large files and read entries without decompressing the entire file to disk.
Opening a ZIP file
This code demonstrates how to open a ZIP file for reading. The 'lazyEntries' option allows reading entries one at a time.
const yauzl = require('yauzl');
yauzl.open('path/to/file.zip', {lazyEntries: true}, function(err, zipfile) {
if (err) throw err;
zipfile.readEntry();
});Reading entries from a ZIP file
This code shows how to read entries from an open ZIP file. It handles directories and files differently, reading the next entry after each file is processed.
zipfile.on('entry', function(entry) {
if (/\/.test(entry.fileName)) {
// Directory file names end with '/'.
zipfile.readEntry();
} else {
// File entry
zipfile.openReadStream(entry, function(err, readStream) {
if (err) throw err;
// Handle the read stream, possibly piping it somewhere
readStream.on('end', function() {
zipfile.readEntry();
});
});
}
});Extracting a file entry
This code snippet demonstrates how to extract a file entry from a ZIP file. It creates a read stream for the entry and pipes it to a write stream.
zipfile.openReadStream(entry, function(err, readStream) {
if (err) throw err;
// Create a write stream to extract the file to
var writeStream = fs.createWriteStream('output/path');
readStream.pipe(writeStream);
});adm-zip is a JavaScript implementation for zip data compression for NodeJS. It provides functionalities to read and write zip files, similar to yauzl, but also includes zip file creation which yauzl does not.
JSZip is a library for creating, reading, and editing .zip files with JavaScript, with a lovely and simple API. It works in both Node.js and browser environments, whereas yauzl is designed specifically for Node.js.
unzipper is a decompression library for Node that supports streaming, promises, and piping for zip files. It is an alternative to yauzl with a slightly different API and additional features like parsing zip file contents without extraction.
yet another unzip library for node. For zipping, see yazl.
Design principles:
"/" or /[A-Za-z]:\//
or if it contains ".." path segments or "\\" (per the spec).var yauzl = require("yauzl");
var fs = require("fs");
var path = require("path");
var mkdirp = require("mkdirp"); // or similar
yauzl.open("path/to/file.zip", {lazyEntries: true}, function(err, zipfile) {
if (err) throw err;
zipfile.readEntry();
zipfile.on("entry", function(entry) {
if (/\/$/.test(entry.fileName)) {
// directory file names end with '/'
mkdirp(entry.fileName, function(err) {
if (err) throw err;
zipfile.readEntry();
});
} else {
// file entry
zipfile.openReadStream(entry, function(err, readStream) {
if (err) throw err;
// ensure parent directory exists
mkdirp(path.dirname(entry.fileName), function(err) {
if (err) throw err;
readStream.pipe(fs.createWriteStream(entry.fileName));
readStream.on("end", function() {
zipfile.readEntry();
});
});
});
}
});
});
The default for every optional callback parameter is:
function defaultCallback(err) {
if (err) throw err;
}
Calls fs.open(path, "r") and gives the fd, options, and callback to fromFd() below.
options may be omitted or null. The defaults are {autoClose: true, lazyEntries: false}.
autoClose is effectively equivalent to:
zipfile.once("end", function() {
zipfile.close();
});
lazyEntries indicates that entries should be read only when readEntry() is called.
If lazyEntries is false, entry events will be emitted as fast as possible to allow pipe()ing
file data from all entries in parallel.
This is not recommended, as it can lead to out of control memory usage for zip files with many entries.
See issue #22.
If lazyEntries is true, an entry or end event will be emitted in response to each call to readEntry().
This allows processing of one entry at a time, and will keep memory usage under control for zip files with many entries.
Reads from the fd, which is presumed to be an open .zip file. Note that random access is required by the zip file specification, so the fd cannot be an open socket or any other fd that does not support random access.
The callback is given the arguments (err, zipfile).
An err is provided if the End of Central Directory Record Signature cannot be found in the file,
which indicates that the fd is not a zip file.
zipfile is an instance of ZipFile.
options may be omitted or null. The defaults are {autoClose: false, lazyEntries: false}.
See open() for the meaning of the options.
Like fromFd(), but reads from a RAM buffer instead of an open file.
buffer is a Buffer.
callback is effectively passed directly to fromFd().
If a ZipFile is acquired from this method,
it will never emit the close event,
and calling close() is not necessary.
options may be omitted or null. The defaults are {lazyEntries: false}.
See open() for the meaning of the options.
The autoClose option is ignored for this method.
This method of creating a zip file allows clients to implement their own back-end file system. For example, a client might translate read calls into network requests.
The reader parameter must be of a type that is a subclass of
RandomAccessReader that implements the required methods.
The totalSize is a Number and indicates the total file size of the zip file.
options may be omitted or null. The defaults are {autoClose: true, lazyEntries: false}.
See open() for the meaning of the options.
Converts MS-DOS date and time data into a JavaScript Date object.
Each parameter is a Number treated as an unsigned 16-bit integer.
Note that this format does not support timezones,
so the returned object will use the local timezone.
The constructor for the class is not part of the public API.
Use open(), fromFd(), fromBuffer(), or fromRandomAccessReader() instead.
Callback gets (entry), which is an Entry.
See open() and readEntry() for when this event is emitted.
Emitted after the last entry event has been emitted.
See open() and readEntry() for more info on when this event is emitted.
Emitted after the fd is actually closed.
This is after calling close() (or after the end event when autoClose is true),
and after all stream pipelines created from openReadStream() have finished reading data from the fd.
If this ZipFile was acquired from fromRandomAccessReader(),
the "fd" in the previous paragraph refers to the RandomAccessReader implemented by the client.
If this ZipFile was acquired from fromBuffer(), this event is never emitted.
Emitted in the case of errors with reading the zip file.
(Note that other errors can be emitted from the streams created from openReadStream() as well.)
After this event has been emitted, no further entry, end, or error events will be emitted,
but the close event may still be emitted.
Causes this ZipFile to emit an entry or end event (or an error event).
This method must only be called when this ZipFile was created with the lazyEntries option set to true (see open()).
When this ZipFile was created with the lazyEntries option set to true,
entry and end events are only ever emitted in response to this method call.
The event that is emitted in response to this method will not be emitted until after this method has returned, so it is safe to call this method before attaching event listeners.
After calling this method, calling this method again before the response event has been emitted will cause undefined behavior.
Calling this method after the end event has been emitted will cause undefined behavior.
Calling this method after calling close() will cause undefined behavior.
entry must be an Entry object from this ZipFile.
callback gets (err, readStream), where readStream is a Readable Stream.
If the entry is compressed (with a supported compression method),
the read stream provides the decompressed data.
If this zipfile is already closed (see close()), the callback will receive an err.
It's possible for the readStream it to emit errors for several reasons.
For example, if zlib cannot decompress the data, the zlib error will be emitted from the readStream.
Two more error cases are if the decompressed data has too many or too few actual bytes
compared to the reported byte count from the entry's uncompressedSize field.
yauzl notices this false information and emits an error from the readStream
after some number of bytes have already been piped through the stream.
Because of this check, clients can always trust the uncompressedSize field in Entry objects.
Guarding against zip bomb attacks can be accomplished by
doing some heuristic checks on the size metadata and then watching out for the above errors.
Such heuristics are outside the scope of this library,
but enforcing the uncompressedSize is implemented here as a security feature.
It is possible to destroy the readStream before it has piped all of its data.
To do this, call readStream.destroy().
You must unpipe() the readStream from any destination before calling readStream.destroy().
If this zipfile was created using fromRandomAccessReader(), the RandomAccessReader implementation
must provide readable streams that implement a .destroy() method (see randomAccessReader._readStreamForRange())
in order for calls to readStream.destroy() to work in this context.
Causes all future calls to openReadStream() to fail,
and closes the fd after all streams created by openReadStream() have emitted their end events.
If the autoClose option is set to true (see open()),
this function will be called automatically effectively in response to this object's end event.
If the lazyEntries option is set to false (see open()) and this object's end event has not been emitted yet,
this function causes undefined behavior.
If the lazyEntries option is set to true,
you can call this function instead of calling readEntry() to abort reading the entries of a zipfile.
It is safe to call this function multiple times; after the first call, successive calls have no effect.
This includes situations where the autoClose option effectively calls this function for you.
Boolean. true until close() is called; then it's false.
Number. Total number of central directory records.
String. Always decoded with CP437 per the spec.
Objects of this class represent Central Directory Records. Refer to the zipfile specification for more details about these fields.
These fields are of type Number:
versionMadeByversionNeededToExtractgeneralPurposeBitFlagcompressionMethodlastModFileTime (MS-DOS format, see getLastModDateTime)lastModFileDate (MS-DOS format, see getLastModDateTime)crc32compressedSizeuncompressedSizefileNameLength (bytes)extraFieldLength (bytes)fileCommentLength (bytes)internalFileAttributesexternalFileAttributesrelativeOffsetOfLocalHeaderString.
Following the spec, the bytes for the file name are decoded with
UTF-8 if generalPurposeBitFlag & 0x800, otherwise with CP437.
If fileName would contain unsafe characters, such as an absolute path or
a relative directory, yauzl emits an error instead of an entry.
Array with each entry in the form {id: id, data: data},
where id is a Number and data is a Buffer.
This library looks for and reads the ZIP64 Extended Information Extra Field (0x0001)
in order to support ZIP64 format zip files.
None of the other fields are considered significant by this library.
String decoded with the same charset as used for fileName.
Effectively implemented as:
return dosDateTimeToDate(this.lastModFileDate, this.lastModFileTime);
This class is meant to be subclassed by clients and instantiated for the fromRandomAccessReader() function.
An example implementation can be found in test/test.js.
Subclasses must implement this method.
start and end are Numbers and indicate byte offsets from the start of the file.
end is exclusive, so _readStreamForRange(0x1000, 0x2000) would indicate to read 0x1000 bytes.
end - start will always be at least 1.
This method should return a readable stream which will be pipe()ed into another stream.
It is expected that the readable stream will provide data in several chunks if necessary.
If the readable stream provides too many or too few bytes, an error will be emitted.
Any errors emitted on the readable stream will be handled and re-emitted on the client-visible stream
(returned from zipfile.openReadStream()) or provided as the err argument to the appropriate callback
(for example, for fromRandomAccessReader()).
The returned stream must implement a method .destroy()
if you call readStream.destroy() on streams you get from openReadStream().
If you never call readStream.destroy(), then streams returned from this method do not need to implement a method .destroy().
.destroy() should abort any streaming that is in progress and clean up any associated resources.
.destroy() will only be called after the stream has been unpipe()d from its destination.
Note that the stream returned from this method might not be the same object that is provided by openReadStream().
The stream returned from this method might be pipe()d through one or more filter streams (for example, a zlib inflate stream).
Subclasses may implement this method.
The default implementation uses createReadStream() to fill the buffer.
This method should behave like fs.read().
Subclasses may implement this method.
The default implementation is effectively setImmediate(callback);.
callback takes parameters (err).
This method is called once the all streams returned from _readStreamForRange() have ended,
and no more _readStreamForRange() or read() requests will be issued to this object.
When a malformed zipfile is encountered, the default behavior is to crash (throw an exception). If you want to handle errors more gracefully than this, be sure to do the following:
callback parameters where they are allowed, and check the err parameter.error event on any ZipFile object you get from open(), fromFd(), fromBuffer(), or fromRandomAccessReader().error event on any stream you get from openReadStream().Due to the design of the .zip file format, it's impossible to interpret a .zip file from start to finish (such as from a readable stream) without sacrificing correctness. The Central Directory, which is the authority on the contents of the .zip file, is at the end of a .zip file, not the beginning. A streaming API would need to either buffer the entire .zip file to get to the Central Directory before interpreting anything (defeating the purpose of a streaming interface), or rely on the Local File Headers which are interspersed through the .zip file. However, the Local File Headers are explicitly denounced in the spec as being unreliable copies of the Central Directory, so trusting them would be a violation of the spec.
Any library that offers a streaming unzip API must make one of the above two compromises, which makes the library either dishonest or nonconformant (usually the latter). This library insists on correctness and adherence to the spec, and so does not offer a streaming API.
For ZIP64, only zip files smaller than 8PiB are supported,
not the full 16EiB range that a 64-bit integer should be able to index.
This is due to the JavaScript Number type being an IEEE 754 double precision float.
The Node.js fs module probably has this same limitation.
The spec does not allow zip file creators to put arbitrary data here, but rather reserves its use for PKWARE and mentions something about Z390. This doesn't seem useful to expose in this library, so it is ignored.
This library does not support multi-disk zip files.
The multi-disk fields in the zipfile spec were intended for a zip file to span multiple floppy disks,
which probably never happens now.
If the "number of this disk" field in the End of Central Directory Record is not 0,
the open(), fromFd(), fromBuffer(), or fromRandomAccessReader() callback will receive an err.
By extension the following zip file fields are ignored by this library and not provided to clients:
Currently, the presence of encryption is not even checked, and encrypted zip files will cause undefined behavior.
Many unzip libraries mistakenly read the Local File Header data in zip files. This data is officially defined to be redundant with the Central Directory information, and is not to be trusted. Aside from checking the signature, yauzl ignores the content of the Local File Header.
This library provides the crc32 field of Entry objects read from the Central Directory.
However, this field is not used for anything in this library.
The field versionNeededToExtract is ignored,
because this library doesn't support the complete zip file spec at any version,
Regarding the compressionMethod field of Entry objects,
only method 0 (stored with no compression)
and method 8 (deflated) are supported.
Any of the other 15 official methods will cause the openReadStream() callback to receive an err.
There may or may not be Data Descriptor sections in a zip file. This library provides no support for finding or interpreting them.
There may or may not be an Archive Extra Data Record section in a zip file. This library provides no support for finding or interpreting it.
Zip files officially support charset encodings other than CP437 and UTF-8, but the zip file spec does not specify how it works. This library makes no attempt to interpret the Language Encoding Flag.
uncompressedSize is correct, or else emit an error. issue #13iconv.iconv.FAQs
yet another unzip library for node
The npm package yauzl receives a total of 9,514,392 weekly downloads. As such, yauzl popularity was classified as popular.
We found that yauzl demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team uncovered a malicious Python package typosquatting the popular 'fabric' SSH library, silently exfiltrating AWS credentials from unsuspecting developers.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.