TAR stands for Tape ARchive. It’s called that because it’s designed to be written to (and read from) non-seekable magnetic tape, meaning it’s written linearly. The metadata for each file (name, mtime etc.) immediately precedes its contents. There is no global table of contents like you’d find on an actual filesystem. In fact, most implementations of tar don’t even put the separate files on gzip boundaries meaning you can’t decompress any given file without decompressing all of the files before it. With a tape backup system, you don’t care, but with a filesystem you absolutely do.
PKZIP mimics the traditional filesystem structure much more closely. The table of contents is at the end instead of the beginning, which is a bit strange as filesystems go, but it is a table of contents consisting of a list of filenames and offsets into the file where they can be found. Each file in a zip archive is compressed separately, meaning you can pull out any given file from a ZIP archive without any prior state, and you can even use different compression algorithms on a per-file basis (few programs make use of this). For obvious reasons, the ZIP format prioritizes storage space over modification speed (the table of contents is a single centralized list and files must be contiguous), meaning if you tried to use it as a filesystem it would utterly suck – but you can very readily find software that will let you read, edit, and delete files in-place as though it were a folder without rewriting the entire archive. That’s not really possible with a .tar file.
You could make the argument that tar is able to more closely mimic a POSIX filesystem since it captures the UNIX permission bits and ZIP doesn’t (ustar was designed for UNIX and pkzip was designed for DOS) but that’s not a great metric.
See, ZIP files are strange because unlike most other archive formats, they put the “header” and table of contents at the end, and all of the members (files within the zip file) are listed in that table of contents as offsets relative to the start of the file. There’s nothing that says that the first member has to begin at the start of the file, or that they have to be contiguous. This means you can concatenate an arbitrary amount of data at the beginning of a ZIP file (such as an exe that opens its argv[0] as a zip file and extracts it) and it will still be valid. (Fun fact! You can also concatenate up to 64KiB at the end and it will still be valid, after you do some finagling. This means that when a program opens a ZIP file it has to search through the last 64KiB to find the “header” with the table of contents. This is why writing a ZIP parser is really annoying.)
As long as whatever’s parsing the .exe doesn’t look past the end of its data, and whatever’s parsing the .zip doesn’t look past the beginning of its data, both can go about their business blissfully unaware of the other’s existence. Of course, there’s no real reason to concatenate an executable with a zip file that wouldn’t access the zip file, but you get the idea.
A common way to package software is to make a self-extracting zip archive in this manner. This is absolutely NOT to say that all .exe files are self extracting .zip archives.
xls & co. (the older ones) are something custom. Only after standardization as OOXML (a shitshow btw, there’s a lengthy wiki article about it) they got zip.
The whole Word and Libre/OO-Writer world is a shit show.
So complex and everyone decides to interpret it a bit differently.
Not even Libre and OO can be interoperabel between the same file and feature.
There are 3 types of files. Renamed txt, renamed zip, and exe
I’d argue with this, but it seems like image and video file extensions have become a lawless zone with no rules so I don’t even think they count.
Looking at you, .webp
Video files are just a bunch of zip files in a trenchcoat.
Don’t forget renamed tar.
It’s a folder that you put files into, but acts as a file itself. Not at all like zip.
Tar.gz is pretty much like zip. Technically tar mimics a file system more closely but like who makes use of that?
Tar mimics a filesystem more closely? Tf???
TAR stands for Tape ARchive. It’s called that because it’s designed to be written to (and read from) non-seekable magnetic tape, meaning it’s written linearly. The metadata for each file (name, mtime etc.) immediately precedes its contents. There is no global table of contents like you’d find on an actual filesystem. In fact, most implementations of tar don’t even put the separate files on gzip boundaries meaning you can’t decompress any given file without decompressing all of the files before it. With a tape backup system, you don’t care, but with a filesystem you absolutely do.
PKZIP mimics the traditional filesystem structure much more closely. The table of contents is at the end instead of the beginning, which is a bit strange as filesystems go, but it is a table of contents consisting of a list of filenames and offsets into the file where they can be found. Each file in a zip archive is compressed separately, meaning you can pull out any given file from a ZIP archive without any prior state, and you can even use different compression algorithms on a per-file basis (few programs make use of this). For obvious reasons, the ZIP format prioritizes storage space over modification speed (the table of contents is a single centralized list and files must be contiguous), meaning if you tried to use it as a filesystem it would utterly suck – but you can very readily find software that will let you read, edit, and delete files in-place as though it were a folder without rewriting the entire archive. That’s not really possible with a .tar file.
You could make the argument that tar is able to more closely mimic a POSIX filesystem since it captures the UNIX permission bits and ZIP doesn’t (ustar was designed for UNIX and pkzip was designed for DOS) but that’s not a great metric.
Isn’t the Windows exe also a renamed zip?
See, ZIP files are strange because unlike most other archive formats, they put the “header” and table of contents at the end, and all of the members (files within the zip file) are listed in that table of contents as offsets relative to the start of the file. There’s nothing that says that the first member has to begin at the start of the file, or that they have to be contiguous. This means you can concatenate an arbitrary amount of data at the beginning of a ZIP file (such as an exe that opens its argv[0] as a zip file and extracts it) and it will still be valid. (Fun fact! You can also concatenate up to 64KiB at the end and it will still be valid, after you do some finagling. This means that when a program opens a ZIP file it has to search through the last 64KiB to find the “header” with the table of contents. This is why writing a ZIP parser is really annoying.)
As long as whatever’s parsing the .exe doesn’t look past the end of its data, and whatever’s parsing the .zip doesn’t look past the beginning of its data, both can go about their business blissfully unaware of the other’s existence. Of course, there’s no real reason to concatenate an executable with a zip file that wouldn’t access the zip file, but you get the idea.
A common way to package software is to make a self-extracting zip archive in this manner. This is absolutely NOT to say that all .exe files are self extracting .zip archives.
No. But the Windows office suite is
You can rename a docx and extract it.
Don’t know how it is with ppt/x and xls/x
xls & co. (the older ones) are something custom. Only after standardization as OOXML (a shitshow btw, there’s a lengthy wiki article about it) they got zip.
The whole Word and Libre/OO-Writer world is a shit show.
So complex and everyone decides to interpret it a bit differently.
Not even Libre and OO can be interoperabel between the same file and feature.
docx are mostly markup language, actually. Much like SVGs and PDFs.
Arent they straight up HTML being specially formatted?
XML
And HTML is a lot like it, all of them are Markup Language.
No
Just because you can open it with 7-zip doesn’t mean it’s a zip file. Some exes are also zip files.