Misplaced Pages

#270729

67-516: ZIP is an archive file format that supports lossless data compression . A ZIP file may contain one or more files or directories that may have been compressed. The ZIP file format permits a number of compression algorithms , though DEFLATE is the most common. This format was originally created in 1989 and was first implemented in PKWARE, Inc. 's PKZIP utility, as a replacement for the previous ARC compression format by Thom Henderson. The ZIP format

134-415: A .ZIP file is 22 bytes. Such an empty zip file contains only an End of Central Directory Record (EOCD): [0x50,0x4B,0x05,0x06,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00] The maximum size for both the archive file and the individual files inside it is 4,294,967,295 bytes (2−1 bytes, or 4 GB minus 1 byte) for standard ZIP. For ZIP64, the maximum size

201-406: A cyclic redundancy check (CRC). RAR archives may include additional error correction data (called recovery records). Archive files that do not natively support recovery records can use separate parchive (PAR) files that allows for additional error correction and recovery of missing files in a multi-file archive. Office Open XML Office Open XML (also informally known as OOXML )

268-543: A directory structure over email , files with names unsupported on the target file system due to length or characters, and retaining files' date and time information . A single archive file may contain multiple member files; this can speed file transfers and other operations with processing overheads for each file, in addition to gains due to compression. Beyond archival purposes, archive files are frequently used for packaging software for distribution , as software contents are often naturally spread across several files;

335-505: A "normal" central directory entry for a file, followed by an optional "zip64" directory entry, which has the larger fields. The format of the Local file header (LOC) and Central directory file header (CDFH) are the same in ZIP and ZIP64. However, ZIP64 specifies an extra field that may be added to those records at the discretion of the compressor, whose purpose is to store values that do not fit in

402-590: A .zip file without prior decompression. It combines the use of ZLib block flushes issued at regular interval with a hidden index file mapping offsets of the uncompressed file to offsets in the compressed stream. ZIP readers that are not aware of that extension can read a SOZip-enabled file normally and ignore the extended features that support efficient seek capability. .ZIP file format includes an extra field facility within file headers, which can be used to store extra data not defined by existing ZIP specifications, and which allow compliant archivers that do not recognize

469-401: A 12-byte structure (optionally preceded by a 4-byte signature) immediately after the compressed data: The central directory file header entry is an expanded form of the local header: After all the central directory entries comes the end of central directory (EOCD) record, which marks the end of the ZIP file: This ordering allows a ZIP file to be created in one pass, but the central directory

536-427: A 16-bit length. A ZIP64 local file extra field record, for example, has the signature 0x0001 and a length of 16 bytes (or more) so that two 64-bit values (the uncompressed and compressed sizes) may follow. Another common local file extension is 0x5455 (or "UT") which contains 32-bit UTC UNIX timestamps. This is immediately followed by the compressed data. If the bit at offset 3 (0x08) of the general-purpose flags field

603-437: A 4 GB (2 bytes) limit on various things (uncompressed size of a file, compressed size of a file, and total size of the archive), as well as a limit of 65,535 (2-1) entries in a ZIP archive. In version 4.5 of the specification (which is not the same as v4.5 of any particular tool), PKWARE introduced the "ZIP64" format extensions to get around these limitations, increasing the limits to 16  EB (2 bytes). In essence, it uses

670-469: A LZ77 variant provided by IBM z/OS CMPSC instruction. The most commonly used compression method is DEFLATE , which is described in IETF RFC   1951 . Other methods mentioned, but not documented in detail in the specification include: PKWARE DCL Implode (old IBM TERSE), new IBM TERSE , IBM LZ77 z Architecture (PFS), and a JPEG variant. A "Tokenize" method was reserved for a third party, but support

737-416: A ZIP file. This identifies what files are in the ZIP and identifies where in the ZIP that file is located. This allows ZIP readers to load the list of files without reading the entire ZIP archive. ZIP archives can also include extra data that is not related to the ZIP archive. This allows for a ZIP archive to be made into a self-extracting archive (application that decompresses its contained data), by prepending

SECTION 10

#1732784016271

804-1112: A ZIP64 extra field. However, if they appear, their order must be as shown in the table. On the other hand, the format of EOCD for ZIP64 is slightly different from the normal ZIP version. It is also not necessarily the last record in the file. An End of Central Directory Locator follows (an additional 20 bytes at the end). The File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista and later do. Likewise, some extension libraries support ZIP64, such as DotNetZip, QuaZIP and IO::Compress::Zip in Perl. Python 's built-in zipfile supports it since 2.5 and defaults to it since 3.4. OpenJDK 's built-in java.util.zip supports ZIP64 from version Java 7 . Android Java API support ZIP64 since Android 6.0. Mac OS Sierra's Archive Utility notably does not support ZIP64, and can create corrupt archives when ZIP64 would be required. However,

871-424: A ballot to determine whether a project should be initiated to create an ISO/IEC International Standard format compatible with ZIP. The proposed project, entitled Document Packaging , envisaged a ZIP-compatible 'minimal compressed archive format' suitable for use with a number of existing standards including OpenDocument , Office Open XML and EPUB . In 2015, ISO/IEC 21320-1 "Document Container File — Part 1: Core"

938-538: A recommendation for the first revision to Office Open XML. Applications capable of reading documents compliant to ECMA-376 Edition 1 would regard ISO/IEC 29500-4 Transitional documents containing ISO 8601 dates as corrupt. Some older versions of Microsoft Word and Microsoft Office are able to read and write .docx files after installation of the free compatibility pack provided by Microsoft, although some items, such as equations, are converted into images that cannot be edited. Starting with Microsoft Office 2007 ,

1005-419: A revision of the ZIP specification providing for the storage of file names using UTF-8 , finally adding Unicode compatibility to ZIP. All multi-byte values in the header are stored in little-endian byte order. All length fields count the length in bytes. The extra field contains a variety of optional data such as OS-specific attributes. It is divided into records, each with at minimum a 16-bit signature and

1072-400: A timestamp resolution of only two seconds; ZIP file records mimic this. As a result, the built-in timestamp resolution of files in a ZIP archive is only two seconds, though extra fields can be used to store more precise timestamps. The ZIP format has no notion of time zone , so timestamps are only meaningful if it is known what time zone they were created in. In September 2006, PKWARE released

1139-421: Is 18,446,744,073,709,551,615 bytes (2−1 bytes, or 16 EB minus 1 byte). A Seek-Optimized ZIP file (SOZip) profile has been proposed for the ZIP format. Such file contains one or several Deflate-compressed files that are organized and annotated such that a SOZip-aware reader can perform very fast random access (seek) within a compressed file. SOZip makes it possible to access large compressed files directly from

1206-530: Is a zipped , XML -based file format developed by Microsoft for representing spreadsheets , charts , presentations and word processing documents. Ecma International standardized the initial version as ECMA-376. ISO and IEC standardized later versions as ISO/IEC 29500. Microsoft Office 2010 provides read support for ECMA-376, full support for ISO/IEC 29500 Transitional, and read support for ISO/IEC 29500 Strict. Microsoft Office 2013 and later fully support ISO/IEC 29500 Strict, but do not use it as

1273-415: Is also placed at the end of the file in order to facilitate easy removal of files from multiple-part (e.g. "multiple floppy-disk") archives, as previously discussed. The .ZIP File Format Specification documents the following compression methods: Store (no compression), Shrink ( LZW ), Reduce (levels 1–4; LZ77 + probabilistic), Implode, Deflate, Deflate64, bzip2 , LZMA , Zstandard , WavPack , PPMd , and

1340-421: Is correctly identified by the presence of an end of central directory record which is located at the end of the archive structure in order to allow the easy appending of new files. If the end of central directory record indicates a non-empty archive, the name of each file or directory within the archive should be specified in a central directory entry, along with other metadata about the entry, and an offset into

1407-542: Is documented in the ZIP specification, and known to be seriously flawed. In particular, it is vulnerable to known-plaintext attacks , which are in some cases made worse by poor implementations of random-number generators . Computers running under native Microsoft Windows without third-party archivers can open, but not create, ZIP files encrypted with ZipCrypto, but cannot extract the contents of files using different encryption. New features including new compression and encryption (e.g. AES ) methods have been documented in

SECTION 20

#1732784016271

1474-467: Is formally named "APPNOTE - .ZIP File Format Specification" and it is published on the PKWARE.com website since the late 1990s. Several versions of the specification were not published. Specifications of some features such as BZIP2 compression, strong encryption specification and others were published by PKWARE a few years after their creation. The URL of the online specification was changed several times on

1541-632: Is introduced in .ZIP File Format Specification 6.2, which encrypts metadata stored in Central Directory portion of an archive, but Local Header sections remain unencrypted. A compliant archiver can falsify the Local Header data when using Central Directory Encryption. As of version 6.2 of the specification, the Compression Method and Compressed Size fields within Local Header are not yet masked. The original .ZIP format had

1608-455: Is not necessarily the case, as this is not required by the ZIP specification - most notably, a self-extracting archive will begin with an executable file header. Tools that correctly read ZIP archives must scan for the end of central directory record signature, and then, as appropriate, the other, indicated, central directory records. They must not scan for entries from the top of the ZIP file, because (as previously mentioned in this section) only

1675-523: Is set, then the CRC-32 and file sizes are not known when the header is written. If the archive is in Zip64 format, the compressed and uncompressed size fields are 8 bytes long instead of 4 bytes long (see section 4.3.9.2). The equivalent fields in the local header (or in the Zip64 extended information extra field in the case of archives in Zip64 format) are filled with zero, and the CRC-32 and size are appended in

1742-722: The ISO / IEC / ITU common patent policy. Microsoft, the main contributor to the standard, provided a covenant not to sue for its patent licensing. The covenant received a mixed reception, with some like the Groklaw blog criticizing it, and others such as Lawrence Rosen , (an attorney and lecturer at Stanford Law School ), endorsing it. Microsoft has added the format to their Open Specification Promise in which Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to

1809-504: The ODF format) threatened to leave standards bodies that it said allow dominant corporations like Microsoft to wield undue influence. The article further says that Microsoft was accused of co-opting the standardization process by leaning on countries to ensure that it got enough votes at the ISO/IEC for Office Open XML to pass, although it does not specify exactly who accused Microsoft. Under

1876-515: The file extensions .zip or .ZIP and the MIME media type application/zip . ZIP is used as a base file format by many programs, usually under a different name. When navigating a file system via a user interface, graphical icons representing ZIP files often appear as a document or other object prominently featuring a zipper . The .ZIP file format was designed by Phil Katz of PKWARE and Gary Conway of Infinity Design Concepts. The format

1943-554: The strict , schemas of the specification. Note that the intent of the ISO/IEC is to allow the removal of the transitional variant from the ISO/IEC 29500 standard. Microsoft Office 2013 and later fully support ISO/IEC 29500 Strict, but do not use it as the default file format because of backwards compatibility concerns. The ability to read and write Office Open XML format is, however, not limited to Microsoft Office; other office products are also able to read & write this format: Other office products that offer import support for

2010-459: The ECMA-376 fast-track submission. Ecma International asserted that, "The OSP enables both open source and commercial software to implement [the specification]". The Office Open XML specification exists in several versions. The ECMA standard is structured in five parts to meet the needs of different audiences. Later versions of the ECMA-376 standard are aligned and technically equivalent to

2077-470: The Ecma International code of conduct in patent matters, participating and approving member organizations of ECMA are required to make their patent rights available on a reasonable and non-discriminatory (RAND) basis. Holders of patents which concern ISO/IEC International Standards may agree to a standardized license governing the terms under which such patents may be licensed, in accord with

ZIP (file format) - Misplaced Pages Continue

2144-483: The Office Open XML file formats have become the default file format of Microsoft Office . However, due to the changes introduced in the Office Open XML standard, Office 2007 is not wholly in compliance with ISO/IEC 29500:2008. Office 2010 includes support for opening documents of the ISO/IEC 29500:2008-compliant version of Office Open XML, but it can only save documents conforming to the transitional , not

2211-422: The PKWARE website. A summary of key advances in various versions of the PKWARE specification: WinZip , starting with version 12.1, uses the extension .zipx for ZIP files that use compression methods newer than DEFLATE; specifically, methods BZip, LZMA, PPMd, Jpeg and Wavpack. The last 2 are applied to appropriate file types when "Best method" compression is selected. In April 2010, ISO/IEC JTC 1 initiated

2278-577: The PKZIP AppNote.txt specification, and can be read by compliant zip tools or libraries. This property of the .ZIP format, and of the JAR format which is a variant of ZIP, can be exploited to hide rogue content (such as harmful Java classes) inside a seemingly harmless file, such as a GIF image uploaded to the web. This so-called GIFAR exploit has been demonstrated as an effective attack against web applications such as Facebook. The minimum size of

2345-620: The ZIP File Format Specification since version 5.2. A WinZip -developed AES-based open standard ("AE-x" in APPNOTE) is used also by 7-Zip and Xceed , but some vendors use other formats. PKWARE SecureZIP (SES, proprietary) also supports RC2, RC4, DES, Triple DES encryption methods, Digital Certificate-based encryption and authentication ( X.509 ), and archive header encryption. It is, however, patented (see § Strong encryption controversy ). File name encryption

2412-402: The ZIP file, pointing to the actual entry data. This allows a file listing of the archive to be performed relatively quickly, as the entire archive does not have to be read to see the list of files. The entries within the ZIP file also include this information, for redundancy, in a local file header . Because ZIP files may be appended to, only files specified in the central directory at the end of

2479-507: The ZIP so start with "MZ"; self-extracting ZIPs for other operating systems may similarly be preceded by executable code for extracting the archive's content on that platform.) The .ZIP specification also supports spreading archives across multiple file-system files. Originally intended for storage of large ZIP files across multiple floppy disks , this feature is now used for sending ZIP archives in parts over email, or over other transports or removable media. The FAT filesystem of DOS has

2546-483: The archive file are indicators of the file format used. Computer archive files are created by file archiver software, optical disc authoring software , and disk image software. An archive format is the file format of an archive file. Some formats are well-defined by their authors and have become conventions supported by multiple vendors and communities. Filename extensions used to distinguish different types of archives include zip , rar , 7z , and tar ,

2613-600: The archive is then known as a package . While the archival file format is the same, there are additional conventions about contents, such as requiring a manifest file , and the resulting format is known as a package format . Examples include deb for Debian , JAR for Java , APK for Android , and self-extracting Windows Installer executables . Features supported by various kinds of archives include: Some archive programs have self-extraction, self-installation, source volume and medium information, and package notes/description. The file extension or file header of

2680-419: The central directory specifies where a file chunk starts and that it has not been deleted. Scanning could lead to false positives, as the format does not forbid other data to be between chunks, nor file data streams from containing such signatures. However, tools that attempt to recover data from damaged ZIP archives will most likely scan the archive for local file header signatures; this is made more difficult by

2747-526: The changes from ECMA-376 1st Edition to ISO/IEC 29500:2008 was that a valid ECMA-376 document would also be a valid ISO 29500 Transitional document; however, at least one change introduced at the BRM—refusing to allow further values for xsd:boolean—had the effect of breaking backwards-compatibility for most documents. A fix for this had been suggested to ISO/IEC JTC 1/SC 34 /WG 4, and was approved in June 2009 as

ZIP (file format) - Misplaced Pages Continue

2814-483: The classic LOC or CDFH records. To signal that the actual values are stored in ZIP64 extra fields, they are set to 0xFFFF or 0xFFFFFFFF in the corresponding LOC or CDFH record. If one entry does not fit into the classic LOC or CDFH record, only that entry is required to be moved into a ZIP64 extra field. The other entries may stay in the classic record. Therefore, not all entries shown in the following table might be stored in

2881-686: The corresponding ISO standard. The ISO/IEC standard is structured into four parts: Parts 1, 2 and 3 are independent standards; for example, Part 2, specifying Open Packaging Conventions , is used by other file formats including XPS and Design Web Format . Part 4 is to be read as a modification to Part 1, which it requires. A technically equivalent set of texts is also published by Ecma as ECMA-376 2nd edition (2008). The standard specifies two levels of document & application conformance, strict and transitional, for each of WordprocessingML, PresentationML and SpreadsheetML, and also specifies applications' descriptions of base and full . The intent of

2948-663: The default file format because of backwards compatibility concerns. In 2000, Microsoft released an initial version of an XML -based format for Microsoft Excel, which was incorporated in Office XP. In 2002, a new file format for Microsoft Word followed. The Excel and Word formats—known as the Microsoft Office XML formats —were later incorporated into the 2003 release of Microsoft Office. Microsoft announced in November 2005 that it would co-sponsor standardization of

3015-420: The ditto command shipped with Mac OS will unzip ZIP64 files. More recent versions of Mac OS ship with info-zip's zip and unzip command line tools which do support Zip64: to verify run zip -v and look for "ZIP64_SUPPORT". The .ZIP file format allows for a comment containing up to 65,535 (2−1) bytes of data to occur at the end of the file after the central directory. Also, because the central directory specifies

3082-422: The extent it conforms to a Covered Specification [...] This is limited to applications which do not deviate from the ISO/IEC 29500:2008 or Ecma-376 standard and to parties that do not "file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification". The Open Specification Promise was included in documents submitted to ISO/IEC in support of

3149-479: The fact that the compressed size of a file chunk may be stored after the file chunk, making sequential processing difficult. Most of the signatures end with the short integer 0x4b50, which is stored in little-endian ordering. Viewed as an ASCII string this reads "PK", the initials of the inventor Phil Katz. Thus, when a ZIP file is viewed in a text editor the first two bytes of the file are usually "PK". (DOS, OS/2 and Windows self-extracting ZIPs have an EXE before

3216-473: The fields to safely skip them. Header IDs 0–31 are reserved for use by PKWARE. The remaining IDs can be used by third-party vendors for proprietary usage. Archive file format Archive files are particularly useful in that they store file system data and metadata within the contents of a particular file, and thus can be stored on systems or sent over channels that do not support the file system in question, only file contents – examples include sending

3283-403: The file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives), as the central directory may declare that some files have been deleted and other files have been updated. For example, we may start with a ZIP file that contains files A, B and C. File B is then deleted and C updated. This may be achieved by just appending a new file C to the end of

3350-470: The file both before and after the ZIP archive data, and for the archive to still be read by a ZIP application. A side-effect of this is that it is possible to author a file that is both a working ZIP archive and another format, provided that the other format tolerates arbitrary data at its end, beginning, or middle. Self-extracting archives (SFX), of the form supported by WinZip, take advantage of this, in that they are executable ( .exe ) files that conform to

3417-475: The first of which is the most widely implemented. Java also introduced a whole family of archive extensions such as jar and war ( j is for Java and w is for web). They are used to exchange entire byte-code deployment. Sometimes they are also used to exchange source code and other text, HTML and XML files. By default they are all compressed. Archive files often include parity checks and other checksums for error detection , for instance zip files use

SECTION 50

#1732784016271

3484-648: The format received the necessary votes for approval as an ISO/IEC Standard as the result of a JTC 1 fast-tracking standardization process that concluded in April 2008. The resulting four-part International Standard (designated ISO/IEC 29500:2008) was published in November 2008 and can be downloaded from the ITTF . A technically equivalent set of texts is published by Ecma as ECMA-376 Office Open XML File Formats—2nd edition (December 2008); they can be downloaded from their website. The ISO/IEC standardization of Office Open XML

3551-631: The new version of their XML-based formats through Ecma International as "Office Open XML". The presentation was made to Ecma by Microsoft's Jean Paoli and Isabelle Valet-Harper. Microsoft submitted initial material to Ecma International Technical Committee TC45, where it was standardized to become ECMA-376, approved in December 2006. This standard was then fast-tracked in the Joint Technical Committee 1 of ISO and IEC. After initially failing to pass , an amended version of

3618-403: The offset of each file in the archive with respect to the start, it is possible for the first file entry to start at an offset other than zero, although some tools might not process archive files that do not start with a file entry at offset zero. The program gzip , for example, happens to be able to extract an entry from a .ZIP file if it is at offset zero. This allows arbitrary data to occur in

3685-416: The old central directory, append the new files then append an updated central directory. The order of the file entries in the central directory need not coincide with the order of file entries in the archive. Each entry stored in a ZIP archive is introduced by a local file header with information about the file such as the comment, file size and file name, followed by optional "extra" data fields, and then

3752-418: The original ZIP file and adding a new central directory that only lists file A and the new file C. When ZIP was first designed, transferring files by floppy disk was common, yet writing to disks was very time-consuming. If you had a large zip file, possibly spanning multiple disks, and only needed to update a few files, rather than reading and re-writing all the files, it would be substantially faster to just read

3819-495: The possibly compressed, possibly encrypted file data. The "Extra" data fields are the key to the extensibility of the ZIP format. "Extra" fields are exploited to support the ZIP64 format, WinZip-compatible AES encryption, file attributes, and higher-resolution NTFS or Unix file timestamps. Other extensions are possible via the "Extra" field. ZIP tools are required by the specification to ignore Extra fields they do not recognize. The ZIP format uses specific 4-byte "signatures" to denote

3886-529: The program code to a ZIP archive and marking the file as executable. Storing the catalog at the end also makes possible to hide a zipped file by appending it to an innocuous file, such as a GIF image file. The .ZIP format uses a 32-bit CRC algorithm and includes two copies of each entry metadata to provide greater protection against data loss. The CRC-32 algorithm was contributed by David Schwaderer and can be found in his book "C Programmers Guide to NetBIOS" published by Howard W. Sams & Co. Inc. A ZIP file

3953-400: The same archive to be compressed using different methods. Because the files in a ZIP archive are compressed individually, it is possible to extract them, or add new ones, without applying compression or decompression to the entire archive. This contrasts with the format of compressed tar files, for which such random-access processing is not easily possible. A directory is placed at the end of

4020-462: The various structures in the file. Each file entry is marked by a specific signature. The end of central directory record is indicated with its specific signature, and each entry in the central directory starts with the 4-byte central file header signature . There is no BOF or EOF marker in the ZIP specification. Conventionally the first thing in a ZIP file is a ZIP entry, which can be identified easily by its local file header signature . However, this

4087-473: The version numbers for the PKZIP tool, especially with PKZIP 6 or later. At various times, PKWARE has added preliminary features that allow PKZIP products to extract archives using advanced features, but PKZIP products that create such archives are not made available until the next major release. Other companies or organizations support the PKWARE specifications at their own pace. The .ZIP file format specification

SECTION 60

#1732784016271

4154-418: Was controversial and embittered, with much discussion both about the specification and about the standardization process. According to InfoWorld , "OOXML was opposed by many on grounds it was unneeded, as software makers could use OpenDocument Format (ODF), a less complicated office software format that was already an international standard." The same InfoWorld article reported that IBM (which supports

4221-467: Was created after Systems Enhancement Associates (SEA) filed a lawsuit against PKWARE claiming that the latter's archiving products, named PKARC, were derivatives of SEA's ARC archiving system. The name "zip" (meaning "move at high speed") was suggested by Katz's friend, Robert Mahoney. They wanted to imply that their product would be faster than ARC and other compression formats of the time. The earliest known version of .ZIP File Format Specification

4288-553: Was first published as part of PKZIP 0.9 package under the file APPNOTE.TXT in 1989. By distributing the zip file format within APPNOTE.TXT, compatibility with the zip file format proliferated widely on the public Internet during the 1990s. PKWARE and Infinity Design Concepts made a joint press release on February 14, 1989, releasing the .ZIP file format into the public domain . The .ZIP File Format Specification has its own version number, which does not necessarily correspond to

4355-494: Was never added. The word Implode is overused by PKWARE: the DCL/TERSE Implode is distinct from the old PKZIP Implode, a predecessor to Deflate. The DCL Implode is undocumented partially due to its proprietary nature held by IBM, but Mark Adler has nevertheless provided a decompressor called "blast" alongside zlib. ZIP supports a simple password -based symmetric encryption system generally known as ZipCrypto. It

4422-400: Was published which states that "Document container files are conforming Zip files". It requires the following main restrictions of the ZIP file format: .ZIP files are archives that store multiple files. ZIP allows contained files to be compressed using many different methods, as well as simply storing a file without compressing it. Each file is stored separately, allowing different files in

4489-668: Was then quickly supported by many software utilities other than PKZIP. Microsoft has included built-in ZIP support (under the name "compressed folders") in versions of Microsoft Windows since 1998 via the "Plus! 98" addon for Windows 98. Native support was added as of the year 2000 in Windows ME. Apple has included built-in ZIP support in Mac ;OS X 10.3 (via BOMArchiveHelper, now Archive Utility ) and later. Most free operating systems have built in support for ZIP in similar manners to Windows and macOS. ZIP files generally use

#270729