Ang ZIP Uncompressed Size ay kung ilang bytes ang magkakaroon ang isang file sa loob ng isang ZIP archive kapag na-unpack na ito, kumpara sa karaniwang mas maliit na Compressed Size na mayroon ito habang nasa loob pa ng archive. Ipinapakita ito ng metadata reader na ExifTool bilang ZipUncompressedSize.
Aling mga file ang may taglay nito, at saan nanggagaling ang numero
Nire-record ito ng mga archive. Ginagawa ito ng mga ZIP file, kasama ng mga pangkaraniwang format na ZIP container sa likod, gaya ng mga dokumentong .docx, .xlsx at .pptx, .odt file, .epub e-book, .jar at .apk package. Nini-store din ng RAR, 7z at iba pang format ng archive ang parehong numero sa sarili nilang layout. Maaaring hindi ito ilista sa isang report para sa mga .odt at .epub file, kahit na sine-save ito ng file.
Karaniwang ginagawa ang isang archive para pagsamahin ang maraming file sa isa, bagaman puwedeng i-archive ang isang file lang. Itinatala ng compression program ang orihinal na laki ng bawat miyembro habang ipinapack ito. Ginagawa iyon nang awtomatiko ng anumang app na bumuo ng archive, maging ito man ay 7-Zip, WinRAR, WinZip, ang Archive Utility sa macOS, ang Windows compressed folder command o ang zip command line tool.
Mahalagang maunawaan na ang halagang ito ay isang deklarasyon. Ipinapahayag ng archive kung gaano kalaki dapat ang laman kapag na-unpack na ito; walang nagsisiguro niyon hanggang sa aktwal na pag-extract, kung saan ikinukumpara ang laki at ang nakaimbak na checksum sa aktuwal na lumabas.
Kung ano ang hitsura ng isang tipikal na halaga
Isang buong bilang ng bytes, na madalas i-convert ng mga app sa KB o MB para ipakita. Ang teksto ng isang maikling Word document ay maaaring magpakitang 48219 bytes uncompressed habang kumukuha lamang ng maliit na bahagi niyon sa loob ng .docx file.
Hatiin ang compressed size sa halagang ito at makukuha mo ang compression ratio. Gaano kalaki ang agwat ay nakadepende sa laman at sa ginamit na method; Deflate ang standard method sa mga ZIP file, at kabilang sa mga alternatibo ang BZIP2 at LZMA. May isang kakaibang detalye na dapat malaman: ang orihinal na ZIP fields ay 32 bits lang at humihinto sa 4,294,967,295 bytes, bahagyang mas mababa sa 4 GB. Umaasa ang mas malalaking laman sa ZIP64 extension, na nagtatago ng totoong halaga sa isang dagdag na record, kaya ang isang napakalumang app na hindi nakakaunawa ng ZIP64 ay maaaring mag-ulat ng limitadong o walang saysay na numero para sa isang napakalaking file.
Bakit ito mahalaga
Pinakapraktikal ang gamit nito sa pagpa-planong maigi. Ito ang halagang nagsasabi kung kasya ba ang laman bago mo ito i-unpack, at puwedeng maging malaki ang sorpresa, dahil ang isang katamtamang laki na archive ng text o log files ay puwedeng lumobo hanggang maraming gigabytes. Ang paghahambing nito sa compressed size ay nagsasabi rin kung nakatulong ba ang pag-compress: dalawang magkalapit na numero ang nangangahulugang naka-compress na ang laman, gaya ng mga JPEG, MP3 at MP4 file, at walang matitipid sa muling pagre-repack.
Nagsisilbi rin itong paunang pagsusuri. Ang isang archive na ilang daang kilobytes lang pero nagdedeklara ng napakalaking uncompressed size ay dapat pag-ingatan, dahil ang mga sadyang ginawang archive para manlamang ay gumagamit ng ganyang taktika para punuin ang disk kapag may nag-unpack sa kanila. Para sa archival work, kabaligtaran naman ang tinitingnan: ang pag-check sa deklaradong laki laban sa aktuwal na lumabas ay isang simpleng paraan para tiyakin na buo pa rin ang isang lumang archive.
Walang dalang personal na impormasyon ang halagang ito. Inilalarawan lang nito kung gaano karaming data ang laman at walang sinasabi tungkol sa taong lumikha nito.