Ano ang ZIP file?
Ang isang file na may .zip extension ay isang archive na maaaring maglaman ng isa o higit pang mga file o direktoryo. Ang archive ay maaaring magkaroon ng compression na inilapat sa mga kasamang file upang mabawasan ang laki ng ZIP file. Ang format ng ZIP file ay ginawang pampubliko noong Pebrero 1989 ni Phil Katz para sa pagkamit ng pag-archive ng mga file at folder. Ang format ay ginawang bahagi ng PKZIP utility, na ginawa ng PKWARE, Inc. Pagkatapos mismo ng pagkakaroon ng available specifications, maraming kumpanya ang gumawa ng ZIP file format na bahagi ng kanilang mga software utilities kabilang ang Microsoft (mula noong Windows 7), Apple (Mac OS X ) at marami pang iba.
Maikling Kasaysayan ng ZIP File Format
Ang kasaysayan para sa format ng ZIP file ay nagsimula sa kaganapan ng kaso na inihain ng System Enhancement Associates (SEA) laban sa PKWARE para sa paggamit ng ARC utility nito nang walang pahintulot para sa trademark nito at ang mga copyright ng hitsura at user interface ng produkto. Bago ito, muling isinulat ni Phil Katz ang source code ng SEA at inilabas ang PKXARC, isang ARC extractor, at PKARC, isang file compressor, bilang freeware para sa MS-DOS based system. Pagkatalo sa demanda, hindi na magagamit ng PKWARE ang anumang bagay na nauugnay sa ARC. Dito nabuo ang paglikha ng bagong file compression, pinangalanang ZIP na ginawang bahagi ng PKZIP utility sa PKWARE, Inc.
Inilabas ni Katz ang mga detalye ng format ng ZIP file sa pampublikong domain, habang pinapanatili ang mga karapatan sa pagmamay-ari sa kanyang compression at extraction utility i.e. PKZIP.Ang ZIP compression system ay (at ay) nakapag-archive ng mga file sa isang folder sa pamamagitan ng isang 32-bit cyclic redundancy check (CRC) algorithm upang i-compress ang file mga sukat. Hindi tulad ng ARC, ang mga .ZIP na folder ay may kasamang direktoryo na file na gumaganap sa papel ng isang aklat ng code ng cryptographer, na nagtataglay ng impormasyong kinakailangan upang i-render ang mga naka-compress na file.
Mga Sinusuportahang Paraan ng Compression sa ZIP
Ayon sa mga detalye ng .ZIP File Format, ang mga sumusunod na paraan ng compression ay sinusuportahan.
- Store - implies no compression
- Shrink
- Reduction (This implies compression factors ranging from level 1 to level 4)
- Implode
- Deflate
- Deflat64
- BZIP2
- LZMA (EFS)
- WavPack
- PPMd version I, Rev 1
Ang DEFLATE ay ang karaniwang ginagamit na paraan ng compression na isang lossless date compression algorithm na gumagamit ng kumbinasyon ng LZ77 at Huffman coding at nakadetalye sa RFC 1951.
Mga Detalye ng Format ng ZIP File
Ang mga ZIP file ay may kakayahang mag-imbak ng maraming mga file gamit ang iba’t ibang mga diskarte sa compression habang sa parehong oras ay sumusuporta sa pag-iimbak ng isang file nang walang anumang compression. Ang bawat file ay naka-imbak/naka-compress nang paisa-isa na tumutulong upang kunin ang mga ito, o magdagdag ng mga bago, nang hindi nag-aaplay ng compression o decompression sa buong archive.
Pangkalahatang ZIP File Format
Ang bawat Zip file ay nakabalangkas sa sumusunod na paraan:
ZIP File format |
---|
Local File Header 1 |
File Data 1 |
Data Descriptor 1 |
Local File Header 2 |
File Data 2 |
Data Descriptor 2 |
…. |
…. |
Local File Header N |
File Data N |
Data Descriptor N |
Archive Decryption Header |
Archive Extra Data Record |
Central Directory |
Ang format ng ZIP file ay gumagamit ng 32-bit na CRC algorithm para sa layunin ng pag-archive. Upang mai-render ang mga naka-compress na file, ang isang ZIP archive ay may hawak na direktoryo sa dulo nito na nagpapanatili sa pagpasok ng mga nilalamang file at ang kanilang lokasyon sa archive file. Ito, sa gayon, ay gumaganap ng papel ng pag-encode para sa pag-encapsulate ng impormasyon na kinakailangan upang mai-render ang mga naka-compress na file. Ginagamit ng mga ZIP reader ang direktoryo upang i-load ang listahan ng mga file nang hindi binabasa ang buong archive ng ZIP. Ang format ay nagpapanatili ng dalawahang kopya ng istraktura ng direktoryo upang magbigay ng higit na proteksyon laban sa pagkawala ng data.
Ang bawat file sa isang ZIP archive ay kinakatawan bilang isang indibidwal na entry kung saan ang bawat entry ay binubuo ng isang Local File Header na sinusundan ng compressed file data. Ang Direktoryo sa dulo ng archive ay nagtataglay ng mga reference sa lahat ng mga file na ito. Dapat iwasan ng mga mambabasa ng ZIP file ang pagbabasa ng mga lokal na header ng file at lahat ng uri ng listahan ng file ay dapat basahin mula sa Direktoryo. Ang Direktoryong ito ay ang tanging pinagmumulan para sa wastong mga entry ng file sa archive dahil ang mga file ay maaaring idugtong din sa dulo ng archive. Kaya naman kung ang isang mambabasa ay nagbabasa ng mga lokal na header ng isang ZIP archive mula sa simula, maaari itong magbasa ng mga hindi wastong (tinanggal) na mga entry pati na rin ang mga iyon ay hindi bahagi ng Direktoryo na tinatanggal mula sa archive.
Ang pagkakasunud-sunod ng mga entry ng file sa gitnang direktoryo ay hindi kailangang tumugma sa pagkakasunud-sunod ng mga entry ng file sa archive.
ZIP File Entries
Ang mga entry sa ZIP file ay isa-isang inaayos kung saan ang bawat entry ay binubuo ng:
- Lokal na File Header
- Opsyonal na Mga Patlang ng Dagdag na Data
- Data ng user (opsyonal na naka-compress/opsyonal na naka-encrypt)
Ang Local File Header ng bawat entry ay kumakatawan sa impormasyon tungkol sa file tulad ng komento, laki ng file at pangalan ng file. Ang mga karagdagang field ng data (opsyonal) ay maaaring tumanggap ng impormasyon para sa mga opsyon sa pagpapalawak ng ZIP format.
Local File Header
Ang Local File Header ay may partikular na istraktura ng field na binubuo ng mga multi-byte na halaga. Ang lahat ng mga halaga ay naka-imbak sa little-endian byte order kung saan binibilang ng haba ng field ang haba sa byte. Gumagamit ang lahat ng istruktura sa isang ZIP file ng 4-byte na lagda para sa bawat file entry.Ang dulo ng central directory signature ay 0x06054b50 at maaaring makilala gamit ang sarili nitong natatanging lagda. Ang sumusunod ay ang pagkakasunud-sunod ng impormasyong nakaimbak sa Local File Header.
Offset | Bytes | Description |
---|---|---|
0 | 4 | Local file header signature # 0x04034b50 (read as a little-endian number) |
4 | 2 | Version needed to extract (minimum) |
6 | 2 | General purpose bit flag |
8 | 2 | Compression method |
10 | 2 | File last modification time |
12 | 2 | File last modification date |
14 | 4 | CRC-32 |
18 | 4 | Compressed size |
22 | 4 | Uncompressed size |
26 | 2 | File name length (n) |
28 | 2 | Extra field length (m) |
30 | n | File Name |
30+n | m | Extra Field |
Central Directory File Header
Offset | Bytes | Description |
---|---|---|
0 | 4 | Central directory file header signature # 0x02014b50 |
4 | 2 | Version made by |
6 | 2 | Version needed to extract (minimum) |
8 | 2 | General purpose bit flag |
10 | 2 | Compression method |
12 | 2 | File last modification time |
14 | 2 | File last modification date |
16 | 4 | CRC-32 |
20 | 4 | Compressed size |
24 | 4 | Uncompressed size |
28 | 2 | File name length (n) |
30 | 2 | Extra field length (m) |
32 | 2 | File comment length (k) |
34 | 2 | Disk number where file starts |
36 | 2 | Internal file attributes |
38 | 4 | External file attributes |
42 | 4 | Relative offset of local file header. This is the number of bytes between the start of the first disk on which the file occurs, and the start of the local file header. This allows software reading the central directory to locate the position of the file inside the ZIP file. |
46 | n | File name |
46+n | m | Extra field |
46+n+m | k | File comment |
End of Central Directory Record
Offset | Bytes | Description |
---|---|---|
0 | 4 | End of central directory signature # 0x06054b50 |
4 | 2 | Number of this disk |
6 | 2 | Disk where central directory starts |
8 | 2 | Number of central directory records on this disk |
10 | 2 | Total number of central directory records |
12 | 4 | Size of central directory (bytes) |
16 | 4 | Offset of start of central directory, relative to start of archive |
20 | 2 | Comment length (n) |
22 | n | Comment |