फ़ाइल फ़ारमैट: Difference between revisions
No edit summary |
|||
| Line 4: | Line 4: | ||
[[File:Boogie riff 1.ogg|thumb|ओग-फाइल: 154 किलोबाइट।]]'''फ़ाइल प्रारूप''' कंप्यूटर फ़ाइल में संग्रहीत जानकारी को कोड करने का एक मानक विधि होता है। यह निर्धारित करता है कि बिट कैसे [[ डिजिटल भंडारण | डिजिटल]] [[ डिजिटल भंडारण |संग्रहण]] माध्यम में जानकारी को कोड करने के लिए उपयोग होते हैं। फ़ाइल प्रारूप संपत्रित या मुक्त दोनों हो सकते हैं। कुछ फ़ाइल प्रारूप विशेष रूप से निर्दिष्ट प्रकार के डेटा के लिए प्रारूपित किए गए होते हैं: उदाहरण के लिए, [[पोर्टेबल नेटवर्क ग्राफ़िक्स]] फ़ाइल [[दोषरहित डेटा संपीड़न]] का उपयोग करके [[रेखापुंज ग्राफिक्स|लाइन ग्राफिक्स]] को संग्रहित करती हैं। | [[File:Boogie riff 1.ogg|thumb|ओग-फाइल: 154 किलोबाइट।]]'''फ़ाइल प्रारूप''' कंप्यूटर फ़ाइल में संग्रहीत जानकारी को कोड करने का एक मानक विधि होता है। यह निर्धारित करता है कि बिट कैसे [[ डिजिटल भंडारण | डिजिटल]] [[ डिजिटल भंडारण |संग्रहण]] माध्यम में जानकारी को कोड करने के लिए उपयोग होते हैं। फ़ाइल प्रारूप संपत्रित या मुक्त दोनों हो सकते हैं। कुछ फ़ाइल प्रारूप विशेष रूप से निर्दिष्ट प्रकार के डेटा के लिए प्रारूपित किए गए होते हैं: उदाहरण के लिए, [[पोर्टेबल नेटवर्क ग्राफ़िक्स]] फ़ाइल [[दोषरहित डेटा संपीड़न]] का उपयोग करके [[रेखापुंज ग्राफिक्स|लाइन ग्राफिक्स]] को संग्रहित करती हैं। | ||
यद्यपि, अन्य | यद्यपि, अन्य फ़ाइलप्रारूपों को विभिन्न प्रकार के डेटा के संग्रह के लिए प्रारूपित किए गए होते हैं,[[Ogg|ओजीजी]] प्रारूप विभिन्न प्रकार की मल्टीमीडिया के लिए एक कंटेनर के रूप में कार्य कर सकता है, जिसमें ऑडियो और वीडियो की किसी भी संयोजन, पाठ उदाहरण के लिए [[उपशीर्षक]] और मेटाडेटा, सम्मिलित हो सकते हैं। | ||
एक [[पाठ फ़ाइल]] में संभावित नियंत्रण वर्णों सहित वर्णों की कोई भी धारा हो सकती है, और विभिन्न [[अक्षरों को सांकेतिक अक्षरों में बदलना|अक्षरों को सांकेतिक अक्षरों में]] परिवर्तन में से एक में एन्कोड किया जाता है। कुछ फ़ाइल प्रारूप, जैसे कि [[HTML|एचटीएमएल]], [[स्केलेबल वेक्टर ग्राफिक्स]], और [[कंप्यूटर सॉफ्टवेयर]] का स्रोत कोड परिभाषित सिंटैक्स वाली टेक्स्ट फ़ाइलें हैं जो उन्हें विशिष्ट उद्देश्यों के लिए उपयोग करने की अनुमति देती हैं। | एक [[पाठ फ़ाइल]] में संभावित नियंत्रण वर्णों सहित वर्णों की कोई भी धारा हो सकती है, और विभिन्न [[अक्षरों को सांकेतिक अक्षरों में बदलना|अक्षरों को सांकेतिक अक्षरों में]] परिवर्तन में से एक में एन्कोड किया जाता है। कुछ फ़ाइल प्रारूप, जैसे कि [[HTML|एचटीएमएल]], [[स्केलेबल वेक्टर ग्राफिक्स]], और [[कंप्यूटर सॉफ्टवेयर]] का स्रोत कोड परिभाषित सिंटैक्स वाली टेक्स्ट फ़ाइलें हैं जो उन्हें विशिष्ट उद्देश्यों के लिए उपयोग करने की अनुमति देती हैं। | ||
== | == विशेष विवरण == | ||
फ़ाइल | फ़ाइल प्रारूपों में प्रायः एक प्रकाशित [[विनिर्देश]] होता है जो एन्कोडिंग विधि का वर्णन करता है और प्रोग्राम के इच्छित कार्यक्षमता के परीक्षण को सक्षम करता है। सभी प्रारूपों में स्वतंत्र रूप से विनिर्देश दस्तावेज़ उपलब्ध नहीं हैं, आंशिक रूप से क्योंकि कुछ डेवलपर्स अपने विनिर्देश दस्तावेज़ों को [[व्यापार रहस्य]] के रूप में देखते हैं, और आंशिक रूप से क्योंकि अन्य डेवलपर्स औपचारिक विनिर्देश दस्तावेज़ को कभी भी लेखक नहीं बनाते हैं, प्रारूप का उपयोग करने वाले अन्य पहले से उपलब्ध प्रोग्रामों द्वारा उदाहरण स्थापित करते हुए प्रारूप को परिभाषित करते हैं कि कैसे ये प्रोग्राम इसका उपयोग करते हैं। | ||
यदि किसी प्रारूप का डेवलपर मुक्त विनिर्देशों को प्रकाशित नहीं करता है, तो उस प्रकार की फ़ाइल का उपयोग करने के इच्छुक अन्य डेवलपर | यदि किसी प्रारूप का डेवलपर, मुक्त विनिर्देशों को प्रकाशित नहीं करता है, तो उस प्रकार की फ़ाइल का उपयोग करने के इच्छुक अन्य डेवलपर को [[रिवर्स इंजीनियरिंग|उत्क्रम]] अभियांत्रिकी का उपयोग करना होगा जिससे यह पता लगाया जा सके कि इसे कैसे पढ़ा जाए या प्रारूप के डेवलपर्स से शुल्क के लिए और हस्ताक्षर करके विनिर्देश दस्तावेज़ कैसे प्राप्त किया जाए। बाद वाला दृष्टिकोण तभी संभव है जब एक औपचारिक विनिर्देश दस्तावेज उपलब्ध हो। दोनों रणनीतियों के लिए महत्वपूर्ण समय, धन या दोनों की आवश्यकता होती है; इसलिए, सार्वजनिक रूप से उपलब्ध विनिर्देशों वाले फ़ाइल प्रारूपों को अधिक प्रोग्रामो द्वारा समर्थित किया जाता है। | ||
== [[पेटेंट]] == | == [[पेटेंट]] == | ||
[[कॉपीराइट]] के बजाय पेटेंट कानून का उपयोग | [[कॉपीराइट]] के बजाय पेटेंट कानून का उपयोग प्रायः फ़ाइल स्वरूप की सुरक्षा के लिए किया जाता है। हालांकि अमेरिकी कानून के तहत फ़ाइलप्रारूपों के पेटेंट की सीधे अनुमति नहीं है, कुछ प्रारूप पेटेंट किए गए एल्गोरिदम का उपयोग करके डेटा को एन्कोड करते हैं। उदाहरण के लिए, [[जीआईएफ]] फ़ाइल प्रारूप के साथ संपीड़न का उपयोग करने के लिए एक पेटेंट [[कलन विधि]] के उपयोग की आवश्यकता होती है, और हालांकि पेटेंट मालिक ने शुरू में अपने पेटेंट को लागू नहीं किया था, बाद में उन्होंने रॉयल्टी भुगतान एकत्र करना शुरू कर दिया। इसके परिणामस्वरूप जीआईएफ के उपयोग में उल्लेखनीय कमी आई है, और वैकल्पिक पोर्टेबल नेटवर्क ग्राफिक्स प्रारूप के विकास के लिए आंशिक रूप से जिम्मेदार है। हालाँकि, GIF पेटेंट अमेरिका में 2003 के मध्य में और दुनिया भर में 2004 के मध्य में समाप्त हो गया। | ||
== फ़ाइल प्रकार की पहचान करना == | == फ़ाइल प्रकार की पहचान करना == | ||
विभिन्न [[ऑपरेटिंग सिस्टम]] ने पारंपरिक रूप से एक विशेष फ़ाइल के प्रारूप को निर्धारित करने के लिए विभिन्न दृष्टिकोण अपनाए हैं, प्रत्येक दृष्टिकोण के अपने फायदे और नुकसान हैं। अधिकांश आधुनिक ऑपरेटिंग सिस्टम और व्यक्तिगत अनुप्रयोगों को विदेशी | विभिन्न [[ऑपरेटिंग सिस्टम]] ने पारंपरिक रूप से एक विशेष फ़ाइल के प्रारूप को निर्धारित करने के लिए विभिन्न दृष्टिकोण अपनाए हैं, प्रत्येक दृष्टिकोण के अपने फायदे और नुकसान हैं। अधिकांश आधुनिक ऑपरेटिंग सिस्टम और व्यक्तिगत अनुप्रयोगों को विदेशी फ़ाइलप्रारूपों को पढ़ने के लिए निम्नलिखित सभी दृष्टिकोणों का उपयोग करने की आवश्यकता होती है, यदि उनके साथ पूरी तरह से काम नहीं किया जाता है। | ||
=== फ़ाइल नाम एक्सटेंशन === | === फ़ाइल नाम एक्सटेंशन === | ||
| Line 23: | Line 23: | ||
[[Microsoft Windows]], [[macOS]], CP/M, DOS, [[OpenVMS]], और VM (ऑपरेटिंग सिस्टम) | VM/CMS सहित कई ऑपरेटिंग सिस्टम द्वारा उपयोग [[की]] जाने वाली एक लोकप्रिय विधि फ़ाइल के नाम के अंत के आधार पर उसके प्रारूप का निर्धारण करना है। अधिक विशेष रूप से अंतिम अवधि के बाद के अक्षर। फ़ाइल नाम के इस भाग को [[फ़ाइल नाम एक्सटेंशन]] के रूप में जाना जाता है। उदाहरण के लिए, HTML दस्तावेज़ों को उन नामों से पहचाना जाता है जिनके साथ समाप्त होता है {{Mono|.html}} (या {{Mono|.htm}}), और जीआईएफ छवियां {{Mono|.gif}}. मूल फ़ाइल आवंटन तालिका [[फाइल सिस्टम]] में, फ़ाइल नाम आठ-वर्ण पहचानकर्ता और तीन-वर्ण एक्सटेंशन तक सीमित थे, जिसे 8.3 फ़ाइल नाम के रूप में जाना जाता है। सीमित संख्या में तीन-अक्षर वाले एक्सटेंशन हैं, जो एक दिए गए एक्सटेंशन को एक से अधिक प्रोग्राम द्वारा उपयोग करने का कारण बन सकते हैं। कई प्रारूप अभी भी तीन-वर्ण एक्सटेंशन का उपयोग करते हैं, हालांकि आधुनिक ऑपरेटिंग सिस्टम और एप्लिकेशन प्रोग्राम में अब यह सीमा नहीं है। चूंकि एक्सटेंशन की कोई मानक सूची नहीं है, एक से अधिक प्रारूप एक ही एक्सटेंशन का उपयोग कर सकते हैं, जो ऑपरेटिंग सिस्टम और उपयोगकर्ता दोनों को भ्रमित कर सकता है। | [[Microsoft Windows]], [[macOS]], CP/M, DOS, [[OpenVMS]], और VM (ऑपरेटिंग सिस्टम) | VM/CMS सहित कई ऑपरेटिंग सिस्टम द्वारा उपयोग [[की]] जाने वाली एक लोकप्रिय विधि फ़ाइल के नाम के अंत के आधार पर उसके प्रारूप का निर्धारण करना है। अधिक विशेष रूप से अंतिम अवधि के बाद के अक्षर। फ़ाइल नाम के इस भाग को [[फ़ाइल नाम एक्सटेंशन]] के रूप में जाना जाता है। उदाहरण के लिए, HTML दस्तावेज़ों को उन नामों से पहचाना जाता है जिनके साथ समाप्त होता है {{Mono|.html}} (या {{Mono|.htm}}), और जीआईएफ छवियां {{Mono|.gif}}. मूल फ़ाइल आवंटन तालिका [[फाइल सिस्टम]] में, फ़ाइल नाम आठ-वर्ण पहचानकर्ता और तीन-वर्ण एक्सटेंशन तक सीमित थे, जिसे 8.3 फ़ाइल नाम के रूप में जाना जाता है। सीमित संख्या में तीन-अक्षर वाले एक्सटेंशन हैं, जो एक दिए गए एक्सटेंशन को एक से अधिक प्रोग्राम द्वारा उपयोग करने का कारण बन सकते हैं। कई प्रारूप अभी भी तीन-वर्ण एक्सटेंशन का उपयोग करते हैं, हालांकि आधुनिक ऑपरेटिंग सिस्टम और एप्लिकेशन प्रोग्राम में अब यह सीमा नहीं है। चूंकि एक्सटेंशन की कोई मानक सूची नहीं है, एक से अधिक प्रारूप एक ही एक्सटेंशन का उपयोग कर सकते हैं, जो ऑपरेटिंग सिस्टम और उपयोगकर्ता दोनों को भ्रमित कर सकता है। | ||
इस दृष्टिकोण का एक आर्टिफैक्ट यह है कि सिस्टम को आसानी से एक फ़ाइल को एक अलग प्रारूप के रूप में नाम देकर आसानी से धोखा दिया जा सकता है - उदाहरण के लिए, एक HTML फ़ाइल को आसानी से [[सादे पाठ]] के रूप में माना जा सकता है। {{Mono|filename.html}} को {{Mono|filename.txt}}. यद्यपि यह रणनीति विशेषज्ञ उपयोगकर्ताओं के लिए उपयोगी थी जो इस जानकारी को आसानी से समझ और हेरफेर कर सकते थे, यह | इस दृष्टिकोण का एक आर्टिफैक्ट यह है कि सिस्टम को आसानी से एक फ़ाइल को एक अलग प्रारूप के रूप में नाम देकर आसानी से धोखा दिया जा सकता है - उदाहरण के लिए, एक HTML फ़ाइल को आसानी से [[सादे पाठ]] के रूप में माना जा सकता है। {{Mono|filename.html}} को {{Mono|filename.txt}}. यद्यपि यह रणनीति विशेषज्ञ उपयोगकर्ताओं के लिए उपयोगी थी जो इस जानकारी को आसानी से समझ और हेरफेर कर सकते थे, यह प्रायः कम तकनीकी उपयोगकर्ताओं के लिए भ्रमित करने वाला था, जो गलती से फ़ाइल को अनुपयोगी बना सकते थे (या इसे खो सकते थे) इसे गलत तरीके से नाम देकर। | ||
इसने विंडोज़ और मैक ओएस के अधिकांश संस्करणों को फाइलों को सूचीबद्ध करते समय एक्सटेंशन को छिपाने का नेतृत्व किया। यह उपयोगकर्ता को गलती से फ़ाइल प्रकार बदलने से रोकता है, और विशेषज्ञ उपयोगकर्ताओं को इस सुविधा को बंद करने और एक्सटेंशन प्रदर्शित करने की अनुमति देता है। | इसने विंडोज़ और मैक ओएस के अधिकांश संस्करणों को फाइलों को सूचीबद्ध करते समय एक्सटेंशन को छिपाने का नेतृत्व किया। यह उपयोगकर्ता को गलती से फ़ाइल प्रकार बदलने से रोकता है, और विशेषज्ञ उपयोगकर्ताओं को इस सुविधा को बंद करने और एक्सटेंशन प्रदर्शित करने की अनुमति देता है। | ||
| Line 35: | Line 35: | ||
==== फाइल हेडर ==== | ==== फाइल हेडर ==== | ||
[[हेडर (कंप्यूटिंग)]] में निहित मेटाडेटा आमतौर पर फ़ाइल की शुरुआत में संग्रहीत होते हैं, लेकिन अन्य क्षेत्रों में भी | [[हेडर (कंप्यूटिंग)]] में निहित मेटाडेटा आमतौर पर फ़ाइल की शुरुआत में संग्रहीत होते हैं, लेकिन अन्य क्षेत्रों में भी उपलब्ध हो सकते हैं, प्रायः अंत सहित, फ़ाइल प्रारूप या डेटा के प्रकार के आधार पर। कैरेक्टर-आधारित (टेक्स्ट) फाइलों में आमतौर पर कैरेक्टर-आधारित हेडर होते हैं, जबकि बाइनरी फॉर्मेट में आमतौर पर बाइनरी हेडर होते हैं, हालांकि यह कोई नियम नहीं है। टेक्स्ट-आधारित फ़ाइल हेडर आमतौर पर अधिक स्थान लेते हैं, लेकिन मानव-पठनीय होने के कारण, उन्हें टेक्स्ट एडिटर या हेक्साडेसिमल एडिटर जैसे सरल सॉफ़्टवेयर का उपयोग करके आसानी से जांचा जा सकता है। | ||
फ़ाइल प्रारूप की पहचान करने के साथ-साथ फ़ाइल हेडर में फ़ाइल और उसकी सामग्री के बारे में मेटाडेटा हो सकता है। उदाहरण के लिए, अधिकांश छवि फ़ाइल प्रारूप छवि प्रारूप, आकार, रिज़ॉल्यूशन और रंग स्थान के बारे में जानकारी संग्रहीत करते हैं, और वैकल्पिक रूप से जानकारी को संलेखित करते हैं जैसे कि छवि किसने बनाई, कब और कहाँ बनाई गई, कौन सा कैमरा मॉडल और | फ़ाइल प्रारूप की पहचान करने के साथ-साथ फ़ाइल हेडर में फ़ाइल और उसकी सामग्री के बारे में मेटाडेटा हो सकता है। उदाहरण के लिए, अधिकांश छवि फ़ाइल प्रारूप छवि प्रारूप, आकार, रिज़ॉल्यूशन और रंग स्थान के बारे में जानकारी संग्रहीत करते हैं, और वैकल्पिक रूप से जानकारी को संलेखित करते हैं जैसे कि छवि किसने बनाई, कब और कहाँ बनाई गई, कौन सा कैमरा मॉडल और फोटोग्राफिकस्थापित िंग्स का उपयोग किया गया ([[Exif]]), और इसी तरह। इस तरह के मेटाडेटा का उपयोग सॉफ्टवेयर द्वारा लोडिंग प्रक्रिया के दौरान और बाद में फाइल को पढ़ने या व्याख्या करने के लिए किया जा सकता है। | ||
फाइल हेडर का उपयोग एक ऑपरेटिंग सिस्टम द्वारा मेमोरी में लोड किए बिना फ़ाइल के बारे में जानकारी को जल्दी से इकट्ठा करने के लिए किया जा सकता है, लेकिन ऐसा करने से कंप्यूटर के संसाधनों का अधिक उपयोग फाइल सिस्टम # निर्देशिकाओं की जानकारी से सीधे पढ़ने की तुलना में होता है। उदाहरण के लिए, जब एक [[ग्राफिकल यूज़र इंटरफ़ेस]] फ़ाइल प्रबंधक को किसी फ़ोल्डर की सामग्री को प्रदर्शित करना होता है, तो उसे उचित आइकन प्रदर्शित करने से पहले कई फ़ाइलों के शीर्षलेखों को पढ़ना चाहिए, लेकिन ये भंडारण माध्यम पर विभिन्न जगहों पर स्थित होंगे, इस प्रकार अधिक समय लगेगा उपयोग करने के लिए। [[थंबनेल]] जानकारी जैसे जटिल मेटाडेटा वाली कई फ़ाइलों वाले फ़ोल्डर को प्रदर्शित होने से पहले काफी समय लग सकता है। | फाइल हेडर का उपयोग एक ऑपरेटिंग सिस्टम द्वारा मेमोरी में लोड किए बिना फ़ाइल के बारे में जानकारी को जल्दी से इकट्ठा करने के लिए किया जा सकता है, लेकिन ऐसा करने से कंप्यूटर के संसाधनों का अधिक उपयोग फाइल सिस्टम # निर्देशिकाओं की जानकारी से सीधे पढ़ने की तुलना में होता है। उदाहरण के लिए, जब एक [[ग्राफिकल यूज़र इंटरफ़ेस]] फ़ाइल प्रबंधक को किसी फ़ोल्डर की सामग्री को प्रदर्शित करना होता है, तो उसे उचित आइकन प्रदर्शित करने से पहले कई फ़ाइलों के शीर्षलेखों को पढ़ना चाहिए, लेकिन ये भंडारण माध्यम पर विभिन्न जगहों पर स्थित होंगे, इस प्रकार अधिक समय लगेगा उपयोग करने के लिए। [[थंबनेल]] जानकारी जैसे जटिल मेटाडेटा वाली कई फ़ाइलों वाले फ़ोल्डर को प्रदर्शित होने से पहले काफी समय लग सकता है। | ||
| Line 43: | Line 43: | ||
यदि हेडर [[ कठिन कोडिंग ]] | बाइनरी हार्ड-कोडेड है जैसे कि हेडर को पहचानने के लिए जटिल व्याख्या की आवश्यकता होती है, विशेष रूप से मेटाडेटा सामग्री सुरक्षा के लिए, एक जोखिम है कि फ़ाइल प्रारूप की गलत व्याख्या की जा सकती है। यह स्रोत पर बुरी तरह लिखा भी हो सकता है। इसके परिणामस्वरूप दूषित मेटाडेटा हो सकता है, जो बेहद खराब मामलों में फ़ाइल को अपठनीय भी बना सकता है।{{clarify|reason=Hard-coding or not does not seem relevant. Coding meant to protect metadata corruption should not make it easier. The issue is probably about complex coding and insufficient standardisation|date=January 2014}} | यदि हेडर [[ कठिन कोडिंग ]] | बाइनरी हार्ड-कोडेड है जैसे कि हेडर को पहचानने के लिए जटिल व्याख्या की आवश्यकता होती है, विशेष रूप से मेटाडेटा सामग्री सुरक्षा के लिए, एक जोखिम है कि फ़ाइल प्रारूप की गलत व्याख्या की जा सकती है। यह स्रोत पर बुरी तरह लिखा भी हो सकता है। इसके परिणामस्वरूप दूषित मेटाडेटा हो सकता है, जो बेहद खराब मामलों में फ़ाइल को अपठनीय भी बना सकता है।{{clarify|reason=Hard-coding or not does not seem relevant. Coding meant to protect metadata corruption should not make it easier. The issue is probably about complex coding and insufficient standardisation|date=January 2014}} | ||
फ़ाइल शीर्षलेखों का एक अधिक जटिल उदाहरण वे हैं जो [[डिजिटल कंटेनर प्रारूप]] (या कंटेनर) | फ़ाइल शीर्षलेखों का एक अधिक जटिल उदाहरण वे हैं जो [[डिजिटल कंटेनर प्रारूप]] (या कंटेनर) फ़ाइलप्रारूपों के लिए उपयोग किए जाते हैं। | ||
==== मैजिक नंबर ==== <!-- Courtesy note per [[MOS:LINK2SECT]]: [[Magic number (programming)]] links here. --> | ==== मैजिक नंबर ==== <!-- Courtesy note per [[MOS:LINK2SECT]]: [[Magic number (programming)]] links here. --> | ||
{{See also|Magic number (programming)#In files}} | {{See also|Magic number (programming)#In files}} | ||
फ़ाइल प्रकार मेटाडेटा को शामिल करने का एक तरीका, जो | फ़ाइल प्रकार मेटाडेटा को शामिल करने का एक तरीका, जो प्रायः [[यूनिक्स]] और इसके डेरिवेटिव से जुड़ा होता है, फ़ाइल के अंदर एक जादुई संख्या को स्टोर करना है। मूल रूप से, इस शब्द का उपयोग फ़ाइलों की शुरुआत में 2-बाइट पहचानकर्ताओं के एक विशिष्टस्थापित के लिए किया गया था, लेकिन चूंकि किसी भी बाइनरी अनुक्रम को एक संख्या के रूप में माना जा सकता है, फ़ाइल प्रारूप की कोई भी विशेषता जो इसे विशिष्ट रूप से अलग करती है, पहचान के लिए उपयोग की जा सकती है। उदाहरण के लिए, GIF छवियां हमेशा [[ASCII]] प्रतिनिधित्व के साथ शुरू होती हैं {{Mono|GIF87a}} या {{Mono|GIF89a}}, उस मानक पर निर्भर करता है जिसका वे पालन करते हैं। कई फ़ाइल प्रकार, विशेष रूप से सादे-पाठ फ़ाइलें, इस पद्धति से स्पॉट करना कठिन हैं। उदाहरण के लिए, HTML फ़ाइलें स्ट्रिंग से शुरू हो सकती हैं {{Mono|<html>}} (जो केस सेंसिटिव नहीं है), या उपयुक्त दस्तावेज़ प्रकार की परिभाषा जो इससे शुरू होती है {{Mono|<!DOCTYPE HTML>}}, या, [[XHTML]] के लिए, [[XML]] पहचानकर्ता, जो से शुरू होता है {{Mono|<?xml}}. फ़ाइलें HTML टिप्पणियों, यादृच्छिक पाठ या कई खाली पंक्तियों के साथ भी शुरू हो सकती हैं, लेकिन फिर भी प्रयोग करने योग्य HTML हो सकती हैं। | ||
जादू संख्या दृष्टिकोण बेहतर गारंटी प्रदान करता है कि प्रारूप सही ढंग से पहचाना जाएगा, और | जादू संख्या दृष्टिकोण बेहतर गारंटी प्रदान करता है कि प्रारूप सही ढंग से पहचाना जाएगा, और प्रायः फ़ाइल के बारे में अधिक सटीक जानकारी निर्धारित कर सकता है। चूंकि यथोचित रूप से विश्वसनीय जादुई संख्या परीक्षण काफी जटिल हो सकते हैं, और प्रत्येक फ़ाइल को जादू डेटाबेस में हर संभावना के खिलाफ प्रभावी ढंग से परीक्षण किया जाना चाहिए, यह दृष्टिकोण अपेक्षाकृत अक्षम है, विशेष रूप से फाइलों की बड़ी सूची प्रदर्शित करने के लिए (इसके विपरीत, फ़ाइल नाम और मेटाडेटा-आधारित विधियां) डेटा के केवल एक टुकड़े की जांच करने की आवश्यकता है, और इसे सॉर्ट किए गए इंडेक्स के विरुद्ध मिलान करें)। साथ ही, डेटा को फ़ाइल से ही पढ़ा जाना चाहिए, निर्देशिका में संग्रहीत मेटाडेटा के विपरीत विलंबता बढ़ाना। जहां फ़ाइल प्रकार इस तरह से खुद को पहचानने के लिए उधार नहीं देते हैं, सिस्टम को मेटाडेटा पर वापस आना चाहिए। हालाँकि, किसी प्रोग्राम के लिए यह जाँचने का सबसे अच्छा तरीका है कि जिस फ़ाइल को संसाधित करने के लिए कहा गया है वह सही प्रारूप की है: जबकि फ़ाइल का नाम या मेटाडेटा इसकी सामग्री से स्वतंत्र रूप से बदला जा सकता है, एक अच्छी तरह से प्रारूपित किए गए जादू संख्या परीक्षण में विफल एक निश्चित संकेत है कि फ़ाइल या तो दूषित है या गलत प्रकार की है। दूसरी ओर, एक मान्य मैजिक नंबर इस बात की गारंटी नहीं देता है कि फ़ाइल दूषित नहीं है या सही प्रकार की है। | ||
स्क्रिप्टिंग भाषा में तथाकथित शेबैंग (यूनिक्स) पंक्तियाँ जादुई संख्याओं का एक विशेष मामला है। यहां, जादू संख्या मानव-पठनीय पाठ है जो एक विशिष्ट [[दुभाषिया (कंप्यूटिंग)]] और कमांड दुभाषिया को पास किए जाने वाले विकल्पों की पहचान करता है। | स्क्रिप्टिंग भाषा में तथाकथित शेबैंग (यूनिक्स) पंक्तियाँ जादुई संख्याओं का एक विशेष मामला है। यहां, जादू संख्या मानव-पठनीय पाठ है जो एक विशिष्ट [[दुभाषिया (कंप्यूटिंग)]] और कमांड दुभाषिया को पास किए जाने वाले विकल्पों की पहचान करता है। | ||
मैजिक नंबरों का उपयोग करने वाला एक अन्य ऑपरेटिंग सिस्टम [[AmigaOS]] है, जहां मैजिक नंबरों को मैजिक कुकीज़ कहा जाता था और [[ दोस्त हंक ]] निष्पादन योग्य फ़ाइल प्रारूप में निष्पादनयोग्य को पहचानने के लिए एक मानक प्रणाली के रूप में अपनाया गया था और एकल | मैजिक नंबरों का उपयोग करने वाला एक अन्य ऑपरेटिंग सिस्टम [[AmigaOS]] है, जहां मैजिक नंबरों को मैजिक कुकीज़ कहा जाता था और [[ दोस्त हंक ]] निष्पादन योग्य फ़ाइल प्रारूप में निष्पादनयोग्य को पहचानने के लिए एक मानक प्रणाली के रूप में अपनाया गया था और एकल प्रोग्राम ों, उपकरणों और उपयोगिताओं को उनकी सहेजी गई डेटा फ़ाइलों के साथ स्वचालित रूप से निपटने के लिए भी दिया गया था। या डेटा सहेजते और लोड करते समय किसी अन्य प्रकार की फ़ाइल प्रकार। इस सिस्टम को तब Amiga सपोर्ट और मेंटेनेंस सॉफ्टवेयर#डेटाटाइप्स रिकग्निशन सिस्टम के साथ बढ़ाया गया था। एक अन्य विधि [[फोरसीसी]] विधि थी, जो मैकिंटोश पर [[ओएस टाइप]] में उत्पन्न हुई थी, जिसे बाद में [[ इंटरचेंज फ़ाइल स्वरूप ]] (आईएफएफ) और डेरिवेटिव द्वारा अनुकूलित किया गया था। | ||
=== बाहरी मेटाडेटा === | === बाहरी मेटाडेटा === | ||
| Line 63: | Line 63: | ||
==== मैक ओएस टाइप-कोड ==== | ==== मैक ओएस टाइप-कोड ==== | ||
Macintosh ऑपरेटिंग सिस्टम '[[पदानुक्रमित फ़ाइल सिस्टम (Apple)]] प्रत्येक फ़ाइल के लिए निर्देशिका प्रविष्टि के भाग के रूप में [[निर्माता कोड]] और [[ कोड टाइप करें ]] के लिए कोड संग्रहीत करता है। इन कोड को OSTypes कहा जाता है। ये कोड कोई भी 4-बाइट अनुक्रम हो सकते हैं लेकिन | Macintosh ऑपरेटिंग सिस्टम '[[पदानुक्रमित फ़ाइल सिस्टम (Apple)]] प्रत्येक फ़ाइल के लिए निर्देशिका प्रविष्टि के भाग के रूप में [[निर्माता कोड]] और [[ कोड टाइप करें ]] के लिए कोड संग्रहीत करता है। इन कोड को OSTypes कहा जाता है। ये कोड कोई भी 4-बाइट अनुक्रम हो सकते हैं लेकिन प्रायः चुने जाते थे ताकि ASCII प्रतिनिधित्व अर्थपूर्ण वर्णों का अनुक्रम बना सके, जैसे कि एप्लिकेशन के नाम का संक्षिप्त नाम या डेवलपर के आद्याक्षर। उदाहरण के लिए एक [[ हाइपर कार्ड ]] स्टैक फ़ाइल का निर्माता होता है {{Mono|WILD}} (हाइपरकार्ड के पिछले नाम, वाइल्डकार्ड से) और एक प्रकार का {{Mono|STAK}}. [[BBEdit]] टेक्स्ट एडिटर का क्रिएटर कोड होता है {{code|R*ch}} अपने मूल प्रोग्रामर, [[ समृद्ध मुहर ]] का जिक्र करते हुए। प्रकार कोड फ़ाइल के प्रारूप को निर्दिष्ट करता है, जबकि निर्माता कोड उपयोगकर्ता द्वारा डबल-क्लिक करने पर इसे खोलने के लिए डिफ़ॉल्ट प्रोग्राम निर्दिष्ट करता है। उदाहरण के लिए, उपयोगकर्ता के पास टाइप कोड के साथ कई टेक्स्ट फाइलें हो सकती हैं {{Mono|TEXT}}, लेकिन विभिन्न निर्माता कोड होने के कारण प्रत्येक एक अलग प्रोग्राम में खुलता है। इस सुविधा का उद्देश्य था, उदाहरण के लिए, मानव-पठनीय सादा-पाठ फ़ाइलें सामान्य-उद्देश्य वाले पाठ संपादक में खोली जा सकती हैं, जबकि प्रोग्रामिंग या HTML कोड फ़ाइलें एक विशेष संपादक या एकीकृत विकास वातावरण में खुलती हैं। हालांकि, यह सुविधा प्रायः उपयोगकर्ता भ्रम का स्रोत थी, क्योंकि फाइलों पर डबल-क्लिक करने पर कौन सा प्रोग्राम लॉन्च होगा, यह प्रायः अप्रत्याशित होता था। [[ जोखिम ]] एक समान प्रणाली का उपयोग करता है, जिसमें 12-बिट संख्या शामिल होती है जिसे विवरण तालिका में देखा जा सकता है- उदा। [[हेक्साडेसिमल]] संख्या {{code|FF5}} का उपनाम है {{Mono|PoScript}}, [[ परिशिष्ट भाग ]] फ़ाइल का प्रतिनिधित्व करता है। | ||
==== macOS यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI) ==== | ==== macOS यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI) ==== | ||
{{main|Uniform Type Identifier}} | {{main|Uniform Type Identifier}} | ||
यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI) एक ऐसी विधि है जिसका उपयोग macOS में विशिष्ट रूप से टाइप की गई संस्थाओं की श्रेणियों, जैसे | यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI) एक ऐसी विधि है जिसका उपयोग macOS में विशिष्ट रूप से टाइप की गई संस्थाओं की श्रेणियों, जैसे फ़ाइलप्रारूपों की पहचान के लिए किया जाता है। इसे Apple Inc. द्वारा OSType (प्रकार और निर्माता कोड) के प्रतिस्थापन के रूप में विकसित किया गया था। | ||
यूटीआई एक [[कोर फाउंडेशन]] [[ स्ट्रिंग (कंप्यूटर विज्ञान) ]] है, जो [[ रिवर्स डीएनएस ]] स्ट्रिंग का उपयोग करता है। कुछ सामान्य और मानक प्रकार एक डोमेन का उपयोग करते हैं जिसे कहा जाता है {{Mono|public}} (उदा {{Mono|public.png}} पोर्टेबल नेटवर्क ग्राफ़िक्स छवि के लिए), जबकि अन्य डोमेन तृतीय-पक्ष प्रकारों के लिए उपयोग किए जा सकते हैं (उदा. {{Mono|com.adobe.pdf}} पोर्टेबल दस्तावेज़ स्वरूप के लिए)। यूटीआई को एक पदानुक्रमित संरचना के भीतर परिभाषित किया जा सकता है, जिसे अनुरूपता पदानुक्रम के रूप में जाना जाता है। इस प्रकार, {{Mono|public.png}} के सुपरटाइप के अनुरूप है {{Mono|public.image}}, जो स्वयं के सुपरटाइप के अनुरूप है {{Mono|public.data}}. एक यूटीआई कई पदानुक्रमों में | यूटीआई एक [[कोर फाउंडेशन]] [[ स्ट्रिंग (कंप्यूटर विज्ञान) ]] है, जो [[ रिवर्स डीएनएस ]] स्ट्रिंग का उपयोग करता है। कुछ सामान्य और मानक प्रकार एक डोमेन का उपयोग करते हैं जिसे कहा जाता है {{Mono|public}} (उदा {{Mono|public.png}} पोर्टेबल नेटवर्क ग्राफ़िक्स छवि के लिए), जबकि अन्य डोमेन तृतीय-पक्ष प्रकारों के लिए उपयोग किए जा सकते हैं (उदा. {{Mono|com.adobe.pdf}} पोर्टेबल दस्तावेज़ स्वरूप के लिए)। यूटीआई को एक पदानुक्रमित संरचना के भीतर परिभाषित किया जा सकता है, जिसे अनुरूपता पदानुक्रम के रूप में जाना जाता है। इस प्रकार, {{Mono|public.png}} के सुपरटाइप के अनुरूप है {{Mono|public.image}}, जो स्वयं के सुपरटाइप के अनुरूप है {{Mono|public.data}}. एक यूटीआई कई पदानुक्रमों में उपलब्ध हो सकता है, जो बहुत अधिक लचीलापन प्रदान करता है। | ||
फ़ाइलप्रारूपों के अलावा, UTI का उपयोग अन्य संस्थाओं के लिए भी किया जा सकता है जो macOS में उपलब्ध हो सकती हैं, जिनमें शामिल हैं: | |||
* पेस्टबोर्ड डेटा | * पेस्टबोर्ड डेटा | ||
* [[निर्देशिका (कंप्यूटिंग)]] (निर्देशिका) | * [[निर्देशिका (कंप्यूटिंग)]] (निर्देशिका) | ||
| Line 83: | Line 83: | ||
IBM OS/VS में z/OS के माध्यम से, VSAM कैटलॉग | IBM OS/VS में z/OS के माध्यम से, VSAM कैटलॉग | ||
(डाटा फैसिलिटी स्टोरेज मैनेजमेंट सबसिस्टम (MVS)#ICF कैटलॉग से पहले) | (डाटा फैसिलिटी स्टोरेज मैनेजमेंट सबसिस्टम (MVS)#ICF कैटलॉग से पहले) | ||
और वीएसएएम वॉल्यूम | और वीएसएएम वॉल्यूम डेटास्थापित (वीवीडीएस) में वीएसएएम वॉल्यूम रिकॉर्ड (आईसीएफ कैटलॉग के साथ) प्रकार की पहचान करता है | ||
वीएसएएम डेटासेट का। | वीएसएएम डेटासेट का। | ||
====वीटीसी==== | ====वीटीसी==== | ||
IBM OS/360 में z/OS के माध्यम से, एक प्रारूप 1 या 7 वॉल्यूम सामग्री की तालिका# | IBM OS/360 में z/OS के माध्यम से, एक प्रारूप 1 या 7 वॉल्यूम सामग्री की तालिका#डेटास्थापित कंट्रोल ब्लॉक प्रकार (DSCB) सामग्री की वॉल्यूम तालिका (VTOC) में पहचान करता है | ||
इसके द्वारा वर्णित डेटासेट का डेटासेट संगठन ([[DSORG]])। | इसके द्वारा वर्णित डेटासेट का डेटासेट संगठन ([[DSORG]])। | ||
==== OS/2 विस्तारित विशेषताएँ ==== | ==== OS/2 विस्तारित विशेषताएँ ==== | ||
उच्च प्रदर्शन फाइल सिस्टम, FAT12, और FAT16 (लेकिन FAT32 नहीं) फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देता है। इनमें एक नाम के साथ ट्रिपलेट का | उच्च प्रदर्शन फाइल सिस्टम, FAT12, और FAT16 (लेकिन FAT32 नहीं) फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देता है। इनमें एक नाम के साथ ट्रिपलेट का मनमानास्थापित , मान के लिए एक कोडित प्रकार और एक मान शामिल है, जहां नाम अद्वितीय हैं और मान 64 KB तक लंबा हो सकता है। कुछ प्रकार और नामों के लिए मानकीकृत अर्थ हैं (OS/2 के तहत)। ऐसा ही एक है कि फ़ाइल प्रकार निर्धारित करने के लिए .TYPE विस्तारित विशेषता का उपयोग किया जाता है। इसके मान में फ़ाइल से जुड़े एक या अधिक फ़ाइल प्रकारों की सूची शामिल होती है, जिनमें से प्रत्येक एक स्ट्रिंग है, जैसे कि सादा पाठ या HTML दस्तावेज़। इस प्रकार एक फ़ाइल कई प्रकार की हो सकती है। | ||
[[NTFS]] फाइल सिस्टम OS/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, लेकिन यह सुविधा केवल OS/2 सबसिस्टम (XP में | [[NTFS]] फाइल सिस्टम OS/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, लेकिन यह सुविधा केवल OS/2 सबसिस्टम (XP में उपलब्ध नहीं) का समर्थन करने के लिए उपलब्ध है, इसलिए Win32 सबसिस्टम इस जानकारी को एक अपारदर्शी के रूप में मानता है। डेटा का ब्लॉक और इसका उपयोग नहीं करता है। इसके बजाय, यह Win32-विशिष्टप्रारूपों में मेटा-सूचना को संग्रहीत करने के लिए अन्य फ़ाइल फोर्क्स पर निर्भर करता है। OS/2 विस्तारित विशेषताओं को अभी भी Win32 प्रोग्राम द्वारा पढ़ा और लिखा जा सकता है, लेकिन डेटा को एप्लिकेशन द्वारा पूरी तरह से पार्स किया जाना चाहिए। | ||
==== POSIX [[विस्तार]]ित विशेषताएँ ==== | ==== POSIX [[विस्तार]]ित विशेषताएँ ==== | ||
| Line 99: | Line 99: | ||
==== PRONOM अद्वितीय पहचानकर्ता (PUIDs) ==== | ==== PRONOM अद्वितीय पहचानकर्ता (PUIDs) ==== | ||
[[PRONOM तकनीकी रजिस्ट्री]] #PRONOM परसिस्टेंट यूनीक आइडेंटिफ़ायर (PUID) योजना| PRONOM पर्सिस्टेंट यूनिक आइडेंटिफ़ायर (PUID) | [[PRONOM तकनीकी रजिस्ट्री]] #PRONOM परसिस्टेंट यूनीक आइडेंटिफ़ायर (PUID) योजना| PRONOM पर्सिस्टेंट यूनिक आइडेंटिफ़ायर (PUID) फ़ाइलप्रारूपों के लिए लगातार, अद्वितीय और स्पष्ट पहचानकर्ताओं की एक एक्स्टेंसिबल योजना है, जिसे [[राष्ट्रीय अभिलेखागार (यूके)]] द्वारा विकसित किया गया है इसकी PRONOM तकनीकी रजिस्ट्री सेवा का हिस्सा है। पीयूआईडी को उपयोग करके [[यूनिफॉर्म रिसोर्स पहचानकर्ता]] के रूप में व्यक्त किया जा सकता है {{Mono|info:pronom/}} नामस्थान। हालांकि यूके सरकार और कुछ [[डिजिटल संरक्षण]] प्रोग्राम ों के बाहर अभी तक व्यापक रूप से उपयोग नहीं किया गया है, पीयूआईडी योजना अधिकांश वैकल्पिक योजनाओं की तुलना में अधिक ग्रैन्युलैरिटी प्रदान करती है। | ||
==== [[माइम]] प्रकार ==== | ==== [[माइम]] प्रकार ==== | ||
| Line 107: | Line 107: | ||
==== फ़ाइल स्वरूप पहचानकर्ता (FFIDs) ==== | ==== फ़ाइल स्वरूप पहचानकर्ता (FFIDs) ==== | ||
फ़ाइल प्रारूप पहचानकर्ता एक अन्य, व्यापक रूप से उपयोग नहीं किया जाने वाला तरीका है जो | फ़ाइल प्रारूप पहचानकर्ता एक अन्य, व्यापक रूप से उपयोग नहीं किया जाने वाला तरीका है जो फ़ाइलप्रारूपों को उनके मूल और उनकी फ़ाइल श्रेणी के अनुसार पहचानने के लिए उपयोग किया जाता है। इसे सॉफ्टवेयर के डिस्क्रिप्शन एक्सप्लोरर सूट के लिए बनाया गया था। यह फॉर्म के कई अंकों से बना होता है {{code|NNNNNNNNN-XX-YYYYYYY}}. पहला भाग संगठन के मूल/रखरखाव को इंगित करता है (यह संख्या कंपनी/मानक संगठन डेटाबेस में एक मान का प्रतिनिधित्व करती है), और बाद के 2 अंक हेक्साडेसिमल में फ़ाइल के प्रकार को वर्गीकृत करते हैं। अंतिम भाग फ़ाइल के सामान्य फ़ाइल नाम एक्सटेंशन या फ़ाइल की अंतर्राष्ट्रीय मानक संख्या से बना है, जो शून्य के साथ गद्देदार है। उदाहरण के लिए, PNG फ़ाइल विनिर्देशन का FFID है {{code|000000001-31-0015948}} कहाँ {{code|31}} एक छवि फ़ाइल इंगित करता है, {{code|0015948}} मानक संख्या है और {{code|000000001}} मानकीकरण के लिए अंतर्राष्ट्रीय संगठन (आईएसओ) को इंगित करता है। | ||
==== फ़ाइल सामग्री आधारित प्रारूप पहचान ==== | ==== फ़ाइल सामग्री आधारित प्रारूप पहचान ==== | ||
फ़ाइल स्वरूप की पहचान करने का एक और कम लोकप्रिय तरीका फ़ाइल प्रकारों के बीच विभिन्न पैटर्न के लिए फ़ाइल सामग्री की जांच करना है। एक फ़ाइल की सामग्री बाइट्स का एक क्रम है और एक बाइट में 256 अद्वितीय क्रमपरिवर्तन (0-255) हैं। इस प्रकार, बाइट पैटर्न की घटना की गणना करना जिसे | फ़ाइल स्वरूप की पहचान करने का एक और कम लोकप्रिय तरीका फ़ाइल प्रकारों के बीच विभिन्न पैटर्न के लिए फ़ाइल सामग्री की जांच करना है। एक फ़ाइल की सामग्री बाइट्स का एक क्रम है और एक बाइट में 256 अद्वितीय क्रमपरिवर्तन (0-255) हैं। इस प्रकार, बाइट पैटर्न की घटना की गणना करना जिसे प्रायः बाइट आवृत्ति वितरण के रूप में संदर्भित किया जाता है, फ़ाइल प्रकारों की पहचान करने के लिए विभिन्न पैटर्न देता है। कई सामग्री-आधारित फ़ाइल प्रकार पहचान योजनाएँ हैं जो फ़ाइल प्रकार के लिए प्रतिनिधि मॉडल बनाने के लिए बाइट आवृत्ति वितरण का उपयोग करती हैं और फ़ाइल प्रकारों की पहचान करने के लिए किसी भी सांख्यिकीय और डेटा माइनिंग तकनीकों का उपयोग करती हैं।<ref>{{cite web| | ||
url=http://www.forensicswiki.org/wiki/File_Format_Identification| | url=http://www.forensicswiki.org/wiki/File_Format_Identification| | ||
title=File Format Identification| | title=File Format Identification| | ||
| Line 123: | Line 123: | ||
=== असंरचित प्रारूप (कच्ची मेमोरी डंप) === | === असंरचित प्रारूप (कच्ची मेमोरी डंप) === | ||
पहले के | पहले के फ़ाइलप्रारूपों में कच्चे डेटाप्रारूपों का उपयोग किया जाता था जिसमें फ़ाइल में एक या अधिक संरचनाओं की मेमोरी छवियों को सीधे डंप करना शामिल था। | ||
इसमें कई कमियां हैं। जब तक मेमोरी छवियों में भविष्य के एक्सटेंशन के लिए आरक्षित स्थान नहीं होते हैं, तब तक इस प्रकार की संरचित फ़ाइल का विस्तार और सुधार करना बहुत मुश्किल होता है। यह ऐसी फ़ाइलें भी बनाता है जो एक प्लेटफ़ॉर्म या प्रोग्रामिंग भाषा के लिए विशिष्ट हो सकती हैं (उदाहरण के लिए [[पास्कल (प्रोग्रामिंग भाषा)]] स्ट्रिंग वाली संरचना को [[सी (प्रोग्रामिंग भाषा)]] में पहचाना नहीं जाता है)। दूसरी ओर, इस प्रकार की फाइलों को पढ़ने और लिखने के लिए उपकरण विकसित करना बहुत आसान है। | इसमें कई कमियां हैं। जब तक मेमोरी छवियों में भविष्य के एक्सटेंशन के लिए आरक्षित स्थान नहीं होते हैं, तब तक इस प्रकार की संरचित फ़ाइल का विस्तार और सुधार करना बहुत मुश्किल होता है। यह ऐसी फ़ाइलें भी बनाता है जो एक प्लेटफ़ॉर्म या प्रोग्रामिंग भाषा के लिए विशिष्ट हो सकती हैं (उदाहरण के लिए [[पास्कल (प्रोग्रामिंग भाषा)]] स्ट्रिंग वाली संरचना को [[सी (प्रोग्रामिंग भाषा)]] में पहचाना नहीं जाता है)। दूसरी ओर, इस प्रकार की फाइलों को पढ़ने और लिखने के लिए उपकरण विकसित करना बहुत आसान है। | ||
असंरचितप्रारूपों की सीमाओं के कारण अन्य प्रकार के फ़ाइलप्रारूपों का विकास हुआ, जिन्हें आसानी से बढ़ाया जा सकता है और एक ही समय में पिछड़े संगत हो सकते हैं। | |||
=== चंक-आधारित प्रारूप === | === चंक-आधारित प्रारूप === | ||
इस तरह की फ़ाइल संरचना में, डेटा का प्रत्येक टुकड़ा एक कंटेनर में एम्बेडेड होता है जो किसी तरह डेटा की पहचान करता है। कंटेनर के दायरे को किसी प्रकार के स्टार्ट- और एंड-मार्कर द्वारा, कहीं स्पष्ट लंबाई क्षेत्र द्वारा, या फ़ाइल प्रारूप की परिभाषा की निश्चित आवश्यकताओं द्वारा पहचाना जा सकता है। | इस तरह की फ़ाइल संरचना में, डेटा का प्रत्येक टुकड़ा एक कंटेनर में एम्बेडेड होता है जो किसी तरह डेटा की पहचान करता है। कंटेनर के दायरे को किसी प्रकार के स्टार्ट- और एंड-मार्कर द्वारा, कहीं स्पष्ट लंबाई क्षेत्र द्वारा, या फ़ाइल प्रारूप की परिभाषा की निश्चित आवश्यकताओं द्वारा पहचाना जा सकता है। | ||
1970 के दशक के दौरान, कई | 1970 के दशक के दौरान, कई प्रोग्राम ों ने इस सामान्य प्रकार के प्रारूपों का उपयोग किया। उदाहरण के लिए, वर्ड-प्रोसेसर जैसे [[ ट्राफ ]], एससीआरआईपीटी (मार्कअप), और [[ मुंशी (मार्कअप भाषा) ]], और डेटाबेस निर्यात फाइलें जैसे अल्पविराम से अलग किए गए मान। [[इलेक्ट्रॉनिक आर्ट]]्स और [[कमोडोर इंटरनेशनल]]-[[अमिगा]] ने भी 1985 में अपने IFF (इंटरचेंज फाइल फॉर्मेट) फाइल फॉर्मेट के साथ इस प्रकार के फाइल फॉर्मेट का इस्तेमाल किया था। | ||
एक कंटेनर को कभी-कभी चंक कहा जाता है, हालांकि चंक का अर्थ यह भी हो सकता है कि प्रत्येक टुकड़ा छोटा है, और/या उस हिस्से में अन्य टुकड़े नहीं होते हैं; कई प्रारूप उन आवश्यकताओं को लागू नहीं करते हैं। | एक कंटेनर को कभी-कभी चंक कहा जाता है, हालांकि चंक का अर्थ यह भी हो सकता है कि प्रत्येक टुकड़ा छोटा है, और/या उस हिस्से में अन्य टुकड़े नहीं होते हैं; कई प्रारूप उन आवश्यकताओं को लागू नहीं करते हैं। | ||
किसी विशेष खंड की पहचान करने वाली जानकारी को कई विभिन्न चीजें कहा जा सकता है, | किसी विशेष खंड की पहचान करने वाली जानकारी को कई विभिन्न चीजें कहा जा सकता है, प्रायः फ़ील्ड नाम, पहचानकर्ता, लेबल या टैग सहित शब्द। पहचानकर्ता प्रायः मानव-पठनीय होते हैं, और डेटा के कुछ हिस्सों को वर्गीकृत करते हैं: उदाहरण के लिए, एक उपनाम, पता, आयत, फ़ॉन्ट नाम, आदि के रूप में। ये डेटाबेस कुंजी या सीरियल नंबर के अर्थ में पहचानकर्ता के समान नहीं हैं ( हालांकि एक पहचानकर्ता इसकी अच्छी तरह से पहचान कर सकता है {{em|associated data}} ऐसी कुंजी के रूप में)। | ||
इस प्रकार की फ़ाइल संरचना के साथ, उपकरण जो कुछ चंक पहचानकर्ताओं को नहीं जानते हैं, वे बस उन्हें छोड़ देते हैं जिन्हें वे नहीं समझते हैं। निर्भर करना | इस प्रकार की फ़ाइल संरचना के साथ, उपकरण जो कुछ चंक पहचानकर्ताओं को नहीं जानते हैं, वे बस उन्हें छोड़ देते हैं जिन्हें वे नहीं समझते हैं। निर्भर करना | ||
| Line 145: | Line 145: | ||
दरअसल, कोई भी डेटा प्रारूप होना चाहिए {{em|somehow}} इसके घटक भागों के महत्व की पहचान करें, और एम्बेडेड सीमा-चिह्न ऐसा करने का एक स्पष्ट तरीका है: | दरअसल, कोई भी डेटा प्रारूप होना चाहिए {{em|somehow}} इसके घटक भागों के महत्व की पहचान करें, और एम्बेडेड सीमा-चिह्न ऐसा करने का एक स्पष्ट तरीका है: | ||
* MIME#MIME शीर्षलेख फ़ील्ड प्रत्येक लॉजिकल लाइन के प्रारंभ में एक कोलन से अलग किए गए लेबल के साथ ऐसा करते हैं। MIME शीर्षलेखों में अन्य MIME शीर्षलेख नहीं हो सकते हैं, हालांकि कुछ शीर्षलेखों की डेटा सामग्री में उप-भाग होते हैं जिन्हें अन्य सम्मेलनों द्वारा निकाला जा सकता है। | * MIME#MIME शीर्षलेख फ़ील्ड प्रत्येक लॉजिकल लाइन के प्रारंभ में एक कोलन से अलग किए गए लेबल के साथ ऐसा करते हैं। MIME शीर्षलेखों में अन्य MIME शीर्षलेख नहीं हो सकते हैं, हालांकि कुछ शीर्षलेखों की डेटा सामग्री में उप-भाग होते हैं जिन्हें अन्य सम्मेलनों द्वारा निकाला जा सकता है। | ||
* अल्पविराम से अलग किए गए मान और समान फ़ाइलें | * अल्पविराम से अलग किए गए मान और समान फ़ाइलें प्रायः फ़ील्ड नामों के साथ हेडर रिकॉर्ड का उपयोग करके और फ़ील्ड सीमाओं को चिह्नित करने के लिए अल्पविराम के साथ ऐसा करते हैं। MIME की तरह, CSV में एक से अधिक स्तरों वाली संरचनाओं के लिए कोई प्रावधान नहीं है। | ||
* XML और उसके संबंधियों को मोटे तौर पर एक प्रकार का चंक-आधारित प्रारूप माना जा सकता है, क्योंकि डेटा तत्वों की पहचान मार्कअप द्वारा की जाती है जो चंक आइडेंटिफ़ायर के समान है। हालांकि, इसमें XML स्कीमा और [[सत्यापन और सत्यापन (सॉफ्टवेयर)]] जैसे औपचारिक फायदे हैं, साथ ही ट्री (डेटा संरचना), निर्देशित विश्वकोश ग्राफ और [[चार्ट]] जैसे अधिक जटिल संरचनाओं का प्रतिनिधित्व करने की क्षमता है। यदि XML को चंक प्रारूप माना जाता है, तो [[SGML]] और इसके पूर्ववर्ती [[IBM GML]] | * XML और उसके संबंधियों को मोटे तौर पर एक प्रकार का चंक-आधारित प्रारूप माना जा सकता है, क्योंकि डेटा तत्वों की पहचान मार्कअप द्वारा की जाती है जो चंक आइडेंटिफ़ायर के समान है। हालांकि, इसमें XML स्कीमा और [[सत्यापन और सत्यापन (सॉफ्टवेयर)]] जैसे औपचारिक फायदे हैं, साथ ही ट्री (डेटा संरचना), निर्देशित विश्वकोश ग्राफ और [[चार्ट]] जैसे अधिक जटिल संरचनाओं का प्रतिनिधित्व करने की क्षमता है। यदि XML को चंक प्रारूप माना जाता है, तो [[SGML]] और इसके पूर्ववर्ती [[IBM GML]] ऐसेप्रारूपों के शुरुआती उदाहरणों में से हैं। | ||
* [[JSON]] स्कीमा, क्रॉस-रेफरेंस, या बार-बार फ़ील्ड-नामों के अर्थ के लिए परिभाषा के बिना XML के समान है, और | * [[JSON]] स्कीमा, क्रॉस-रेफरेंस, या बार-बार फ़ील्ड-नामों के अर्थ के लिए परिभाषा के बिना XML के समान है, और प्रायः प्रोग्रामर के लिए सुविधाजनक होता है। | ||
* [[YAML]] JSON के समान है, लेकिन डेटा को अलग करने के लिए इंडेंटेशन का उपयोग करें और JSON या XML की तुलना में अधिक मानव-पठनीय होने का लक्ष्य रखें। | * [[YAML]] JSON के समान है, लेकिन डेटा को अलग करने के लिए इंडेंटेशन का उपयोग करें और JSON या XML की तुलना में अधिक मानव-पठनीय होने का लक्ष्य रखें। | ||
* [[प्रोटोकॉल बफ़र्स]] बदले में JSON के समान हैं, विशेष रूप से फ़ील्ड नंबरों के साथ डेटा में सीमा-चिह्नकों को प्रतिस्थापित करते हैं, जिन्हें कुछ बाहरी तंत्र द्वारा नामों से/से मैप किया जाता है। | * [[प्रोटोकॉल बफ़र्स]] बदले में JSON के समान हैं, विशेष रूप से फ़ील्ड नंबरों के साथ डेटा में सीमा-चिह्नकों को प्रतिस्थापित करते हैं, जिन्हें कुछ बाहरी तंत्र द्वारा नामों से/से मैप किया जाता है। | ||
| Line 156: | Line 156: | ||
कुछ फ़ाइल स्वरूप जैसे ODT और DOCX, [[PKZIP]]-आधारित होने के कारण, दोनों खंडित हैं और एक निर्देशिका रखते हैं।{{cn|date=December 2022}} | कुछ फ़ाइल स्वरूप जैसे ODT और DOCX, [[PKZIP]]-आधारित होने के कारण, दोनों खंडित हैं और एक निर्देशिका रखते हैं।{{cn|date=December 2022}} | ||
एक निर्देशिका-आधारित फ़ाइल स्वरूप की संरचना असंरचित या चंक- | एक निर्देशिका-आधारित फ़ाइल स्वरूप की संरचना असंरचित या चंक-आधारितप्रारूपों की तुलना में अधिक आसानी से संशोधनों के लिए उधार देती है।{{cn|date=December 2022}} इस प्रकार के प्रारूप की प्रकृति उपयोगकर्ताओं को सावधानी से फ़ाइलों का निर्माण करने की अनुमति देती है जो पाठक सॉफ़्टवेयर को उन चीजों को करने का कारण बनती है जो प्रारूप के लेखक कभी नहीं होने का इरादा रखते थे। इसका एक उदाहरण [[ज़िप बम]] है। निर्देशिका-आधारित फ़ाइल स्वरूप भी उन मानों का उपयोग करते हैं जो फ़ाइल में अन्य क्षेत्रों को इंगित करते हैं लेकिन यदि कुछ बाद के डेटा मान पहले पढ़े गए डेटा पर वापस जाते हैं, तो इसका परिणाम किसी भी पाठक सॉफ़्टवेयर के लिए अनंत लूप में हो सकता है जो इनपुट फ़ाइल को मान्य करता है और आँख बंद करके पाश का पालन करता है।{{cn|date=December 2022}} | ||
== यह भी देखें == | == यह भी देखें == | ||
* [[ऑडियो फ़ाइल स्वरूप]] | * [[ऑडियो फ़ाइल स्वरूप]] | ||
* [[रासायनिक फ़ाइल स्वरूप]] | * [[रासायनिक फ़ाइल स्वरूप]] | ||
* [[निष्पादन योग्य फ़ाइल स्वरूपों की तुलना]] | * [[निष्पादन योग्य फ़ाइल स्वरूपों की तुलना|निष्पादन योग्य फ़ाइलप्रारूपों की तुलना]] | ||
* डिजिटल कंटेनर प्रारूप | * डिजिटल कंटेनर प्रारूप | ||
* [[दस्तावेज़ फ़ाइल स्वरूप]] | * [[दस्तावेज़ फ़ाइल स्वरूप]] | ||
| Line 174: | Line 174: | ||
* फाइल सिग्नेचर, या मैजिक नंबरों की सूची | * फाइल सिग्नेचर, या मैजिक नंबरों की सूची | ||
* [[फ़ाइल नाम एक्सटेंशन की सूची (वर्णमाला)]] | * [[फ़ाइल नाम एक्सटेंशन की सूची (वर्णमाला)]] | ||
* मुफ्त [[फ़ाइल स्वरूपों की सूची]] | * मुफ्त [[फ़ाइल स्वरूपों की सूची|फ़ाइलप्रारूपों की सूची]] | ||
* मोशन और जेस्चर | * मोशन और जेस्चर फ़ाइलप्रारूपों की सूची | ||
* [[ जादू संख्या (प्रोग्रामिंग) ]] | * [[ जादू संख्या (प्रोग्रामिंग) ]] | ||
* [[वस्तु फ़ाइल]] | * [[वस्तु फ़ाइल]] | ||
Revision as of 12:01, 29 June 2023
फ़ाइल प्रारूप कंप्यूटर फ़ाइल में संग्रहीत जानकारी को कोड करने का एक मानक विधि होता है। यह निर्धारित करता है कि बिट कैसे डिजिटल संग्रहण माध्यम में जानकारी को कोड करने के लिए उपयोग होते हैं। फ़ाइल प्रारूप संपत्रित या मुक्त दोनों हो सकते हैं। कुछ फ़ाइल प्रारूप विशेष रूप से निर्दिष्ट प्रकार के डेटा के लिए प्रारूपित किए गए होते हैं: उदाहरण के लिए, पोर्टेबल नेटवर्क ग्राफ़िक्स फ़ाइल दोषरहित डेटा संपीड़न का उपयोग करके लाइन ग्राफिक्स को संग्रहित करती हैं।
यद्यपि, अन्य फ़ाइलप्रारूपों को विभिन्न प्रकार के डेटा के संग्रह के लिए प्रारूपित किए गए होते हैं,ओजीजी प्रारूप विभिन्न प्रकार की मल्टीमीडिया के लिए एक कंटेनर के रूप में कार्य कर सकता है, जिसमें ऑडियो और वीडियो की किसी भी संयोजन, पाठ उदाहरण के लिए उपशीर्षक और मेटाडेटा, सम्मिलित हो सकते हैं।
एक पाठ फ़ाइल में संभावित नियंत्रण वर्णों सहित वर्णों की कोई भी धारा हो सकती है, और विभिन्न अक्षरों को सांकेतिक अक्षरों में परिवर्तन में से एक में एन्कोड किया जाता है। कुछ फ़ाइल प्रारूप, जैसे कि एचटीएमएल, स्केलेबल वेक्टर ग्राफिक्स, और कंप्यूटर सॉफ्टवेयर का स्रोत कोड परिभाषित सिंटैक्स वाली टेक्स्ट फ़ाइलें हैं जो उन्हें विशिष्ट उद्देश्यों के लिए उपयोग करने की अनुमति देती हैं।
विशेष विवरण
फ़ाइल प्रारूपों में प्रायः एक प्रकाशित विनिर्देश होता है जो एन्कोडिंग विधि का वर्णन करता है और प्रोग्राम के इच्छित कार्यक्षमता के परीक्षण को सक्षम करता है। सभी प्रारूपों में स्वतंत्र रूप से विनिर्देश दस्तावेज़ उपलब्ध नहीं हैं, आंशिक रूप से क्योंकि कुछ डेवलपर्स अपने विनिर्देश दस्तावेज़ों को व्यापार रहस्य के रूप में देखते हैं, और आंशिक रूप से क्योंकि अन्य डेवलपर्स औपचारिक विनिर्देश दस्तावेज़ को कभी भी लेखक नहीं बनाते हैं, प्रारूप का उपयोग करने वाले अन्य पहले से उपलब्ध प्रोग्रामों द्वारा उदाहरण स्थापित करते हुए प्रारूप को परिभाषित करते हैं कि कैसे ये प्रोग्राम इसका उपयोग करते हैं।
यदि किसी प्रारूप का डेवलपर, मुक्त विनिर्देशों को प्रकाशित नहीं करता है, तो उस प्रकार की फ़ाइल का उपयोग करने के इच्छुक अन्य डेवलपर को उत्क्रम अभियांत्रिकी का उपयोग करना होगा जिससे यह पता लगाया जा सके कि इसे कैसे पढ़ा जाए या प्रारूप के डेवलपर्स से शुल्क के लिए और हस्ताक्षर करके विनिर्देश दस्तावेज़ कैसे प्राप्त किया जाए। बाद वाला दृष्टिकोण तभी संभव है जब एक औपचारिक विनिर्देश दस्तावेज उपलब्ध हो। दोनों रणनीतियों के लिए महत्वपूर्ण समय, धन या दोनों की आवश्यकता होती है; इसलिए, सार्वजनिक रूप से उपलब्ध विनिर्देशों वाले फ़ाइल प्रारूपों को अधिक प्रोग्रामो द्वारा समर्थित किया जाता है।
पेटेंट
कॉपीराइट के बजाय पेटेंट कानून का उपयोग प्रायः फ़ाइल स्वरूप की सुरक्षा के लिए किया जाता है। हालांकि अमेरिकी कानून के तहत फ़ाइलप्रारूपों के पेटेंट की सीधे अनुमति नहीं है, कुछ प्रारूप पेटेंट किए गए एल्गोरिदम का उपयोग करके डेटा को एन्कोड करते हैं। उदाहरण के लिए, जीआईएफ फ़ाइल प्रारूप के साथ संपीड़न का उपयोग करने के लिए एक पेटेंट कलन विधि के उपयोग की आवश्यकता होती है, और हालांकि पेटेंट मालिक ने शुरू में अपने पेटेंट को लागू नहीं किया था, बाद में उन्होंने रॉयल्टी भुगतान एकत्र करना शुरू कर दिया। इसके परिणामस्वरूप जीआईएफ के उपयोग में उल्लेखनीय कमी आई है, और वैकल्पिक पोर्टेबल नेटवर्क ग्राफिक्स प्रारूप के विकास के लिए आंशिक रूप से जिम्मेदार है। हालाँकि, GIF पेटेंट अमेरिका में 2003 के मध्य में और दुनिया भर में 2004 के मध्य में समाप्त हो गया।
फ़ाइल प्रकार की पहचान करना
विभिन्न ऑपरेटिंग सिस्टम ने पारंपरिक रूप से एक विशेष फ़ाइल के प्रारूप को निर्धारित करने के लिए विभिन्न दृष्टिकोण अपनाए हैं, प्रत्येक दृष्टिकोण के अपने फायदे और नुकसान हैं। अधिकांश आधुनिक ऑपरेटिंग सिस्टम और व्यक्तिगत अनुप्रयोगों को विदेशी फ़ाइलप्रारूपों को पढ़ने के लिए निम्नलिखित सभी दृष्टिकोणों का उपयोग करने की आवश्यकता होती है, यदि उनके साथ पूरी तरह से काम नहीं किया जाता है।
फ़ाइल नाम एक्सटेंशन
Microsoft Windows, macOS, CP/M, DOS, OpenVMS, और VM (ऑपरेटिंग सिस्टम) | VM/CMS सहित कई ऑपरेटिंग सिस्टम द्वारा उपयोग की जाने वाली एक लोकप्रिय विधि फ़ाइल के नाम के अंत के आधार पर उसके प्रारूप का निर्धारण करना है। अधिक विशेष रूप से अंतिम अवधि के बाद के अक्षर। फ़ाइल नाम के इस भाग को फ़ाइल नाम एक्सटेंशन के रूप में जाना जाता है। उदाहरण के लिए, HTML दस्तावेज़ों को उन नामों से पहचाना जाता है जिनके साथ समाप्त होता है .html (या .htm), और जीआईएफ छवियां .gif. मूल फ़ाइल आवंटन तालिका फाइल सिस्टम में, फ़ाइल नाम आठ-वर्ण पहचानकर्ता और तीन-वर्ण एक्सटेंशन तक सीमित थे, जिसे 8.3 फ़ाइल नाम के रूप में जाना जाता है। सीमित संख्या में तीन-अक्षर वाले एक्सटेंशन हैं, जो एक दिए गए एक्सटेंशन को एक से अधिक प्रोग्राम द्वारा उपयोग करने का कारण बन सकते हैं। कई प्रारूप अभी भी तीन-वर्ण एक्सटेंशन का उपयोग करते हैं, हालांकि आधुनिक ऑपरेटिंग सिस्टम और एप्लिकेशन प्रोग्राम में अब यह सीमा नहीं है। चूंकि एक्सटेंशन की कोई मानक सूची नहीं है, एक से अधिक प्रारूप एक ही एक्सटेंशन का उपयोग कर सकते हैं, जो ऑपरेटिंग सिस्टम और उपयोगकर्ता दोनों को भ्रमित कर सकता है।
इस दृष्टिकोण का एक आर्टिफैक्ट यह है कि सिस्टम को आसानी से एक फ़ाइल को एक अलग प्रारूप के रूप में नाम देकर आसानी से धोखा दिया जा सकता है - उदाहरण के लिए, एक HTML फ़ाइल को आसानी से सादे पाठ के रूप में माना जा सकता है। filename.html को filename.txt. यद्यपि यह रणनीति विशेषज्ञ उपयोगकर्ताओं के लिए उपयोगी थी जो इस जानकारी को आसानी से समझ और हेरफेर कर सकते थे, यह प्रायः कम तकनीकी उपयोगकर्ताओं के लिए भ्रमित करने वाला था, जो गलती से फ़ाइल को अनुपयोगी बना सकते थे (या इसे खो सकते थे) इसे गलत तरीके से नाम देकर।
इसने विंडोज़ और मैक ओएस के अधिकांश संस्करणों को फाइलों को सूचीबद्ध करते समय एक्सटेंशन को छिपाने का नेतृत्व किया। यह उपयोगकर्ता को गलती से फ़ाइल प्रकार बदलने से रोकता है, और विशेषज्ञ उपयोगकर्ताओं को इस सुविधा को बंद करने और एक्सटेंशन प्रदर्शित करने की अनुमति देता है।
हालाँकि, एक्सटेंशन को छिपाने से एक ही फ़ोल्डर में दो या दो से अधिक समान फ़ाइल नामों का स्वरूप बन सकता है। उदाहरण के लिए, एनकैप्सुलेटेड पोस्टस्क्रिप्ट | दोनों में कंपनी के लोगो की आवश्यकता हो सकती है.eps प्रारूप (प्रकाशन के लिए) और .png प्रारूप (वेबसाइटों के लिए)। दिखाई देने वाले एक्सटेंशन के साथ, ये अद्वितीय फ़ाइलनामों के रूप में दिखाई देंगे:CompanyLogo.eps औरCompanyLogo.png . दूसरी ओर, एक्सटेंशन छुपाने से दोनों ऐसे दिखाई देंगेCompanyLogo, जिससे भ्रम हो सकता है।
एक्सटेंशन छुपाने से सुरक्षा जोखिम भी हो सकता है।[1] उदाहरण के लिए, एक दुर्भावनापूर्ण उपयोगकर्ता एक निर्दोष नाम के साथ एक ट्रोजन हॉर्स (कंप्यूटिंग) बना सकता है जैसेHoliday photo.jpg.exe ..exe छुपा दिया जाएगा और एक अनजान उपयोगकर्ता देखेगाHoliday photo.jpg , जो एक JPEG छवि प्रतीत होगी, आमतौर पर मशीन को नुकसान पहुँचाने में असमर्थ होती है। हालाँकि, ऑपरेटिंग सिस्टम अभी भी देखेगा.exe एक्सटेंशन और प्रोग्राम चलाएं, जो तब कंप्यूटर को नुकसान पहुंचाने में सक्षम होगा। केवल एक एक्सटेंशन वाली फ़ाइलों के साथ भी यही सच है: चूंकि यह उपयोगकर्ता को नहीं दिखाया जाता है, फ़ाइल के बारे में कोई भी जानकारी स्पष्ट रूप से फ़ाइल की जांच किए बिना नहीं निकाली जा सकती। उपयोगकर्ताओं को और अधिक धोखा देने के लिए, प्रोग्राम के अंदर एक आइकन स्टोर करना संभव है, इस स्थिति में निष्पादन योग्य फ़ाइल के लिए कुछ ऑपरेटिंग सिस्टम के आइकन असाइनमेंट (.exe) जेपीईजी छवियों का प्रतिनिधित्व करने के लिए आमतौर पर उपयोग किए जाने वाले आइकन के साथ ओवरराइड किया जाएगा, जिससे प्रोग्राम एक छवि जैसा दिखता है। एक्सटेंशन को धोखा भी दिया जा सकता है: कुछ माइक्रोसॉफ्ट वर्ड मैक्रो वायरस टेम्पलेट प्रारूप में वर्ड फ़ाइल बनाते हैं और इसे एक से सहेजते हैं .doc विस्तार। चूँकि Word आम तौर पर एक्सटेंशन की उपेक्षा करता है और फ़ाइल के प्रारूप को देखता है, ये टेम्प्लेट के रूप में खुलेंगे, निष्पादित होंगे और वायरस फैलाएंगे।[citation needed] यह विंडोज सिस्टम के लिए एक व्यावहारिक समस्या का प्रतिनिधित्व करता है जहां डिफ़ॉल्ट रूप से एक्सटेंशन-छिपाना चालू होता है।
आंतरिक मेटाडेटा
फ़ाइल प्रारूप की पहचान करने का दूसरा तरीका फ़ाइल के अंदर संग्रहीत प्रारूप के बारे में जानकारी का उपयोग करना है, या तो इस उद्देश्य के लिए जानकारी या स्ट्रिंग (कंप्यूटर विज्ञान) # गैर-पाठ स्ट्रिंग्स जो हमेशा कुछ फ़ाइलों में विशिष्ट स्थानों में होती हैं प्रारूप। चूंकि उनका पता लगाने का सबसे आसान स्थान शुरुआत में है, ऐसे क्षेत्र को आमतौर पर फ़ाइल हेडर कहा जाता है जब यह कुछ बाइट्स से अधिक होता है, या मैजिक नंबर अगर यह केवल कुछ बाइट्स लंबा होता है।
फाइल हेडर
हेडर (कंप्यूटिंग) में निहित मेटाडेटा आमतौर पर फ़ाइल की शुरुआत में संग्रहीत होते हैं, लेकिन अन्य क्षेत्रों में भी उपलब्ध हो सकते हैं, प्रायः अंत सहित, फ़ाइल प्रारूप या डेटा के प्रकार के आधार पर। कैरेक्टर-आधारित (टेक्स्ट) फाइलों में आमतौर पर कैरेक्टर-आधारित हेडर होते हैं, जबकि बाइनरी फॉर्मेट में आमतौर पर बाइनरी हेडर होते हैं, हालांकि यह कोई नियम नहीं है। टेक्स्ट-आधारित फ़ाइल हेडर आमतौर पर अधिक स्थान लेते हैं, लेकिन मानव-पठनीय होने के कारण, उन्हें टेक्स्ट एडिटर या हेक्साडेसिमल एडिटर जैसे सरल सॉफ़्टवेयर का उपयोग करके आसानी से जांचा जा सकता है।
फ़ाइल प्रारूप की पहचान करने के साथ-साथ फ़ाइल हेडर में फ़ाइल और उसकी सामग्री के बारे में मेटाडेटा हो सकता है। उदाहरण के लिए, अधिकांश छवि फ़ाइल प्रारूप छवि प्रारूप, आकार, रिज़ॉल्यूशन और रंग स्थान के बारे में जानकारी संग्रहीत करते हैं, और वैकल्पिक रूप से जानकारी को संलेखित करते हैं जैसे कि छवि किसने बनाई, कब और कहाँ बनाई गई, कौन सा कैमरा मॉडल और फोटोग्राफिकस्थापित िंग्स का उपयोग किया गया (Exif), और इसी तरह। इस तरह के मेटाडेटा का उपयोग सॉफ्टवेयर द्वारा लोडिंग प्रक्रिया के दौरान और बाद में फाइल को पढ़ने या व्याख्या करने के लिए किया जा सकता है।
फाइल हेडर का उपयोग एक ऑपरेटिंग सिस्टम द्वारा मेमोरी में लोड किए बिना फ़ाइल के बारे में जानकारी को जल्दी से इकट्ठा करने के लिए किया जा सकता है, लेकिन ऐसा करने से कंप्यूटर के संसाधनों का अधिक उपयोग फाइल सिस्टम # निर्देशिकाओं की जानकारी से सीधे पढ़ने की तुलना में होता है। उदाहरण के लिए, जब एक ग्राफिकल यूज़र इंटरफ़ेस फ़ाइल प्रबंधक को किसी फ़ोल्डर की सामग्री को प्रदर्शित करना होता है, तो उसे उचित आइकन प्रदर्शित करने से पहले कई फ़ाइलों के शीर्षलेखों को पढ़ना चाहिए, लेकिन ये भंडारण माध्यम पर विभिन्न जगहों पर स्थित होंगे, इस प्रकार अधिक समय लगेगा उपयोग करने के लिए। थंबनेल जानकारी जैसे जटिल मेटाडेटा वाली कई फ़ाइलों वाले फ़ोल्डर को प्रदर्शित होने से पहले काफी समय लग सकता है।
यदि हेडर कठिन कोडिंग | बाइनरी हार्ड-कोडेड है जैसे कि हेडर को पहचानने के लिए जटिल व्याख्या की आवश्यकता होती है, विशेष रूप से मेटाडेटा सामग्री सुरक्षा के लिए, एक जोखिम है कि फ़ाइल प्रारूप की गलत व्याख्या की जा सकती है। यह स्रोत पर बुरी तरह लिखा भी हो सकता है। इसके परिणामस्वरूप दूषित मेटाडेटा हो सकता है, जो बेहद खराब मामलों में फ़ाइल को अपठनीय भी बना सकता है।[clarification needed]
फ़ाइल शीर्षलेखों का एक अधिक जटिल उदाहरण वे हैं जो डिजिटल कंटेनर प्रारूप (या कंटेनर) फ़ाइलप्रारूपों के लिए उपयोग किए जाते हैं।
मैजिक नंबर
फ़ाइल प्रकार मेटाडेटा को शामिल करने का एक तरीका, जो प्रायः यूनिक्स और इसके डेरिवेटिव से जुड़ा होता है, फ़ाइल के अंदर एक जादुई संख्या को स्टोर करना है। मूल रूप से, इस शब्द का उपयोग फ़ाइलों की शुरुआत में 2-बाइट पहचानकर्ताओं के एक विशिष्टस्थापित के लिए किया गया था, लेकिन चूंकि किसी भी बाइनरी अनुक्रम को एक संख्या के रूप में माना जा सकता है, फ़ाइल प्रारूप की कोई भी विशेषता जो इसे विशिष्ट रूप से अलग करती है, पहचान के लिए उपयोग की जा सकती है। उदाहरण के लिए, GIF छवियां हमेशा ASCII प्रतिनिधित्व के साथ शुरू होती हैं GIF87a या GIF89a, उस मानक पर निर्भर करता है जिसका वे पालन करते हैं। कई फ़ाइल प्रकार, विशेष रूप से सादे-पाठ फ़ाइलें, इस पद्धति से स्पॉट करना कठिन हैं। उदाहरण के लिए, HTML फ़ाइलें स्ट्रिंग से शुरू हो सकती हैं <html> (जो केस सेंसिटिव नहीं है), या उपयुक्त दस्तावेज़ प्रकार की परिभाषा जो इससे शुरू होती है <!DOCTYPE HTML>, या, XHTML के लिए, XML पहचानकर्ता, जो से शुरू होता है <?xml. फ़ाइलें HTML टिप्पणियों, यादृच्छिक पाठ या कई खाली पंक्तियों के साथ भी शुरू हो सकती हैं, लेकिन फिर भी प्रयोग करने योग्य HTML हो सकती हैं।
जादू संख्या दृष्टिकोण बेहतर गारंटी प्रदान करता है कि प्रारूप सही ढंग से पहचाना जाएगा, और प्रायः फ़ाइल के बारे में अधिक सटीक जानकारी निर्धारित कर सकता है। चूंकि यथोचित रूप से विश्वसनीय जादुई संख्या परीक्षण काफी जटिल हो सकते हैं, और प्रत्येक फ़ाइल को जादू डेटाबेस में हर संभावना के खिलाफ प्रभावी ढंग से परीक्षण किया जाना चाहिए, यह दृष्टिकोण अपेक्षाकृत अक्षम है, विशेष रूप से फाइलों की बड़ी सूची प्रदर्शित करने के लिए (इसके विपरीत, फ़ाइल नाम और मेटाडेटा-आधारित विधियां) डेटा के केवल एक टुकड़े की जांच करने की आवश्यकता है, और इसे सॉर्ट किए गए इंडेक्स के विरुद्ध मिलान करें)। साथ ही, डेटा को फ़ाइल से ही पढ़ा जाना चाहिए, निर्देशिका में संग्रहीत मेटाडेटा के विपरीत विलंबता बढ़ाना। जहां फ़ाइल प्रकार इस तरह से खुद को पहचानने के लिए उधार नहीं देते हैं, सिस्टम को मेटाडेटा पर वापस आना चाहिए। हालाँकि, किसी प्रोग्राम के लिए यह जाँचने का सबसे अच्छा तरीका है कि जिस फ़ाइल को संसाधित करने के लिए कहा गया है वह सही प्रारूप की है: जबकि फ़ाइल का नाम या मेटाडेटा इसकी सामग्री से स्वतंत्र रूप से बदला जा सकता है, एक अच्छी तरह से प्रारूपित किए गए जादू संख्या परीक्षण में विफल एक निश्चित संकेत है कि फ़ाइल या तो दूषित है या गलत प्रकार की है। दूसरी ओर, एक मान्य मैजिक नंबर इस बात की गारंटी नहीं देता है कि फ़ाइल दूषित नहीं है या सही प्रकार की है।
स्क्रिप्टिंग भाषा में तथाकथित शेबैंग (यूनिक्स) पंक्तियाँ जादुई संख्याओं का एक विशेष मामला है। यहां, जादू संख्या मानव-पठनीय पाठ है जो एक विशिष्ट दुभाषिया (कंप्यूटिंग) और कमांड दुभाषिया को पास किए जाने वाले विकल्पों की पहचान करता है।
मैजिक नंबरों का उपयोग करने वाला एक अन्य ऑपरेटिंग सिस्टम AmigaOS है, जहां मैजिक नंबरों को मैजिक कुकीज़ कहा जाता था और दोस्त हंक निष्पादन योग्य फ़ाइल प्रारूप में निष्पादनयोग्य को पहचानने के लिए एक मानक प्रणाली के रूप में अपनाया गया था और एकल प्रोग्राम ों, उपकरणों और उपयोगिताओं को उनकी सहेजी गई डेटा फ़ाइलों के साथ स्वचालित रूप से निपटने के लिए भी दिया गया था। या डेटा सहेजते और लोड करते समय किसी अन्य प्रकार की फ़ाइल प्रकार। इस सिस्टम को तब Amiga सपोर्ट और मेंटेनेंस सॉफ्टवेयर#डेटाटाइप्स रिकग्निशन सिस्टम के साथ बढ़ाया गया था। एक अन्य विधि फोरसीसी विधि थी, जो मैकिंटोश पर ओएस टाइप में उत्पन्न हुई थी, जिसे बाद में इंटरचेंज फ़ाइल स्वरूप (आईएफएफ) और डेरिवेटिव द्वारा अनुकूलित किया गया था।
बाहरी मेटाडेटा
फ़ाइल के प्रारूप को संग्रहीत करने का एक अंतिम तरीका फ़ाइल सिस्टम में प्रारूप के बारे में जानकारी को स्पष्ट रूप से फ़ाइल के भीतर संग्रहीत करना है।
यह दृष्टिकोण मेटाडेटा को मुख्य डेटा और नाम दोनों से अलग रखता है, लेकिन फ़ाइल नाम एक्सटेंशन या मैजिक नंबरों की तुलना में कम में porting भी करता है, क्योंकि प्रारूप को फ़ाइल सिस्टम से फ़ाइल सिस्टम में बदलना पड़ता है। जबकि यह फ़ाइल नाम एक्सटेंशन के साथ एक हद तक सही है - उदाहरण के लिए, MS-DOS विभाजन तालिका के साथ संगतता के लिए | MS-DOS की तीन वर्ण सीमा - भंडारण के अधिकांश रूपों में फ़ाइल के डेटा और नाम की लगभग समतुल्य परिभाषा होती है, लेकिन हो सकती है आगे के मेटाडेटा का भिन्न या कोई प्रतिनिधित्व नहीं।
ध्यान दें कि ज़िप फ़ाइलें या संग्रह फ़ाइलें मेटाडेटा को संभालने की समस्या को हल करती हैं। एक यूटिलिटी प्रोग्राम प्रत्येक फ़ाइल के बारे में मेटाडेटा के साथ-साथ एक नई फ़ाइल (जैसे एक ज़िप (फ़ाइल प्रारूप) फ़ाइल) के विस्तार के साथ कई फ़ाइलों को एक साथ इकट्ठा करता है। .zip). नई फ़ाइल भी संपीड़ित और संभवतः एन्क्रिप्ट की गई है, लेकिन अब फाइल ट्रांसफर प्रोटोकॉल ट्रांसमिशन द्वारा ऑपरेटिंग सिस्टम में एकल फाइल के रूप में ट्रांसमिसिबल है या अटैचमेंट के रूप में ईमेल द्वारा भेजी गई है। गंतव्य पर, प्राप्त एकल फ़ाइल को उपयोगी होने के लिए एक संगत उपयोगिता द्वारा अनज़िप करना पड़ता है। ज़िप फ़ाइलों या संग्रह फ़ाइलों का उपयोग करके मेटाडेटा को संभालने की समस्या इस तरह हल हो जाती है।
मैक ओएस टाइप-कोड
Macintosh ऑपरेटिंग सिस्टम 'पदानुक्रमित फ़ाइल सिस्टम (Apple) प्रत्येक फ़ाइल के लिए निर्देशिका प्रविष्टि के भाग के रूप में निर्माता कोड और कोड टाइप करें के लिए कोड संग्रहीत करता है। इन कोड को OSTypes कहा जाता है। ये कोड कोई भी 4-बाइट अनुक्रम हो सकते हैं लेकिन प्रायः चुने जाते थे ताकि ASCII प्रतिनिधित्व अर्थपूर्ण वर्णों का अनुक्रम बना सके, जैसे कि एप्लिकेशन के नाम का संक्षिप्त नाम या डेवलपर के आद्याक्षर। उदाहरण के लिए एक हाइपर कार्ड स्टैक फ़ाइल का निर्माता होता है WILD (हाइपरकार्ड के पिछले नाम, वाइल्डकार्ड से) और एक प्रकार का STAK. BBEdit टेक्स्ट एडिटर का क्रिएटर कोड होता है R*ch अपने मूल प्रोग्रामर, समृद्ध मुहर का जिक्र करते हुए। प्रकार कोड फ़ाइल के प्रारूप को निर्दिष्ट करता है, जबकि निर्माता कोड उपयोगकर्ता द्वारा डबल-क्लिक करने पर इसे खोलने के लिए डिफ़ॉल्ट प्रोग्राम निर्दिष्ट करता है। उदाहरण के लिए, उपयोगकर्ता के पास टाइप कोड के साथ कई टेक्स्ट फाइलें हो सकती हैं TEXT, लेकिन विभिन्न निर्माता कोड होने के कारण प्रत्येक एक अलग प्रोग्राम में खुलता है। इस सुविधा का उद्देश्य था, उदाहरण के लिए, मानव-पठनीय सादा-पाठ फ़ाइलें सामान्य-उद्देश्य वाले पाठ संपादक में खोली जा सकती हैं, जबकि प्रोग्रामिंग या HTML कोड फ़ाइलें एक विशेष संपादक या एकीकृत विकास वातावरण में खुलती हैं। हालांकि, यह सुविधा प्रायः उपयोगकर्ता भ्रम का स्रोत थी, क्योंकि फाइलों पर डबल-क्लिक करने पर कौन सा प्रोग्राम लॉन्च होगा, यह प्रायः अप्रत्याशित होता था। जोखिम एक समान प्रणाली का उपयोग करता है, जिसमें 12-बिट संख्या शामिल होती है जिसे विवरण तालिका में देखा जा सकता है- उदा। हेक्साडेसिमल संख्या FF5 का उपनाम है PoScript, परिशिष्ट भाग फ़ाइल का प्रतिनिधित्व करता है।
macOS यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI)
यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI) एक ऐसी विधि है जिसका उपयोग macOS में विशिष्ट रूप से टाइप की गई संस्थाओं की श्रेणियों, जैसे फ़ाइलप्रारूपों की पहचान के लिए किया जाता है। इसे Apple Inc. द्वारा OSType (प्रकार और निर्माता कोड) के प्रतिस्थापन के रूप में विकसित किया गया था।
यूटीआई एक कोर फाउंडेशन स्ट्रिंग (कंप्यूटर विज्ञान) है, जो रिवर्स डीएनएस स्ट्रिंग का उपयोग करता है। कुछ सामान्य और मानक प्रकार एक डोमेन का उपयोग करते हैं जिसे कहा जाता है public (उदा public.png पोर्टेबल नेटवर्क ग्राफ़िक्स छवि के लिए), जबकि अन्य डोमेन तृतीय-पक्ष प्रकारों के लिए उपयोग किए जा सकते हैं (उदा. com.adobe.pdf पोर्टेबल दस्तावेज़ स्वरूप के लिए)। यूटीआई को एक पदानुक्रमित संरचना के भीतर परिभाषित किया जा सकता है, जिसे अनुरूपता पदानुक्रम के रूप में जाना जाता है। इस प्रकार, public.png के सुपरटाइप के अनुरूप है public.image, जो स्वयं के सुपरटाइप के अनुरूप है public.data. एक यूटीआई कई पदानुक्रमों में उपलब्ध हो सकता है, जो बहुत अधिक लचीलापन प्रदान करता है।
फ़ाइलप्रारूपों के अलावा, UTI का उपयोग अन्य संस्थाओं के लिए भी किया जा सकता है जो macOS में उपलब्ध हो सकती हैं, जिनमें शामिल हैं:
- पेस्टबोर्ड डेटा
- निर्देशिका (कंप्यूटिंग) (निर्देशिका)
- अनुवाद योग्य प्रकार (अनुवाद प्रबंधक द्वारा नियंत्रित)
- बंडल
- चौखटे
- स्ट्रीमिंग डेटा
- उपनाम और सहानुभूति
वीएसएएम कैटलॉग
IBM OS/VS में z/OS के माध्यम से, VSAM कैटलॉग (डाटा फैसिलिटी स्टोरेज मैनेजमेंट सबसिस्टम (MVS)#ICF कैटलॉग से पहले) और वीएसएएम वॉल्यूम डेटास्थापित (वीवीडीएस) में वीएसएएम वॉल्यूम रिकॉर्ड (आईसीएफ कैटलॉग के साथ) प्रकार की पहचान करता है वीएसएएम डेटासेट का।
वीटीसी
IBM OS/360 में z/OS के माध्यम से, एक प्रारूप 1 या 7 वॉल्यूम सामग्री की तालिका#डेटास्थापित कंट्रोल ब्लॉक प्रकार (DSCB) सामग्री की वॉल्यूम तालिका (VTOC) में पहचान करता है इसके द्वारा वर्णित डेटासेट का डेटासेट संगठन (DSORG)।
OS/2 विस्तारित विशेषताएँ
उच्च प्रदर्शन फाइल सिस्टम, FAT12, और FAT16 (लेकिन FAT32 नहीं) फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देता है। इनमें एक नाम के साथ ट्रिपलेट का मनमानास्थापित , मान के लिए एक कोडित प्रकार और एक मान शामिल है, जहां नाम अद्वितीय हैं और मान 64 KB तक लंबा हो सकता है। कुछ प्रकार और नामों के लिए मानकीकृत अर्थ हैं (OS/2 के तहत)। ऐसा ही एक है कि फ़ाइल प्रकार निर्धारित करने के लिए .TYPE विस्तारित विशेषता का उपयोग किया जाता है। इसके मान में फ़ाइल से जुड़े एक या अधिक फ़ाइल प्रकारों की सूची शामिल होती है, जिनमें से प्रत्येक एक स्ट्रिंग है, जैसे कि सादा पाठ या HTML दस्तावेज़। इस प्रकार एक फ़ाइल कई प्रकार की हो सकती है।
NTFS फाइल सिस्टम OS/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, लेकिन यह सुविधा केवल OS/2 सबसिस्टम (XP में उपलब्ध नहीं) का समर्थन करने के लिए उपलब्ध है, इसलिए Win32 सबसिस्टम इस जानकारी को एक अपारदर्शी के रूप में मानता है। डेटा का ब्लॉक और इसका उपयोग नहीं करता है। इसके बजाय, यह Win32-विशिष्टप्रारूपों में मेटा-सूचना को संग्रहीत करने के लिए अन्य फ़ाइल फोर्क्स पर निर्भर करता है। OS/2 विस्तारित विशेषताओं को अभी भी Win32 प्रोग्राम द्वारा पढ़ा और लिखा जा सकता है, लेकिन डेटा को एप्लिकेशन द्वारा पूरी तरह से पार्स किया जाना चाहिए।
POSIX विस्तारित विशेषताएँ
यूनिक्स और यूनिक्स जैसी प्रणालियों पर, ext2, ext3, ext4, ReiserFS संस्करण 3, XFS, IBM जर्नलेड फाइल सिस्टम 2 (JFS2), बर्कले फास्ट फाइल सिस्टम और HFS Plus|HFS+ फाइलसिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देते हैं। इनमें नाम = मूल्य स्ट्रिंग्स की मनमाना सूची शामिल है, जहां नाम अद्वितीय हैं और इसके संबंधित नाम के माध्यम से मूल्य तक पहुंचा जा सकता है।
PRONOM अद्वितीय पहचानकर्ता (PUIDs)
PRONOM तकनीकी रजिस्ट्री #PRONOM परसिस्टेंट यूनीक आइडेंटिफ़ायर (PUID) योजना| PRONOM पर्सिस्टेंट यूनिक आइडेंटिफ़ायर (PUID) फ़ाइलप्रारूपों के लिए लगातार, अद्वितीय और स्पष्ट पहचानकर्ताओं की एक एक्स्टेंसिबल योजना है, जिसे राष्ट्रीय अभिलेखागार (यूके) द्वारा विकसित किया गया है इसकी PRONOM तकनीकी रजिस्ट्री सेवा का हिस्सा है। पीयूआईडी को उपयोग करके यूनिफॉर्म रिसोर्स पहचानकर्ता के रूप में व्यक्त किया जा सकता है info:pronom/ नामस्थान। हालांकि यूके सरकार और कुछ डिजिटल संरक्षण प्रोग्राम ों के बाहर अभी तक व्यापक रूप से उपयोग नहीं किया गया है, पीयूआईडी योजना अधिकांश वैकल्पिक योजनाओं की तुलना में अधिक ग्रैन्युलैरिटी प्रदान करती है।
माइम प्रकार
MIME प्रकार व्यापक रूप से इंटरनेट से संबंधित कई अनुप्रयोगों में और कहीं और तेजी से उपयोग किए जाते हैं, हालांकि ऑन-डिस्क प्रकार की जानकारी के लिए उनका उपयोग दुर्लभ है। इनमें पहचानकर्ताओं की एक मानकीकृत प्रणाली शामिल है (इंटरनेट असाइन किए गए नंबर प्राधिकरण द्वारा प्रबंधित) जिसमें एक प्रकार और एक उप-प्रकार शामिल है, जो स्लैश (विराम चिह्न) द्वारा अलग किया गया है - उदाहरण के लिए, text/html या image/gif. ये मूल रूप से यह पहचानने के तरीके के रूप में अभिप्रेत थे कि किस प्रकार की फ़ाइल किसी ईमेल से जुड़ी हुई थी, जो स्रोत और लक्ष्य ऑपरेटिंग सिस्टम से स्वतंत्र थी। MIME प्रकार BeOS, AmigaOS 4.0 और MorphOS पर फ़ाइलों की पहचान करते हैं, साथ ही एप्लिकेशन लॉन्चिंग के लिए अद्वितीय एप्लिकेशन हस्ताक्षरों को संग्रहीत करते हैं। AmigaOS और MorphOS में, माइम टाइप सिस्टम Amiga विशिष्ट डेटाटाइप सिस्टम के समानांतर काम करता है।
यद्यपि MIME प्रकारों के साथ समस्याएँ हैं; कई संगठनों और लोगों ने IANA के साथ ठीक से पंजीकृत किए बिना अपने स्वयं के MIME प्रकार बनाए हैं, जो कुछ मामलों में इस मानक के उपयोग को अजीब बनाता है।
फ़ाइल स्वरूप पहचानकर्ता (FFIDs)
फ़ाइल प्रारूप पहचानकर्ता एक अन्य, व्यापक रूप से उपयोग नहीं किया जाने वाला तरीका है जो फ़ाइलप्रारूपों को उनके मूल और उनकी फ़ाइल श्रेणी के अनुसार पहचानने के लिए उपयोग किया जाता है। इसे सॉफ्टवेयर के डिस्क्रिप्शन एक्सप्लोरर सूट के लिए बनाया गया था। यह फॉर्म के कई अंकों से बना होता है NNNNNNNNN-XX-YYYYYYY. पहला भाग संगठन के मूल/रखरखाव को इंगित करता है (यह संख्या कंपनी/मानक संगठन डेटाबेस में एक मान का प्रतिनिधित्व करती है), और बाद के 2 अंक हेक्साडेसिमल में फ़ाइल के प्रकार को वर्गीकृत करते हैं। अंतिम भाग फ़ाइल के सामान्य फ़ाइल नाम एक्सटेंशन या फ़ाइल की अंतर्राष्ट्रीय मानक संख्या से बना है, जो शून्य के साथ गद्देदार है। उदाहरण के लिए, PNG फ़ाइल विनिर्देशन का FFID है 000000001-31-0015948 कहाँ 31 एक छवि फ़ाइल इंगित करता है, 0015948 मानक संख्या है और 000000001 मानकीकरण के लिए अंतर्राष्ट्रीय संगठन (आईएसओ) को इंगित करता है।
फ़ाइल सामग्री आधारित प्रारूप पहचान
फ़ाइल स्वरूप की पहचान करने का एक और कम लोकप्रिय तरीका फ़ाइल प्रकारों के बीच विभिन्न पैटर्न के लिए फ़ाइल सामग्री की जांच करना है। एक फ़ाइल की सामग्री बाइट्स का एक क्रम है और एक बाइट में 256 अद्वितीय क्रमपरिवर्तन (0-255) हैं। इस प्रकार, बाइट पैटर्न की घटना की गणना करना जिसे प्रायः बाइट आवृत्ति वितरण के रूप में संदर्भित किया जाता है, फ़ाइल प्रकारों की पहचान करने के लिए विभिन्न पैटर्न देता है। कई सामग्री-आधारित फ़ाइल प्रकार पहचान योजनाएँ हैं जो फ़ाइल प्रकार के लिए प्रतिनिधि मॉडल बनाने के लिए बाइट आवृत्ति वितरण का उपयोग करती हैं और फ़ाइल प्रकारों की पहचान करने के लिए किसी भी सांख्यिकीय और डेटा माइनिंग तकनीकों का उपयोग करती हैं।[2]
फ़ाइल संरचना
किसी फ़ाइल में डेटा की संरचना करने के कई तरीके हैं। सबसे सामान्य नीचे वर्णित हैं।
असंरचित प्रारूप (कच्ची मेमोरी डंप)
पहले के फ़ाइलप्रारूपों में कच्चे डेटाप्रारूपों का उपयोग किया जाता था जिसमें फ़ाइल में एक या अधिक संरचनाओं की मेमोरी छवियों को सीधे डंप करना शामिल था।
इसमें कई कमियां हैं। जब तक मेमोरी छवियों में भविष्य के एक्सटेंशन के लिए आरक्षित स्थान नहीं होते हैं, तब तक इस प्रकार की संरचित फ़ाइल का विस्तार और सुधार करना बहुत मुश्किल होता है। यह ऐसी फ़ाइलें भी बनाता है जो एक प्लेटफ़ॉर्म या प्रोग्रामिंग भाषा के लिए विशिष्ट हो सकती हैं (उदाहरण के लिए पास्कल (प्रोग्रामिंग भाषा) स्ट्रिंग वाली संरचना को सी (प्रोग्रामिंग भाषा) में पहचाना नहीं जाता है)। दूसरी ओर, इस प्रकार की फाइलों को पढ़ने और लिखने के लिए उपकरण विकसित करना बहुत आसान है।
असंरचितप्रारूपों की सीमाओं के कारण अन्य प्रकार के फ़ाइलप्रारूपों का विकास हुआ, जिन्हें आसानी से बढ़ाया जा सकता है और एक ही समय में पिछड़े संगत हो सकते हैं।
चंक-आधारित प्रारूप
इस तरह की फ़ाइल संरचना में, डेटा का प्रत्येक टुकड़ा एक कंटेनर में एम्बेडेड होता है जो किसी तरह डेटा की पहचान करता है। कंटेनर के दायरे को किसी प्रकार के स्टार्ट- और एंड-मार्कर द्वारा, कहीं स्पष्ट लंबाई क्षेत्र द्वारा, या फ़ाइल प्रारूप की परिभाषा की निश्चित आवश्यकताओं द्वारा पहचाना जा सकता है।
1970 के दशक के दौरान, कई प्रोग्राम ों ने इस सामान्य प्रकार के प्रारूपों का उपयोग किया। उदाहरण के लिए, वर्ड-प्रोसेसर जैसे ट्राफ , एससीआरआईपीटी (मार्कअप), और मुंशी (मार्कअप भाषा) , और डेटाबेस निर्यात फाइलें जैसे अल्पविराम से अलग किए गए मान। इलेक्ट्रॉनिक आर्ट्स और कमोडोर इंटरनेशनल-अमिगा ने भी 1985 में अपने IFF (इंटरचेंज फाइल फॉर्मेट) फाइल फॉर्मेट के साथ इस प्रकार के फाइल फॉर्मेट का इस्तेमाल किया था।
एक कंटेनर को कभी-कभी चंक कहा जाता है, हालांकि चंक का अर्थ यह भी हो सकता है कि प्रत्येक टुकड़ा छोटा है, और/या उस हिस्से में अन्य टुकड़े नहीं होते हैं; कई प्रारूप उन आवश्यकताओं को लागू नहीं करते हैं।
किसी विशेष खंड की पहचान करने वाली जानकारी को कई विभिन्न चीजें कहा जा सकता है, प्रायः फ़ील्ड नाम, पहचानकर्ता, लेबल या टैग सहित शब्द। पहचानकर्ता प्रायः मानव-पठनीय होते हैं, और डेटा के कुछ हिस्सों को वर्गीकृत करते हैं: उदाहरण के लिए, एक उपनाम, पता, आयत, फ़ॉन्ट नाम, आदि के रूप में। ये डेटाबेस कुंजी या सीरियल नंबर के अर्थ में पहचानकर्ता के समान नहीं हैं ( हालांकि एक पहचानकर्ता इसकी अच्छी तरह से पहचान कर सकता है associated data ऐसी कुंजी के रूप में)।
इस प्रकार की फ़ाइल संरचना के साथ, उपकरण जो कुछ चंक पहचानकर्ताओं को नहीं जानते हैं, वे बस उन्हें छोड़ देते हैं जिन्हें वे नहीं समझते हैं। निर्भर करना छोड़े गए डेटा का वास्तविक अर्थ, यह उपयोगी हो सकता है या नहीं भी हो सकता है (सीएसएस स्पष्ट रूप से ऐसे व्यवहार को परिभाषित करता है)।
आरआईएफएफ (फाइल फॉर्मेट) (आईएफएफ के माइक्रोसॉफ्ट-आईबीएम समतुल्य), पीएनजी, जेपीईजी स्टोरेज, डीईआर (विशिष्ट एन्कोडिंग नियम) एन्कोडेड स्ट्रीम और फाइलों (जो मूल रूप से सीसीआईटीटी एक्स.409:1984 में वर्णित थे) द्वारा इस अवधारणा का बार-बार उपयोग किया गया है। और इसलिए IFF), और SDXF | स्ट्रक्चर्ड डेटा एक्सचेंज फॉर्मेट (SDXF) से पहले का है।
दरअसल, कोई भी डेटा प्रारूप होना चाहिए somehow इसके घटक भागों के महत्व की पहचान करें, और एम्बेडेड सीमा-चिह्न ऐसा करने का एक स्पष्ट तरीका है:
- MIME#MIME शीर्षलेख फ़ील्ड प्रत्येक लॉजिकल लाइन के प्रारंभ में एक कोलन से अलग किए गए लेबल के साथ ऐसा करते हैं। MIME शीर्षलेखों में अन्य MIME शीर्षलेख नहीं हो सकते हैं, हालांकि कुछ शीर्षलेखों की डेटा सामग्री में उप-भाग होते हैं जिन्हें अन्य सम्मेलनों द्वारा निकाला जा सकता है।
- अल्पविराम से अलग किए गए मान और समान फ़ाइलें प्रायः फ़ील्ड नामों के साथ हेडर रिकॉर्ड का उपयोग करके और फ़ील्ड सीमाओं को चिह्नित करने के लिए अल्पविराम के साथ ऐसा करते हैं। MIME की तरह, CSV में एक से अधिक स्तरों वाली संरचनाओं के लिए कोई प्रावधान नहीं है।
- XML और उसके संबंधियों को मोटे तौर पर एक प्रकार का चंक-आधारित प्रारूप माना जा सकता है, क्योंकि डेटा तत्वों की पहचान मार्कअप द्वारा की जाती है जो चंक आइडेंटिफ़ायर के समान है। हालांकि, इसमें XML स्कीमा और सत्यापन और सत्यापन (सॉफ्टवेयर) जैसे औपचारिक फायदे हैं, साथ ही ट्री (डेटा संरचना), निर्देशित विश्वकोश ग्राफ और चार्ट जैसे अधिक जटिल संरचनाओं का प्रतिनिधित्व करने की क्षमता है। यदि XML को चंक प्रारूप माना जाता है, तो SGML और इसके पूर्ववर्ती IBM GML ऐसेप्रारूपों के शुरुआती उदाहरणों में से हैं।
- JSON स्कीमा, क्रॉस-रेफरेंस, या बार-बार फ़ील्ड-नामों के अर्थ के लिए परिभाषा के बिना XML के समान है, और प्रायः प्रोग्रामर के लिए सुविधाजनक होता है।
- YAML JSON के समान है, लेकिन डेटा को अलग करने के लिए इंडेंटेशन का उपयोग करें और JSON या XML की तुलना में अधिक मानव-पठनीय होने का लक्ष्य रखें।
- प्रोटोकॉल बफ़र्स बदले में JSON के समान हैं, विशेष रूप से फ़ील्ड नंबरों के साथ डेटा में सीमा-चिह्नकों को प्रतिस्थापित करते हैं, जिन्हें कुछ बाहरी तंत्र द्वारा नामों से/से मैप किया जाता है।
निर्देशिका-आधारित प्रारूप
यह एक अन्य एक्स्टेंसिबल प्रारूप है, जो एक फ़ाइल सिस्टम के समान दिखता है (जोडकर परनिगरानी और उद्देश् य दस्तावेज़ वास्तविक फ़ाइल सिस्टम हैं), जहां फ़ाइल 'निर्देशिका प्रविष्टियों' से बनी होती है जिसमें फ़ाइल के भीतर डेटा का स्थान और साथ ही इसके हस्ताक्षर होते हैं ( और कुछ मामलों में इसका प्रकार)। इस प्रकार की फ़ाइल संरचनाओं के अच्छे उदाहरण डिस्क छवियां, निष्पादनयोग्य, OLE दस्तावेज़ TIFF, पुस्तकालय (कम्प्यूटिंग) हैं।
कुछ फ़ाइल स्वरूप जैसे ODT और DOCX, PKZIP-आधारित होने के कारण, दोनों खंडित हैं और एक निर्देशिका रखते हैं।[citation needed]
एक निर्देशिका-आधारित फ़ाइल स्वरूप की संरचना असंरचित या चंक-आधारितप्रारूपों की तुलना में अधिक आसानी से संशोधनों के लिए उधार देती है।[citation needed] इस प्रकार के प्रारूप की प्रकृति उपयोगकर्ताओं को सावधानी से फ़ाइलों का निर्माण करने की अनुमति देती है जो पाठक सॉफ़्टवेयर को उन चीजों को करने का कारण बनती है जो प्रारूप के लेखक कभी नहीं होने का इरादा रखते थे। इसका एक उदाहरण ज़िप बम है। निर्देशिका-आधारित फ़ाइल स्वरूप भी उन मानों का उपयोग करते हैं जो फ़ाइल में अन्य क्षेत्रों को इंगित करते हैं लेकिन यदि कुछ बाद के डेटा मान पहले पढ़े गए डेटा पर वापस जाते हैं, तो इसका परिणाम किसी भी पाठक सॉफ़्टवेयर के लिए अनंत लूप में हो सकता है जो इनपुट फ़ाइल को मान्य करता है और आँख बंद करके पाश का पालन करता है।[citation needed]
यह भी देखें
- ऑडियो फ़ाइल स्वरूप
- रासायनिक फ़ाइल स्वरूप
- निष्पादन योग्य फ़ाइलप्रारूपों की तुलना
- डिजिटल कंटेनर प्रारूप
- दस्तावेज़ फ़ाइल स्वरूप
- PRONOM तकनीकी रजिस्ट्री#DROID फ़ाइल स्वरूप पहचान उपयोगिता
- फ़ाइल (कमांड), एक फ़ाइल प्रकार की पहचान उपयोगिता
- फ़ाइल रूपांतरण
- भविष्य प्रमाण
- ग्राफिक्स फ़ाइल प्रारूप सारांश
- छवि फ़ाइल स्वरूप
- संग्रह प्रारूपों की सूची
- फ़ाइल हस्ताक्षरों की सूची
- फाइल सिग्नेचर, या मैजिक नंबरों की सूची
- फ़ाइल नाम एक्सटेंशन की सूची (वर्णमाला)
- मुफ्त फ़ाइलप्रारूपों की सूची
- मोशन और जेस्चर फ़ाइलप्रारूपों की सूची
- जादू संख्या (प्रोग्रामिंग)
- वस्तु फ़ाइल
- वीडियो फ़ाइल स्वरूप
- विंडोज़ फ़ाइल प्रकार
- फ़ाइल नाम एक्सटेंशन
संदर्भ
 | This article includes a list of general references, but it lacks sufficient corresponding inline citations. (October 2008) (Learn how and when to remove this template message) |
- ↑ PC World (23 December 2003). "Windows Tips: For Security Reasons, It Pays To Know Your File Extensions". Archived from the original on 23 April 2008. Retrieved 20 June 2008.
- ↑ "File Format Identification". Archived from the original on 2009-08-14. Retrieved 2009-07-21.
- "Extended Attribute Data Types". REXX Tips & Tricks, Version 2.80. Archived from the original on December 25, 2004. Retrieved February 9, 2005.
- "Extended Attributes used by the WPS". REXX Tips & Tricks, Version 2.80. Archived from the original on March 21, 2005. Retrieved February 9, 2005.
- "Extended Attributes - what are they and how can you use them ?". Roger Orr. Archived from the original on March 21, 2008. Retrieved February 9, 2005.
बाहरी संबंध
| Library resources about File Use |
- फ़ाइल फ़ारमैट at Curlie
- Best Practices for File Formats, US: Stanford University Libraries, Data Management Services ("The file formats you use have a direct impact on your ability to open those files at a later date and on the ability of other people to access those data")
