फाइल का असंपीड़ित आकार क्या है

ZIP Uncompressed Size वह बाइट्स की संख्या है, जो ZIP archive के अंदर मौजूद किसी फ़ाइल का आकार फिर से अनपैक होने के बाद होगा, इसके विपरीत कि archive के अंदर रहते समय वह आम तौर पर उससे छोटे Compressed Size में कितनी जगह घेरती है। मेटाडेटा reader ExifTool इसे ZipUncompressedSize के रूप में दिखाता है।

कौन सी फ़ाइलें इसे रखती हैं, और यह संख्या कहाँ से आती है

Archives इसे रिकॉर्ड करते हैं। ZIP फ़ाइलें ऐसा करती हैं, और उनके साथ वे सभी रोज़मर्रा के फ़ॉर्मेट भी जो अंदर से ZIP container होते हैं, जैसे .docx, .xlsx और .pptx दस्तावेज़, .odt फ़ाइलें, .epub ई-बुक्स, .jar और .apk पैकेज। RAR, 7z और अन्य archive फ़ॉर्मेट भी वही मान अपने-अपने लेआउट में सहेजते हैं। किसी रिपोर्ट में .odt और .epub फ़ाइलों के लिए यह मान सूचीबद्ध न हो, भले ही फ़ाइल के अंदर यह संग्रहीत हो।

Archive आम तौर पर कई फाइलों को एक में मिलाने के लिए होता है, हालांकि एक अकेली फाइल को भी अलग से archive किया जा सकता है, और compression प्रोग्राम पैक करते समय हर सदस्य का original size नोट कर लेता है। यह काम अपने आप हो जाता है, चाहे archive 7-Zip, WinRAR, WinZip, macOS के Archive Utility, Windows compressed folder कमांड या zip command line टूल से बनाया गया हो।

समझने लायक बात यह है कि यह मान एक घोषणा है। Archive केवल यह बताता है कि unpack होने पर सामग्री कितनी बड़ी होनी चाहिए; इसकी पुष्टि तब तक नहीं होती जब तक आप वास्तव में extract नहीं करते, और उस समय वास्तविक size की तुलना सहेजे गए checksum और घोषित size से होती है।

एक सामान्य मान कैसा दिखता है

यह bytes की एक पूर्ण संख्या होती है, जिसे apps अक्सर दिखाने के लिए KB या MB में बदल देते हैं। एक छोटे Word दस्तावेज़ के text के लिए 48219 bytes uncompressed लिखा हो सकता है, जबकि वह .docx फाइल के अंदर उसका केवल एक छोटा हिस्सा भर जगह लेता है।

Compressed size को इस मान से विभाजित करें और आपके पास compression ratio आ जाता है। अंतर कितना बड़ा होगा, यह सामग्री और इस्तेमाल किए गए तरीके पर निर्भर करता है; ZIP फाइलों में Deflate मानक तरीका है, जबकि BZIP2 और LZMA विकल्पों में शामिल हैं। एक महत्वपूर्ण बात यह है कि मूल ZIP फ़ील्ड्स 32 बिट के होते हैं और 4,294,967,295 bytes, यानी लगभग 4 GB पर रुक जाते हैं। इससे बड़े content के लिए ZIP64 एक्सटेंशन पर भरोसा किया जाता है, जो असली मान को एक अतिरिक्त रिकॉर्ड में रखता है, इसलिए कोई बहुत पुराना टूल जो ZIP64 को नहीं समझता, किसी बहुत बड़ी फाइल के लिए काट-छांट किया हुआ या बे मतलब नंबर दिखा सकता है।

यह क्यों महत्वपूर्ण है

इसका सबसे व्यावहारिक उपयोग योजना बनाना है। यही वह मान है जो आपको पहले से बताता है कि unpack करने पर सामग्री उपलब्ध जगह में आ पाएगी या नहीं, और यह चौंका भी सकता है, क्योंकि text या log फाइलों का छोटा-सा archive कई gigabytes तक फैल सकता है। इसे compressed size से तुलना करने से यह भी पता चलता है कि compression से वास्तव में लाभ हुआ या नहीं: यदि दोनों मान लगभग बराबर हैं, तो सामग्री पहले से ही compressed थी, जैसे JPEG, MP3 और MP4 फाइलों के साथ होता है, और उसे दोबारा पैक करने से कोई जगह नहीं बचेगी।

यह एक sanity check की तरह भी काम करता है। कुछ सौ kilobytes के archive में यदि बहुत बड़ा uncompressed size घोषित हो, तो सावधानी बरतनी चाहिए, क्योंकि जानबूझकर बनाए गए कुछ archive इसी तरीके से extraction के समय डिस्क भरने की कोशिश करते हैं। लंबे समय तक सुरक्षित रखी गई फाइलों के लिए तुलना उलटी दिशा में काम आती है: घोषित size की तुलना वास्तव में निकले हुए डेटा से करना किसी पुराने archive के अब भी पूरा होने की सरल जाँच है।

यह मान कोई व्यक्तिगत जानकारी नहीं रखता। यह केवल डेटा की मात्रा बताता है, न कि उसे बनाने वाले व्यक्ति के बारे में कुछ।