Interface GetEntriesOptions

true to throw an ERR_AMBIGUOUS_ARCHIVE error when the archive could be parsed differently by other tools. This detects data before or after the zip structure (e.g. a self-extracting archive stub or a concatenated archive), central directory records not accounted for by the end of central directory record, an end of central directory record disagreeing with its zip64 counterpart, and duplicate filenames. When reading the content of an entry, it also validates the local file header against the central directory record (see ZipReaderOptions#checkAmbiguity).

This is the boolean form of GetEntriesOptions#strictness: true means "strict" and false means any value but "strict". When both options are set, the value passed to ZipReader#getEntries takes precedence over the value passed to the constructor of ZipReader, and strictness takes precedence over checkAmbiguity when both are set at the same level. false downgrades an inherited "strict" value to "balanced" and leaves an inherited "tolerant" value unchanged.

The encoding of the comment of the entry.

The encoding of the filename of the entry.

How strictly the filename of each entry should be validated. A rejected name throws an ERR_UNSAFE_FILENAME error carrying the offending name in its filename property.

• "strict": reject the names rejected by "balanced", plus the names that do not map cleanly to a file path, i.e. empty names and names containing a "." path component or an empty one (e.g. "a//b.txt").
• "balanced": reject names that would escape the directory they are extracted into, i.e. names containing a ".." path component, and absolute names, i.e. names starting with "/", with a drive letter (e.g. "C:/file.txt") or with two backslashes (UNC paths).
• "tolerant": never reject a name.

A backslash is never interpreted as a path separator: it is a valid filename character on UNIX systems, and it also occurs as the trail byte of legitimate double-byte filenames (e.g. CP932) decoded with another charset.

Names are validated, never rewritten, so the filename reported for an entry always matches its central directory record.

The maximum number of bytes tolerated after the zip structure before the archive is rejected. Defaults to 0 when GetEntriesOptions#strictness is "strict", 65535 when it is "balanced", and Infinity when it is "tolerant".

An explicit value takes precedence over the strictness default at every level, so it can loosen "strict" or reintroduce a rejection under "tolerant". It also bounds how far back the end of central directory record is searched for, so a value smaller than the amount of data actually appended surfaces an ERR_EOCDR_NOT_FOUND error when the record lies beyond the searched region and an ERR_AMBIGUOUS_ARCHIVE error otherwise.

How tolerant the reader should be when the archive can be parsed in more than one way.

• "strict": reject anything another tool could interpret differently. The end of central directory record must sit exactly at the end of the file, no data may precede the zip structure, and the local file headers must agree with the central directory records. Equivalent to GetEntriesOptions#checkAmbiguity set to true.
• "balanced": select the last end of central directory record whose comment reaches the end of the file and that points to a central directory, ignore stale records left by in-place updates as well as records forged inside a comment, and tolerate a self-extracting stub or up to GetEntriesOptions#maxAppendedDataSize bytes of appended data. Throw an ERR_AMBIGUOUS_ARCHIVE error only when two or more records reach the end of the file and each points to a central directory, which cannot be disambiguated. A record that reaches the end of the file but points to no central directory (an empty archive) is only selected when no record points to one.
• "tolerant": never reject a parseable archive, except when GetEntriesOptions#maxAppendedDataSize is set explicitly and exceeded; recover by selecting the last end of central directory record that reaches the end of the file and points to a central directory (or, failing that, the last one that reaches the end of the file).