कच्ची फ़ाइल से 7zipped फ़ाइल बड़ी क्यों है? [डुप्लिकेट]

Question

संभव डुप्लिकेट:
क्यों ज़िप संपीड़न कुछ भी संपीड़ित नहीं करता है?

मैंने .exe फ़ाइल 7zipping की कोशिश की, लेकिन यह वास्तव में बड़ा हो गया।

क्या यह अपेक्षित परिणाम है?

Comments

हां, यह अपेक्षित परिणाम है। क्यूं कर? क्योंकि जब कोई चीज़ पहले से ही संपीड़ित होती है (= छोटे संभावित स्थान का उपयोग करते हुए), तो उसे आगे संकुचित नहीं किया जा सकता है।

— woliveirajr

बस सभी को जोड़ने के लिए - - क्योंकि यह exe फ़ाइल विशेष रूप से एक इंस्टॉलर है, इसकी अधिकांश सामग्री संभवतः एक ज़िप या कैब संग्रह है। आपको सामान्य exe फ़ाइल से समान परिणाम नहीं मिलेंगे (लेकिन सबसे सामान्य exe फ़ाइलें 145 मेगाबाइट नहीं होंगी)

— random832

केवल मूल तर्क का उपयोग कर स्पष्टीकरण: संपीड़न एक कच्ची फ़ाइल के लिए एक UNIQUE ज़िपित फ़ाइल, और ज़िपित फ़ाइल UNIQUE कच्ची (असम्पीडित) मूल फ़ाइल के लिए पाता है। कल्पना कीजिए कि आपके पास 8-बिट फाइलें हैं और उन्हें 5-बिट फ़ाइलों में संपीड़ित करना चाहते हैं। 256 अद्वितीय 8-बिट फ़ाइलें हैं, लेकिन केवल 32 अद्वितीय 5-बिट फ़ाइलें (!) तो कुछ 8-बिट फ़ाइलों को समान 5-बिट फ़ाइल (!) में संपीड़ित किया जाना चाहिए। और अगर 2 अलग-अलग कच्ची फाइलें एक ही ज़िप फ़ाइल में संपीड़ित होती हैं, तो आप किसको डिकम्प्रेसन के बाद प्राप्त करना चाहते हैं? किसी भी जिपिंग विधि के लिए, अगर ऐसी फाइलें मौजूद हैं जो ज़िप करने के बाद छोटी हो जाती हैं, तो फाइलें मौजूद होनी चाहिए, जो कि बड़ी हो जाती हैं (!)

— इवान कुकिर

Answer 1

यह एन्ट्रापी नामक एक अवधारणा के लिए आता है । विकिपीडिया देखें ।

मूल विचार यह है कि, अगर कोई संपीड़न ऑपरेशन मौजूद होता है जो हमेशा फ़ाइल को छोटा बना सकता है , तो तर्क यह बताता है कि संपीड़न ऑपरेशन किसी भी फ़ाइल को 0 बाइट्स में कम करने में सक्षम होगा और अभी भी सभी डेटा को बनाए रखेगा। लेकिन यह बेतुका है , क्योंकि हम जानते हैं कि 0 बाइट्स किसी भी जानकारी को व्यक्त नहीं कर सकते हैं। इसलिए हमने केवल यह साबित किया है कि एक संपीड़न एल्गोरिदम मौजूद नहीं हो सकता है जो हमेशा अपने इनपुट को छोटा बनाता है, क्योंकि अगर ऐसा होता, तो किसी भी जानकारी को 0 बाइट्स में संग्रहीत किया जा सकता है - लेकिन 0 बाइट्स जानकारी के अभाव का मतलब है , इसलिए आप ' t साथ में कोई जानकारी और सभी जानकारी नहीं है। इसलिए, यह बेतुका है।

इस सैद्धांतिक अवधारणा के कारण, आपके द्वारा उपयोग किया जाने वाला प्रत्येक संपीड़न प्रोग्राम कुछ इनपुट के आकार (या सर्वोत्तम रूप से, उसी आकार को बनाए रखने) को बढ़ाने जा रहा है । यही है, आपके द्वारा डिज़ाइन या उपयोग किए जाने वाले किसी भी संपीड़न एल्गोरिदम के लिए, कुछ इनपुट होंगे जो छोटे से निकलेंगे, और कुछ ऐसे नहीं होंगे।

पहले से संपीड़ित डेटा आम तौर पर आगे के संपीड़न के लिए एक भयानक उम्मीदवार है, क्योंकि अधिकांश दोषरहित संपीड़न एल्गोरिदम एक ही सैद्धांतिक सिद्धांतों पर आधारित हैं। यह है आगे भी खराब संकुचित डेटा को संपीड़ित करने के लिए संभव; लेकिन यह मूल डेटा से उपलब्ध सर्वोत्तम एल्गोरिथ्म के साथ इसे संक्षिप्त करने की तुलना में कम कुशल है।

उदाहरण के लिए, यदि आपके पास एक 100 एमबी पाठ फ़ाइल थी और इसे नियमित ज़िप एल्गोरिथ्म का उपयोग करके संपीड़ित किया गया था, तो यह 50 एमबी तक संकुचित हो सकता है। यदि आप LZMA2 के साथ ज़िप फ़ाइल को संपीड़ित करते हैं, तो आप इसे 40 या 45 एमबी तक नीचे ला सकते हैं, क्योंकि LZMA में ज़िप की तुलना में अधिकांश संपीड़ित डेटा के लिए उच्च संपीड़न अनुपात है। तो यह इस कारण से है कि यह ज़िप डेटा को संपीड़ित कर सकता है, क्योंकि ज़िप पूरी तरह से इसमें से सभी एन्ट्रापी को नहीं चूसता है। लेकिन अगर आप ज़िप कंटेनर को पूरी तरह से खत्म कर देते हैं, तो आप LZMA2 के साथ कच्चे पाठ को संपीड़ित करके इसे और भी छोटा कर सकते हैं, संभावित रूप से 30 - 35 एमबी (ये अवधारणा को स्पष्ट करने के लिए ये केवल "एयर नंबर" हैं) ।

उस बाइनरी के मामले में, जिसे आप संपीड़ित करने का प्रयास कर रहे हैं, यह बड़ा है क्योंकि 7-ज़िप फ़ाइल प्रारूप को अपनी आंतरिक संरचना बनाना है और पहले से संपीड़ित निष्पादन योग्य डेटा को 7-ज़िप प्रारूप में पैक करना है। इसमें शब्दकोश, फ़ाइल हेडर और इसी तरह की चीजें शामिल हैं। ये अतिरिक्त डेटा आमतौर पर डेटा को स्वयं को संपीड़ित करने की बचत से अधिक होते हैं, लेकिन ऐसा प्रतीत होता है कि जिस निष्पादन योग्य को आप संपीड़ित करने का प्रयास कर रहे हैं, वह पहले से ही LZMA के कुछ रूप के साथ संपीड़ित है; अन्यथा, यह संभवतः निष्पादन योग्य के आकार को छोटा कर देगा या बहुत कम बढ़ा देगा, बजाय इसे 2 एमबी बढ़ाकर (जो बहुत अधिक है)।

Comments

इस सवाल का जवाब देने के लिए सबसे महत्वपूर्ण हिस्सा है btw अंत में सही है: "यह एक शब्दकोश, एक फ़ाइल हैडर, और इसी तरह की चीजें शामिल हैं। ये अतिरिक्त डेटा आमतौर पर डेटा को संपीड़ित करने की बचत से ऑफसेट से अधिक होते हैं, लेकिन यह ऐसा प्रतीत होता है कि जिस निष्पादन योग्य को आप संपीड़ित करने का प्रयास कर रहे हैं वह पहले से ही LZMA के कुछ रूप के साथ संपीड़ित है "

— झॉकिंग

@ जॉकिंग: नहीं, सबसे महत्वपूर्ण हिस्सा मध्य की ओर है: "आपके द्वारा उपयोग किया जाने वाला प्रत्येक संपीड़न कार्यक्रम ... कुछ इनपुट के आकार को बढ़ाने जा रहा है।" 7zip के फ़ाइल-प्रारूप में एक शब्दकोश / फ़ाइल-हेडर / आदि है, लेकिन भले ही 7zip ने एक एल्गोरिथ्म का उपयोग किया हो, जिनमें से कोई भी चीज़ नहीं है, हम अभी भी गारंटी देते हैं कि कुछ (वास्तव में, अधिकांश) इनपुट में आउटपुट होंगे के रूप में बड़े-या-खुद आदानों से बड़ा है। यह सूचना-सिद्धांत का एक मूल तथ्य है, और फ़ाइल-हेडर से इसका कोई लेना-देना नहीं है।

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

@ मेहरदाद ज़रूर: बस एक "संपीड़न" एल्गोरिथ्म लिखें जो हमेशा मूल इनपुट लौटाता है। क्या आप वहां मौजूद हैं; किया हुआ। : P ... उस के अलावा, नहीं - किसी भी संपीड़न एल्गोरिथ्म है कि सभी में एक एल्गोरिथ्म कुछ मेटाडेटा जा रहा है , भले ही यह फ़ाइल की शुरुआत में सिर्फ एक बिट है जो इंगित करता है कि फ़ाइल संपीड़ित है या नहीं (0) == असम्पीडित, 1 == संपीड़ित)। यदि आप फ़ाइल की सामग्री को सभी में संशोधित करने जा रहे हैं , तो आपको कुछ मेटाडेटा की आवश्यकता है। और यदि आप सामग्री को संशोधित कर रहे हैं, तो आप कुछ इनपुट बड़ा करने जा रहे हैं ।

— एलाक्विओटिक

हालांकि, यदि आपका प्रश्न "क्या कोई संपीड़न एल्गोरिथ्म है जो मेटाडेटा की निश्चित मात्रा से परे इनपुट की लंबाई नहीं बढ़ाता है", तो उत्तर है: मुझे नहीं पता, लेकिन ऐसा करना सैद्धांतिक रूप से संभव होना चाहिए। वास्तव में आसान है। आपको बस एक कंटेनर प्रारूप विकसित करना है जिसमें या तो मूल फ़ाइल, या संपीड़ित डेटा स्ट्रीम हो सकती है। फिर, जब आप संग्रह बनाते हैं, तो संपीड़ित करने का प्रयास करें: यदि संपीड़ित आकार इनपुट से बड़ा है, तो बस मूल इनपुट संग्रहीत करें और अपना मेटाडेटा सामने रखें। फ़ाइल का आकार बढ़ जाएगा, लेकिन अगर मेटाडेटा छोटा है (cont'd)

— allquixotic

@ मेहरदाद: "क्या कोई संपीड़न एल्गोरिथ्म (हालांकि खराब) है जो किसी इनपुट की लंबाई नहीं बढ़ाता है? " - जवाब है नहीं। 2^(n+1)-1आकार n- बिट या उससे कम के संभावित संदेश हैं । हमारे एल्गोरिथ्म को इनमें से हर एक को एक अद्वितीय आउटपुट में मैप करना होगा । यदि इनमें से एक भी कम बिट्स के साथ एक मूल्य के लिए मैप किया जाता है, तो दूसरे मूल्य को आवश्यक रूप से अधिक के साथ मैप किया जाना चाहिए।

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

Answer 2

7z में प्रयुक्त अंतर्निहित संपीड़न एल्गोरिदम दोषरहित हैं । जिसका अर्थ है कि आप किसी फ़ाइल को कई बार संपीड़ित-डिकम्प्रेस कर सकते हैं। इसके अलावा, प्रत्येक पुनरावृत्ति के बाद फ़ाइल बिल्कुल वैसी ही रहेगी ।

दुर्भाग्य से, आप उम्मीद नहीं कर सकते कि दोषरहित संपीड़न एल्गोरिथ्म हमेशा सकारात्मक परिणाम के साथ कई बार लागू किया जाता है। एक सख्त सीमा है जिस पर वह कूद नहीं सकता। मोटे तौर पर, यह सीमा इस बात पर निर्भर करती है कि इनपुट अनुक्रम कितनी बारीकी से यादृच्छिक डेटा को सुनिश्चित करता है। इन सबसे ऊपर, दोषरहित एल्गोरिदम का उपयोग फ़ाइलों के संपीड़न, इंटरनेट HTML डेटा ट्रांसफ़र, बैकअप और अन्य कार्यों के लिए किया जाता है, जो आउटपुट फ़ाइल को उसी मूल इनपुट फ़ाइल में विघटित होने की उम्मीद करते हैं।

दोषरहित संपीड़न के विपरीत , आप हमेशा दोषपूर्ण (या हानिरहित) संपीड़न एल्गोरिदम के साथ संपीड़न के बाद फ़ाइल आकार में कमी की उम्मीद कर सकते हैं । नीचे की ओर है कि आप नहीं कर सकते हैं वास्तव में एक एकल संपीड़ित-दबाव हटाना यात्रा के बाद एक मूल फ़ाइल को पुनर्स्थापित। ये एल्गोरिदम ऑडियो / वीडियो / छवि प्रसारण और भंडारण के लिए सबसे प्रसिद्ध हैं।

bzip2 , LZMA , LZMA2 और 7z प्रारूप द्वारा उपयोग किए जाने वाले अन्य एल्गोरिदम सभी दोषरहित हैं । इसलिए एक सीमा होगी जिसके बाद यह अब संपीड़ित नहीं हो सकता है। उसके ऊपर, निष्पादन योग्य छवियां (.exe) आमतौर पर अत्यधिक संपीड़ित फ़ाइलें होती हैं। 7zip के रूप में कई अन्य संपीड़न उपकरण कुछ मेटाडेटा एम्बेड करता है, जो वास्तव में आउटपुट फ़ाइल को बड़ा बना सकता है।

ब्रेन टीज़र: क्या होगा अगर हमारे पास एक दोषरहित एल्गोरिथ्म है जो हमेशा फ़ाइल के आकार को कम कर सकता है?

इस स्थिति में, आप हमेशा देखेंगे कि संपीड़ित फ़ाइल इनपुट फ़ाइल से छोटी है। एक टिप्पणी देखें कि यह क्यों संभव नहीं है।

Comments

विरोधाभास द्वारा प्रमाण। परिकल्पना: मान लीजिए कि किसी फ़ाइल को दोषरहित एल्गोरिथ्म के साथ संपीड़ित करना हमेशा संभव है। चरण 1। एकल संपीड़न एक आउटपुट फ़ाइल को कम से कम एक बिट से छोटा करता है। यदि हां, तो कई पुनरावृत्तियों के बाद हम एक ऐसी फ़ाइल के साथ समाप्त हो जाएंगे जिसमें केवल दो बिट्स हैं। चरण 2 अगला पुनरावृत्ति 1 बिट के आकार की फ़ाइल बनाता है। चरण 3 लेकिन संपीड़न एल्गोरिदम दोषरहित है, जिसका अर्थ है कि केवल एक वैध अपघटन की अनुमति है। स्पष्ट रूप से आप 1 संपीड़ित बिट से 2 मूल बिट्स को पुनर्स्थापित नहीं कर सकते हैं - आपको एक अनुमान लगाना होगा। अंतिम बिंदु परिकल्पना का उल्लंघन करता है।

— oleksii

आप एक एल्गोरिथ्म की गारंटी नहीं दे सकते हैं जो फ़ाइल को छोटा बनाता है, लेकिन आप एक की गारंटी दे सकते हैं जो उन मामलों में कोई "संपीड़न" लागू करके आकार में वृद्धि नहीं करेगा। हालांकि वास्तव में कोई फ़ाइल आकार वृद्धि नहीं हुई है, इसलिए आपको इसे बैंड से बाहर (जैसे फ़ाइल नाम में) इंगित करना होगा।

— जेटी

@jeteon मुझे यकीन नहीं है कि आप क्या कहना चाह रहे हैं।

— oleksii

मैं सिर्फ यह जोड़ रहा था कि चूंकि आपके पास हमेशा इनपुट को संपीड़ित न करने का विकल्प है, इसलिए आपके पास एक संपीड़न कार्यक्रम हो सकता है जो फ़ाइल को बिल्कुल भी संपीड़ित नहीं करेगा। असल में, यदि आप यह निर्धारित करते हैं कि संपीड़ित संस्करण असम्पीडित संस्करण से बड़ा है, तो आप इसे छोड़ देते हैं। फिर आपको किसी तरह यह भी बताना होगा कि आउटपुट के आकार को जोड़े बिना यह मामला है इसलिए डिकम्प्रेसर को पता है कि फ़ाइल संपीड़ित नहीं थी। फ़ाइल का आकार बढ़ाए बिना ऐसा करने का एकमात्र तरीका, फ़ाइल नाम को बदलने जैसा कुछ करना है।

— जेटी

@jeteon ओह, मैं देख रहा हूँ। हां, समझ में आता है।

— oleksii

Answer 3

यदि मूल निष्पादन योग्य पहले से ही संपीड़ित था (या भारी संपीड़ित डेटा या गैर-सक्षम डेटा शामिल था) तो इसे संपीड़ित करने से आकार में वृद्धि होगी।

Answer 4

अधिकांश संपीड़न एल्गोरिदम एक प्रतीक तालिका नामक व्हाट्सएप का उपयोग करते हैं, मूल रूप से फ़ाइल के केवल पेइसेस का उपयोग करते हैं जो इसे संपीड़ित कर सकते हैं। यह, निश्चित रूप से फ़ाइल में कुछ ओवरहेड बनाता है, लेकिन आमतौर पर एक बहुत छोटी फ़ाइल होती है।

पहले से ही संपीड़ित फ़ाइलों में, यह अभी भी प्रतीकों का एक सेट बनाता है, लेकिन बहुत कम है जो आकार को कम कर सकता है। आपके मामले में, पहले से ही संपीड़ित फ़ाइल का प्रतीक तालिका शायद 2 एमबी के पड़ोस में है या शायद अधिक है अगर उसने दो कंप्रेस्डिंग करने का प्रबंधन किया।

Answer 5

कंप्रेसिंग आइडिया:

संपीड़न सॉफ्टवेयर फाइलों की एक सूची बनाता है और डुप्लिकेट सामग्री को समाप्त करता है।

जब पहले से संपीड़ित फ़ाइलों को संपीड़ित किया जाता है, तो आप अपनी संपीड़ित फ़ाइलों को मूल से बड़ा कर सकते हैं।