ZIP Uncompressed Size سے مراد وہ بائٹس کی تعداد ہے جو کسی ZIP آرکائیو کے اندر موجود فائل کے پاس دوبارہ ان پیک ہونے کے بعد ہوگی، اس کے برعکس کہ آرکائیو کے اندر رہتے ہوئے اس کی عموماً کم Compressed Size کتنی ہوتی ہے۔ میٹاڈیٹا ریڈر ExifTool اسے ZipUncompressedSize کے طور پر دکھاتا ہے۔
کن فائلوں میں یہ شامل ہوتا ہے، اور یہ نمبر کہاں سے آتا ہے
آرکائیوز اسے ریکارڈ کرتے ہیں۔ ZIP فائلیں، اور وہ تمام عام فارمیٹس جو اندرونی طور پر ZIP کنٹینرز ہوتے ہیں، مثلاً .docx، .xlsx اور .pptx ڈاکیومنٹس، .odt فائلیں، .epub ای بُکس، .jar اور .apk پیکجز، سب اسے محفوظ کرتے ہیں۔ RAR، 7z اور دیگر آرکائیو فارمیٹس بھی یہی عدد اپنے الگ لےآؤٹ میں اسٹور کرتے ہیں۔ کسی رپورٹ میں .odt اور .epub فائلوں کے لیے یہ فیلڈ درج نہ ہو، حالانکہ فائل کے اندر یہ موجود ہوتا ہے۔
آرکائیو عموماً اس لیے بنتی ہے کہ کئی فائلوں کو ملا کر ایک بنا دیا جائے، اگرچہ ایک ہی فائل کو الگ سے بھی آرکائیو کیا جا سکتا ہے، اور کمپریشن پروگرام پیک کرتے وقت ہر فائل کے اصل سائز کو نوٹ کرتا ہے۔ یہ اس ایپ کے ذریعے خودکار طور پر ہوتا ہے جس نے آرکائیو بنائی ہو، چاہے وہ 7-Zip، WinRAR، WinZip، macOS پر Archive Utility، Windows کا compressed folder کمانڈ ہو یا zip کمانڈ لائن ایپ۔
یہ سمجھنا اہم ہے کہ یہ عدد ایک اعلان ہوتا ہے۔ آرکائیو بیان کرتی ہے کہ مواد ان پیک ہونے کے بعد کتنا بڑا ہونا چاہیے؛ جب تک آپ واقعی Extract نہیں کرتے، کوئی چیز اسے تصدیق نہیں کرتی، اور اسی وقت سائز اور محفوظ شدہ checksum کا موازنہ نکلی ہوئی فائل سے کیا جاتا ہے۔
ایک عام ویلیو کیسی دکھتی ہے
یہ بائٹس کی ایک مکمل عددی مقدار ہوتی ہے، جسے ایپس عموماً دکھانے کے لیے KB یا MB میں تبدیل کر دیتی ہیں۔ کسی مختصر Word دستاویز کے متن کے لیے یہ لکھا ہو سکتا ہے کہ 48219 بائٹس uncompressed، جبکہ .docx فائل کے اندر وہ اس کا صرف ایک چھوٹا حصہ جگہ لے رہی ہو۔
Compressed size کو اس عدد پر تقسیم کریں تو آپ کے پاس compression ratio آ جاتا ہے۔ فرق کتنا بڑا ہو گا، یہ مواد اور استعمال ہونے والے طریقے پر منحصر ہے؛ Deflate ZIP فائلوں میں معیاری طریقہ ہے، جبکہ BZIP2 اور LZMA متبادل طریقوں میں شامل ہیں۔ ایک اہم نکتہ یہ ہے کہ اصل ZIP فیلڈز 32 بٹ تک محدود ہیں، اس لیے 4,294,967,295 بائٹس، یعنی تقریباً 4 GB پر رک جاتے ہیں۔ اس سے بڑے مواد کے لیے ZIP64 ایکسٹینشن پر انحصار کیا جاتا ہے، جو اصل عدد کو ایک اضافی ریکارڈ میں رکھتی ہے، اس لیے کوئی بہت پرانا ایپ جو ZIP64 کو نہیں سمجھتا، کسی بڑی فائل کے لیے محدود یا بے معنی نمبر دکھا سکتا ہے۔
یہ کیوں اہم ہے
اس کا سب سے عملی استعمال منصوبہ بندی ہے۔ یہی عدد آپ کو پہلے سے بتاتا ہے کہ Unpack کرنے سے پہلے مواد جگہ میں آئے گا یا نہیں، اور حیرت کافی ہو سکتی ہے، کیونکہ متن یا لاگ فائلوں کی ایک معمولی سی آرکائیو بھی کئی گیگا بائٹس تک پھیل سکتی ہے۔ اسے compressed size سے ملا کر آپ دیکھ سکتے ہیں کہ کمپریشن نے واقعی مدد کی یا نہیں: اگر دونوں اعداد تقریباً برابر ہوں تو مطلب یہ ہے کہ مواد پہلے ہی compressed تھا، جیسے JPEG، MP3 اور MP4 فائلیں، اور انہیں دوبارہ پیک کرنے سے کچھ نہیں بچے گا۔
یہ ایک اضافی حفاظتی جانچ کے طور پر بھی کام کرتا ہے۔ چند سو کلو بائٹس کی کوئی آرکائیو جو بہت بڑا uncompressed size ظاہر کرے، احتیاط کی مستحق ہے، کیونکہ جان بوجھ کر بنائی گئی کچھ آرکائیوز اسی چال سے کسی کے Unpack کرنے پر ڈسک بھر دیتی ہیں۔ آرکائیو محفوظ رکھنے کے کام میں موازنہ اس کے برعکس ہوتا ہے: ظاہر کردہ سائز کو اصل میں نکلی ہوئی فائلوں کے ساتھ ملا کر دیکھنا ایک پرانی آرکائیو کے مکمل ہونے کی سادہ تصدیق ہے۔
یہ عدد کسی قسم کی ذاتی معلومات نہیں رکھتا۔ یہ صرف ڈیٹا کے حجم کو بیان کرتا ہے، اور اس شخص کے بارے میں کچھ نہیں بتاتا جس نے اسے بنایا۔