zip

Standardisasi
Pada bulan April 2010, ISO/IEC JTC 1 memprakarsai pemungutan suara untuk menentukan apakah suatu proyek harus dimulai untuk membuat format Standar Internasional ISO/IEC yang kompatibel dengan ZIP.[30] Proyek yang diusulkan, berjudul Pengemasan Dokumen, membayangkan ‘format arsip terkompresi minimal’ yang kompatibel dengan ZIP yang cocok untuk digunakan dengan sejumlah standar yang ada termasuk OpenDocument, Office Open XML dan EPUB.

Pada tahun 2015, ISO/IEC 21320-1 “File Wadah Dokumen — Bagian 1: Inti” diterbitkan yang menyatakan bahwa “File wadah dokumen sesuai dengan file Zip”. Itu membutuhkan batasan utama berikut dari format file ZIP:

File dalam arsip ZIP hanya dapat disimpan tanpa kompresi, atau menggunakan kompresi “deflate” (yaitu metode kompresi dapat berisi nilai “0” – disimpan atau “8” – dikempiskan).
Fitur enkripsi dilarang.
Fitur tanda tangan digital (dari SES) dilarang.
Fitur “data yang ditambal” (dari PKPatchMaker) dilarang.
Arsip tidak boleh menjangkau beberapa volume atau tersegmentasi.
Mendesain
File .ZIP adalah arsip yang menyimpan banyak file. ZIP memungkinkan file yang dikompresi menggunakan berbagai metode, serta hanya menyimpan file tanpa mengompresinya. Setiap file disimpan secara terpisah, memungkinkan file yang berbeda di arsip yang sama dikompres menggunakan metode yang berbeda. Karena file dalam arsip ZIP dikompresi satu per satu, dimungkinkan untuk mengekstraknya, atau menambahkan yang baru, tanpa menerapkan kompresi atau dekompresi ke seluruh arsip. Ini kontras dengan format file tar terkompresi, yang pemrosesan akses acaknya tidak mudah dilakukan.

Direktori ditempatkan di akhir file ZIP. Ini mengidentifikasi file apa yang ada di ZIP dan mengidentifikasi di mana di ZIP file itu berada. Ini memungkinkan pembaca ZIP memuat daftar file tanpa membaca seluruh arsip ZIP. Arsip ZIP juga dapat menyertakan data tambahan yang tidak terkait dengan arsip ZIP. Hal ini memungkinkan arsip ZIP dibuat menjadi arsip yang mengekstraksi sendiri (aplikasi yang mendekompresi data yang terkandung di dalamnya), dengan menambahkan kode program ke arsip ZIP dan menandai file sebagai dapat dieksekusi. Menyimpan katalog di bagian akhir juga memungkinkan menyembunyikan file zip dengan menambahkannya ke file yang tidak berbahaya, seperti file gambar GIF.

Format .ZIP menggunakan algoritme CRC 32-bit dan menyertakan dua salinan struktur direktori arsip untuk memberikan perlindungan lebih besar terhadap kehilangan data.

Struktur

ZIP-64 Tata Letak Internal
File ZIP diidentifikasi dengan benar dengan adanya akhir catatan direktori pusat yang terletak di akhir struktur arsip untuk memungkinkan penambahan file baru dengan mudah. Jika akhir catatan direktori pusat menunjukkan arsip yang tidak kosong, nama setiap file atau direktori di dalam arsip harus ditentukan dalam entri direktori pusat, bersama dengan metadata lain tentang entri tersebut, dan offset ke dalam file ZIP, menunjuk ke data entri yang sebenarnya. Ini memungkinkan daftar file arsip dilakukan relatif cepat, karena seluruh arsip tidak perlu dibaca untuk melihat daftar file. Entri dalam file ZIP juga menyertakan informasi ini, untuk redundansi, di header file lokal. Karena file ZIP dapat ditambahkan, hanya file yang ditentukan di direktori pusat di akhir file yang valid. Memindai file ZIP untuk header file lokal tidak valid (kecuali dalam kasus arsip yang rusak), karena direktori pusat dapat menyatakan bahwa beberapa file telah dihapus dan file lainnya telah diperbarui.

Misalnya, kita mungkin mulai dengan file ZIP yang berisi file A, B, dan C. File B kemudian dihapus dan C diperbarui. Ini dapat dicapai hanya dengan menambahkan file C baru ke akhir file ZIP asli dan menambahkan direktori pusat baru yang hanya mencantumkan file A dan file baru C. Ketika ZIP pertama kali dirancang, mentransfer file dengan floppy disk adalah hal biasa, namun menulis ke disk sangat memakan waktu. Jika Anda memiliki file zip besar, mungkin menjangkau banyak disk, dan hanya perlu memperbarui beberapa file, daripada membaca dan menulis ulang semua file, akan jauh lebih cepat untuk hanya membaca direktori pusat lama, tambahkan file baru kemudian tambahkan direktori pusat yang diperbarui.

Urutan entri file di direktori pusat tidak perlu sama dengan urutan entri file di arsip.

Setiap entri yang disimpan dalam arsip ZIP diperkenalkan oleh header file lokal dengan informasi tentang file seperti komentar, ukuran file dan nama file, diikuti oleh bidang data “ekstra” opsional, dan kemudian data file yang mungkin dikompresi, mungkin dienkripsi. Bidang data “Ekstra” adalah kunci perluasan format ZIP. Bidang “Ekstra” dieksploitasi untuk mendukung format ZIP64, enkripsi AES yang kompatibel dengan WinZip, atribut file, dan cap waktu file NTFS atau Unix dengan resolusi lebih tinggi. Ekstensi lain dimungkinkan melalui bidang “Ekstra”. Alat ZIP diperlukan oleh spesifikasi untuk mengabaikan bidang Ekstra yang tidak mereka kenali.

Format ZIP menggunakan “tanda tangan” 4-byte khusus untuk menunjukkan berbagai struktur dalam file. Setiap entri file ditandai dengan tanda tangan tertentu. Akhir dari catatan direktori pusat ditunjukkan dengan tanda tangannya yang spesifik, dan setiap entri dalam direktori pusat dimulai dengan tanda tangan header file pusat 4-byte.

Tidak ada penanda BOF atau EOF dalam spesifikasi ZIP. Secara konvensional hal pertama dalam file ZIP adalah entri ZIP, yang dapat dengan mudah diidentifikasi dengan tanda tajuk file lokalnya. Namun, ini belum tentu demikian, karena ini tidak diperlukan oleh spesifikasi ZIP – terutama, arsip yang mengekstraksi sendiri akan dimulai dengan header file yang dapat dieksekusi.

Alat yang membaca arsip ZIP dengan benar harus memindai akhir tanda tangan catatan direktori pusat, dan kemudian, sebagaimana mestinya, catatan direktori pusat lainnya yang ditunjukkan. Mereka tidak boleh memindai entri dari bagian atas file ZIP, karena (seperti yang disebutkan sebelumnya di bagian ini) hanya direktori pusat yang menentukan di mana potongan file dimulai dan belum dihapus. Pemindaian dapat menyebabkan positif palsu, karena format tidak melarang data lain berada di antara potongan, atau aliran data file berisi tanda tangan tersebut. Namun, alat yang mencoba memulihkan data dari arsip ZIP yang rusak kemungkinan besar akan memindai arsip untuk mencari tanda tangan tajuk file lokal; ini menjadi lebih sulit dengan fakta bahwa ukuran terkompresi dari potongan file dapat disimpan setelah potongan file, membuat pemrosesan sekuensial menjadi sulit.

Sebagian besar tanda tangan diakhiri dengan bilangan bulat pendek 0x4b50, yang disimpan dalam urutan little-endian. Dilihat sebagai string ASCII ini berbunyi “PK”, inisial dari penemu Phil Katz. Jadi, ketika file ZIP dilihat di editor teks, dua byte pertama dari file tersebut biasanya adalah “PK”. (ZIP yang mengekstrak sendiri DOS, OS/2 dan Windows memiliki EXE sebelum ZIP, jadi mulailah dengan “MZ”; ZIP yang mengekstrak sendiri untuk sistem operasi lain juga dapat didahului oleh kode yang dapat dieksekusi untuk mengekstraksi konten arsip pada platform tersebut.)

Spesifikasi .ZIP juga mendukung penyebaran arsip ke beberapa file sistem file. Awalnya dimaksudkan untuk penyimpanan file ZIP besar di beberapa floppy disk, fitur ini sekarang digunakan untuk mengirim arsip ZIP sebagian melalui email, atau melalui transportasi lain atau media yang dapat dilepas.

Filesystem FAT DOS memiliki resolusi timestamp hanya dua detik; Catatan file ZIP meniru ini. Hasilnya, resolusi stempel waktu bawaan file dalam arsip ZIP hanya dua detik, meskipun kolom tambahan dapat digunakan untuk menyimpan stempel waktu yang lebih akurat. Format ZIP tidak memiliki gagasan tentang zona waktu, jadi stempel waktu hanya bermakna jika diketahui di zona waktu mana mereka dibuat.

Pada bulan September 2006, PKWARE merilis revisi spesifikasi ZIP yang menyediakan penyimpanan nama file menggunakan UTF-8, akhirnya menambahkan kompatibilitas Unicode ke ZIP.[17]

File header
Semua nilai multi-byte di header disimpan dalam urutan byte little-endian. Semua bidang panjang menghitung panjang dalam byte.

Tajuk file lokal/Local file header

Bidang tambahan berisi berbagai data opsional seperti atribut khusus OS. Itu dibagi menjadi catatan, masing-masing dengan minimal tanda tangan 16-bit dan panjang 16-bit. Rekaman lapangan ekstra file lokal ZIP64, misalnya, memiliki tanda tangan 0x0001 dan panjang 16 byte (atau lebih) sehingga dua nilai 64-bit (ukuran yang tidak dikompresi dan dikompresi) dapat mengikuti. Ekstensi file lokal umum lainnya adalah 0x5455 (atau “UT”) yang berisi cap waktu UNIX UTC 32-bit.

Ini segera diikuti oleh data terkompresi.

Deskriptor data
Jika bit pada offset 3 (0x08) dari bidang flag tujuan umum disetel, maka CRC-32 dan ukuran file tidak diketahui saat header ditulis. Jika arsip dalam format Zip64, bidang ukuran terkompresi dan tidak terkompresi memiliki panjang 8 byte, bukan 4 byte (lihat bagian 4.3.9.2[33]). Bidang yang setara di header lokal (atau di bidang tambahan informasi tambahan Zip64 dalam kasus arsip dalam format Zip64) diisi dengan nol, dan CRC-32 dan ukuran ditambahkan dalam struktur 12-byte (opsional didahului oleh Tanda tangan 4-byte) segera setelah data terkompresi:

Tajuk file direktori pusat
Entri direktori pusat adalah bentuk yang diperluas dari header lokal:

Akhir catatan direktori pusat (EOCD)
Setelah semua entri direktori pusat muncul akhir catatan direktori pusat (EOCD), yang menandai akhir dari file ZIP:

Pengurutan ini memungkinkan file ZIP dibuat dalam satu pass, tetapi direktori pusat juga ditempatkan di akhir file untuk memfasilitasi penghapusan file dengan mudah dari arsip multi-bagian (mis. “multiple floppy-disk”), seperti dibahas sebelumnya.

Metode kompresi
Spesifikasi Format File .ZIP mendokumentasikan metode kompresi berikut: Store (tanpa kompresi), Shrink (LZW), Reduce (level 1–4; LZ77 + probabilistic), Implode, Deflate, Deflate64, bzip2, LZMA, WavPack, PPMd, dan varian LZ77 yang disediakan oleh instruksi IBM z/OS CMPSC.Metode kompresi yang paling umum digunakan adalah DEFLATE, yang dijelaskan dalam IETF RFC 1951.

Metode lain yang disebutkan, tetapi tidak didokumentasikan secara rinci dalam spesifikasi meliputi: PKWARE DCL Implode (IBM TERSE lama), IBM TERSE baru, IBM LZ77 z Architecture (PFS), dan varian JPEG. Metode “Tokenize” disediakan untuk pihak ketiga, tetapi dukungan tidak pernah ditambahkan

Kata Implode terlalu sering digunakan oleh PKWARE: Implode DCL/TERSE berbeda dari Implode PKZIP lama, pendahulu Deflate. DCL Implode tidak terdokumentasikan sebagian karena sifat kepemilikannya dipegang oleh IBM, tetapi Mark Adler tetap menyediakan dekompresor yang disebut “ledakan” bersama zlib.

Enkripsi
ZIP mendukung sistem enkripsi simetris berbasis kata sandi sederhana yang umumnya dikenal sebagai ZipCrypto. Itu didokumentasikan dalam spesifikasi ZIP, dan diketahui cacat serius. Secara khusus, ini rentan terhadap serangan teks biasa yang diketahui, yang dalam beberapa kasus diperparah oleh implementasi yang buruk dari generator nomor acak. Komputer yang berjalan di bawah Microsoft Windows asli tanpa pengarsipan pihak ketiga dapat membuka, tetapi tidak dapat membuat, file ZIP yang dienkripsi dengan ZipCrypto, tetapi tidak dapat mengekstrak konten file menggunakan enkripsi yang berbeda

Fitur baru termasuk metode kompresi dan enkripsi baru (misalnya AES) telah didokumentasikan dalam Spesifikasi Format File ZIP sejak versi 5.2. Standar terbuka berbasis AES yang dikembangkan oleh WinZip (“AE-x” dalam APPNOTE) juga digunakan oleh 7-Zip dan Xceed, tetapi beberapa vendor menggunakan format lain. PKWARE SecureZIP (SES, proprietary) juga mendukung metode enkripsi RC2, RC4, DES, Triple DES, enkripsi dan autentikasi berbasis Sertifikat Digital (X.509), dan enkripsi header arsip. Namun, ini dipatenkan (lihat § Kontroversi enkripsi yang kuat).

Enkripsi nama file diperkenalkan dalam Spesifikasi Format File .ZIP 6.2, yang mengenkripsi metadata yang disimpan di bagian Direktori Pusat dari suatu arsip, tetapi bagian Header Lokal tetap tidak terenkripsi. Pengarsip yang patuh dapat memalsukan data Tajuk Lokal saat menggunakan Enkripsi Direktori Pusat. Pada spesifikasi versi 6.2, kolom Compression Method dan Compressed Size di dalam Local Header belum ditutup.

ZIP64
Format .ZIP asli memiliki batas 4 GB (232 byte) untuk berbagai hal (ukuran file tidak terkompresi, ukuran file terkompresi, dan ukuran total arsip), serta batas 65.535 (216-1) entri dalam arsip ZIP. Dalam spesifikasi versi 4.5 (yang tidak sama dengan v4.5 alat tertentu), PKWARE memperkenalkan ekstensi format “ZIP64” untuk mengatasi batasan ini, meningkatkan batas menjadi 16 EB (264 byte). Intinya, ini menggunakan entri direktori pusat “normal” untuk sebuah file, diikuti dengan entri direktori “zip64” opsional, yang memiliki bidang yang lebih besar.

Format header file lokal (LOC) dan entri direktori pusat (CEN) sama di ZIP dan ZIP64. Namun, ZIP64 menentukan bidang tambahan yang dapat ditambahkan ke rekaman tersebut sesuai kebijaksanaan kompresor, yang tujuannya adalah untuk menyimpan nilai yang tidak sesuai dengan rekaman LOC atau CEN klasik. Untuk menandakan bahwa nilai sebenarnya disimpan dalam bidang ekstra ZIP64, nilai tersebut diatur ke 0xFFFF atau 0xFFFFFFFF dalam catatan LOC atau CEN yang sesuai. Jika satu entri tidak cocok dengan catatan LOC atau CEN klasik, hanya entri tersebut yang harus dipindahkan ke bidang tambahan ZIP64. Entri lain mungkin tetap dalam catatan klasik. Oleh karena itu, tidak semua entri yang diperlihatkan dalam tabel berikut mungkin disimpan dalam bidang tambahan ZIP64. Namun, jika muncul, urutannya harus seperti yang ditunjukkan pada tabel.

Di sisi lain, format EOCD untuk ZIP64 sedikit berbeda dari versi ZIP biasa

Itu juga belum tentu catatan terakhir dalam file. End of Central Directory Locator mengikuti (tambahan 20 byte di bagian akhir).

File Explorer di Windows XP tidak mendukung ZIP64, tetapi Explorer di Windows Vista dan yang lebih baru melakukannya. Perl. Zipfile bawaan Python mendukungnya sejak 2.5 dan defaultnya sejak 3.4. Java.util.zip bawaan OpenJDK mendukung ZIP64 dari versi Java 7. Android Java API mendukung ZIP64 sejak Android 6.0. Utilitas Arsip Mac OS Sierra khususnya tidak mendukung ZIP64, dan dapat membuat arsip korup saat ZIP64 diperlukan. Namun, perintah ditto yang disertakan dengan Mac OS akan meng-unzip file ZIP64 Versi terbaru [kapan?] Mac OS dikirimkan dengan zip info-zip dan alat baris perintah unzip yang mendukung Zip64: untuk memverifikasi, jalankan zip -v dan cari “ZIP64_SUPPORT”.

Kombinasi dengan format file lainnya
Format file .ZIP memungkinkan komentar yang berisi hingga 65.535 (216−1) byte data muncul di akhir file setelah direktori pusat. Juga, karena direktori pusat menentukan offset setiap file dalam arsip sehubungan dengan awal, entri file pertama mungkin dimulai dengan offset selain nol, meskipun beberapa alat, misalnya gzip, tidak akan memproses arsip file yang tidak dimulai dengan entri file di offset nol.

Ini memungkinkan data sewenang-wenang muncul di file sebelum dan sesudah data arsip ZIP, dan agar arsip tetap dapat dibaca oleh aplikasi ZIP. Efek samping dari hal ini adalah memungkinkan untuk membuat file yang merupakan arsip ZIP yang berfungsi dan format lain, asalkan format lain mentolerir data arbitrer di bagian akhir, awal, atau tengah. Self-extracting archives (SFX), dalam bentuk yang didukung oleh WinZip, manfaatkan ini, karena merupakan file yang dapat dieksekusi (.exe) yang sesuai dengan spesifikasi PKZIP AppNote.txt, dan dapat dibaca oleh alat atau pustaka zip yang sesuai .

Properti format .ZIP ini, dan format JAR yang merupakan varian dari ZIP, dapat dimanfaatkan untuk menyembunyikan konten jahat (seperti kelas Java yang berbahaya) di dalam file yang tampaknya tidak berbahaya, seperti gambar GIF yang diunggah ke web. Eksploitasi GIFAR yang disebut ini telah didemonstrasikan sebagai serangan yang efektif terhadap aplikasi web seperti Facebook.

Batas
Ukuran minimum file .ZIP adalah 22 byte. File zip kosong seperti itu hanya berisi 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]

Ukuran maksimum untuk file arsip dan file individual di dalamnya adalah 4.294.967.295 byte (232−1 byte, atau 4 GB dikurangi 1 byte) untuk ZIP standar. Untuk ZIP64, ukuran maksimumnya adalah 18.446.744.073.709.551.615 byte (264−1 byte, atau 16 EB dikurangi 1 byte).

Ekstensi berpemilik
Bidang ekstra
Format file .ZIP menyertakan fasilitas bidang tambahan di dalam header file, yang dapat digunakan untuk menyimpan data tambahan yang tidak ditentukan oleh spesifikasi ZIP yang ada, dan yang memungkinkan pengarsipan yang sesuai yang tidak mengenali bidang untuk melewatinya dengan aman. Header ID 0–31 dicadangkan untuk digunakan oleh PKWARE. ID yang tersisa dapat digunakan oleh vendor pihak ketiga untuk penggunaan kepemilikan.

Kontroversi enkripsi yang kuat
Ketika WinZip 9.0 beta publik dirilis pada tahun 2003, WinZip memperkenalkan enkripsi AES-256 miliknya sendiri, menggunakan format file yang berbeda, bersama dengan dokumentasi untuk spesifikasi baru.[48] Standar enkripsi itu sendiri bukanlah hak milik, tetapi PKWARE belum memperbarui APPNOTE.TXT untuk menyertakan Spesifikasi Enkripsi Kuat (SES) sejak tahun 2001, yang telah digunakan oleh PKZIP versi 5.0 dan 6.0. Konsultan teknis WinZip Kevin Kearney dan manajer produk StuffIt Mathew Covington menuduh PKWARE menahan SES, tetapi kepala petugas teknologi PKZIP Jim Peterson mengklaim bahwa enkripsi berbasis sertifikat masih belum lengkap.

Dalam langkah kontroversial lainnya, PKWare mengajukan permohonan paten pada 16 Juli 2003 yang menjelaskan metode untuk menggabungkan ZIP dan enkripsi yang kuat untuk membuat file yang aman.

Pada akhirnya, PKWARE dan WinZip sepakat untuk saling mendukung produk masing-masing. Pada 21 Januari 2004, PKWARE mengumumkan dukungan format kompresi AES berbasis WinZip. Dalam versi beta WinZip yang lebih baru, ia dapat mendukung file ZIP berbasis SES. PKWARE akhirnya merilis versi 5.2 dari Spesifikasi Format File .ZIP kepada publik, yang mendokumentasikan SES. Proyek Perangkat Lunak Bebas 7-Zip juga mendukung AES, tetapi tidak mendukung SES dalam file ZIP (seperti halnya port POSIX p7zip).

Saat menggunakan enkripsi AES di bawah WinZip, metode kompresi selalu diatur ke 99, dengan metode kompresi yang sebenarnya disimpan dalam bidang data ekstra AES.[52] Sebaliknya, Spesifikasi Enkripsi Kuat menyimpan metode kompresi di segmen header file dasar dari Header Lokal dan Direktori Pusat, kecuali Enkripsi Direktori Pusat digunakan untuk menutupi/mengenkripsi metadata.

Penerapan
Ada banyak alat .ZIP yang tersedia, dan banyak pustaka .ZIP untuk berbagai lingkungan pemrograman; lisensi yang digunakan termasuk perangkat lunak berpemilik dan bebas. WinZip, WinRAR, Info-ZIP, ZipGenius, 7-Zip, PeaZip dan B1 Free Archiver adalah alat .ZIP yang terkenal, tersedia di berbagai platform. Beberapa dari alat tersebut memiliki pustaka atau antarmuka terprogram.

Beberapa pustaka pengembangan yang dilisensikan berdasarkan perjanjian sumber terbuka adalah libzip, libarchive, dan Info-ZIP. Untuk Java: Java Platform, Edisi Standar berisi paket “java.util.zip” untuk menangani file .ZIP standar; pustaka Zip64File secara khusus mendukung file besar (lebih besar dari 4 GB) dan memperlakukan file .ZIP menggunakan akses acak; dan alat Apache Ant berisi implementasi yang lebih lengkap yang dirilis di bawah Lisensi Perangkat Lunak Apache.

Implementasi Info-ZIP dari format .ZIP menambahkan dukungan untuk fitur sistem file Unix, seperti ID pengguna dan grup, izin file, dan dukungan untuk tautan simbolik. Implementasi Apache Ant menyadari hal ini sejauh ia dapat membuat file dengan izin Unix yang telah ditentukan sebelumnya. Implementasi Info-ZIP juga mengetahui cara menggunakan kemampuan koreksi kesalahan yang ada di dalam format kompresi .ZIP. Beberapa program tidak, dan akan gagal pada file yang memiliki kesalahan.

Alat Windows Info-ZIP juga mendukung izin sistem file NTFS, dan akan berusaha menerjemahkan dari izin NTFS ke izin Unix atau sebaliknya saat mengekstraksi file. Hal ini dapat mengakibatkan kombinasi yang berpotensi tidak diinginkan, mis. File .exe dibuat pada volume NTFS dengan izin yang dapat dieksekusi ditolak.

Versi Microsoft Windows telah menyertakan dukungan untuk kompresi .ZIP di Explorer sejak Microsoft Plus! paket dirilis untuk Windows 98. Microsoft menyebut fitur ini “Folder Terkompresi”. Tidak semua fitur .ZIP didukung oleh kemampuan Windows Compressed Folders. Misalnya, enkripsi tidak didukung dalam edisi Windows 10 Home,[53] meskipun dapat mendekripsi. Pengkodean entri Unicode tidak didukung hingga Windows 7, sementara arsip terpisah dan terbentang tidak dapat dibaca atau ditulis oleh fitur Folder Terkompresi, dan Enkripsi AES juga tidak didukung.

Microsoft Office mulai menggunakan format arsip zip pada tahun 2006 untuk file Office Open XML .docx, .xlsx, .pptx, dll., yang menjadi format file default dengan Microsoft Office 2007.

Warisan
Ada banyak standar dan format lain yang menggunakan “zip” sebagai bagian dari namanya. Misalnya, zip berbeda dari gzip, dan gzip didefinisikan dalam IETF RFC 1952. Baik zip maupun gzip terutama menggunakan algoritme DEFLATE untuk kompresi. Demikian pula, format ZLIB (IETF RFC 1950) juga menggunakan algoritma kompresi DEFLATE, tetapi menentukan header yang berbeda untuk pemeriksaan kesalahan dan konsistensi. Format dan program umum lainnya yang bernama serupa dengan format asli yang berbeda termasuk 7-Zip, bzip2, dan rzip.

Kekhawatiran
Faktor kompresi maksimum teoretis untuk aliran DEFLATE mentah adalah sekitar 1032 berbanding satu, [55] tetapi dengan mengeksploitasi format ZIP dengan cara yang tidak diinginkan, arsip ZIP dengan rasio kompresi miliaran berbanding satu dapat dibangun. Bom zip ini di-unzip ke ukuran yang sangat besar, melebihi kapasitas komputer tempat mereka didekompresi.[