ZIP archive

Knowing it is really that

The extension is a property of the directory entry, not of the file. What identifies the format is what is in the bytes.

PK. Shared by every zip-based format, so it identifies the container and nothing else: .jar, .apk, .docm, .vsix, .crx and .nupkg all begin this way.

What is actually inside

Entries written sequentially, each with a local header, followed by a central directory at the end of the file that indexes them. The central directory is authoritative for extraction; the local headers are what a streaming reader sees first. Both describe the same entries, and nothing enforces that they agree.

What reading it tells you

• the complete entry list with names, sizes and timestamps, without extracting anything
• compression method and CRC per entry, so damage and truncation are detectable
• whether entries are encrypted, and whether the entry names themselves are encrypted
• path structure, including entries whose names traverse upward out of the extraction directory

What it does not tell you

The useful half, and the half a file-type reference usually leaves out.

• what the entries are. A zip carries bytes; the meaning of those bytes belongs to whatever unpacks them, which is why so many formats are a zip with a manifest
• whether the central directory and the local headers agree. Different tools trust different ones, so two readers can legitimately produce two different listings of the same file
• the contents of an encrypted entry, including whether it is dangerous, without the key
• what its entries are. The archive carries bytes and names; every entry inside is a separate question

Why it turns up on an endpoint

It is how files cross boundaries. Email gateways, download pages and file shares all move archives, and the wrapper is often chosen precisely because the contents travel better inside it than alongside it.

All file types