ZIPเป็นรูปแบบไฟล์เก็บถาวรที่รองรับการบีบอัดข้อมูลแบบไม่สูญเสียคุณภาพ ไฟล์ ZIP อาจประกอบด้วยไฟล์หรือโฟลเดอร์ตั้งแต่หนึ่งไฟล์ขึ้นไป ซึ่งอาจถูกบีบอัดไว้แล้ว รูปแบบไฟล์ ZIP อนุญาตให้ใช้ อัลกอริธึมการบีบอัดหลายแบบแต่DEFLATEเป็นแบบที่ใช้กันมากที่สุด

รูปแบบนี้ถูกสร้างขึ้นครั้งแรกในปี 1989 และถูกนำไปใช้ครั้งแรกในยูทิลิตี้PKZIPของPKWARE, Inc. ^{[ 2 ]}เพื่อทดแทน รูปแบบการบีบอัด ARC ก่อนหน้านี้ โดย Thom Henderson จากนั้นรูปแบบ ZIP ก็ได้รับการสนับสนุนอย่างรวดเร็วจากยูทิลิตี้ซอฟต์แวร์อื่นๆ นอกเหนือจาก PKZIP รูปแบบ ZIP ได้รับการสนับสนุนโดยตรงในระบบปฏิบัติการหลักๆ (เช่นAndroid , ChromeOS , iOS , Linux , macOSและWindows ) โดยทั่วไปแล้วจะถูกสร้างขึ้นในโปรแกรมจัดการไฟล์ของระบบปฏิบัติการ

^โดยทั่วไปไฟล์ ZIP จะใช้ส่วนขยายไฟล์.zipหรือ.ZIPและประเภทสื่อMIME [ ^{1 ]} ZIP ถูกใช้เป็นรูปแบบไฟล์พื้นฐานโดยโปรแกรมหลายโปรแกรม โดยปกติจะใช้ชื่อที่แตกต่างกัน เมื่อนำทางระบบไฟล์ผ่านอินเทอร์เฟซผู้ใช้ไอคอน กราฟิก ที่แสดงถึงไฟล์ ZIP มักจะปรากฏเป็นเอกสารหรือวัตถุอื่น ๆ ที่มีซิปเป็น จุดเด่นapplication/zip

รูป แบบไฟล์ .ZIPถูกออกแบบโดยPhil KatzจากPKWARE, Inc.และ Gary Conway จาก Infinity Design Concepts รูปแบบนี้ถูกสร้างขึ้นหลังจาก Systems Enhancement Associates (SEA) ฟ้องร้องPKWAREโดยอ้างว่าผลิตภัณฑ์การจัดเก็บถาวรของ PKWARE ที่ชื่อ PKARC นั้นเป็นอนุพันธ์ของระบบการจัดเก็บถาวรARC ของ SEA ^{[ 3 ]} ชื่อ "zip" (หมายถึง "เคลื่อนที่ด้วยความเร็วสูง") ได้รับการแนะนำโดย Robert Mahoney เพื่อนของ Katz ^{[ 4 ]} พวกเขาต้องการสื่อว่าผลิตภัณฑ์ของพวกเขาจะเร็วกว่าARCและรูปแบบการบีบอัดอื่นๆ ในเวลานั้น^{[ 4 ]}เวอร์ชันแรกสุดที่รู้จักของข้อกำหนดรูปแบบไฟล์ . ZIP ได้รับการเผยแพร่ครั้งแรกเป็นส่วนหนึ่งของ แพ็คเกจ PKZIP 0.9 ภายใต้ไฟล์ APPNOTE.TXT ในปี 1989 การแจกจ่ายรูปแบบไฟล์ zip ภายใน APPNOTE.TXT ทำให้ความเข้ากันได้กับรูปแบบไฟล์ zip แพร่หลายอย่างกว้างขวางบนอินเทอร์เน็ตสาธารณะในช่วงทศวรรษ 1990 ^{[ 5 ]}

PKWARE และ Infinity Design Concepts ได้ออกแถลงข่าวร่วมกันเมื่อวันที่ 14 กุมภาพันธ์ พ.ศ. 2532 โดยปล่อย^รูปแบบไฟล์. ZIP ให้เป็น สาธารณสมบัติ^{[ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]}

ข้อกำหนดรูปแบบไฟล์ .ZIP มีหมายเลขเวอร์ชันของตัวเอง ซึ่งไม่จำเป็นต้องตรงกับหมายเลขเวอร์ชันของเครื่องมือ PKZIP โดยเฉพาะอย่างยิ่งกับ PKZIP เวอร์ชัน 6 หรือใหม่กว่า ในบางช่วงเวลา PKWARE ได้เพิ่มคุณสมบัติเบื้องต้นที่ช่วยให้ผลิตภัณฑ์ PKZIP สามารถแตกไฟล์เก็บถาวรโดยใช้คุณสมบัติขั้นสูงได้ แต่ผลิตภัณฑ์ PKZIP ที่สร้างไฟล์เก็บถาวรดังกล่าวจะยังไม่พร้อมใช้งานจนกว่าจะมีการออกเวอร์ชันหลักถัดไป บริษัทหรือองค์กรอื่นๆ ก็ให้การสนับสนุนข้อกำหนดของ PKWARE ในอัตราที่แตกต่างกันไป

ข้อกำหนดรูปแบบไฟล์ .ZIP มีชื่ออย่างเป็นทางการว่า "APPNOTE - ข้อกำหนดรูปแบบไฟล์ .ZIP" และเผยแพร่บนเว็บไซต์ PKWARE.com ตั้งแต่ปลายทศวรรษ 1990 ^{[ 11 ]}ข้อกำหนดหลายเวอร์ชันไม่ได้รับการเผยแพร่ ข้อกำหนดของฟีเจอร์บางอย่าง เช่น การบีบอัด BZIP2ข้อกำหนดการเข้ารหัสที่แข็งแกร่ง และอื่นๆ ได้รับการเผยแพร่โดย PKWARE ในอีกไม่กี่ปีหลังจากที่สร้างขึ้น URL ของข้อกำหนดออนไลน์มีการเปลี่ยนแปลงหลายครั้งบนเว็บไซต์ PKWARE

สรุปความก้าวหน้าสำคัญในซอฟต์แวร์ PKWARE เวอร์ชันต่างๆ และ/หรือข้อกำหนด:

• 2.0: (1993) ^{[ 1 ]}รายการไฟล์สามารถบีบอัดด้วยDEFLATEและใช้การเข้ารหัส PKWARE แบบดั้งเดิม (ZipCrypto)
• 2.1: (1996) รองรับการบีบอัด Deflate64 (อ้างใน APPNOTE 6.1.0 ที่เผยแพร่ในภายหลังมาก) ^{[ 12 ]} APPNOTE อาจไม่ได้เผยแพร่สำหรับ 2.1
• 2.5: การบีบอัด PKWARE DCL Implode ^{[ 12 ]} APPNOTE อาจยังไม่ได้เผยแพร่สำหรับเวอร์ชัน 2.5
• 2.5: รองรับการบีบอัด Deflate64 (อ้างในคู่มือผู้ใช้ฉบับหลัง เช่น ในปี 2547) ^{[ 13 ]}
• 4.0: (2000) การสนับสนุนการบีบอัด Deflate64 (ตามข้อมูลที่ Jim Peterson หัวหน้านักวิทยาศาสตร์ PKWARE ให้กับห้องสมุดรัฐสภาให้ไว้ และ APPNOTE 4.0) ^{[ 14 ] [ 15 ]}
• 4.5: (2001) ^{[ 16 ]}รูปแบบ zip 64 บิตที่บันทึกไว้
• 4.6: (2001) การบีบอัด BZIP2 (ไม่ได้เผยแพร่ทางออนไลน์จนกระทั่งมีการเผยแพร่ APPNOTE 5.2)
• 5.0: (2002) SES: รองรับ DES , Triple DES , RC2 , RC4สำหรับการเข้ารหัส (ไม่ได้เผยแพร่ทางออนไลน์จนกระทั่งมีการเผยแพร่ APPNOTE 5.2)
• 5.2: (2003) ^{[ 17 ] [ 18 ]}การสนับสนุนการเข้ารหัส AES สำหรับ SES (กำหนดไว้ใน APPNOTE 5.1 ​​ซึ่งไม่ได้เผยแพร่ทางออนไลน์) และ AES จาก WinZip ("AE-x"); รองรับเวอร์ชันที่แก้ไขของ RC2-64 สำหรับการเข้ารหัส SES
• 6.1: (2004) ^{[ 12 ]}การจัดเก็บใบรับรองเอกสาร
• 6.2.0: (2004) ^{[ 19 ]}การเข้ารหัสไดเร็กทอรีกลางที่บันทึกไว้
• 6.3.0: (2006) ^{[ 20 ]} การจัดเก็บชื่อไฟล์ Unicode ( UTF-8 ) ที่มีเอกสารประกอบ รายการอัลกอริทึมการบีบอัดที่รองรับ ( LZMA , PPMd+ ) อัลกอริทึมการเข้ารหัส ( Blowfish , Twofish ) และแฮชที่ ขยายเพิ่มเติม
• 6.3.1: (2007) ^{[ 21 ]}ค่าแฮชมาตรฐานที่แก้ไขสำหรับ SHA-256/384/512
• 6.3.2: (2007) ^{[ 22 ]}วิธีการบีบอัดเอกสาร 97 ( WavPack )
• 6.3.3: (2012) ^{[ 23 ]}การเปลี่ยนแปลงรูปแบบเอกสารเพื่ออำนวยความสะดวกในการอ้างอิงบันทึกการใช้งาน PKWARE จากมาตรฐานอื่น ๆ โดยใช้วิธีการเช่น JTC 1 Referencing Explanatory Report (RER) ตามคำสั่งของ JTC 1/SC 34 N 1621
• 6.3.4: (2014) ^{[ 24 ]}อัปเดตที่อยู่สำนักงานของ PKWARE, Inc.
• 6.3.5: (2018) ^{[ 25 ]}บันทึกวิธีการบีบอัด 16, 96 และ 99, ยุคและความแม่นยำของไทม์สแตมป์ DOS, เพิ่มฟิลด์เพิ่มเติมสำหรับคีย์และการถอดรหัส รวมถึงแก้ไขข้อผิดพลาดในการพิมพ์และคำชี้แจง
• 6.3.6: (2019) ^{[ 26 ]}แก้ไขข้อผิดพลาดในการพิมพ์
• 6.3.7: (2020) ^{[ 27 ]}เพิ่ม วิธีการบีบอัด Zstandardรหัส 20
• 6.3.8: (2020) ^{[ 28 ]}ย้ายรหัสวิธีการบีบอัด Zstandard จาก 20 เป็น 93 และยกเลิกวิธีเดิม บันทึกรหัสวิธี 94 และ 95 ( MP3และXZตามลำดับ)
• 6.3.9: (2020) ^{[ 29 ]}แก้ไขข้อผิดพลาดในการพิมพ์ในคำอธิบายการจัดเรียงสตรีมข้อมูล
• 6.3.10: (2022) ^{[ 30 ]}เพิ่มค่าแอตทริบิวต์ z/OS หลายรายการสำหรับภาคผนวก B เพิ่มการแมปฟิลด์เสริมของบุคคลที่สามเพิ่มเติมอีกหลายรายการ

WinZipตั้งแต่เวอร์ชัน 12.1 เป็นต้นไป ใช้ส่วนขยาย.zipxสำหรับไฟล์ ZIP ที่ใช้วิธีการบีบอัดที่ใหม่กว่า DEFLATE โดยเฉพาะวิธีการ BZip, LZMA, PPMd, Jpeg และ Wavpack สองวิธีหลังจะถูกนำไปใช้กับประเภทไฟล์ที่เหมาะสมเมื่อเลือกการบีบอัดแบบ "วิธีที่ดีที่สุด" ^{[ 31 ] [ 32 ]}

ในเดือนเมษายน พ.ศ. 2553 ISO/IEC JTC 1ได้เริ่มการลงคะแนนเพื่อพิจารณาว่าควรเริ่มโครงการสร้างรูปแบบมาตรฐานสากล ISO/IEC ที่เข้ากันได้กับ ZIP หรือไม่^{[ 33 ]}โครงการที่เสนอชื่อว่าDocument Packagingได้วางแผน 'รูปแบบไฟล์เก็บถาวรแบบบีบอัดขั้นต่ำ' ที่เข้ากันได้กับ ZIP ซึ่งเหมาะสำหรับใช้กับมาตรฐานที่มีอยู่หลายมาตรฐาน รวมถึงOpenDocument , Office Open XMLและEPUBซึ่งจะช่วยแก้ปัญหาต่างๆ เช่น ความจำเป็นในการมีมาตรฐานอย่างเป็นทางการ ความหลากหลายของส่วนขยายของ ZIP ความไม่พึงประสงค์ของเทคโนโลยีที่ใช้สำหรับมาตรฐานเปิดที่อาจมีส่วนขยายที่เป็นกรรมสิทธิ์หรือสิทธิบัตร "ใต้น้ำ" (เช่น ซึ่งอาจปรากฏขึ้นโดยไม่คาดคิด) ความจำเป็นในการทำให้เป็นสากลมากขึ้น และความปรารถนาที่จะไม่ทำให้เทคโนโลยีแตกแยกมากขึ้นไปอีกโดยการอ้างว่ามีข้อกำหนดทางเลือกอื่นนอกเหนือจากเอกสาร PKWARE APPNOTE

ในปี 2558 ISO/IEC 21320-1 "ไฟล์คอนเทนเนอร์เอกสาร — ส่วนที่ 1: หลัก" ได้รับการเผยแพร่ ซึ่งระบุว่า "ไฟล์คอนเทนเนอร์เอกสารเป็นไฟล์ Zip ที่สอดคล้อง" โดยอ้างอิงถึงเอกสาร PKWARE APPNOTE อย่างเป็นทางการ และกำหนดข้อจำกัดหลักต่อไปนี้สำหรับรูปแบบไฟล์ ZIP: ^{[ 34 ]}

• ไฟล์ในไฟล์ ZIP อาจถูกจัดเก็บโดยไม่บีบอัด หรือใช้การบีบอัดแบบ "deflate" เท่านั้น (เช่น วิธีการบีบอัดอาจมีค่า "0" - จัดเก็บ หรือ "8" - คลายการบีบอัด) สิทธิบัตรเกี่ยวกับวิธีการบีบอัดแบบ "deflate" หลักหมดอายุในช่วงปลายปี 2553 ^{[ 35 ]}
• คุณสมบัติการเข้ารหัสถูกห้ามใช้
• ไม่อนุญาตให้ใช้คุณสมบัติลายเซ็นดิจิทัล (จาก SES)
• ฟีเจอร์ "ข้อมูลที่แก้ไขแล้ว" (จาก PKPatchMaker) นั้นไม่ได้รับอนุญาต
• เอกสารจดหมายเหตุอาจไม่ครอบคลุมหลายเล่มหรือแบ่งออกเป็นส่วนๆ

ไฟล์ . ZIPเป็นไฟล์เก็บถาวรที่จัดเก็บไฟล์หลายไฟล์ ZIP อนุญาตให้บีบอัดไฟล์ที่อยู่ภายในโดยใช้วิธีการต่างๆ มากมาย รวมถึงการจัดเก็บไฟล์โดยไม่บีบอัดด้วย แต่ละไฟล์จะถูกจัดเก็บแยกกัน ทำให้สามารถบีบอัดไฟล์ต่างๆ ในไฟล์เก็บถาวรเดียวกันโดยใช้วิธีการที่แตกต่างกันได้ เนื่องจากไฟล์ในไฟล์เก็บถาวร ZIP ถูกบีบอัดแยกกัน จึงสามารถแตกไฟล์หรือเพิ่มไฟล์ใหม่ได้โดยไม่ต้องบีบอัดหรือคลายการบีบอัดทั้งไฟล์เก็บถาวร ซึ่งแตกต่างจากรูปแบบของไฟล์บีบอัดแบบtarที่การประมวลผลแบบเข้าถึงแบบสุ่มทำได้ยากกว่า

โดยทั่วไปแล้ว ไฟล์ ZIP จะมีการสร้างไดเร็กทอรีไว้ที่ส่วนท้ายของไฟล์ เพื่อระบุว่ามีไฟล์ใดบ้างในไฟล์ ZIP และไฟล์นั้นอยู่ที่ใดในไฟล์ ZIP วิธีนี้ช่วยให้โปรแกรมอ่านไฟล์ ZIP สามารถโหลดรายการไฟล์ได้โดยไม่ต้องอ่านไฟล์ ZIP ทั้งหมด นอกจากนี้ ไฟล์ ZIP ยังสามารถมีข้อมูลเพิ่มเติมที่ไม่เกี่ยวข้องกับไฟล์ ZIP หลักได้ เช่น การสร้างไฟล์ ZIP ที่สามารถแตกไฟล์ได้เอง (โปรแกรมที่แตกไฟล์ภายใน) โดยการเพิ่มโค้ดโปรแกรมไว้ด้านหน้าไฟล์ ZIP และกำหนดให้ไฟล์นั้นเป็นไฟล์ที่สามารถเรียกใช้งานได้ การจัดเก็บแคตตาล็อกไว้ที่ส่วนท้ายยังช่วยให้สามารถซ่อนไฟล์ ZIP ได้โดยการแนบไปกับไฟล์ที่ไม่เป็นอันตราย เช่น ไฟล์ภาพ GIF

รูป แบบ .ZIPใช้CRC-32และรวมเมตาเดตาของแต่ละรายการไว้สองชุดเพื่อให้การป้องกันการสูญเสียข้อมูลที่ดียิ่งขึ้น อัลกอริทึม CRC-32 ได้รับการเสนอโดย David Schwaderer และสามารถพบได้ในหนังสือของเขา "C Programmers Guide to NetBIOS" ซึ่งตีพิมพ์โดย Howard W. Sams & Co. Inc. ^{[ 36 ]}

ไฟล์ ZIP จะถูกระบุอย่างถูกต้องโดยการมีระเบียนสิ้นสุดของไดเร็กทอรีกลางซึ่งอยู่ที่ส่วนท้ายของโครงสร้างไฟล์เก็บถาวร เพื่อให้สามารถเพิ่มไฟล์ใหม่ได้อย่างง่ายดาย หากระเบียนสิ้นสุดของไดเร็กทอรีกลางระบุว่าไฟล์เก็บถาวรไม่ว่างเปล่า ชื่อของแต่ละไฟล์หรือไดเร็กทอรีภายในไฟล์เก็บถาวรควรระบุไว้ใน รายการ ไดเร็กทอรีกลางพร้อมกับข้อมูลเมตาอื่นๆ เกี่ยวกับรายการนั้น และค่าออฟเซ็ตในไฟล์ ZIP ที่ชี้ไปยังข้อมูลรายการจริง วิธีนี้ช่วยให้สามารถแสดงรายการไฟล์ในไฟล์เก็บถาวรได้อย่างรวดเร็ว เนื่องจากไม่จำเป็นต้องอ่านไฟล์เก็บถาวรทั้งหมดเพื่อดูรายการไฟล์ รายการภายในไฟล์ ZIP ยังรวมถึงข้อมูลนี้ไว้ด้วย เพื่อความซ้ำซ้อน ในส่วนหัวไฟล์ภายในเนื่องจากไฟล์ ZIP สามารถเพิ่มไฟล์ได้ ดังนั้นเฉพาะไฟล์ที่ระบุไว้ในไดเร็กทอรีกลางที่ส่วนท้ายของไฟล์เท่านั้นที่ถูกต้อง การสแกนไฟล์ ZIP เพื่อหาส่วนหัวไฟล์ภายในนั้นไม่ถูกต้อง (ยกเว้นในกรณีที่ไฟล์เก็บถาวรเสียหาย) เนื่องจากไดเร็กทอรีกลางอาจประกาศว่าไฟล์บางไฟล์ถูกลบและไฟล์อื่นๆ ได้รับการอัปเดตแล้ว

ตัวอย่างเช่น เราอาจเริ่มต้นด้วยไฟล์ ZIP ที่มีไฟล์ A, B และ C จากนั้นลบไฟล์ B และอัปเดตไฟล์ C ซึ่งอาจทำได้โดยการเพิ่มไฟล์ C ใหม่ต่อท้ายไฟล์ ZIP เดิม และเพิ่มไดเร็กทอรีกลางใหม่ที่แสดงเฉพาะไฟล์ A และไฟล์ C ใหม่เท่านั้น เมื่อ ZIP ถูกออกแบบครั้งแรก การถ่ายโอนไฟล์ด้วยฟลอปปี้ดิสก์เป็นเรื่องปกติ แต่การเขียนลงดิสก์นั้นใช้เวลานานมาก หากคุณมีไฟล์ ZIP ขนาดใหญ่ ซึ่งอาจกระจายอยู่บนหลายดิสก์ และต้องการอัปเดตเพียงไม่กี่ไฟล์ แทนที่จะอ่านและเขียนไฟล์ทั้งหมดใหม่ การอ่านไดเร็กทอรีกลางเก่า เพิ่มไฟล์ใหม่ แล้วเพิ่มไดเร็กทอรีกลางที่อัปเดตแล้วจะเร็วกว่ามาก

ลำดับของรายการไฟล์ในไดเร็กทอรีกลางไม่จำเป็นต้องตรงกับลำดับของรายการไฟล์ในไฟล์เก็บถาวร

แต่ละไฟล์ที่จัดเก็บในไฟล์ ZIP จะเริ่มต้นด้วยส่วนหัวของไฟล์ที่มีข้อมูลเกี่ยวกับไฟล์ เช่น ข้อความแสดงความคิดเห็น ขนาดไฟล์ และชื่อไฟล์ ตามด้วยฟิลด์ข้อมูล "เพิ่มเติม" ที่เป็นตัวเลือก และข้อมูลไฟล์ที่อาจถูกบีบอัดหรือเข้ารหัส ฟิลด์ข้อมูล "เพิ่มเติม" เป็นกุญแจสำคัญในการขยายรูปแบบของไฟล์ ZIP ฟิลด์ "เพิ่มเติม" ถูกนำมาใช้เพื่อรองรับรูปแบบ ZIP64 การเข้ารหัส AES ที่เข้ากันได้กับ WinZip คุณสมบัติของไฟล์ และการประทับเวลาไฟล์ NTFS หรือ Unix ที่มีความละเอียดสูงขึ้น การขยายอื่นๆ ก็เป็นไปได้ผ่านฟิลด์ "เพิ่มเติม" โปรแกรม ZIP จำเป็นต้องละเว้นฟิลด์ "เพิ่มเติม" ที่ไม่รู้จักตามข้อกำหนด

รูปแบบไฟล์ ZIP ใช้ "ลายเซ็น" 4 ไบต์เฉพาะเพื่อระบุโครงสร้างต่างๆ ในไฟล์ แต่ละรายการในไฟล์จะถูกทำเครื่องหมายด้วยลายเซ็นเฉพาะ ส่วนท้ายของระเบียนในไดเร็กทอรีกลางจะถูกระบุด้วยลายเซ็นเฉพาะของมัน และแต่ละรายการในไดเร็กทอรีกลางจะเริ่มต้นด้วยลายเซ็นส่วนหัวของไฟล์กลางขนาด 4 ไบต์

ในข้อกำหนดของไฟล์ ZIP ไม่มีเครื่องหมาย BOF หรือ EOF โดยทั่วไปแล้ว สิ่งแรกในไฟล์ ZIP คือรายการ ZIP ซึ่งสามารถระบุได้ง่ายจากลายเซ็นส่วนหัวไฟล์เฉพาะที่อย่างไรก็ตาม นี่ไม่ใช่กรณีเสมอไป เนื่องจากข้อกำหนดของไฟล์ ZIP ไม่ได้กำหนดไว้ โดยเฉพาะอย่างยิ่ง ไฟล์เก็บถาวรแบบแตกไฟล์ได้เองจะเริ่มต้นด้วยส่วนหัวไฟล์ที่สามารถเรียกใช้งานได้

เครื่องมือที่อ่านไฟล์ ZIP ได้อย่างถูกต้องจะต้องสแกนหาลายเซ็นท้ายสุดของระเบียนไดเร็กทอรีกลาง จากนั้นจึงสแกนหาระเบียนไดเร็กทอรีกลางอื่นๆ ที่ระบุไว้ตามความเหมาะสม เครื่องมือเหล่านั้นจะต้องไม่สแกนหาข้อมูลจากส่วนบนสุดของไฟล์ ZIP เพราะ (ดังที่ได้กล่าวไว้ก่อนหน้านี้ในส่วนนี้) มีเพียงไดเร็กทอรีกลางเท่านั้นที่ระบุว่าส่วนของไฟล์เริ่มต้นที่ใดและส่วนนั้นยังไม่ถูกลบ การสแกนอาจนำไปสู่ผลลัพธ์ที่ผิดพลาดได้ เนื่องจากรูปแบบไฟล์ไม่ได้ห้ามไม่ให้มีข้อมูลอื่นๆ อยู่ระหว่างส่วนของไฟล์ หรือสตรีมข้อมูลไฟล์มีลายเซ็นดังกล่าว อย่างไรก็ตาม เครื่องมือที่พยายามกู้คืนข้อมูลจากไฟล์ ZIP ที่เสียหายมักจะสแกนไฟล์เก็บถาวรเพื่อหาลายเซ็นส่วนหัวของไฟล์ในเครื่อง ซึ่งทำได้ยากขึ้นเนื่องจากขนาดที่บีบอัดของส่วนของไฟล์อาจถูกจัดเก็บไว้หลังจากส่วนของไฟล์ ทำให้การประมวลผลตามลำดับทำได้ยาก

ลายเซ็นส่วนใหญ่ลงท้ายด้วยจำนวนเต็มสั้น 0x4b50 ซึ่งจัดเก็บใน ลำดับแบบ little-endianเมื่อมองเป็น สตริง ASCIIจะอ่านว่า "PK" ซึ่งเป็นอักษรย่อของ Phil Katz ผู้คิดค้น ดังนั้น เมื่อดูไฟล์ ZIP ในโปรแกรมแก้ไขข้อความ สองไบต์แรกของไฟล์มักจะเป็น "PK" (ไฟล์ ZIP ที่แตกไฟล์ได้เองสำหรับ DOS, OS/2 และ Windows จะมีEXEอยู่หน้า ZIP ดังนั้นจึงเริ่มต้นด้วย "MZ"; ไฟล์ ZIP ที่แตกไฟล์ได้เองสำหรับระบบปฏิบัติการอื่นๆ อาจมีโค้ดที่สามารถเรียกใช้งานได้เพื่อแตกไฟล์ในแพลตฟอร์มนั้นๆ อยู่ข้างหน้าเช่นกัน)

ข้อกำหนด ของไฟล์.ZIPยังรองรับการกระจายไฟล์เก็บถาวรไปยังไฟล์ระบบไฟล์หลายไฟล์ เดิมทีคุณสมบัตินี้มีไว้สำหรับการจัดเก็บไฟล์ ZIP ขนาดใหญ่ใน ฟลอป ปี้ดิสก์ หลายแผ่น แต่ปัจจุบันใช้สำหรับการส่งไฟล์ ZIP เป็นส่วนๆ ผ่านทางอีเมล หรือผ่านวิธีการขนส่งอื่นๆ หรือสื่อบันทึกข้อมูลแบบถอดได้

ระบบไฟล์ FATของ DOS มีความละเอียดในการประทับเวลาเพียงสองวินาทีเท่านั้น และไฟล์ ZIP ก็เลียนแบบคุณสมบัตินี้ ดังนั้น ความละเอียดในการประทับเวลาของไฟล์ในไฟล์ ZIP จึงมีเพียงสองวินาทีเท่านั้น แม้ว่าจะสามารถใช้ฟิลด์เพิ่มเติมเพื่อจัดเก็บการประทับเวลาที่แม่นยำยิ่งขึ้นได้ก็ตาม รูปแบบไฟล์ ZIP ไม่มีการรับรู้ถึงเขตเวลาดังนั้น การประทับเวลาจึงมีความหมายก็ต่อเมื่อทราบว่าไฟล์นั้นสร้างขึ้นในเขตเวลาใด

ในเดือนกันยายน พ.ศ. 2549 PKWARE ได้ออกการแก้ไขข้อกำหนด ZIP ซึ่งรองรับการจัดเก็บชื่อไฟล์โดยใช้UTF-8และในที่สุดก็เพิ่มความเข้ากันได้กับ Unicode ให้กับ ZIP ^{[ 20 ]}

ค่าหลายไบต์ทั้งหมดในส่วนหัวจะถูกจัดเก็บใน ลำดับไบต์แบบ little-endianฟิลด์ความยาวทั้งหมดจะนับความยาวเป็นไบต์

ฟิลด์เพิ่มเติมประกอบด้วยข้อมูลเสริมหลากหลายประเภท เช่น คุณลักษณะเฉพาะของระบบปฏิบัติการ โดยแบ่งออกเป็นเรคอร์ด แต่ละเรคอร์ดมีลายเซ็นอย่างน้อย 16 บิตและความยาว 16 บิต ตัวอย่างเช่น เรคอร์ดฟิลด์เพิ่มเติมของไฟล์โลคอล ZIP64 มีลายเซ็น 0x0001 และความยาว 16 ไบต์ (หรือมากกว่า) เพื่อให้สามารถระบุค่า 64 บิตสองค่า (ขนาดก่อนบีบอัดและหลังบีบอัด) ได้ อีกหนึ่งส่วนขยายไฟล์โลคอลที่พบบ่อยคือ 0x5455 (หรือ "UT") ซึ่งประกอบด้วยการประทับเวลา UTC UNIX 32 บิต

จากนั้นจะเป็นข้อมูลที่ถูกบีบอัดตามมาทันที

หากบิตที่ตำแหน่งออฟเซ็ต 3 (0x08) ของฟิลด์แฟล็กอเนกประสงค์ถูกตั้งค่าไว้ ค่า CRC-32 และขนาดไฟล์จะไม่ทราบเมื่อเขียนส่วนหัว หากไฟล์เก็บถาวรอยู่ในรูปแบบ Zip64 ฟิลด์ขนาดที่บีบอัดและไม่บีบอัดจะมีขนาด 8 ไบต์แทนที่จะเป็น 4 ไบต์ (ดูหัวข้อ 4.3.9.2 ^{[ 38 ]} ) ฟิลด์ที่เทียบเท่าในส่วนหัวภายใน (หรือในฟิลด์ข้อมูลเพิ่มเติมของ Zip64 ในกรณีของไฟล์เก็บถาวรในรูปแบบ Zip64) จะถูกเติมด้วยศูนย์ และค่า CRC-32 และขนาดจะถูกเพิ่มในโครงสร้าง 12 ไบต์ (อาจมีลายเซ็น 4 ไบต์นำหน้า) ทันทีหลังจากข้อมูลที่บีบอัด:

ส่วนหัวของไฟล์ในไดเร็กทอรีกลางเป็นรูปแบบที่ขยายมาจากส่วนหัวในเครื่อง:

หลังจากรายการทั้งหมดในไดเร็กทอรีกลางแล้ว จะพบกับระเบียนสิ้นสุดของไดเร็กทอรีกลาง (EOCD) ซึ่งเป็นตัวบ่งบอกจุดสิ้นสุดของไฟล์ ZIP:

การจัดเรียงแบบนี้ช่วยให้สามารถสร้างไฟล์ ZIP ได้ในครั้งเดียว แต่ไดเร็กทอรีกลางจะถูกวางไว้ที่ส่วนท้ายของไฟล์ด้วย เพื่ออำนวยความสะดวกในการแยกไฟล์ออกจากไฟล์เก็บถาวรแบบหลายส่วน(เช่น "ดิสก์ฟลอปปี้หลายแผ่น")ดังที่ได้กล่าวไว้ก่อนหน้านี้

เอกสารข้อกำหนดรูปแบบไฟล์ .ZIP ระบุวิธีการบีบอัดดังต่อไปนี้: Store (ไม่มีการบีบอัด), Shrink ( LZW ), Reduce (ระดับ 1–4; LZ77 + ความน่าจะเป็น), Implode, Deflate, Deflate64, bzip2 , LZMA , Zstandard , WavPack , PPMdและ LZ77 เวอร์ชันที่จัดทำโดยคำสั่ง CMPSC ของ IBM z/OS ^{[ 39 ] [ 30 ]}วิธีการบีบอัดที่ใช้กันทั่วไปมากที่สุดคือDEFLATEซึ่งอธิบายไว้ในIETF RFC  1951

วิธีการอื่นๆ ที่กล่าวถึง แต่ไม่ได้บันทึกรายละเอียดไว้ในข้อกำหนด ได้แก่ PKWARE DCL Implode (IBM TERSE รุ่นเก่า), IBM TERSE รุ่น ใหม่ , IBM LZ77 z Architecture (PFS) และ JPEG รูปแบบหนึ่ง วิธีการ "Tokenize" ถูกสงวนไว้สำหรับบุคคลที่สาม แต่ไม่เคยมีการเพิ่มการสนับสนุน^{[ 25 ]}

คำว่าImplodeถูกใช้มากเกินไปโดย PKWARE: Implode ของ DCL/TERSE นั้นแตกต่างจาก Implode ของ PKZIP รุ่นเก่า ซึ่งเป็นรุ่นก่อนหน้าของ Deflate Implode ของ DCL นั้นไม่มีเอกสารประกอบ ส่วนหนึ่งเป็นเพราะเป็นกรรมสิทธิ์ของ IBM แต่Mark Adlerก็ได้จัดเตรียมตัวคลายการบีบอัดที่เรียกว่า "blast" ไว้ควบคู่กับ zlib ^{[ 40 ]}

ZIP รองรับ ระบบ การเข้ารหัสแบบสมมาตรที่ใช้รหัสผ่าน แบบง่าย ซึ่งโดยทั่วไปเรียกว่า ZipCrypto ระบบนี้ได้รับการบันทึกไว้ในข้อกำหนดของ ZIP และเป็นที่ทราบกันดีว่ามีข้อบกพร่องร้ายแรง โดยเฉพาะอย่างยิ่ง ระบบนี้มีความเสี่ยงต่อการโจมตีแบบรู้ข้อความต้นฉบับซึ่งในบางกรณีอาจแย่ลงไปอีกเนื่องจากการใช้งานตัวสร้างเลขสุ่มที่ไม่ ดี ^{[ 5 ]}คอมพิวเตอร์ที่ทำงานภายใต้ระบบปฏิบัติการ Microsoft Windows ดั้งเดิม โดยไม่มีโปรแกรมบีบอัดไฟล์ของบุคคลที่สามสามารถเปิดไฟล์ ZIP ที่เข้ารหัสด้วย ZipCrypto ได้ แต่ไม่สามารถสร้างไฟล์ดังกล่าวได้ และไม่สามารถแยกเนื้อหาของไฟล์โดยใช้การเข้ารหัสแบบอื่นได้^{[ 41 ]}

คุณสมบัติใหม่ๆ รวมถึง วิธี การบีบอัดและการเข้ารหัส แบบใหม่ (เช่นAES ) ได้รับการบันทึกไว้ในข้อกำหนดรูปแบบไฟล์ ZIP ตั้งแต่เวอร์ชัน 5.2 มาตรฐานเปิดที่ใช้ AES ซึ่งพัฒนาโดยWinZip ("AE-x" ใน APPNOTE) ยังถูกใช้โดย 7-ZipและXceed ด้วย แต่ผู้จำหน่ายบางรายใช้รูปแบบอื่นๆ^{[ 42 ]} PKWARE SecureZIP (SES, กรรมสิทธิ์) ยังรองรับวิธีการเข้ารหัส RC2, RC4, DES, Triple DES, การเข้ารหัสและการตรวจสอบความถูกต้องตามใบรับรองดิจิทัล ( X.509 ) และการเข้ารหัสส่วนหัวของไฟล์เก็บถาวร อย่างไรก็ตาม มันได้รับการจดสิทธิบัตรแล้ว (ดู§ ข้อโต้แย้งเกี่ยวกับการเข้ารหัสที่แข็งแกร่ง ) ^{[ 43 ]}

การเข้ารหัสชื่อไฟล์ถูกนำมาใช้ในข้อกำหนดรูปแบบไฟล์ .ZIP เวอร์ชัน 6.2 ซึ่งจะเข้ารหัสข้อมูลเมตาที่จัดเก็บไว้ในส่วนไดเร็กทอรีกลางของไฟล์เก็บถาวร แต่ส่วนหัวภายใน (Local Header) จะยังคงไม่ถูกเข้ารหัส โปรแกรมบีบอัดไฟล์ที่สอดคล้องกับข้อกำหนดสามารถปลอมแปลงข้อมูลส่วนหัวภายในได้เมื่อใช้การเข้ารหัสไดเร็กทอรีกลาง ณ เวอร์ชัน 6.2 ของข้อกำหนดนี้ ฟิลด์วิธีการบีบอัดและขนาดที่บีบอัดภายในส่วนหัวภายในยังไม่ถูกปิดบัง

รูปแบบ .ZIPดั้งเดิมมีข้อจำกัด 4  GiB ( 2³² ^ไบต์ ) สำหรับสิ่งต่างๆ (ขนาดไฟล์ที่ไม่ได้บีบอัด ขนาดไฟล์ที่บีบอัด และขนาดรวมของไฟล์เก็บถาวร) รวมถึงข้อจำกัดจำนวนรายการ 65,535 ( 2¹⁶ − 1 ) รายการในไฟล์เก็บถาวร ZIP ในเวอร์ชัน 4.5 ของข้อกำหนด (ซึ่งไม่เหมือนกับเวอร์ชัน 4.5 ของเครื่องมือใดๆ) PKWARE ได้แนะนำส่วนขยายรูปแบบ "ZIP64" เพื่อหลีกเลี่ยงข้อจำกัดเหล่านี้ โดยเพิ่มขีดจำกัดเป็น 16  ^EiB ( 2⁶⁴ ไบต์ ) โดยพื้นฐานแล้ว จะใช้รายการไดเร็กทอรี ^กลาง "ปกติ" สำหรับไฟล์ ตามด้วยรายการไดเร็กทอรี "zip64" ที่เป็นตัวเลือก ซึ่งมีฟิลด์ขนาดใหญ่กว่า^{[ 44 ]}

รูปแบบของส่วนหัวไฟล์ภายในเครื่อง (LOC) และส่วนหัวไฟล์ไดเร็กทอรีกลาง (CDFH) นั้นเหมือนกันทั้งใน ZIP และ ZIP64 อย่างไรก็ตาม ZIP64 กำหนดฟิลด์พิเศษที่อาจถูกเพิ่มเข้าไปในเรคอร์ดเหล่านั้นตามดุลยพินิจของโปรแกรมบีบอัด ซึ่งมีวัตถุประสงค์เพื่อจัดเก็บค่าที่ไม่พอดีกับเรคอร์ด LOC หรือ CDFH แบบดั้งเดิม เพื่อบ่งชี้ว่าค่าจริงถูกจัดเก็บไว้ในฟิลด์พิเศษของ ZIP64 ค่าเหล่านั้นจะถูกตั้งค่าเป็น 0xFFFF หรือ 0xFFFFFFFF ในเรคอร์ด LOC หรือ CDFH ที่เกี่ยวข้อง หากรายการใดรายการหนึ่งไม่พอดีกับเรคอร์ด LOC หรือ CDFH แบบดั้งเดิม เฉพาะรายการนั้นเท่านั้นที่จะต้องย้ายไปยังฟิลด์พิเศษของ ZIP64 รายการอื่นๆ อาจยังคงอยู่ในเรคอร์ดแบบดั้งเดิม ดังนั้น รายการทั้งหมดที่แสดงในตารางต่อไปนี้อาจไม่ได้จัดเก็บไว้ในฟิลด์พิเศษของ ZIP64 เสมอไป อย่างไรก็ตาม หากปรากฏขึ้น ลำดับของรายการเหล่านั้นจะต้องเป็นไปตามที่แสดงในตาราง

ในทางกลับกัน รูปแบบของ EOCD สำหรับ ZIP64 นั้นแตกต่างจากเวอร์ชัน ZIP ปกติเล็กน้อย^{[ 37 ]}

EOCD64 ไม่จำเป็นต้องเป็นเรคอร์ดสุดท้ายในไฟล์เสมอไป ถัดจากนั้นเป็นเรคอร์ด End of Central Directory Locator ขนาด 20 ไบต์ และตามด้วยเรคอร์ด EOCD แบบดั้งเดิม

โปรแกรม File Explorer ในWindows XPไม่รองรับ ZIP64 แต่ Explorer ในWindows Vistaและเวอร์ชันที่ใหม่กว่ารองรับ ในทำนองเดียวกัน ไลบรารีส่วนขยายบางตัวรองรับ ZIP64 เช่น DotNetZip, QuaZIP ^{[ 45 ]}และ IO::Compress::Zip ใน Perl zipfile ในตัวของ Python รองรับตั้งแต่เวอร์ชัน 2.5 และตั้งค่าเป็นค่าเริ่มต้นตั้งแต่เวอร์ชัน 3.4 [ ^{46 ] java.util.zip} ในตัวของOpenJDK รองรับ ZIP64 ตั้งแต่ Java เวอร์ชัน 7 [ ^{47 ] Android} Java API รองรับ ZIP64 ตั้งแต่ Android 6.0 ^{[ 48 ]}โปรแกรม Archive Utility ของ Mac OS Sierra ไม่รองรับ ZIP64 และอาจสร้างไฟล์เก็บถาวรที่เสียหายเมื่อจำเป็นต้องใช้ ZIP64 ^{[ 49 ]} อย่างไรก็ตาม คำสั่ง ditto ที่มาพร้อมกับ Mac OS จะคลายไฟล์ ZIP64 ^{[ 50 ]} Mac OS เวอร์ชันใหม่กว่ามาพร้อมกับเครื่องมือบรรทัดคำสั่ง zip และ unzip ของ info-zip ซึ่งรองรับ Zip64: เพื่อตรวจสอบ ให้รัน zip -v และมองหา "ZIP64_SUPPORT"

รูป แบบไฟล์ .ZIPอนุญาตให้มีข้อความแสดงความคิดเห็นที่มีข้อมูลได้มากถึง 65,535 ( 2 ¹⁶ − 1 ) ไบต์ที่ส่วนท้ายของไฟล์หลังจากไดเร็กทอรีกลาง^{[ 37 ]}นอกจากนี้ เนื่องจากไดเร็กทอรีกลางระบุค่าออฟเซ็ตของแต่ละไฟล์ในไฟล์เก็บถาวรโดยสัมพันธ์กับจุดเริ่มต้น จึงเป็นไปได้ที่รายการไฟล์แรกจะเริ่มต้นที่ค่าออฟเซ็ตอื่นที่ไม่ใช่ศูนย์ แม้ว่าเครื่องมือบางอย่างอาจไม่สามารถประมวลผลไฟล์เก็บถาวรที่ไม่ได้เริ่มต้นด้วยรายการไฟล์ที่ค่าออฟเซ็ตศูนย์ได้ก็ตาม ตัวอย่างเช่น โปรแกรมgzipสามารถแยกรายการจากไฟล์ .ZIP ได้หากรายการนั้นอยู่ที่ค่าออฟเซ็ตศูนย์

วิธีนี้ทำให้สามารถมีข้อมูลใดๆ ก็ได้ในไฟล์ ทั้งก่อนและหลังข้อมูลของไฟล์ ZIP และไฟล์นั้นยังคงสามารถอ่านได้โดยโปรแกรม ZIP ผลข้างเคียงของวิธีนี้คือ สามารถสร้างไฟล์ที่ใช้งานได้ทั้งในรูปแบบ ZIP และรูปแบบอื่นๆ ได้ โดยมีเงื่อนไขว่ารูปแบบอื่นๆ นั้นต้องยอมรับข้อมูลใดๆ ก็ได้ที่ส่วนท้าย ส่วนต้น หรือส่วนกลางของไฟล์ไฟล์บีบอัดแบบแตกไฟล์ได้เอง (SFX) ในรูปแบบที่ WinZip รองรับนั้น ใช้ประโยชน์จากสิ่งนี้ เนื่องจากเป็นไฟล์ที่สามารถเรียกใช้งานได้ ( .exe ) ซึ่งเป็นไปตามข้อกำหนด PKZIP AppNote.txt และสามารถอ่านได้โดยโปรแกรมหรือไลบรารี ZIP ที่เป็นไปตามข้อกำหนด

คุณสมบัติของ รูปแบบ .ZIPและ รูปแบบ JARซึ่งเป็นรูปแบบหนึ่งของ ZIP สามารถใช้ประโยชน์เพื่อซ่อนเนื้อหาที่เป็นอันตราย (เช่น คลาส Java ที่เป็นอันตราย) ไว้ภายในไฟล์ที่ดูเหมือนไม่มีอันตราย เช่น รูปภาพ GIF ที่อัปโหลดไปยังเว็บ การโจมตีที่เรียกว่าGIFAR exploit นี้ได้รับการพิสูจน์แล้วว่าเป็นวิธีการโจมตีที่มีประสิทธิภาพต่อแอปพลิเคชันเว็บ เช่น Facebook ^{[ 51 ]}

ไฟล์ .ZIP ต้อง มีขนาดขั้นต่ำ22 ไบต์ไฟล์ .ZIP ที่ว่าง เปล่า จะมีเพียงระเบียนสิ้นสุดของไดเร็กทอรีกลาง (EOCD) เท่านั้น50 4B 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ขนาดสูงสุดสำหรับทั้งไฟล์เก็บถาวรและไฟล์แต่ละไฟล์ภายในนั้นคือ 4,294,967,295 ไบต์ ( 2³² - 1ไบต์ หรือ 4 GiB ลบ 1 ไบต์) สำหรับ ZIP มาตรฐาน สำหรับ ZIP64 ขนาดสูงสุดคือ 18,446,744,073,709,551,615 ไบต์ ( 2⁶⁴ - 1 ^{ไบต์หรือ} 16 EiB ลบ 1 ไบต์) ^{[ 52 ]}

รูปแบบไฟล์ .ZIPมีฟิลด์พิเศษในส่วนหัวของไฟล์ ซึ่งสามารถใช้จัดเก็บข้อมูลเพิ่มเติมที่ไม่ได้กำหนดไว้ในข้อกำหนดของ ZIP ที่มีอยู่ และช่วยให้โปรแกรมบีบอัดไฟล์ที่รองรับรูปแบบนี้แต่ไม่รู้จักฟิลด์เหล่านั้น สามารถข้ามฟิลด์เหล่านั้นได้อย่างปลอดภัย รหัสส่วนหัว 0–31 สงวนไว้สำหรับการใช้งานโดย PKWARE ส่วนรหัสที่เหลือสามารถใช้โดยผู้จำหน่ายบุคคลที่สามเพื่อการใช้งานเฉพาะของตนเอง

เมื่อWinZip 9.0 รุ่นเบต้าสาธารณะถูกปล่อยออกมาในปี 2546 WinZip ได้แนะนำการเข้ารหัส AES-256ของตนเองโดยใช้รูปแบบไฟล์ที่แตกต่างกัน พร้อมกับเอกสารประกอบสำหรับข้อกำหนดใหม่^{[ 53 ]}มาตรฐานการเข้ารหัสเองไม่ได้เป็นกรรมสิทธิ์แต่ PKWARE ไม่ได้อัปเดต APPNOTE.TXT เพื่อรวม Strong Encryption Specification (SES) ตั้งแต่ปี 2544 ซึ่งถูกใช้โดย PKZIP เวอร์ชัน 5.0 และ 6.0 Kevin Kearney ที่ปรึกษาด้านเทคนิคของ WinZip และ Mathew Covington ผู้จัดการผลิตภัณฑ์ของ StuffItกล่าวหา PKWARE ว่าปกปิด SES แต่ Jim Peterson หัวหน้าเจ้าหน้าที่ฝ่ายเทคโนโลยีของ PKZIP อ้างว่าการเข้ารหัสแบบใช้ใบรับรองยังไม่สมบูรณ์

ในการดำเนินการที่เป็นข้อถกเถียงอีกประการหนึ่ง PKWare ได้ยื่นขอสิทธิบัตรเมื่อวันที่ 16 กรกฎาคม พ.ศ. 2546 โดยอธิบายวิธีการรวม ZIP และการเข้ารหัสที่แข็งแกร่งเพื่อสร้างไฟล์ที่ปลอดภัย^{[ 54 ]}

ในที่สุด PKWARE และ WinZip ก็ตกลงที่จะสนับสนุนผลิตภัณฑ์ของกันและกัน ในวันที่ 21 มกราคม 2547 PKWARE ประกาศการสนับสนุนรูปแบบการบีบอัด AES ที่ใช้ WinZip ^{[ 55 ]}ในเวอร์ชันเบต้าของ WinZip ในภายหลัง สามารถรองรับไฟล์ ZIP ที่ใช้ SES ได้^{[ 56 ]}ในที่สุด PKWARE ก็ได้เผยแพร่ข้อกำหนดรูปแบบไฟล์ .ZIP เวอร์ชัน 5.2 สู่สาธารณะ ซึ่งมีเอกสารเกี่ยวกับ SES โครงการซอฟต์แวร์เสรี7-Zipก็รองรับ AES แต่ไม่รองรับ SES ในไฟล์ ZIP (เช่นเดียวกับพอร์ตPOSIX ของมัน p7zip )

เมื่อใช้การเข้ารหัส AES ภายใต้ WinZip วิธีการบีบอัดจะถูกตั้งค่าเป็น 99 เสมอ โดยวิธีการบีบอัดจริงจะถูกเก็บไว้ในฟิลด์ข้อมูลเพิ่มเติมของ AES ^{[ 57 ]}ในทางตรงกันข้าม ข้อกำหนดการเข้ารหัสที่เข้มงวดจะเก็บวิธีการบีบอัดไว้ในส่วนหัวไฟล์พื้นฐานของส่วนหัวภายในเครื่องและไดเร็กทอรีกลาง เว้นแต่จะใช้การเข้ารหัสไดเร็กทอรีกลางเพื่อปกปิด/เข้ารหัสข้อมูลเมตา

มี เครื่องมือ .ZIP มากมาย ให้เลือกใช้ และมี ไลบรารี .ZIP มากมาย สำหรับสภาพแวดล้อมการเขียนโปรแกรมต่างๆ ลิขสิทธิ์ที่ใช้มีทั้งแบบกรรมสิทธิ์และแบบฟรีWinZip , WinRAR , Info-ZIP , ZipGenius , 7-Zip , PeaZipและB1 Free Archiver เป็นเครื่องมือ . ZIPที่รู้จักกันดีและมีให้ใช้งานบนแพลตฟอร์มต่างๆ บางเครื่องมือเหล่านี้มีอินเทอร์เฟซแบบไลบรารีหรือแบบโปรแกรม

ไลบรารีสำหรับการพัฒนาบางส่วนที่ได้รับอนุญาตภายใต้ข้อตกลงโอเพนซอร์ส ได้แก่libzip , libarchiveและInfo-ZIPสำหรับ Java: Java Platform, Standard Editionมีแพ็กเกจ "java.util.zip" สำหรับจัดการ ไฟล์ .ZIP มาตรฐาน ; ไลบรารี Zip64File รองรับไฟล์ขนาดใหญ่โดยเฉพาะ (ใหญ่กว่า 4 GiB) และจัดการ ไฟล์ .ZIP โดยใช้การเข้าถึงแบบสุ่ม ; และ เครื่องมือ Apache Antมีการใช้งานที่สมบูรณ์ยิ่งขึ้นซึ่งเผยแพร่ภายใต้Apache Software License

โปรแกรม Info-ZIP ที่รองรับรูปแบบไฟล์ .ZIP นั้นเพิ่มการรองรับคุณสมบัติของระบบไฟล์ Unix เช่น รหัสผู้ใช้และกลุ่ม สิทธิ์การเข้าถึงไฟล์ และการรองรับลิงก์สัญลักษณ์ โปรแกรม Apache Antรู้จักคุณสมบัติเหล่านี้ในระดับที่สามารถสร้างไฟล์ที่มีสิทธิ์การเข้าถึง Unix ที่กำหนดไว้ล่วงหน้าได้ นอกจากนี้ โปรแกรม Info-ZIP ยังรู้วิธีการใช้ความสามารถในการแก้ไขข้อผิดพลาดที่สร้างขึ้นใน รูปแบบการบีบอัด . ZIPซึ่งบางโปรแกรมไม่รู้ และจะล้มเหลวเมื่อพบไฟล์ที่มีข้อผิดพลาด

โปรแกรม Info-ZIP สำหรับ Windows รองรับ สิทธิ์การเข้าถึง ไฟล์ระบบNTFS ด้วย และจะพยายามแปลงสิทธิ์จาก NTFS เป็นสิทธิ์ Unix หรือในทางกลับกันเมื่อทำการแตกไฟล์ ซึ่งอาจส่งผลให้เกิดการผสมผสานที่ไม่พึงประสงค์ เช่น ไฟล์ .exeถูกสร้างขึ้นบนไดรฟ์ NTFS โดยที่สิทธิ์ในการเรียกใช้งานถูกปฏิเสธ

ระบบปฏิบัติการ Microsoft Windows ได้รวมการสนับสนุน การบีบอัด ไฟล์ .ZIPใน Explorer มาตั้งแต่มีการเปิดตัวชุดMicrosoft Plus! สำหรับ Windows 98 Microsoft เรียกคุณสมบัตินี้ว่า "โฟลเดอร์บีบอัด" (Compressed Folders) มีการเพิ่มการสนับสนุนแบบเนทีฟใน Windows MEตั้งแต่ปี 2000 อย่างไรก็ตาม คุณสมบัติ . ZIPบางอย่างไม่ได้รับการสนับสนุนโดยคุณสมบัติโฟลเดอร์บีบอัดของ Windows ตัวอย่างเช่น การเข้ารหัสไม่ได้รับการสนับสนุนใน Windows 10 Home edition ^{[ 58 ]}แม้ว่าจะสามารถถอดรหัสได้ก็ตาม การเข้ารหัสรายการ Unicode ไม่ได้รับการสนับสนุนจนกระทั่งถึงWindows 7ในขณะที่ไฟล์เก็บถาวรแบบแยกและแบบขยายไม่สามารถอ่านหรือเขียนได้โดยคุณสมบัติโฟลเดอร์บีบอัด และการเข้ารหัส AES ก็ไม่ได้รับการสนับสนุนเช่นกัน^{[ 59 ]}การสนับสนุน .zip ของ Windows มาจากการเข้าซื้อกิจการ "VisualZip" ที่เขียนโดยDave Plummer ^{[ 60 ] [ 61 ] [ 62 ]}

Apple ได้เพิ่มการรองรับไฟล์ ZIP ไว้ในMac OS X 10.3 (ผ่าน BOMArchiveHelper ซึ่งปัจจุบันคือArchive Utility ) และเวอร์ชันที่ใหม่กว่าระบบปฏิบัติการโอเพนซอร์ส ส่วนใหญ่ มีการรองรับไฟล์ ZIP ในลักษณะที่คล้ายคลึงกับ Windows และ macOS

OpenDocument Format (ODF) เริ่มใช้รูปแบบไฟล์เก็บถาวร zip ในปี 2548 ODF เป็นรูปแบบเปิดสำหรับเอกสารสำนักงานทุกประเภท ซึ่งเป็นรูปแบบไฟล์เริ่มต้นที่ใช้ในCollabora Online , LibreOfficeและอื่นๆ^{[ 63 ]} Microsoft Office เริ่มใช้รูปแบบไฟล์เก็บถาวร zip ในปี 2549 สำหรับ ไฟล์ Office Open XML .docx, .xlsx, .pptx เป็นต้น ซึ่งกลายเป็นรูปแบบไฟล์เริ่มต้นในMicrosoft Office 2007

รูปแบบเวอร์ชันก่อน 6.3.0 ไม่รองรับการจัดเก็บชื่อไฟล์ใน รูป แบบUnicode ^{[ 64 ]}ตามมาตรฐาน^{[ 64 ]}ชื่อไฟล์ควรจัดเก็บใน รูปแบบการเข้ารหัส CP437ซึ่งเป็นมาตรฐานสำหรับIBM PC [ ^{64 ]}แต่ในทางปฏิบัติ โปรแกรม บีบอัดไฟล์ ของ DOS ใช้ การเข้ารหัสอักขระที่ติดตั้งในระบบ โปรแกรม บีบอัดไฟล์ในตัวของ Windows จนถึง ^{เวอร์ชัน} 11 ยังใช้การเข้ารหัส "ANSI" ของระบบที่สอดคล้องกับภาษาของระบบที่เลือกไว้เพื่อความเข้ากันได้กับ DOS ในอดีตเมื่อสร้างไฟล์เก็บถาวร

ต่อมา มาตรฐานได้รับการปรับปรุงให้รวมตัวเลือกสองข้อสำหรับการจัดเก็บชื่อไฟล์ใน Unicode: 1) เมื่อบิตที่ 11 ในฟิลด์แฟล็กบิตวัตถุประสงค์ทั่วไปถูกตั้งค่า ชื่อไฟล์ในฟิลด์ "ชื่อไฟล์" ของส่วนหัวควรได้รับการพิจารณาว่าเป็นUTF-8แทนที่จะเป็นการเข้ารหัสไบต์เดียว และ 2) มีการเพิ่มฟิลด์ Unicode Path Extra เพื่อจัดเก็บชื่อไฟล์ในการเข้ารหัส UTF-8 ^{[ 64 ]}อัลกอริทึมต่อไปนี้คำนึงถึงทั้งฟิลด์ "ชื่อไฟล์" ใหม่และแนวปฏิบัติในอดีตเพื่อแยกไฟล์ที่มีชื่อที่มีอักขระที่ไม่ใช่ภาษาอังกฤษอย่างถูกต้อง: ^{[ 65 ]}

1. ตรวจสอบว่ามีฟิลด์ Unicode Path Extra หรือไม่ และถ้ามี ให้ใช้ชื่อไฟล์จากฟิลด์นั้น โดยเข้ารหัสเป็น UTF-8
2. ตรวจสอบว่ามีการตั้งค่าแฟล็ก 11 ในช่องบิตแฟล็กอเนกประสงค์หรือไม่ และหากมีการตั้งค่าไว้ ให้พิจารณาการเข้ารหัสชื่อไฟล์ในช่อง "ชื่อไฟล์" เป็น UTF-8
3. หากฟิลด์ "packing OS" มีค่าเป็น 11 (NTFS, Windows) และค่าในฟิลด์ "version of the packer" มากกว่าหรือเท่ากับ 20 ให้พิจารณาการเข้ารหัสชื่อไฟล์ในฟิลด์ "File name" เป็นการเข้ารหัส ANSI (Windows) ที่ตรงกับภาษาท้องถิ่นของระบบ หากสามารถระบุได้ มิเช่นนั้น ให้ใช้ CP437
4. หากฟิลด์ "packing OS" มีค่าเป็น 0 (FAT, DOS) และค่าในฟิลด์ "version of the packer" อยู่ระหว่าง 25 ถึง 40 ให้พิจารณาการเข้ารหัสชื่อไฟล์ในฟิลด์ "File name" ของส่วนหัวภายในเป็นแบบ ANSI (Windows) และในฟิลด์ "File name" ของส่วนหัวกลางเป็นแบบ OEM (DOS) ซึ่งตรงกับภาษาท้องถิ่นของระบบหากสามารถระบุได้ มิเช่นนั้น ให้ใช้ CP437
5. ในกรณีอื่นๆ หากช่อง "OS packing" มีค่าเป็น 0 (FAT, DOS), 6 (HPFS, OS/2) หรือ 11 (NTFS, Windows) ให้ถือว่าการเข้ารหัสชื่อไฟล์ในช่อง "File name" เป็นการเข้ารหัส OEM (DOS) ซึ่งตรงกับภาษาของระบบหากสามารถระบุได้ มิเช่นนั้น ให้ใช้ CP437
6. ในกรณีอื่นๆ ทั้งหมด ให้ถือว่าการเข้ารหัสชื่อไฟล์ในช่อง "ชื่อไฟล์" เป็นการเข้ารหัสของระบบปฏิบัติการที่โปรแกรมแตกไฟล์กำลังทำงานอยู่

หากใช้การเข้ารหัสที่ไม่ถูกต้องในการถอดรหัสชื่อไฟล์ ผู้ใช้จะเห็นชุดอักขระที่ผิดเพี้ยน ซึ่งเรียกว่า " โมจิบาเกะ " แทนที่จะเป็นตัวอักษรของอักษรประจำชาติ อัลกอริทึมข้างต้นพยายามอย่างเต็มที่เพื่อหลีกเลี่ยงผลลัพธ์ดังกล่าว แทนที่จะใช้ "ภาษาของระบบ" และ "การเข้ารหัสของระบบ" โปรแกรมบางโปรแกรมอนุญาตให้ผู้ใช้เลือกการเข้ารหัสที่ไม่ใช่ Unicode ที่ต้องการได้

ในปี 2016 ปัญหานี้ได้รับการแก้ไขในโปรแกรม จัดการไฟล์และไฟล์เก็บถาวร far2lสำหรับ Linux, BSD และ Mac ^{[ 66 ]}ในปี 2024 ได้มีการเพิ่มวิธีแก้ปัญหาที่คล้ายกัน^{[ 67 ]}ลงในเวอร์ชันของ 7zip ที่ใช้ใน การแจกจ่าย Debianและอนุพันธ์ของมัน และในเวอร์ชันของ unzip ที่ใช้ใน การแจกจ่าย Ubuntuและอนุพันธ์ของมัน^{[ 65 ]}

มีมาตรฐานและรูปแบบอื่นๆ อีกมากมายที่ใช้คำว่า "zip" เป็นส่วนหนึ่งของชื่อ ตัวอย่างเช่น zip แตกต่างจากgzipและ gzip นั้นถูกกำหนดไว้ในIETF RFC 1952ทั้ง zip และ gzip ใช้ขั้นตอนวิธีDEFLATE เป็นหลักในการบีบอัดข้อมูล ในทำนองเดียวกัน รูปแบบ ZLIB (IETF RFC 1950 ) ก็ใช้ขั้นตอนวิธีบีบอัดข้อมูล DEFLATE เช่นกัน แต่กำหนดส่วนหัวที่แตกต่างกันสำหรับการตรวจสอบข้อผิดพลาดและความสอดคล้อง นอกจากนี้ยังมีรูปแบบและโปรแกรมอื่นๆ ที่มีชื่อคล้ายกันแต่มีรูปแบบดั้งเดิมแตกต่างกัน ได้แก่7 -Zip , bzip2และrzip  

ปัจจัยการบีบอัดสูงสุดตามทฤษฎีสำหรับสตรีม DEFLATE ดิบอยู่ที่ประมาณ 1032 ต่อหนึ่ง^{[ 68 ]}แต่ด้วยการใช้รูปแบบ ZIP ในลักษณะที่ไม่ตั้งใจ สามารถสร้างไฟล์ ZIP ที่มีอัตราส่วนการบีบอัดหลายพันล้านต่อหนึ่งได้ ไฟล์ZIP เหล่านี้จะคลายการบีบอัดออกมาเป็นขนาดที่ใหญ่มากจนเกินความจุของคอมพิวเตอร์ที่ใช้ในการคลายการบีบอัด^{[ 69 ]}

• การเปรียบเทียบโปรแกรมบีบอัดไฟล์
• การเปรียบเทียบรูปแบบไฟล์เก็บถาวร
• รายการรูปแบบไฟล์เก็บถาวร

• หมายเหตุการใช้งานไฟล์ .ZIP
• โปรแกรมสร้างไฟล์ ZIP อย่างเป็นทางการ

เก็บถาวรเมื่อวันที่ 17 กรกฎาคม 2017 ที่ หน้า Wayback Machineสำหรับไฟล์ .ZIP ปัจจุบันและในอดีตของ PKWARE

• ISO/IEC 21320-1:2015 — ไฟล์คอนเทนเนอร์เอกสาร — ส่วนที่ 1: เนื้อหาหลัก
• ไฟล์ Zip: ประวัติความเป็นมา คำอธิบาย และการใช้งาน
• ย่อ ลดขนาด และบีบอัด: วิธีการบีบอัดข้อมูลแบบดั้งเดิมของ Zip
• APPNOTE.TXT mirror
• โครงสร้างของข้อกำหนดรูปแบบไฟล์ PKZip และตารางกราฟิก