फ़ाइल फ़ारमैट: Difference between revisions
| Line 9: | Line 9: | ||
== विशेष विवरण == | == विशेष विवरण == | ||
फ़ाइल प्रारूपों में प्रायः एक प्रकाशित [[विनिर्देश]] होता है जो एन्कोडिंग विधि का वर्णन करता है और प्रोग्राम के इच्छित कार्यक्षमता के परीक्षण को सक्षम करता है। सभी प्रारूपों में स्वतंत्र रूप से विनिर्देश | फ़ाइल प्रारूपों में प्रायः एक प्रकाशित [[विनिर्देश]] होता है जो एन्कोडिंग विधि का वर्णन करता है और प्रोग्राम के इच्छित कार्यक्षमता के परीक्षण को सक्षम करता है। सभी प्रारूपों में स्वतंत्र रूप से विनिर्देश फाइल उपलब्ध नहीं हैं, आंशिक रूप से क्योंकि कुछ डेवलपर्स अपने विनिर्देश फाइलों को [[व्यापार रहस्य]] के रूप में देखते हैं, और आंशिक रूप से क्योंकि अन्य डेवलपर्स औपचारिक विनिर्देश फाइल को कभी भी लेखक नहीं बनाते हैं, प्रारूप का उपयोग करने वाले अन्य पहले से उपलब्ध प्रोग्रामों द्वारा उदाहरण स्थापित करते हुए प्रारूप को परिभाषित करते हैं कि कैसे ये प्रोग्राम इसका उपयोग करते हैं। | ||
यदि किसी प्रारूप का डेवलपर, मुक्त विनिर्देशों को प्रकाशित नहीं करता है, तो उस प्रकार की फ़ाइल का उपयोग करने के इच्छुक अन्य डेवलपर को [[रिवर्स इंजीनियरिंग|उत्क्रम]] अभियांत्रिकी का उपयोग करना होगा जिससे यह पता लगाया जा सके कि इसे कैसे पढ़ा जाए या प्रारूप के डेवलपर्स से शुल्क के लिए और हस्ताक्षर करके विनिर्देश | यदि किसी प्रारूप का डेवलपर, मुक्त विनिर्देशों को प्रकाशित नहीं करता है, तो उस प्रकार की फ़ाइल का उपयोग करने के इच्छुक अन्य डेवलपर को [[रिवर्स इंजीनियरिंग|उत्क्रम]] अभियांत्रिकी का उपयोग करना होगा जिससे यह पता लगाया जा सके कि इसे कैसे पढ़ा जाए या प्रारूप के डेवलपर्स से शुल्क के लिए और हस्ताक्षर करके विनिर्देश फाइल कैसे प्राप्त किया जाए। बाद वाला दृष्टिकोण तभी संभव है जब एक औपचारिक विनिर्देश दस्तावेज उपलब्ध हो। दोनों रणनीतियों के लिए महत्वपूर्ण समय, धन या दोनों की आवश्यकता होती है; इसलिए, सार्वजनिक रूप से उपलब्ध विनिर्देशों वाले फ़ाइल प्रारूपों को अधिक प्रोग्रामो द्वारा समर्थित किया जाता है। | ||
== [[पेटेंट|एकस्व]] == | == [[पेटेंट|एकस्व]] == | ||
| Line 21: | Line 21: | ||
=== फ़ाइल नाम एक्सटेंशन === | === फ़ाइल नाम एक्सटेंशन === | ||
{{main|फ़ाइल नाम एक्सटेंशन}} | {{main|फ़ाइल नाम एक्सटेंशन}} | ||
[[Microsoft Windows|माइक्रोसॉफ्ट विंडोज़, मैकओएस]], सीपी/एम, डॉस, [[OpenVMS|ओपन]] वीएमएस, और वीएम वीएम/सीएमएस सहित कई ऑपरेटिंग सिस्टम द्वारा उपयोग [[की]] जाने वाली एक लोकप्रिय विधि फ़ाइल के नाम के अंत, विशेष रूप से अंतिम अवधि के बाद के अक्षर के आधार पर उसके प्रारूप का निर्धारण करता है। फ़ाइल नाम के इस भाग को [[फ़ाइल नाम एक्सटेंशन]] के रूप में जाना जाता है। उदाहरण के लिए, एचटीएमएल | [[Microsoft Windows|माइक्रोसॉफ्ट विंडोज़, मैकओएस]], सीपी/एम, डॉस, [[OpenVMS|ओपन]] वीएमएस, और वीएम वीएम/सीएमएस सहित कई ऑपरेटिंग सिस्टम द्वारा उपयोग [[की]] जाने वाली एक लोकप्रिय विधि फ़ाइल के नाम के अंत, विशेष रूप से अंतिम अवधि के बाद के अक्षर के आधार पर उसके प्रारूप का निर्धारण करता है। फ़ाइल नाम के इस भाग को [[फ़ाइल नाम एक्सटेंशन]] के रूप में जाना जाता है। उदाहरण के लिए, एचटीएमएल फाइलों को उन नामों से पहचाना जाता है जिनके साथ समाप्त होता है {{Mono|.html}} (या {{Mono|.htm}}), और जीआईएफ छवियां {{Mono|.gif}}. मूल फ़ाइल आवंटन तालिका [[फाइल सिस्टम]] में, फ़ाइल नाम आठ-वर्ण पहचानकर्ता और तीन-वर्ण एक्सटेंशन तक सीमित थे, जिसे 8.3 फ़ाइल नाम के रूप में जाना जाता है। सीमित संख्या में तीन-अक्षर वाले एक्सटेंशन हैं, जो एक दिए गए एक्सटेंशन को एक से अधिक प्रोग्राम द्वारा उपयोग करने का कारण बन सकते हैं। कई प्रारूप अभी भी तीन-वर्ण एक्सटेंशन का उपयोग करते हैं, यद्यपि आधुनिक ऑपरेटिंग सिस्टम और एप्लिकेशन प्रोग्राम में अब यह सीमा नहीं है। चूंकि एक्सटेंशन की कोई मानक सूची नहीं है, एक से अधिक प्रारूप एक ही एक्सटेंशन का उपयोग कर सकते हैं, जो ऑपरेटिंग सिस्टम और उपयोगकर्ता दोनों को भ्रमित कर सकता है। | ||
इस दृष्टिकोण का एक आर्टिफैक्ट यह है कि सिस्टम को सरलता से एक फ़ाइल को एक अलग प्रारूप के रूप में नाम देकर सरलता से युग्मित किया जा सकता है - उदाहरण के लिए, एक एचटीएमएल फ़ाइल को सरलता से [[सादे पाठ]] {{Mono|filename.html}} को {{Mono|filename.txt}}. के रूप में संदर्भित किया जा सकता है। यद्यपि यह रणनीति विशेषज्ञ उपयोगकर्ताओं के लिए उपयोगी थी जो इस जानकारी को सरलता से समझ और परिवर्तित कर सकते थे, यह प्रायः कम तकनीकी उपयोगकर्ताओं के लिए भ्रमित करने वाला था, जो इसे गलत तरीके से नाम देकर फ़ाइल को अनुपयोगी बना सकते थे या इसे खो सकते थे। | इस दृष्टिकोण का एक आर्टिफैक्ट यह है कि सिस्टम को सरलता से एक फ़ाइल को एक अलग प्रारूप के रूप में नाम देकर सरलता से युग्मित किया जा सकता है - उदाहरण के लिए, एक एचटीएमएल फ़ाइल को सरलता से [[सादे पाठ]] {{Mono|filename.html}} को {{Mono|filename.txt}}. के रूप में संदर्भित किया जा सकता है। यद्यपि यह रणनीति विशेषज्ञ उपयोगकर्ताओं के लिए उपयोगी थी जो इस जानकारी को सरलता से समझ और परिवर्तित कर सकते थे, यह प्रायः कम तकनीकी उपयोगकर्ताओं के लिए भ्रमित करने वाला था, जो इसे गलत तरीके से नाम देकर फ़ाइल को अनुपयोगी बना सकते थे या इसे खो सकते थे। | ||
| Line 49: | Line 49: | ||
}} | }} | ||
फ़ाइल प्रारूप मेटाडेटा को सम्मिलित करने का एक विधि, जिसे प्रायः यूनिक्स और उसके उपशाखाओं के साथ जोड़ा जाता है, फ़ाइल के अंदर एक "मैजिक नंबर" संग्रहित करना है। पहले, यह शब्द फ़ाइलों की प्रारंभ में दिए गए विशेष सेट के 2-बाइट पहचानकर्ताओं के लिए उपयोग होता था, परंतु क्योंकि किसी भी बाइनरी सरणी को एक संख्या के रूप में माना जा सकता है, इसलिए फ़ाइल प्रारूप की कोई भी विशेषता जो उसे अद्वितीय रूप से पहचानती हो, पहचान के लिए उपयोग की जा सकती है। उदाहरण के लिए, जीआईएफ इमेजेज़ सदैव GIF87a या GIF89a के एएससीआईआई प्रतिष्ठान के साथ प्रारंभ होती हैं, जो इसके अनुरूप मानक पर निर्भर करता है। इस तरह के विधियों से कई फ़ाइल प्रारूप, विशेषतः सादा पाठ फ़ाइलें, इसके द्वारा पहचाना जाना कठिन होता है। उदाहरण के लिए, एचटीएमएल फ़ाइलें प्रारंभ में <html> स्ट्रिंग के साथ प्रारंभ हो सकती हैं जो मामले के आधार पर अनुसारित नहीं होती है, या ऐसे एक उचित | फ़ाइल प्रारूप मेटाडेटा को सम्मिलित करने का एक विधि, जिसे प्रायः यूनिक्स और उसके उपशाखाओं के साथ जोड़ा जाता है, फ़ाइल के अंदर एक "मैजिक नंबर" संग्रहित करना है। पहले, यह शब्द फ़ाइलों की प्रारंभ में दिए गए विशेष सेट के 2-बाइट पहचानकर्ताओं के लिए उपयोग होता था, परंतु क्योंकि किसी भी बाइनरी सरणी को एक संख्या के रूप में माना जा सकता है, इसलिए फ़ाइल प्रारूप की कोई भी विशेषता जो उसे अद्वितीय रूप से पहचानती हो, पहचान के लिए उपयोग की जा सकती है। उदाहरण के लिए, जीआईएफ इमेजेज़ सदैव GIF87a या GIF89a के एएससीआईआई प्रतिष्ठान के साथ प्रारंभ होती हैं, जो इसके अनुरूप मानक पर निर्भर करता है। इस तरह के विधियों से कई फ़ाइल प्रारूप, विशेषतः सादा पाठ फ़ाइलें, इसके द्वारा पहचाना जाना कठिन होता है। उदाहरण के लिए, एचटीएमएल फ़ाइलें प्रारंभ में <html> स्ट्रिंग के साथ प्रारंभ हो सकती हैं जो मामले के आधार पर अनुसारित नहीं होती है, या ऐसे एक उचित फाइल प्रकार परिभाषण जो <!DOCTYPE HTML> से प्रारंभ होता है, या एक्सएचटीएमएल के लिए, एक्सएमएल पहचानकर्ता जो <?xml से प्रारंभ होता है। फ़ाइलें एचटीएमएल टिप्पणियों, यादृच्छिक पाठ या कई खाली पंक्तियों के साथ प्रारंभ हो सकती हैं, परंतु फिर भी वे उपयोगी एचटीएमएल हो सकती हैं। | ||
मैजिक नंबर दृष्टिकोण प्रारूप को सही ढंग से पहचानें में बेहतर गारंटी प्रदान करता है और प्रायः फ़ाइल के बारे में अधिक सटीक जानकारी निर्धारित कर सकता है। क्योंकि संयंत्रित रूप से "मैजिक नंबर" परीक्षण कई जटिल हो सकते हैं, और प्रत्येक फ़ाइल को डेटाबेस में हर संभावना के विपरीत परीक्षण किया जाना चाहिए, इस दृष्टिकोण में तुलनात्मक अप्रभावी है, विशेष रूप से बड़ी सूचीबद्ध फ़ाइलों को प्रदर्शित करने के लिए इसके विपरीत में, फ़ाइल नाम और मेटाडेटा पर आधारित विधियों में केवल एक डेटा की जांच की आवश्यकता होती है, और इसे एक सॉर्टेड इंडेक्स के साथ मिलाया जाता है। इसके अतिरिक्त, डेटा स्वयं फ़ाइल से पढ़ा जाना चाहिए, जो निर्देशिका में संग्रहीत मेटाडेटा के सापेक्ष में लैटेंसी को बढ़ाता है।, जब फ़ाइल प्रकार इस तरह से पहचानने के लिए उपयुक्त नहीं होते हैं, तो सिस्टम को मेटाडेटा का उपयोग करना होता है। यद्यपि, यह किसी प्रोग्राम के लिए फ़ाइल की सही प्रारूप में है या नहीं की जांच करने की सबसे अच्छी विधि है, जबकि फ़ाइल का नाम या मेटाडेटा उसकी सामग्री के अलग हो सकते हैं, एक अच्छी मैजिक नंबर परीक्षण असफल होना यह सुनिश्चित करता है कि फ़ाइल या तो दोषपूर्ण है या गलत प्रकार की है। दूसरी ओर, एक मान्य मैजिक नंबर यह गारंटी नहीं देता है कि फ़ाइल दोषपूर्ण नहीं है या सही प्रकार की है। | मैजिक नंबर दृष्टिकोण प्रारूप को सही ढंग से पहचानें में बेहतर गारंटी प्रदान करता है और प्रायः फ़ाइल के बारे में अधिक सटीक जानकारी निर्धारित कर सकता है। क्योंकि संयंत्रित रूप से "मैजिक नंबर" परीक्षण कई जटिल हो सकते हैं, और प्रत्येक फ़ाइल को डेटाबेस में हर संभावना के विपरीत परीक्षण किया जाना चाहिए, इस दृष्टिकोण में तुलनात्मक अप्रभावी है, विशेष रूप से बड़ी सूचीबद्ध फ़ाइलों को प्रदर्शित करने के लिए इसके विपरीत में, फ़ाइल नाम और मेटाडेटा पर आधारित विधियों में केवल एक डेटा की जांच की आवश्यकता होती है, और इसे एक सॉर्टेड इंडेक्स के साथ मिलाया जाता है। इसके अतिरिक्त, डेटा स्वयं फ़ाइल से पढ़ा जाना चाहिए, जो निर्देशिका में संग्रहीत मेटाडेटा के सापेक्ष में लैटेंसी को बढ़ाता है।, जब फ़ाइल प्रकार इस तरह से पहचानने के लिए उपयुक्त नहीं होते हैं, तो सिस्टम को मेटाडेटा का उपयोग करना होता है। यद्यपि, यह किसी प्रोग्राम के लिए फ़ाइल की सही प्रारूप में है या नहीं की जांच करने की सबसे अच्छी विधि है, जबकि फ़ाइल का नाम या मेटाडेटा उसकी सामग्री के अलग हो सकते हैं, एक अच्छी मैजिक नंबर परीक्षण असफल होना यह सुनिश्चित करता है कि फ़ाइल या तो दोषपूर्ण है या गलत प्रकार की है। दूसरी ओर, एक मान्य मैजिक नंबर यह गारंटी नहीं देता है कि फ़ाइल दोषपूर्ण नहीं है या सही प्रकार की है। | ||
| Line 72: | Line 72: | ||
यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर एक ऐसी विधि है जिसका उपयोग मैक ओएस में विशिष्ट रूप से टाइप की गई संस्थाओं की श्रेणियों, जैसे फ़ाइल प्रारूपों की पहचान के लिए किया जाता है। इसे एप्पल निगम द्वारा ओएस टाइप के प्रतिस्थापन के रूप में विकसित किया गया था। | यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर एक ऐसी विधि है जिसका उपयोग मैक ओएस में विशिष्ट रूप से टाइप की गई संस्थाओं की श्रेणियों, जैसे फ़ाइल प्रारूपों की पहचान के लिए किया जाता है। इसे एप्पल निगम द्वारा ओएस टाइप के प्रतिस्थापन के रूप में विकसित किया गया था। | ||
यूटीआई एक [[कोर फाउंडेशन]][[ स्ट्रिंग (कंप्यूटर विज्ञान) | स्ट्रिंग]] है, जो [[ रिवर्स डीएनएस |रिवर्स डीएनएस]] स्ट्रिंग का उपयोग करता है। कुछ सामान्य और मानक टाइप public नामक | यूटीआई एक [[कोर फाउंडेशन]][[ स्ट्रिंग (कंप्यूटर विज्ञान) | स्ट्रिंग]] है, जो [[ रिवर्स डीएनएस |रिवर्स डीएनएस]] स्ट्रिंग का उपयोग करता है। कुछ सामान्य और मानक टाइप public नामक क्षेत्र का उपयोग करते हैं (उदाहरण के लिए public.png एक पोर्टेबल नेटवर्क ग्राफिक्स इमेज के लिए), जबकि अन्य क्षेत्र तृतीय-पक्ष टाइप के लिए उपयोग किए जा सकते हैं (उदाहरण के लिए com.adobe.pdf पोर्टेबल डॉक्यूमेंट फ़ॉर्मेट के लिए)। यूटीआई को एक पदानुक्रमित संरचना के भीतर परिभाषित किया जा सकता है, जिसे अनुरूपता पदानुक्रम के रूप में जाना जाता है। इस प्रकार, {{Mono|public.png}} के सुपरटाइप के अनुरूप {{Mono|public.image}} है, जो स्वयं के सुपरटाइप {{Mono|public.data}} के अनुरूप है। एक यूटीआई कई पदानुक्रमों में उपलब्ध हो सकता है, जो अत्यधिक लचीलापन प्रदान करता है। | ||
फ़ाइल प्रारूपों के अतिरिक्त, यूटीआइ का उपयोग अन्य संस्थाओं के लिए भी किया जा सकता है जो मैक ओएस में भी उपलब्ध हो सकती हैं, जिनमें सम्मिलित हैं: | फ़ाइल प्रारूपों के अतिरिक्त, यूटीआइ का उपयोग अन्य संस्थाओं के लिए भी किया जा सकता है जो मैक ओएस में भी उपलब्ध हो सकती हैं, जिनमें सम्मिलित हैं: | ||
| Line 84: | Line 84: | ||
==== वीएसएएम कैटलॉग ==== | ==== वीएसएएम कैटलॉग ==== | ||
आईबीएम ओएस/वीएस से जेड/ओएस तक, वीएसएएम कैटलॉग और वीएसएएम वॉल्यूम रिकॉर्ड आईसीएफ कैटलॉग के साथ वीएसएएम डेटासेट के प्रकार की पहचान करता है। | |||
और | |||
====वीटीसी==== | ====वीटीसी==== | ||
आईबीएम ओएस/360 से जेड/ओएस तक, वॉल्यूम टेबल ऑफ़ कंटेंट्स में एक फ़ॉर्मेट 1 या 7 डेटा समुच्चय कंट्रोल खंड द्वारा वर्णित डेटासेट के संगठन की पहचान की जाती है। | |||
==== | ==== ओएस/2 विस्तारित विशेषताएँ ==== | ||
उच्च प्रदर्शन फाइल सिस्टम, | उच्च प्रदर्शन फाइल सिस्टम, एफएटी 12, और एफएटी 16 फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देता है। इनमें एक नाम के साथ ट्रिपलेट का यादृच्छिक कूटबद्ध टाइप और एक मान सम्मिलित है, जहां नाम अद्वितीय हैं और मान 64 KB तक लंबा हो सकता है। कुछ टाइप और नामों के लिए OS/2 के अंतर्गत मानकीकृत अर्थ हैं। ऐसा ही एक डॉटटाइप है जहां फ़ाइल प्रकार निर्धारित करने के लिए .TYPE विस्तारित विशेषता का उपयोग किया जाता है। इसके मान में फ़ाइल से जुड़े एक या अधिक फ़ाइल प्रकारों की सूची सम्मिलित होती है, जिनमें से प्रत्येक फाइल एक स्ट्रिंग है, जैसे कि सादा टेक्स्ट या एचटीएमएल फाइल। इस प्रकार की फ़ाइल कई प्रकार की हो सकती है। | ||
[[NTFS]] फाइल सिस्टम OS/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, परंतु यह सुविधा केवल OS/2 सबसिस्टम (XP में उपलब्ध नहीं) का समर्थन करने के लिए उपलब्ध है, इसलिए Win32 सबसिस्टम इस जानकारी को एक अपारदर्शी के रूप में मानता है। डेटा का ब्लॉक और इसका उपयोग नहीं करता है। इसके अतिरिक्त, यह Win32-विशिष्टप्रारूपों में मेटा-सूचना को संग्रहीत करने के लिए अन्य फ़ाइल फोर्क्स पर निर्भर करता है। OS/2 विस्तारित विशेषताओं को अभी भी Win32 प्रोग्राम द्वारा पढ़ा और लिखा जा सकता है, परंतु डेटा को एप्लिकेशन द्वारा पूरी तरह से पार्स किया जाना चाहिए। | [[NTFS]] फाइल सिस्टम OS/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, परंतु यह सुविधा केवल OS/2 सबसिस्टम (XP में उपलब्ध नहीं) का समर्थन करने के लिए उपलब्ध है, इसलिए Win32 सबसिस्टम इस जानकारी को एक अपारदर्शी के रूप में मानता है। डेटा का ब्लॉक और इसका उपयोग नहीं करता है। इसके अतिरिक्त, यह Win32-विशिष्टप्रारूपों में मेटा-सूचना को संग्रहीत करने के लिए अन्य फ़ाइल फोर्क्स पर निर्भर करता है। OS/2 विस्तारित विशेषताओं को अभी भी Win32 प्रोग्राम द्वारा पढ़ा और लिखा जा सकता है, परंतु डेटा को एप्लिकेशन द्वारा पूरी तरह से पार्स किया जाना चाहिए। | ||
| Line 155: | Line 151: | ||
=== निर्देशिका-आधारित प्रारूप === | === निर्देशिका-आधारित प्रारूप === | ||
यह एक अन्य एक्स्टेंसिबल प्रारूप है, जो एक फ़ाइल सिस्टम के समान दिखता है ([[जोडकर परनिगरानी और उद्देश् य]] | यह एक अन्य एक्स्टेंसिबल प्रारूप है, जो एक फ़ाइल सिस्टम के समान दिखता है ([[जोडकर परनिगरानी और उद्देश् य]] फाइल वास्तविक फ़ाइल सिस्टम हैं), जहां फ़ाइल 'निर्देशिका प्रविष्टियों' से बनी होती है जिसमें फ़ाइल के भीतर डेटा का स्थान और साथ ही इसके हस्ताक्षर होते हैं ( और कुछ मामलों में इसका प्रकार)। इस प्रकार की फ़ाइल संरचनाओं के अच्छे उदाहरण [[डिस्क छवि]]यां, [[निष्पादन]]योग्य, OLE फाइल [[TIFF]], [[ पुस्तकालय (कम्प्यूटिंग) ]] हैं। | ||
कुछ फ़ाइल स्वरूप जैसे ODT और DOCX, [[PKZIP]]-आधारित होने के कारण, दोनों खंडित हैं और एक निर्देशिका रखते हैं।{{cn|date=December 2022}} | कुछ फ़ाइल स्वरूप जैसे ODT और DOCX, [[PKZIP]]-आधारित होने के कारण, दोनों खंडित हैं और एक निर्देशिका रखते हैं।{{cn|date=December 2022}} | ||
| Line 166: | Line 162: | ||
* [[निष्पादन योग्य फ़ाइल स्वरूपों की तुलना|निष्पादन योग्य फ़ाइलप्रारूपों की तुलना]] | * [[निष्पादन योग्य फ़ाइल स्वरूपों की तुलना|निष्पादन योग्य फ़ाइलप्रारूपों की तुलना]] | ||
* डिजिटल कंटेनर प्रारूप | * डिजिटल कंटेनर प्रारूप | ||
* [[दस्तावेज़ फ़ाइल स्वरूप]] | * [[दस्तावेज़ फ़ाइल स्वरूप|फाइल फ़ाइल स्वरूप]] | ||
* PRONOM तकनीकी रजिस्ट्री#DROID फ़ाइल स्वरूप पहचान उपयोगिता | * PRONOM तकनीकी रजिस्ट्री#DROID फ़ाइल स्वरूप पहचान उपयोगिता | ||
* [[फ़ाइल (कमांड)]], एक फ़ाइल प्रकार की पहचान उपयोगिता | * [[फ़ाइल (कमांड)]], एक फ़ाइल प्रकार की पहचान उपयोगिता | ||
Revision as of 19:10, 29 June 2023
फ़ाइल प्रारूप कंप्यूटर फ़ाइल में संग्रहीत जानकारी को कोड करने का एक मानक विधि होता है। यह निर्धारित करता है कि बिट कैसे डिजिटल संग्रहण माध्यम में जानकारी को कोड करने के लिए उपयोग होते हैं। फ़ाइल प्रारूप संपत्रित या मुक्त दोनों हो सकते हैं। कुछ फ़ाइल प्रारूप विशेष रूप से निर्दिष्ट प्रकार के डेटा के लिए प्रारूपित किए गए होते हैं: उदाहरण के लिए, पोर्टेबल नेटवर्क ग्राफ़िक्स फ़ाइल दोषरहित डेटा संपीड़न का उपयोग करके लाइन ग्राफिक्स को संग्रहित करती हैं।
यद्यपि, अन्य फ़ाइलप्रारूपों को विभिन्न प्रकार के डेटा के संग्रह के लिए प्रारूपित किए गए होते हैं,ओजीजी प्रारूप विभिन्न प्रकार की मल्टीमीडिया के लिए एक कंटेनर के रूप में कार्य कर सकता है, जिसमें ऑडियो और वीडियो की किसी भी संयोजन, पाठ उदाहरण के लिए उपशीर्षक और मेटाडेटा, सम्मिलित हो सकते हैं।
एक पाठ फ़ाइल में संभावित नियंत्रण वर्णों सहित वर्णों की कोई भी धारा हो सकती है, और विभिन्न अक्षरों को सांकेतिक अक्षरों में परिवर्तन में से एक में एन्कोड किया जाता है। कुछ फ़ाइल प्रारूप, जैसे कि एचटीएमएल, स्केलेबल वेक्टर ग्राफिक्स, और कंप्यूटर सॉफ्टवेयर का स्रोत कोड परिभाषित सिंटैक्स वाली टेक्स्ट फ़ाइलें हैं जो उन्हें विशिष्ट उद्देश्यों के लिए उपयोग करने की अनुमति देती हैं।
विशेष विवरण
फ़ाइल प्रारूपों में प्रायः एक प्रकाशित विनिर्देश होता है जो एन्कोडिंग विधि का वर्णन करता है और प्रोग्राम के इच्छित कार्यक्षमता के परीक्षण को सक्षम करता है। सभी प्रारूपों में स्वतंत्र रूप से विनिर्देश फाइल उपलब्ध नहीं हैं, आंशिक रूप से क्योंकि कुछ डेवलपर्स अपने विनिर्देश फाइलों को व्यापार रहस्य के रूप में देखते हैं, और आंशिक रूप से क्योंकि अन्य डेवलपर्स औपचारिक विनिर्देश फाइल को कभी भी लेखक नहीं बनाते हैं, प्रारूप का उपयोग करने वाले अन्य पहले से उपलब्ध प्रोग्रामों द्वारा उदाहरण स्थापित करते हुए प्रारूप को परिभाषित करते हैं कि कैसे ये प्रोग्राम इसका उपयोग करते हैं।
यदि किसी प्रारूप का डेवलपर, मुक्त विनिर्देशों को प्रकाशित नहीं करता है, तो उस प्रकार की फ़ाइल का उपयोग करने के इच्छुक अन्य डेवलपर को उत्क्रम अभियांत्रिकी का उपयोग करना होगा जिससे यह पता लगाया जा सके कि इसे कैसे पढ़ा जाए या प्रारूप के डेवलपर्स से शुल्क के लिए और हस्ताक्षर करके विनिर्देश फाइल कैसे प्राप्त किया जाए। बाद वाला दृष्टिकोण तभी संभव है जब एक औपचारिक विनिर्देश दस्तावेज उपलब्ध हो। दोनों रणनीतियों के लिए महत्वपूर्ण समय, धन या दोनों की आवश्यकता होती है; इसलिए, सार्वजनिक रूप से उपलब्ध विनिर्देशों वाले फ़ाइल प्रारूपों को अधिक प्रोग्रामो द्वारा समर्थित किया जाता है।
एकस्व
कॉपीराइट के अतिरिक्त एकस्व कानून का उपयोग प्रायः फ़ाइल स्वरूप की सुरक्षा के लिए किया जाता है। यद्यपि अमेरिकी कानून के अंतर्गत फ़ाइलप्रारूपों के एकस्व की सीधे अनुमति नहीं है, कुछ प्रारूप एकस्व किए गए विधिकलन का उपयोग करके डेटा को एन्कोड करते हैं। उदाहरण के लिए, जीआईएफ फ़ाइल प्रारूप के साथ संपीड़न का उपयोग करने के लिए किसी एकस्व कलन विधि के उपयोग की आवश्यकता होती है, और यद्यपि एकस्व मालिक ने प्रारंभ में अपने एकस्व को लागू नहीं किया था, बाद में उन्होंने रॉयल्टी भुगतान एकत्र करना प्रारंभ कर दिया। इसके परिणामस्वरूप जीआईएफ के उपयोग में उल्लेखनीय कमी आई है, और वैकल्पिक पोर्टेबल नेटवर्क ग्राफिक्स प्रारूप के विकास के लिए आंशिक रूप से उत्तरदायी है। यद्यपि, जीआईएफ एकस्व अमेरिका में 2003 के मध्य में और दुनिया भर में 2004 के मध्य में समाप्त हो गया।
फ़ाइल प्रकार की पहचान करना
विभिन्न ऑपरेटिंग सिस्टम ने पारंपरिक रूप से एक विशेष फ़ाइल के प्रारूप को निर्धारित करने के लिए विभिन्न दृष्टिकोण अपनाए हैं, प्रत्येक दृष्टिकोण के अपने लाभ और हानि हैं। अधिकांश आधुनिक ऑपरेटिंग सिस्टम और व्यक्तिगत अनुप्रयोगों को विदेशी फ़ाइलप्रारूपों को पढ़ने के लिए निम्नलिखित सभी दृष्टिकोणों का उपयोग करने की आवश्यकता होती है, यदि उनके साथ पूरी तरह से कार्य नहीं किया जाता है।
फ़ाइल नाम एक्सटेंशन
माइक्रोसॉफ्ट विंडोज़, मैकओएस, सीपी/एम, डॉस, ओपन वीएमएस, और वीएम वीएम/सीएमएस सहित कई ऑपरेटिंग सिस्टम द्वारा उपयोग की जाने वाली एक लोकप्रिय विधि फ़ाइल के नाम के अंत, विशेष रूप से अंतिम अवधि के बाद के अक्षर के आधार पर उसके प्रारूप का निर्धारण करता है। फ़ाइल नाम के इस भाग को फ़ाइल नाम एक्सटेंशन के रूप में जाना जाता है। उदाहरण के लिए, एचटीएमएल फाइलों को उन नामों से पहचाना जाता है जिनके साथ समाप्त होता है .html (या .htm), और जीआईएफ छवियां .gif. मूल फ़ाइल आवंटन तालिका फाइल सिस्टम में, फ़ाइल नाम आठ-वर्ण पहचानकर्ता और तीन-वर्ण एक्सटेंशन तक सीमित थे, जिसे 8.3 फ़ाइल नाम के रूप में जाना जाता है। सीमित संख्या में तीन-अक्षर वाले एक्सटेंशन हैं, जो एक दिए गए एक्सटेंशन को एक से अधिक प्रोग्राम द्वारा उपयोग करने का कारण बन सकते हैं। कई प्रारूप अभी भी तीन-वर्ण एक्सटेंशन का उपयोग करते हैं, यद्यपि आधुनिक ऑपरेटिंग सिस्टम और एप्लिकेशन प्रोग्राम में अब यह सीमा नहीं है। चूंकि एक्सटेंशन की कोई मानक सूची नहीं है, एक से अधिक प्रारूप एक ही एक्सटेंशन का उपयोग कर सकते हैं, जो ऑपरेटिंग सिस्टम और उपयोगकर्ता दोनों को भ्रमित कर सकता है।
इस दृष्टिकोण का एक आर्टिफैक्ट यह है कि सिस्टम को सरलता से एक फ़ाइल को एक अलग प्रारूप के रूप में नाम देकर सरलता से युग्मित किया जा सकता है - उदाहरण के लिए, एक एचटीएमएल फ़ाइल को सरलता से सादे पाठ filename.html को filename.txt. के रूप में संदर्भित किया जा सकता है। यद्यपि यह रणनीति विशेषज्ञ उपयोगकर्ताओं के लिए उपयोगी थी जो इस जानकारी को सरलता से समझ और परिवर्तित कर सकते थे, यह प्रायः कम तकनीकी उपयोगकर्ताओं के लिए भ्रमित करने वाला था, जो इसे गलत तरीके से नाम देकर फ़ाइल को अनुपयोगी बना सकते थे या इसे खो सकते थे।
इसने विंडोज़ और मैक ओएस के अधिकांश संस्करणों को फाइलों को सूचीबद्ध करते समय एक्सटेंशन को छिपाने का नेतृत्व किया। यह उपयोगकर्ता को गलती से फ़ाइल प्रकार को बदलने से रोकता है, और विशेषज्ञ उपयोगकर्ताओं को इस सुविधा को बंद करने और एक्सटेंशन प्रदर्शित करने की अनुमति देता है।
एक्सटेंशन को छिपाने से, एक ही फ़ोल्डर में दो या अधिक अद्वितीय फ़ाइल नामों की उपस्थिति का अनुभव हो सकता है। उदाहरण के रूप में, किसी कंपनी के लोगो को दोनों .eps प्रारूप में (प्रकाशन के लिए) और .png प्रारूप में वेबसाइटों के लिए आवश्यक हो सकता है। एक्सटेंशन दिखाए जाने पर, ये अद्वितीय फ़ाइल नाम के रूप में प्रकट होंगे: "CompanyLogo.eps" और "CompanyLogo.png"। दूसरी ओर, एक्सटेंशन को छिपाने से दोनों "CompanyLogo" के रूप में प्रदर्शित होंगे, जो भ्रम का कारण बन सकता है।
एक्सटेंशन छुपाने से सुरक्षा जोखिम भी हो सकता है।[1]उदाहरण के लिए, कोई दुर्भाग्यपूर्ण उपयोगकर्ता एक एग्ज़िक्यूटेबल प्रोग्राम को एक नाम जैसे "Holiday photo.jpg.exe" देने के बाद बना सकता है। ".exe" छिपा रहेगा और एक असंदेही उपयोगकर्ता "Holiday photo.jpg" देखेगा, जो जेपीईजी छवि के रूप में प्रकट होगी और सामान्यतः कंप्यूटर को क्षति पहुंचाने के लिए असमर्थ होगी। यद्यपि,ऑपरेटिंग सिस्टम फ़ाइल के वास्तविक एक्सटेंशन को देख सकता है और प्रोग्राम को चला सकता है, जिससे कंप्यूटर को क्षति पहुंचाने की संभावना होती है। एक्सटेंशन को छिपाने से, जो फ़ाइल के वास्तविक प्रारूप को दर्शाने के लिए उपयोगकर्ता को प्रदर्शित नहीं किया जाता है, उस फ़ाइल के बारे में कोई जानकारी स्पष्ट रूप से जांच किए बिना नहीं निकाली जा सकती है। यह एक सुरक्षा संबंधी समस्या हो सकती है और उपयोगकर्ताओं को सतर्क रहने की आवश्यकता होती है।कुछ ऑपरेटिंग सिस्टम एक्ज़ेक्यूटेबल फ़ाइल्स (.exe) के लिए आइकन निर्धारण करते हैं और यदि एक प्रोग्राम में आइकन को संग्रहीत किया जाता है, तो वह आइकन सामान्यतः जेपीईजी छवि को प्रतिष्ठित करने के लिए प्रयुक्त एक आइकन के साथ ओवरराइड किया जा सकता है, जिससे प्रोग्राम एक छवि की तरह दिखाई देगा। इससे उपयोगकर्ता को धोखा देना संभव होता है और उन्हें पहचानने में कठिनाई हो सकती है। यह एक और सुरक्षा संबंधी चिंता का कारण हो सकता है, और उपयोगकर्ताओं को सतर्क रहने की आवश्यकता होती है। कुछ माइक्रोसॉफ्ट वर्ड मैक्रो वायरस टेम्पलेट प्रारूप में वर्ड फ़ाइल बनाते हैं और इसे एक.doc विस्तार नाम से सहेजते हैं। चूँकि वर्ड सामान्यतः एक्सटेंशन की उपेक्षा करता है और फ़ाइल के प्रारूप को देखता है, ये टेम्प्लेट के रूप में खुलेंगे, निष्पादित होंगे और वायरस फैलाएंगे। यह विंडोज सिस्टम के लिए एक व्यावहारिक समस्या का प्रतिनिधित्व करता है जहां डिफ़ॉल्ट रूप से एक्सटेंशन-छिपाना प्रारंभ होता है।
आंतरिक मेटाडेटा
फ़ाइल प्रारूप की पहचान करने की दूसरी विधि, फ़ाइल के अंदर संग्रहीत प्रारूप के बारे में जानकारी का उपयोग करना है, या तो इस उद्देश्य के लिए जानकारी या स्ट्रिंग गैर-पाठ स्ट्रिंग्स जो सदैव कुछ फ़ाइलों में विशिष्ट स्थानों में होती हैं। चूंकि उनका पता लगाने का सबसे सरल स्थान प्रारंभ में है, ऐसे क्षेत्र को सामान्यतः फ़ाइल हेडर कहा जाता है जब यह कुछ बाइट्स से अधिक होता है, या मैजिक नंबर अगर यह केवल कुछ बाइट्स लंबा होता है।
फाइल हेडर
हेडर में निहित मेटाडेटा सामान्यतःफ़ाइल के प्रारंभ में संग्रहीत होते हैं, परंतु अन्य क्षेत्रों में भी उपलब्ध हो सकते हैं, प्रायः अंत सहित, फ़ाइल प्रारूप या डेटा के प्रकार के आधार पर टेक्स्ट-आधारित फाइलों में सामान्यतः कैरेक्टर-आधारित हेडर होते हैं, जबकि बाइनरी फॉर्मेट में सामान्यतःबाइनरी हेडर होते हैं, यद्यपि यह कोई नियम नहीं है। टेक्स्ट-आधारित फ़ाइल हेडर सामान्यतःअधिक स्थान लेते हैं, परंतु मानव-पठनीय होने के कारण, उन्हें टेक्स्ट एडिटर या हेक्साडेसिमल एडिटर जैसे सरल सॉफ़्टवेयर का उपयोग करके सरलता से जांचा जा सकता है।
फ़ाइल हैडर में फ़ाइल प्रारूप की पहचान के साथ-साथ फ़ाइल और उसकी सामग्री के बारे में मेटाडेटा भी हो सकती है। उदाहरण के लिए, अधिकांश छवि फ़ाइल में छवि प्रारूप, आकार, रेज़ोल्यूशन और रंग स्थान के बारे में जानकारी संग्रहित की जाती है, और ऐच्छिक रूप से तथ्य संग्रहित की जा सकती है जैसे कि छवि किसने बनाई है, कब और कहां बनाई गई है, कौन सा कैमरा मॉडल और फोटोग्राफिक सेटिंग्स इत्यादि का उपयोग किया गया है। ऐसे मेटाडेटा को फ़ाइल को लोड करते समय और उसके बाद कोई सॉफ़्टवेयर जो फ़ाइल को पढ़ रहा है या इंटरप्रिट कर रहा है, के द्वारा उपयोग किया जा सकता है।
फ़ाइल हैडर्स का उपयोग ऑपरेटिंग सिस्टम द्वारा फ़ाइल के बारे में तत्काल जानकारी इकट्ठा करने के लिए किया जा सकता है, परंतु ऐसा करने से संगठन मेमोरी में सीधे पढ़ने के सापेक्ष में अधिक कंप्यूटर संसाधनों का उपयोग किया जाता है। उदाहरण के लिए, जब एक ग्राफिक फ़ाइल प्रबंधक को फ़ोल्डर की सामग्री प्रदर्शित करनी होती है, तो इसे उचित आइकन प्रदर्शित करने के लिए इसे कई फ़ाइलों के हैडर्स को पढ़ना होता है, परंतु ये हेडर भंडारण माध्यम पर विभिन्न स्थानों पर स्थित होंगे, जिससे उन्हें पहुंचने में अधिक समय लगेगा। एक फ़ोल्डर जिसमें संक्षेप जानकारी के रूप में थंबनेल जानकारी जैसे जटिल मेटाडेटा वाली कई फ़ाइलें हों, उन्हें प्रदर्शित करने से पहले बहुत समय लग सकता है।
यदि हेडर बाइनरी रूप में हार्ड-कोड किया जाता है और हेडर को पहचानने के लिए जटिल व्याख्या की आवश्यकता होती है, विशेषतः मेटाडेटा सामग्री की सुरक्षा के लिए, तो इससे फ़ाइल प्रारूप को गलत तरीके से समझा जा सकता है। इससे प्राथमिकता में यह संकेतित करता है कि फ़ाइल प्रारूप की समझ में कठिनाई हो सकती है। यह अवश्यकता के विपरीत हो सकता है कि हेडर का अविरामी रूप में लिखा गया हो या गलतियों से प्रभावित हो जाए। इसके परिणामस्वरूप, मेटाडेटा में क्षति हो सकती है जो अत्यंत खराब मामलों में फ़ाइल को अपठित बना सकती है।
फ़ाइल हेडर के और जटिल उदाहरण हैं वे जो व्रैपर या कंटेनर फ़ाइल प्रारूपों के लिए उपयोग होते हैं।
मैजिक नंबर
फ़ाइल प्रारूप मेटाडेटा को सम्मिलित करने का एक विधि, जिसे प्रायः यूनिक्स और उसके उपशाखाओं के साथ जोड़ा जाता है, फ़ाइल के अंदर एक "मैजिक नंबर" संग्रहित करना है। पहले, यह शब्द फ़ाइलों की प्रारंभ में दिए गए विशेष सेट के 2-बाइट पहचानकर्ताओं के लिए उपयोग होता था, परंतु क्योंकि किसी भी बाइनरी सरणी को एक संख्या के रूप में माना जा सकता है, इसलिए फ़ाइल प्रारूप की कोई भी विशेषता जो उसे अद्वितीय रूप से पहचानती हो, पहचान के लिए उपयोग की जा सकती है। उदाहरण के लिए, जीआईएफ इमेजेज़ सदैव GIF87a या GIF89a के एएससीआईआई प्रतिष्ठान के साथ प्रारंभ होती हैं, जो इसके अनुरूप मानक पर निर्भर करता है। इस तरह के विधियों से कई फ़ाइल प्रारूप, विशेषतः सादा पाठ फ़ाइलें, इसके द्वारा पहचाना जाना कठिन होता है। उदाहरण के लिए, एचटीएमएल फ़ाइलें प्रारंभ में <html> स्ट्रिंग के साथ प्रारंभ हो सकती हैं जो मामले के आधार पर अनुसारित नहीं होती है, या ऐसे एक उचित फाइल प्रकार परिभाषण जो <!DOCTYPE HTML> से प्रारंभ होता है, या एक्सएचटीएमएल के लिए, एक्सएमएल पहचानकर्ता जो <?xml से प्रारंभ होता है। फ़ाइलें एचटीएमएल टिप्पणियों, यादृच्छिक पाठ या कई खाली पंक्तियों के साथ प्रारंभ हो सकती हैं, परंतु फिर भी वे उपयोगी एचटीएमएल हो सकती हैं।
मैजिक नंबर दृष्टिकोण प्रारूप को सही ढंग से पहचानें में बेहतर गारंटी प्रदान करता है और प्रायः फ़ाइल के बारे में अधिक सटीक जानकारी निर्धारित कर सकता है। क्योंकि संयंत्रित रूप से "मैजिक नंबर" परीक्षण कई जटिल हो सकते हैं, और प्रत्येक फ़ाइल को डेटाबेस में हर संभावना के विपरीत परीक्षण किया जाना चाहिए, इस दृष्टिकोण में तुलनात्मक अप्रभावी है, विशेष रूप से बड़ी सूचीबद्ध फ़ाइलों को प्रदर्शित करने के लिए इसके विपरीत में, फ़ाइल नाम और मेटाडेटा पर आधारित विधियों में केवल एक डेटा की जांच की आवश्यकता होती है, और इसे एक सॉर्टेड इंडेक्स के साथ मिलाया जाता है। इसके अतिरिक्त, डेटा स्वयं फ़ाइल से पढ़ा जाना चाहिए, जो निर्देशिका में संग्रहीत मेटाडेटा के सापेक्ष में लैटेंसी को बढ़ाता है।, जब फ़ाइल प्रकार इस तरह से पहचानने के लिए उपयुक्त नहीं होते हैं, तो सिस्टम को मेटाडेटा का उपयोग करना होता है। यद्यपि, यह किसी प्रोग्राम के लिए फ़ाइल की सही प्रारूप में है या नहीं की जांच करने की सबसे अच्छी विधि है, जबकि फ़ाइल का नाम या मेटाडेटा उसकी सामग्री के अलग हो सकते हैं, एक अच्छी मैजिक नंबर परीक्षण असफल होना यह सुनिश्चित करता है कि फ़ाइल या तो दोषपूर्ण है या गलत प्रकार की है। दूसरी ओर, एक मान्य मैजिक नंबर यह गारंटी नहीं देता है कि फ़ाइल दोषपूर्ण नहीं है या सही प्रकार की है।
स्क्रिप्ट फ़ाइलों में सो-कॉल्ड शिबैंग लाइनें एक विशेष परिस्थिति हैं जो मैजिक नंबर की एक विशेष प्रकार हैं। यहां, मैजिक नंबर मानव-पठनीय पाठ होता है जो एक विशेष कमांड इंटरप्रेटर को पहचानता है और कमांड इंटरप्रेटर को पास करने के लिए विकल्पों को निर्दिष्ट करता है।
मैजिक नंबरों का उपयोग करने वाला एक अन्य ऑपरेटिंग सिस्टम अमिगाओएस है, जहां मैजिक नंबरों को मैजिक कुकीज़ कहा जाता था और हंक निष्पादन योग्य फ़ाइल प्रारूप में निष्पादनयोग्य प्रोग्राम को पहचानने के लिए एक मानक प्रणाली के रूप में अपनाया गया था और एकल प्रोग्राम, उपकरणों और उपयोगिताओं को उनकी सहेजी गई डेटा फ़ाइलों के साथ स्वचालित रूप से निपटने के लिए भी संदर्भित किया गया था। डेटा सहेजते और लोड करते समय किसी अन्य प्रकार की फ़ाइल प्रकार इस सिस्टम को तब अमिगा सपोर्ट और मेंटेनेंस सॉफ्टवेयर डेटाटाइप्स रिकग्निशन सिस्टम के साथ प्रवर्धित किया गया था। एक अन्य विधि फोरसीसी विधि थी, जो मैकिंटोश पर ओएस टाइप में उत्पन्न हुई थी, जिसे बाद में इंटरचेंज फ़ाइल स्वरूप और डेरिवेटिव द्वारा अनुकूलित किया गया था।
बाहरी मेटाडेटा
फ़ाइल के प्रारूप को संग्रहीत करने का एक अंतिम विधि फ़ाइल सिस्टम में प्रारूप के बारे में जानकारी को स्पष्ट रूप से फ़ाइल के भीतर संग्रहीत करना है।
यह दृष्टिकोण मेटाडेटा को मुख्य डेटा और नाम दोनों से अलग रखता है, परंतु फ़ाइल नाम एक्सटेंशन या मैजिक नंबरों की तुलना में कम में स्थानांतरेयन भी करता है, क्योंकि प्रारूप को फ़ाइल सिस्टम से फ़ाइल सिस्टम में बदलना पड़ता है। जबकि यह फ़ाइल नाम एक्सटेंशन के साथ एक हद तक सही है - उदाहरण के लिए, एमएस-डॉस विभाजन तालिका के साथ संगतता के लिए एमएस-डॉस की तीन वर्ण सीमा - भंडारण के अधिकांश रूपों में फ़ाइल के डेटा और नाम की लगभग समतुल्य परिभाषा होती है, परंतु ऐसा भी हो सकता है की आगे के मेटाडेटा का भिन्न या कोई प्रतिनिधित्व न होता हो।
ध्यान दें कि ज़िप फ़ाइलें या संग्रह फ़ाइलें मेटाडेटा को संभालने की समस्या को हल करती हैं। एक यूटिलिटी प्रोग्राम प्रत्येक फ़ाइल के बारे में मेटाडेटा के साथ-साथ एक नई फ़ाइल के विस्तार के साथ कई फ़ाइलों को एक साथ इकट्ठा करता है। नई फ़ाइल भी संपीड़ित और संभवतः एन्क्रिप्ट की गई है, परंतु अब फाइल ट्रांसफर प्रोटोकॉल ट्रांसमिशन द्वारा ऑपरेटिंग सिस्टम में एकल फाइल के रूप में ट्रांसमिसिबल है या अटैचमेंट के रूप में ईमेल द्वारा भेजी गई है। गंतव्य पर, प्राप्त एकल फ़ाइल को उपयोगी होने के लिए एक संगत उपयोगिता द्वारा अनज़िप करना पड़ता है। ज़िप फ़ाइलों या संग्रह फ़ाइलों का उपयोग करके मेटाडेटा को संभालने की समस्या इस तरह हल हो जाती है।
मैक ओएस टाइप-कोड
मैक ओएस ऑपरेटिंग सिस्टम 'पदानुक्रमित फ़ाइल सिस्टम' प्रत्येक फ़ाइल के लिए निर्देशिका प्रविष्टि के भाग के रूप में निर्माता कोड और कोड टाइप के लिए कोड संग्रहीत करता है। इन कोड को ओ.एस.टाइप कहा जाता है। ये कोड कोई भी 4-बाइट अनुक्रम हो सकते हैं परंतु प्रायः चुने जाते थे जिससे एएससीआईआई प्रतिनिधित्व अर्थपूर्ण वर्णों का अनुक्रम बना सके, जैसे कि एप्लिकेशन के नाम का संक्षिप्त नाम या डेवलपर के आद्याक्षर निर्मित कर सके। उदाहरण के लिए एक हाइपर कार्ड स्टैक फ़ाइल WILD और एक प्रकार का STAK. का निर्माता होता है। BBEdit टेक्स्ट एडिटर में वाक्यांश R*chवास्तविकता में इसके मूल प्रोग्रामर, रिच सेगल, के लिए निर्माता कोड को संदर्भित करता है। प्रकार कोड फ़ाइल के प्रारूप को निर्दिष्ट करता है, जबकि निर्माता कोड उपयोगकर्ता द्वारा डबल-क्लिक करने पर इसे खोलने के लिए डिफ़ॉल्ट प्रोग्राम निर्दिष्ट करता है। उदाहरण के लिए, उपयोगकर्ता के पास टाइप कोड के साथ कई टेक्स्ट फाइलें हो सकती हैं TEXT, परंतु विभिन्न निर्माता कोड होने के कारण प्रत्येक एक अलग प्रोग्राम में खुलता है। इस सुविधा का उद्देश्य था, उदाहरण के लिए, मानव-पठनीय सादा-पाठ फ़ाइलें सामान्य-उद्देश्य वाले पाठ संपादक में खोली जा सकती हैं, जबकि प्रोग्रामिंग या एचटीएमएल कोड फ़ाइलें एक विशेष संपादक या एकीकृत विकास वातावरण में खुलती हैं। यद्यपि, यह सुविधा प्रायः उपयोगकर्ता भ्रम का स्रोत थी, क्योंकि फाइलों पर डबल-क्लिक करने पर कौन सा प्रोग्राम लॉन्च होगा, यह प्रायः अप्रत्याशित होता था। रिस्क एक समान प्रणाली का उपयोग करता है, जिसमें 12-बिट संख्या सम्मिलित होती है जिसे विवरण तालिका में देखा जा सकता है। हेक्साडेसिमल संख्या FF5 का उपनाम है PoScript, परिशिष्ट भाग फ़ाइल का प्रतिनिधित्व करता है।
मैक ओएस यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (यूटीआई)
यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर एक ऐसी विधि है जिसका उपयोग मैक ओएस में विशिष्ट रूप से टाइप की गई संस्थाओं की श्रेणियों, जैसे फ़ाइल प्रारूपों की पहचान के लिए किया जाता है। इसे एप्पल निगम द्वारा ओएस टाइप के प्रतिस्थापन के रूप में विकसित किया गया था।
यूटीआई एक कोर फाउंडेशन स्ट्रिंग है, जो रिवर्स डीएनएस स्ट्रिंग का उपयोग करता है। कुछ सामान्य और मानक टाइप public नामक क्षेत्र का उपयोग करते हैं (उदाहरण के लिए public.png एक पोर्टेबल नेटवर्क ग्राफिक्स इमेज के लिए), जबकि अन्य क्षेत्र तृतीय-पक्ष टाइप के लिए उपयोग किए जा सकते हैं (उदाहरण के लिए com.adobe.pdf पोर्टेबल डॉक्यूमेंट फ़ॉर्मेट के लिए)। यूटीआई को एक पदानुक्रमित संरचना के भीतर परिभाषित किया जा सकता है, जिसे अनुरूपता पदानुक्रम के रूप में जाना जाता है। इस प्रकार, public.png के सुपरटाइप के अनुरूप public.image है, जो स्वयं के सुपरटाइप public.data के अनुरूप है। एक यूटीआई कई पदानुक्रमों में उपलब्ध हो सकता है, जो अत्यधिक लचीलापन प्रदान करता है।
फ़ाइल प्रारूपों के अतिरिक्त, यूटीआइ का उपयोग अन्य संस्थाओं के लिए भी किया जा सकता है जो मैक ओएस में भी उपलब्ध हो सकती हैं, जिनमें सम्मिलित हैं:
- पेस्टबोर्ड डेटा
- निर्देशिका
- अनुवाद योग्य प्रकार
- बंडल
- फ्रेमवर्क
- स्ट्रीमिंग डेटा
- उपनाम और सहसंबंध
वीएसएएम कैटलॉग
आईबीएम ओएस/वीएस से जेड/ओएस तक, वीएसएएम कैटलॉग और वीएसएएम वॉल्यूम रिकॉर्ड आईसीएफ कैटलॉग के साथ वीएसएएम डेटासेट के प्रकार की पहचान करता है।
वीटीसी
आईबीएम ओएस/360 से जेड/ओएस तक, वॉल्यूम टेबल ऑफ़ कंटेंट्स में एक फ़ॉर्मेट 1 या 7 डेटा समुच्चय कंट्रोल खंड द्वारा वर्णित डेटासेट के संगठन की पहचान की जाती है।
ओएस/2 विस्तारित विशेषताएँ
उच्च प्रदर्शन फाइल सिस्टम, एफएटी 12, और एफएटी 16 फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देता है। इनमें एक नाम के साथ ट्रिपलेट का यादृच्छिक कूटबद्ध टाइप और एक मान सम्मिलित है, जहां नाम अद्वितीय हैं और मान 64 KB तक लंबा हो सकता है। कुछ टाइप और नामों के लिए OS/2 के अंतर्गत मानकीकृत अर्थ हैं। ऐसा ही एक डॉटटाइप है जहां फ़ाइल प्रकार निर्धारित करने के लिए .TYPE विस्तारित विशेषता का उपयोग किया जाता है। इसके मान में फ़ाइल से जुड़े एक या अधिक फ़ाइल प्रकारों की सूची सम्मिलित होती है, जिनमें से प्रत्येक फाइल एक स्ट्रिंग है, जैसे कि सादा टेक्स्ट या एचटीएमएल फाइल। इस प्रकार की फ़ाइल कई प्रकार की हो सकती है।
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")
