Search files, editable visual templates, and live browser targets from one registry-backed directory. Filtered query views stay crawlable for links but are deliberately noindex; the stable taxonomy pages below remain the canonical search surfaces.
Page 4 of 6; 24 results per page.
Two members use a backslash as the path separator, which APPNOTE 4.4.17.1 forbids and which Windows-written archives contain anyway. Readers that split on '/' only will create files literally named 'data\config.json' in the extraction root instead of data/config.json.
A deliberately bounded compression-ratio fixture: 4474 bytes on disk expanding to exactly 4 MiB of zeros, roughly 937:1. It is not a decompression bomb - there is no nesting and no recursion, and the expanded size is a fixed 4 MiB - so it exercises a ratio guard or a streaming extractor's memory ceiling without being dangerous to open.
Three members under docs/ whose names differ only in letter case. On ext4 they are three files; on NTFS or a default APFS volume they are one file written three times, and the last one silently wins. Each payload names its own casing so you can tell which survived.
The legacy twin: names encoded in IBM CP437 with the language-encoding flag clear, which is what the ZIP spec says an un-flagged name means. Decoding these bytes as UTF-8 produces mojibake or an outright decode error, which is exactly the bug this file is for.
The same streaming layout with the data descriptor's PK\x07\x08 signature omitted, which the spec permits and which breaks readers that scan for the signature instead of trusting the central directory. The central directory here carries the authoritative sizes and CRCs.
A ZIP written the way a streaming writer must write one: general-purpose bit 3 is set, the local header carries CRC 0 and sizes 0, and the real values follow the compressed data in a data descriptor introduced by the optional PK\x07\x08 signature.
A streaming ZIP in ZIP64 form: the data descriptor's compressed and uncompressed sizes are 8 bytes each rather than 4. Readers that assume a fixed 16-byte descriptor desynchronise on the very next local header.
A ZIP archive — a file nested six directory levels deep. Deterministic (fixed member timestamps) and safe to extract anywhere.
The same three-directory tree with no directory records at all — the parents exist only as path components inside member names. Extractors that create directories only when they see a directory record fail on this shape, which is what most command-line ZIP writers produce.
Directory records whose names do NOT end in a slash — the directory-ness is carried only by the MS-DOS attribute bit in the external attributes field. A reader that decides by name alone creates three empty files called project, project/src and project/data, and then cannot create the directories that have to replace them.
Member names carrying './' prefixes, an inner './' and one inner '../' that cancels the segment before it. Every path resolves inside the archive root, so this exercises a normaliser without being a traversal payload: docs/sub/../notes.md must land at docs/notes.md, not at docs/sub/notes.md and not outside the extraction directory.
A valid ZIP with zero entries — the empty-archive edge case for testing how unarchivers handle a container with nothing inside.
A valid ZIP with zero members whose end record still carries an archive comment - the combination that catches readers which treat 'no entries' as 'not an archive' and readers which look for the end record only in the last 22 bytes. Its group siblings are the same empty case in five other container formats.
A ZIP that stores each directory as its own zero-length record with a trailing slash and the MS-DOS directory attribute set. Its group siblings hold the same tree with the directory records implied and with the trailing slash missing, which is the trio an extractor's mkdir logic has to survive.
The DOS timestamp in a ZIP header has 2-second resolution and no timezone, so Info-ZIP adds a 0x5455 extended timestamp and a 0x7875 uid/gid field. Here the uid/gid field appears in the local header only, matching what Info-ZIP actually writes, so a reader that reads extras from the central directory alone sees the timestamp but loses the ownership.
A ZIP archive — 3 files at the root, no directories. Deterministic (fixed member timestamps) and safe to extract anywhere.
The third way a ZIP carries a non-ASCII name: an ASCII-safe name in the header plus an Info-ZIP Unicode Path extra field (0x7075) holding the real UTF-8 name and a CRC32 of the header name. A reader must prefer the extra field, but only while that CRC still matches the header name it was computed from.
397 bytes of readable text precede the first local file header, giving the layout of a self-extracting archive without shipping an executable stub. Readers that start at byte zero see garbage; readers that find the end-of-central-directory record and work backwards read all three members. Open the file in a text editor to read the prefix.
A 512-byte archive comment pushes the end-of-central-directory record well away from the end of the file. Readers that seek to the last 22 bytes and expect the end signature there fail immediately; correct readers scan backwards for it, which is what the format requires.
A ZIP archive — 100 tiny files for throughput testing. Deterministic (fixed member timestamps) and safe to extract anywhere.
The last segment of a two-part spanned set: its end record says this is disk 1, that the central directory lives on disk 1, and that 2 of the archive's 4 entries are here. The bytes are well-formed - this is not a corrupt file - but a reader given it alone must say so rather than silently reporting a 2-entry archive. The .z01 first segment is deliberately absent, because .z01 is not a format this catalog registers.
A ZIP archive — files organised into data/ and docs/ subfolders. Deterministic (fixed member timestamps) and safe to extract anywhere.
Two of three members carry a central-directory file comment and the third carries none. Comments exist only in the central directory, so a reader that walks local headers to build its listing loses them entirely; a rewriter that drops them loses them permanently.
A complete, extractable ZIP that begins with the four-byte PK00 marker a splitting writer emits when the archive fitted into a single segment after all. The marker shifts every local header four bytes forward, so a reader that assumes the first local header sits at offset 0 misparses a file it is perfectly capable of reading.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
