कंप्यूटर फ़ाइल के प्रकारों का पता कैसे लगाते हैं: मैजिक बाइट्स की व्याख्या
फ़ाइल एक्सटेंशन पूरी कहानी क्यों नहीं बताते
ज़्यादातर लोग यह मान लेते हैं कि कंप्यूटर को पता है कि कोई फ़ाइल JPEG है क्योंकि उसके अंत में .jpg लगा होता है। यह एक वाजिब अनुमान है, लेकिन यह लगभग आधे समय गलत होता है। फ़ाइल एक्सटेंशन सिर्फ़ नाम रखने का एक तरीका है। वे ऑपरेटिंग सिस्टम के लिए एक संकेत हैं, इस बात की गारंटी नहीं कि अंदर क्या है। किसी PNG फ़ाइल का नाम बदलकर .txt कर दें, और विंडोज खुशी-खुशी उसे नोटपैड में खोलने की कोशिश करेगा, और आपको अजीबोगरीब अक्षरों से भरी एक स्क्रीन दिखाएगा। किसी Word डॉक्यूमेंट का नाम बदलकर .pdf करके खोलने की कोशिश करें, और Adobe Acrobat उसे खोलने से साफ़ इनकार कर देगा। फ़ाइल रूपांतरण (conversion) के लिए यह बहुत मायने रखता है। जब आप CocoConvert जैसी किसी सेवा पर कोई फ़ाइल अपलोड करते हैं, तो सिस्टम सिर्फ़ एक्सटेंशन पर भरोसा नहीं कर सकता। कोई व्यक्ति किसी दुर्भावनापूर्ण एक्जीक्यूटेबल (.exe) का नाम बदलकर .jpg रख सकता है ताकि वह एक साधारण फ़ाइल हैंडलर को धोखा दे सके। या, जो अधिक सामान्य है, हो सकता है कि कोई उपयोगकर्ता गलती से किसी फ़ाइल को गलत एक्सटेंशन के साथ सहेज ले। हम सभी ने ऐसी खराब डाउनलोड की हुई फ़ाइलें देखी हैं जिनका एक्सटेंशन मेटाडेटा पूरी तरह से गायब हो जाता है। दशकों पहले तय किया गया इसका समाधान यह है कि फ़ाइल नाम को नज़रअंदाज़ किया जाए और फ़ाइल की वास्तविक बाइनरी सामग्री को पढ़ा जाए। विशेष रूप से, एक प्रोग्राम पहले कुछ बाइट्स पढ़ता है और उनकी तुलना हस्ताक्षरों (signatures) के एक ज्ञात डेटाबेस से करता है। इन हस्ताक्षरों को मैजिक बाइट्स, या अधिक औपचारिक रूप से, फ़ाइल सिग्नेचर कहा जाता है। वे किसी फ़ाइल की सामग्री के बारे में ज़मीनी सच्चाई हैं, चाहे उसका नाम कुछ भी हो।
मैजिक बाइट्स असल में क्या हैं
हर मानकीकृत फ़ाइल प्रारूप अपने पहले कुछ बाइट्स को एक अद्वितीय पहचानकर्ता (unique identifier) के लिए आरक्षित रखता है। हेक्साडेसिमल में लिखे गए ये बाइट्स, प्रारूप के विनिर्देश (specification) में ही बेक किए जाते हैं—उन्हें बाद में ऑपरेटिंग सिस्टम द्वारा नहीं जोड़ा जाता है। आप इन्हें स्वयं एक हेक्स एडिटर से देख सकते हैं। कुछ सामान्य फ़ाइल प्रकारों पर एक नज़र डालें: - **JPEG छवियाँ** हमेशा FF D8 FF से शुरू होती हैं। पहले दो बाइट्स (FF D8) डेटा स्ट्रीम की शुरुआत को चिह्नित करते हैं, और तीसरा (FF) पहले मार्कर सेगमेंट को शुरू करता है। - **PNG छवियाँ** 8-बाइट के सिग्नेचर से शुरू होती हैं: 89 50 4E 47 0D 0A 1A 0A। ध्यान दें कि 50 4E 47 वाला हिस्सा ASCII में 'PNG' है। - **PDF फ़ाइलें** 25 50 44 46 से शुरू होती हैं, जो ASCII में '%PDF' है। आप किसी भी PDF को एक सादे टेक्स्ट एडिटर में खोल सकते हैं और इसे सबसे ऊपर देख सकते हैं। - **ZIP आर्काइव** 50 4B 03 04 से शुरू होते हैं। यह ASCII में 'PK' है, जो इस प्रारूप के निर्माता फिल काट्ज़ (Phil Katz) के लिए है। चूँकि DOCX, XLSX, PPTX, और JAR फ़ाइलें सभी ZIP-आधारित हैं, वे इस सिग्नेचर को साझा करती हैं। - **MP3 ऑडियो** फ़ाइलें अक्सर FF FB या FF F3 से शुरू होती हैं, जो MPEG सिंक वर्ड है। - **EXE फ़ाइलें** विंडोज पर 4D 5A से शुरू होती हैं—ASCII में 'MZ', जो MS-DOS के मूल वास्तुकारों में से एक मार्क ज़बिकोव्स्की (Mark Zbikowski) के लिए है। 'मैजिक बाइट्स' नाम यूनिक्स की `file` यूटिलिटी से आया है, जो 1970 के दशक से `/etc/magic` (या आधुनिक सिस्टम पर `/usr/share/misc/magic`) नामक डेटाबेस का उपयोग कर रही है। जब आप टर्मिनल में `file photo.jpg` चलाते हैं, तो यह यूटिलिटी शुरुआती बाइट्स को पढ़ती है, अपने डेटाबेस से परामर्श करती है, और आपको .jpg एक्सटेंशन को पूरी तरह से अनदेखा करते हुए असली फ़ाइल प्रकार बताती है।
डिटेक्शन सॉफ़्टवेयर सिग्नेचर को कैसे पढ़ता है
सिद्धांत रूप में, मैजिक बाइट्स पढ़ना सरल है। लेकिन व्यवहार में, कुछ विशेष परिस्थितियाँ (edge cases) आपको परेशान कर सकती हैं। मूल प्रक्रिया में फ़ाइल को एक रॉ बाइनरी स्ट्रीम के रूप में खोलना, एक छोटा बफर पढ़ना—अक्सर पहले 512 बाइट्स—और उस बफर की तुलना ज्ञात हस्ताक्षरों की सूची से करना शामिल है। हालाँकि, कुछ प्रारूपों को बहुत आगे तक पढ़ने की आवश्यकता होती है। यह तुलना हमेशा एक साधारण उपसर्ग मिलान (prefix match) नहीं होती है। कुछ प्रारूप अपने सिग्नेचर को एक निश्चित ऑफ़सेट पर रखते हैं। ISO डिस्क इमेज प्रारूप, उदाहरण के लिए, इसका 'CD001' सिग्नेचर बाइट 32,769 से शुरू होता है। ZIP फ़ाइलों में उनकी केंद्रीय निर्देशिका (central directory) फ़ाइल के अंत में हो सकती है, जिससे कुछ डिटेक्टरों को सिर के बजाय पूंछ से स्कैन करने के लिए मजबूर होना पड़ता है। Apache Tika (जावा), python-magic (पाइथन), और libmagic (सी) जैसी आधुनिक लाइब्रेरी इस जटिलता को संभालती हैं। अकेले Apache Tika 1,300 से अधिक फ़ाइल प्रकारों को जानता है, जो MIME प्रकार, कैरेक्टर एन्कोडिंग और यहां तक कि एम्बेडेड मेटाडेटा का भी पता लगाता है। CocoConvert में, हम सर्वर-साइड सिग्नेचर डिटेक्शन को अपनी सुरक्षा की पहली पंक्ति के रूप में उपयोग करते हैं। यदि आपका ब्राउज़र जो MIME प्रकार घोषित करता है, वह बाइनरी सिग्नेचर से मेल नहीं खाता है, तो किसी भी रूपांतरण से पहले फ़ाइल को करीब से देखने के लिए फ़्लैग किया जाता है। कंटेनर प्रारूप चीजों को और भी मुश्किल बना देते हैं। एक DOCX फ़ाइल और एक JAR फ़ाइल दोनों 50 4B 03 04 से शुरू होती हैं क्योंकि वे दोनों ZIP आर्काइव हैं। उनमें अंतर बताने के लिए, सॉफ़्टवेयर को आर्काइव के अंदर विशिष्ट फ़ाइलों को देखना पड़ता है, जैसे DOCX के लिए [Content_Types].xml या JAR के लिए META-INF/MANIFEST.MF। यह दो-चरणीय पहचान (two-pass detection) किसी भी गंभीर फ़ाइल हैंडलिंग पाइपलाइन के लिए मानक अभ्यास है।
जब मैजिक बाइट्स विफल होते हैं (और वे होते हैं)
मैजिक बाइट्स भरोसेमंद हैं, लेकिन वे अचूक नहीं हैं। कई वास्तविक दुनिया के परिदृश्य सिग्नेचर-आधारित पहचान को विफल कर सकते हैं और आपको गलत या अस्पष्ट उत्तर दे सकते हैं। **कटी हुई (Truncated) फ़ाइलें** एक स्थायी सिरदर्द हैं। यदि कोई डाउनलोड बाधित हो जाता है, तो आपके पास एक ऐसी फ़ाइल हो सकती है जिसमें एक वैध JPEG हेडर हो लेकिन कोई वास्तविक छवि डेटा न हो। सिग्नेचर की जाँच तो पास हो जाती है, लेकिन बाद में रूपांतरण विफल हो जाता है जब डिकोडर एक पूरी छवि की उम्मीद करता है और उसे केवल एक टुकड़ा मिलता है। **जानबूझकर बनाई गई फ़ाइलें** इस तथ्य का फायदा उठा सकती हैं कि मैजिक बाइट्स केवल हेडर को कवर करते हैं। एक फ़ाइल में एक वैध PNG हेडर हो सकता है जिसके बाद एक दुर्भावनापूर्ण पेलोड हो। यह एक ज्ञात हमला करने का तरीका है जिसे पॉलीग्लॉट फ़ाइल कहा जाता है—एक एकल बाइनरी जो एक ही समय में दो अलग-अलग फ़ाइल प्रकारों के रूप में मान्य होती है। शोधकर्ताओं ने JPEG/JavaScript पॉलीग्लॉट बनाए हैं जिन्हें एक ब्राउज़र स्क्रिप्ट के रूप में निष्पादित करेगा जबकि एक छवि दर्शक इसे एक तस्वीर के रूप में प्रदर्शित करेगा। केवल सिग्नेचर डिटेक्शन इन्हें नहीं पकड़ पाएगा। **प्रारूप संस्करण के टकराव (Format version conflicts)** अस्पष्टता की एक और परत बनाते हैं। 2007 से पहले, Microsoft Office फ़ाइलें (DOC, XLS, PPT) कंपाउंड डॉक्यूमेंट बाइनरी फॉर्मेट का उपयोग करती थीं, जो D0 CF 11 E0 A1 B1 1A E1 से शुरू होता है। तीनों प्रारूपों का सिग्नेचर बिल्कुल एक जैसा है। आप मैजिक बाइट्स का उपयोग करके .doc को .xls या .ppt से अलग नहीं कर सकते; आपको आंतरिक संरचना को पार्स करना होगा। **सादे टेक्स्ट प्रारूप (Plain text formats)** जैसे CSV, JSON, XML, HTML, और Markdown में कोई मैजिक बाइट्स नहीं होते हैं। वे सिर्फ़ अक्षरों के अनुक्रम हैं। यहाँ पता लगाना अनुमान-आधारित विश्लेषण (heuristic analysis) पर निर्भर करता है: कोण कोष्ठक (HTML/XML) या घुंघराले ब्रेसिज़ (JSON) जैसे पैटर्न की तलाश करना। ये अनुमान गलत हो सकते हैं। जिसने भी कभी ऐसे 'CSV' से संघर्ष किया है जो कॉमा के बजाय सेमीकोलन का उपयोग करता है, वह इस दर्द को अच्छी तरह जानता है। अगर CocoConvert किसी फ़ाइल प्रकार की आत्मविश्वास से पहचान नहीं कर पाता है, तो वह आपको बता देता है। हमारा मानना है कि अनुमान लगाकर एक खराब फ़ाइल बनाने की तुलना में एक स्पष्ट त्रुटि देना कहीं अधिक उपयोगी है।
फ़ाइल रूपांतरण के लिए व्यावहारिक निहितार्थ
तो यह आपकी मदद कैसे करता है? यह आपके विफल रूपांतरणों के समस्या-निवारण के तरीके को पूरी तरह से बदल देता है। जब कोई सेवा 'असमर्थित या अपरिचित फ़ाइल प्रारूप' की रिपोर्ट करती है, तो समस्या लगभग कभी भी फ़ाइल नाम एक्सटेंशन नहीं होती है। यह सामग्री होती है। यहाँ सबसे आम अपराधी और उनके बारे में क्या करना है, दिए गए हैं: **फ़ाइल आपके सोचे हुए प्रारूप से अलग है।** यह डिज़ाइन टूल से निर्यात के साथ बहुत होता है। उदाहरण के लिए, फिग्मा (Figma) एक .jpg लेबल वाली फ़ाइल निर्यात कर सकता है जो वास्तव में एक PNG है। आपका सबसे अच्छा दांव यह है कि फ़ाइल को एक हेक्स एडिटर (जैसे विंडोज पर HxD या macOS पर Hex Fiend) में खोलें और पहले कुछ बाइट्स की जांच करें। यदि आप 89 50 4E 47 देखते हैं, तो यह एक PNG है, चाहे नाम कुछ भी हो। इसका नाम बदलें और फिर से प्रयास करें। **फ़ाइल पासवर्ड से सुरक्षित या DRM-लॉक है।** एन्क्रिप्टेड Office दस्तावेज़ अभी भी D0 CF 11 E0 से शुरू होते हैं, इसलिए सिग्नेचर की जाँच पास हो जाती है। लेकिन अंदर की सामग्री सिफरटेक्स्ट (ciphertext) है। CocoConvert पासवर्ड से सुरक्षित फ़ाइलों को डिक्रिप्ट नहीं कर सकता। इसे सेवा की सीमा न समझें; यह एन्क्रिप्शन की एक मौलिक सुरक्षा सुविधा है। **फ़ाइल गलत सामग्री वाला एक कंटेनर है।** एक सामान्य .zip का नाम बदलकर .docx करने से बनी फ़ाइल का सिग्नेचर तो सही (50 4B) होगा, लेकिन यह रूपांतरण में विफल हो जाएगी क्योंकि इसमें आवश्यक Word प्रोसेसिंग XML संरचना का अभाव है। कनवर्टर आर्काइव खोलता है, काम करने के लिए कुछ भी नहीं पाता है, और हार मान लेता है। **वीडियो फ़ाइलों में कोडेक का बेमेल होना।** एक MKV कंटेनर (1A 45 DF A3 से शुरू होता है) में H.264, H.265, AV1, VP9, या दर्जनों अन्य में एन्कोड किया गया वीडियो हो सकता है। मैजिक बाइट्स MKV कंटेनर की पुष्टि करते हैं, वीडियो स्ट्रीम के कोडेक की नहीं। यदि CocoConvert MKV का समर्थन करता है, लेकिन आपकी फ़ाइल RealVideo 4 जैसे किसी अस्पष्ट कोडेक का उपयोग करती है, तो प्रारंभिक पहचान पास हो जाएगी लेकिन ट्रांसकोडिंग चरण विफल हो जाएगा।
बिना विशेष सॉफ़्टवेयर के फ़ाइल का असली प्रकार कैसे जांचें
किसी फ़ाइल की वास्तविक पहचान को सत्यापित करने के लिए आपको विशेष सॉफ़्टवेयर स्थापित करने की आवश्यकता नहीं है। ये तरीके हर प्रमुख ऑपरेटिंग सिस्टम पर उन उपकरणों के साथ काम करते हैं जो आपके पास पहले से हैं। **विंडोज पर:** PowerShell खोलें और `Format-Hex -Path 'C:\path\to\yourfile.ext' | Select-Object -First 3` चलाएँ। यह कमांड पहले 48 बाइट्स को हेक्साडेसिमल में प्रिंट करता है। बाइट्स की पहली पंक्ति की तुलना इस लेख में पहले सूचीबद्ध हस्ताक्षरों से करें। **macOS और Linux पर:** टर्मिनल खोलें और `xxd yourfile | head -3` चलाएँ। यह बाइट ऑफ़सेट, हेक्स मान और ASCII प्रतिनिधित्व दिखाता है। इससे भी बेहतर, बस `file yourfile` चलाएँ। `file` यूटिलिटी अंतर्निहित है और आपको तुरंत एक साफ़, मानव-पठनीय उत्तर देती है। **ब्राउज़र में, बिना किसी टूल के:** यदि आप एक लॉक-डाउन मशीन पर हैं जहाँ आप कमांड नहीं चला सकते हैं, तो cocoConvert.com/detect पर CocoConvert के डिटेक्शन पेज पर जाएँ। फ़ाइल अपलोड करें, और हमारी सेवा पता लगाए गए MIME प्रकार, जिन सिग्नेचर बाइट्स से यह मेल खाती है, और उसके आत्मविश्वास के स्तर की रिपोर्ट करेगी। **पाइथन में (डेवलपर्स के लिए):** `pip install python-magic` के बाद, आप `import magic; print(magic.from_file('yourfile', mime=True))` चला सकते हैं। यह `image/jpeg` जैसा एक मानक MIME प्रकार देता है। हालाँकि, प्रोडक्शन पाइथन कोड के लिए मेरी सलाह है कि इसके बजाय `filetype` लाइब्रेरी का उपयोग करें। इसकी कोई सिस्टम निर्भरता नहीं है, जो इसे libmagic DLLs के साथ संघर्ष किए बिना विंडोज पर तैनात करना बहुत आसान बनाता है। अपलोड करने से पहले असली MIME प्रकार जानने से बहुत समय बचता है। यदि किसी फ़ाइल का पता लगाया गया प्रकार किसी सेवा की समर्थित इनपुट सूची में नहीं है, तो आप तुरंत जान जाते हैं कि रूपांतरण विफल हो जाएगा।
कोई भी रूपांतरण सेवा क्या वादा कर सकती है, उसकी सीमाएँ
मैजिक बाइट डिटेक्शन उन लगभग 200 फ़ाइल प्रारूपों के लिए एक सुलझी हुई समस्या है जो रोज़मर्रा के 99% उपयोग को कवर करते हैं। लेकिन विशेष, मालिकाना, या पुराने प्रारूपों की लंबी सूची के लिए, कोई भी सेवा—CocoConvert सहित—पूर्ण कवरेज का वादा नहीं कर सकती। CAD ड्रॉइंग के लिए Autodesk DWG, विशिष्ट स्कैनर ब्रांडों से मालिकाना मेडिकल इमेजिंग वेरिएंट, या पुराने सिंथेसाइज़र से विशिष्ट ऑडियो प्रारूप जैसे प्रारूपों में अक्सर खराब या कोई खुला दस्तावेज़ीकरण नहीं होता है। भले ही मैजिक बाइट्स ज्ञात हों, आंतरिक संरचना एक ब्लैक बॉक्स हो सकती है। एक कनवर्टर ऐसा आउटपुट उत्पन्न कर सकता है जिसमें डेटा गायब हो, रंग गलत हों, या मेटाडेटा परतें छूट गई हों। इस लेखन के समय, CocoConvert लगभग 300 इनपुट प्रारूपों का समर्थन करता है। जबकि यह बहुत कुछ लगता है, लाइब्रेरी ऑफ कांग्रेस की PRONOM रजिस्ट्री 2,000 से अधिक विशिष्ट फ़ाइल प्रारूपों का दस्तावेजीकरण करती है। यह अंतर उन प्रारूपों का प्रतिनिधित्व करता है जो इतने अस्पष्ट हैं कि इंजीनियरिंग प्रयास को उचित नहीं ठहराते, पेटेंट द्वारा कानूनी रूप से बाधित हैं, या इतने खराब तरीके से प्रलेखित हैं कि कोई भी रूपांतरण प्रयास एक जुआ होगा। मेरी सलाह यह है: यदि आप मेडिकल इमेजिंग, भू-स्थानिक डेटा, या पेशेवर वीडियो जैसे उद्योगों में काम करते हैं, तो आपको रूपांतरण वर्कफ़्लो के लिए प्रतिबद्ध होने से पहले प्रारूप समर्थन को सत्यापित करना होगा। CocoConvert का प्रारूप समर्थन पृष्ठ देखें। यह प्रत्येक समर्थित इनपुट और आउटपुट को सूचीबद्ध करता है, साथ ही ज्ञात सीमाओं पर नोट्स भी देता है। पहले जांचना बेहतर है, बजाय इसके कि आप 4GB की ब्रॉडकास्ट मास्टर फ़ाइल अपलोड करें और बाद में पाएं कि इसका विशिष्ट MXF फ्लेवर समर्थित नहीं है। मैजिक बाइट्स एक कंप्यूटर को बताते हैं कि एक फ़ाइल *क्या है*। वे यह नहीं बताते कि उस फ़ाइल को परिवर्तित करने से कुछ *उपयोगी* बनेगा या नहीं। यह दूसरा, अधिक महत्वपूर्ण प्रश्न अच्छे दस्तावेज़ीकरण, स्पष्ट लाइसेंसिंग और समर्पित इंजीनियरिंग कार्य पर निर्भर करता है जिसे किसी भी मात्रा में चतुर बाइट-स्निफिंग प्रतिस्थापित नहीं कर सकती है।