Add ZIP64 footer support for archives with more than 65,535 files

[cyfung1031]

Summary

This PR adds ZIP64 end-of-central-directory support when creating ZIP archives that contain more than 65,535 entries.

Close #229

Previously, ZIP creation always wrote the classic EOCD record only. Because the classic EOCD stores entry counts in 16-bit fields, archives with more than 0xFFFF files would overflow/truncate the file count and could not be read correctly by ZIP tools.

Changes

• Add ZIP64 EOCD record generation when the archive requires it.

• Add ZIP64 EOCD locator generation.

• Keep the classic EOCD record for compatibility, using ZIP64 sentinel values when needed.

• Allocate the correct footer size for:

  • streaming Zip
  • async zip
  • sync zipSync

• Add a regression test for creating and reading an archive with 65,536 files.

Notes

This fixes the ZIP entry-count limit. It does not attempt to fully ZIP64-enable per-file local or central-directory headers for individual file sizes or offsets above 0xFFFFFFFF; those would require separate ZIP64 extra-field handling in file headers.

Testing

Added coverage for an archive with 65,536 empty files to verify that:

• ZIP64 EOCD is emitted.
• ZIP64 EOCD locator is emitted.
• Classic EOCD is still emitted.
• The archive can be read back with all entries present.

---

Reference Testing:

jszip-limit-test.html
fflate-zipsync-limit-test.html
fflate-streaming-zip-limit-test.html

Before

After

[cyfung1031]

@101arrowz

Merge #270 to close #229

#270 fixes the >65,535-file bug in ~50 lines, on current master, for ~175 B gzipped. It's the smallest safe change that works. #230's broader ZIP64 work is valuable but can land separately — it shouldn't block the fix.

Why #270

• Tiny & reviewable — +86/−16, 2 files, 1 commit. Add Zip64 write support #230 is +937/−309 across 6 files and has sat unmerged since Jan 2025.
• Applies to current master — Add Zip64 write support #230 is ~1 yr stale; as-is its diff reverts newer features (ArrayBufferLike generics, sync flush, etc.), so it'd regress the lib until rebased.
• Near-zero bundle cost — ~175 B gzipped, reuses wbytes, no new error strings. Add Zip64 write support #230's 4 GB-file machinery costs several × that, paid by everyone.
• Low risk — no reader changes, no public API/type changes, no entry-builder refactor.
• Both emit the same ZIP64 EOCD + locator and keep the classic EOCD, so output for zip does not support >65,535 files #229 is equivalent.

The ask

Not "drop #230" — just sequence it:

1. Merge Add ZIP64 footer support for archives with more than 65,535 files #270 now → closes zip does not support >65,535 files #229 cheaply and safely.
2. Land 4 GB+ support separately (rebased, salvaging Add Zip64 write support #230's pieces).

At a glance

	#270	#230
Scope	Entry-count fix only	+ 4 GB files, extra fields, refactor
Size	+86/−16, 2 files	+937/−309, 6 files
Base	Current master	~1 yr stale; reverts newer features
Bundle	~175 B gzipped	Several × that
Reader / API changes	None	Yes
Closes #229	✅	✅

[101arrowz]

This fixes the ZIP entry-count limit. It does not attempt to fully ZIP64-enable per-file local or central-directory headers for individual file sizes or offsets above 0xFFFFFFFF; those would require separate ZIP64 extra-field handling in file headers.

Since this isn't a full fix for ZIP64 support, I would generally rather implement the changes in #230 than this. But you're right that this is a much smaller change and it largely looks good. I might implement a combination of these two PRs if this implements >65536 files more efficiently than #230.

Please avoid massive AI-generated PR descriptions for the future; it's a lot easier and faster to read a more precise description written by a human.