कमांड का /bझंडा copyफाइलों को बाइनरी (यानी, अर्थहीन बाइट्स की एक कच्ची धारा) के रूप में मानता है, और उन्हें डिफ़ॉल्ट (या /a) व्यवहार के बजाय बाइट के लिए बाइट की प्रतिलिपि बनाता है जो उन्हें पाठ की पंक्तियों के रूप में मानता है (अंत-पंक्ति के साथ) अक्षर, अंतिम-फ़ाइलें, आदि)
आप पाठ फ़ाइलों को डिफ़ॉल्ट पाठ व्यवहार या बाइनरी स्विच के साथ मर्ज कर सकते हैं, लेकिन बहुत अधिक किसी भी बाइनरी फ़ाइल काम नहीं करेगी। आप बस दो बाइनरी फ़ाइलों से बाइट्स कॉपी नहीं कर सकते हैं और उनसे काम करने की उम्मीद कर सकते हैं क्योंकि बाइनरी फ़ाइलों में आमतौर पर हेडर , मेटाडेटा , डेटा संरचनाएं होती हैं, आदि जो फ़ाइल के प्रारूप को परिभाषित करते हैं। यदि आप एक बाइनरी कॉपी करते हैं, तो आप बस सभी बाइट्स की नकल करेंगे, जो इन संरचनाओं को उन जगहों पर डाल रहा है, जो उन्हें नहीं होना चाहिए, इसलिए जब आप उन्हें खोलते हैं, तो पार्सिंग फ़ंक्शन में परेशानी होगी और देखें कि क्या अनिवार्य रूप से भ्रष्ट डेटा है । कुछ प्रोग्राम उन भागों को अनदेखा कर देंगे जो समझ में नहीं आते हैं और बस दिखाते हैं कि वे क्या कर सकते हैं (जो काम करने के लिए स्टीरियोग्राफी की अनुमति देता है), लेकिन कुछ एक त्रुटि को फेंक देंगे और शिकायत करेंगे कि फ़ाइल भ्रष्ट है। भ्रष्टाचार का पता लगाने की क्षमता फ़ाइल-प्रकार पर निर्भर करती है।
एक उदाहरण के रूप में, आइए एक सरलीकृत पीडीएफ प्रारूप का आविष्कार करें:
Byte(s) Meaning
---------------------
File header:
0-1 # of Pages
2-3 Language
4-5 Font
6-EOF Data (each page encoded separately)
Page data:
0-1 Page number
2-3 # of characters on page
4-#chars Letters contained on the page
जैसा कि आप देख सकते हैं, प्रत्येक फ़ाइल में कुछ सामान्य जानकारी के साथ एक फ़ाइल-स्तरीय शीर्षलेख होगा, जिसके बाद पृष्ठ डेटा वाले प्रत्येक पृष्ठ के लिए डेटा ब्लॉक होगा। यदि आप दो फ़ाइलें लेते हैं, तो प्रत्येक में एक पृष्ठ होता है और उन्हें बाइनरी फ़ाइलों के रूप में मर्ज किया जाता है, तो आप एक दो पृष्ठ की फ़ाइल नहीं बना रहे होंगे, बल्कि एक भ्रष्ट फ़ाइल जो एक पृष्ठ से शुरू होती है, तो उसमें रद्दी का एक गुच्छा होता है (फ़ाइल हेडर का कोई मतलब नहीं है जब प्रोग्राम पेज दो को पढ़ने की कोशिश करता है)।
यही बात आपके MP3 के लिए भी होती है। जब आप उन्हें इस तरह से जोड़ते हैं, तो दूसरी फ़ाइल के प्रारंभ और / या अंत में ID3 टैग बनाए रहते हैं, और जब खिलाड़ी अगले फ्रेम को पढ़ने की कोशिश करता है, तो यह ऑडियो डेटा की उम्मीद कर रहा है, लेकिन हैडर का पता लगा रहा है दूसरी फ़ाइल जो ऑडियो डेटा के लिए अपेक्षित प्रारूप से मेल नहीं खाती है, इसलिए यह नहीं पता है कि क्या करना है। कुछ खिलाड़ी हेडर को ऑडियो डेटा के रूप में चलाएंगे (जो निश्चित रूप से स्थिर / शोर / पॉप / आदि के रूप में चलेगा।), कुछ अगले सही फ्रेम तक ध्वनि में कटौती करेंगे, कुछ पूरी तरह से गाना बजाना बंद कर सकते हैं, और कुछ दुर्घटना भी कर सकते हैं। ।
copyआदेश सादे-पाठ (और फिर भी, केवल ASCII पाठ) के अलावा अन्य फ़ाइल प्रकार, इसलिए केवल सादे-पाठ सही ढंग से इसके साथ जोड़ा जा सकता है के बारे में कुछ भी नहीं जानता है। बाइनरी फ़ाइलों को एक संपादक का उपयोग करके जोड़ा जाना चाहिए जो जानता है कि सामग्री को कैसे पार्स और व्याख्या करना है।
