फ़ाइल फ़ारमैट: Difference between revisions
No edit summary |
|||
| (12 intermediate revisions by 3 users not shown) | |||
| 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 35: | Line 35: | ||
==== फाइल हेडर ==== | ==== फाइल हेडर ==== | ||
[[हेडर (कंप्यूटिंग)|हेडर]] में निहित मेटाडेटा सामान्यतःफ़ाइल के प्रारंभ में संग्रहीत होते हैं, परंतु अन्य क्षेत्रों में भी उपलब्ध हो सकते हैं, प्रायः अंत सहित, फ़ाइल प्रारूप या डेटा के प्रकार के आधार पर टेक्स्ट-आधारित फाइलों में सामान्यतः कैरेक्टर-आधारित हेडर होते हैं, जबकि बाइनरी फॉर्मेट में | [[हेडर (कंप्यूटिंग)|हेडर]] में निहित मेटाडेटा सामान्यतःफ़ाइल के प्रारंभ में संग्रहीत होते हैं, परंतु अन्य क्षेत्रों में भी उपलब्ध हो सकते हैं, प्रायः अंत सहित, फ़ाइल प्रारूप या डेटा के प्रकार के आधार पर टेक्स्ट-आधारित फाइलों में सामान्यतः कैरेक्टर-आधारित हेडर होते हैं, जबकि बाइनरी फॉर्मेट में सामान्यतः बाइनरी हेडर होते हैं, यद्यपि यह कोई नियम नहीं है। टेक्स्ट-आधारित फ़ाइल हेडर सामान्यतःअधिक स्थान लेते हैं, परंतु मानव-पठनीय होने के कारण, उन्हें टेक्स्ट एडिटर या हेक्साडेसिमल एडिटर जैसे सरल सॉफ़्टवेयर का उपयोग करके सरलता से जांचा जा सकता है। | ||
फ़ाइल हैडर में फ़ाइल प्रारूप की पहचान के साथ-साथ फ़ाइल और उसकी | फ़ाइल हैडर में फ़ाइल प्रारूप की पहचान के साथ-साथ फ़ाइल और उसकी कंटेंट के बारे में मेटाडेटा भी हो सकती है। उदाहरण के लिए, अधिकांश छवि फ़ाइल में छवि प्रारूप, आकार, रेज़ोल्यूशन और रंग स्थान के बारे में जानकारी संग्रहित की जाती है, और ऐच्छिक रूप से तथ्य संग्रहित की जा सकती है जैसे कि छवि किसने बनाई है, कब और कहां बनाई गई है, कौन सा कैमरा मॉडल और फोटोग्राफिक सेटिंग्स इत्यादि का उपयोग किया गया है। ऐसे मेटाडेटा को फ़ाइल को लोड करते समय और उसके बाद कोई सॉफ़्टवेयर जो फ़ाइल को पढ़ रहा है या इंटरप्रिट कर रहा है, के द्वारा उपयोग किया जा सकता है। | ||
फ़ाइल हैडर्स का उपयोग ऑपरेटिंग सिस्टम द्वारा फ़ाइल के बारे में तत्काल जानकारी इकट्ठा करने के लिए किया जा सकता है, परंतु ऐसा करने से संगठन मेमोरी में सीधे पढ़ने के सापेक्ष में अधिक कंप्यूटर संसाधनों का उपयोग किया जाता है। उदाहरण के लिए, जब एक ग्राफिक फ़ाइल प्रबंधक को फ़ोल्डर की | फ़ाइल हैडर्स का उपयोग ऑपरेटिंग सिस्टम द्वारा फ़ाइल के बारे में तत्काल जानकारी इकट्ठा करने के लिए किया जा सकता है, परंतु ऐसा करने से संगठन मेमोरी में सीधे पढ़ने के सापेक्ष में अधिक कंप्यूटर संसाधनों का उपयोग किया जाता है। उदाहरण के लिए, जब एक ग्राफिक फ़ाइल प्रबंधक को फ़ोल्डर की कंटेंट प्रदर्शित करनी होती है, तो इसे उचित आइकन प्रदर्शित करने के लिए इसे कई फ़ाइलों के हैडर्स को पढ़ना होता है, परंतु ये हेडर भंडारण माध्यम पर विभिन्न स्थानों पर स्थित होंगे, जिससे उन्हें पहुंचने में अधिक समय लगेगा। एक फ़ोल्डर जिसमें संक्षेप जानकारी के रूप में थंबनेल जानकारी जैसे जटिल मेटाडेटा वाली कई फ़ाइलें हों, उन्हें प्रदर्शित करने से पहले बहुत समय लग सकता है। | ||
यदि हेडर बाइनरी रूप में हार्ड-कोड किया जाता है और हेडर को पहचानने के लिए जटिल व्याख्या की आवश्यकता होती है, विशेषतः मेटाडेटा | यदि हेडर बाइनरी रूप में हार्ड-कोड किया जाता है और हेडर को पहचानने के लिए जटिल व्याख्या की आवश्यकता होती है, विशेषतः मेटाडेटा कंटेंट की सुरक्षा के लिए, तो इससे फ़ाइल प्रारूप को गलत तरीके से समझा जा सकता है। इससे प्राथमिकता में यह संकेतित करता है कि फ़ाइल प्रारूप की समझ में कठिनाई हो सकती है। यह अवश्यकता के विपरीत हो सकता है कि हेडर का अविरामी रूप में लिखा गया हो या गलतियों से प्रभावित हो जाए। इसके परिणामस्वरूप, मेटाडेटा में क्षति हो सकती है जो अत्यंत खराब मामलों में फ़ाइल को अपठित बना सकती है। | ||
फ़ाइल हेडर के और जटिल उदाहरण हैं वे जो व्रैपर या कंटेनर फ़ाइल प्रारूपों के लिए उपयोग होते हैं। | फ़ाइल हेडर के और जटिल उदाहरण हैं वे जो व्रैपर या कंटेनर फ़ाइल प्रारूपों के लिए उपयोग होते हैं। | ||
| 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 तक लंबा हो सकता है। कुछ टाइप और नामों के लिए ओएस/2 के अंतर्गत मानकीकृत अर्थ हैं। ऐसा ही एक डॉटटाइप है जहां फ़ाइल प्रकार निर्धारित करने के लिए .TYPE विस्तारित विशेषता का उपयोग किया जाता है। इसके मान में फ़ाइल से जुड़े एक या अधिक फ़ाइल प्रकारों की सूची सम्मिलित होती है, जिनमें से प्रत्येक फाइल एक स्ट्रिंग है, जैसे कि सादा टेक्स्ट या एचटीएमएल फाइल। इस प्रकार की फ़ाइल कई प्रकार की हो सकती है। | ||
[[NTFS]] फाइल सिस्टम | [[NTFS|एनटीएफएस]] फाइल सिस्टम ओएस/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, परंतु यह सुविधा केवल ओएस/2 सबसिस्टम का समर्थन करने के लिए उपलब्ध है, इसलिए विन32 सबसिस्टम इस जानकारी को एक अपारदर्शी के रूप में प्रदर्शित करता है। डेटा का खंड और इसका उपयोग नहीं करता है। इसके अतिरिक्त, यह विन32-विशिष्टप्रारूपों में मेटा-सूचना को संग्रहीत करने के लिए अन्य फ़ाइल फोर्क्स पर निर्भर करता है। ओएस/2 विस्तारित विशेषताओं को अभी भी विन32 प्रोग्राम द्वारा पढ़ा और लिखा जा सकता है, परंतु डेटा को एप्लिकेशन द्वारा पूरी तरह से पार्स किया जाना चाहिए। | ||
==== | ==== पीओएसआइएक्स [[विस्तार]] विशेषताएँ ==== | ||
यूनिक्स और यूनिक्स जैसी प्रणालियों पर, [[ext2]], | यूनिक्स और यूनिक्स जैसी प्रणालियों पर,ईएक्सटी[[ext2|2]],ईएक्सटी3,ईएक्सटी[[ext4|4]], [[ReiserFS|रेसेरएफएस]] संस्करण 3, [[XFS|एक्सएफएस]], आइबीएम जर्नलेड फाइल सिस्टम 2, [[बर्कले फास्ट फाइल सिस्टम]] और [[HFS Plus|एचएफएस]] प्लस फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देते हैं। इनमें नाम = मूल्य स्ट्रिंग्स की यादृच्छिक सूची सम्मिलित है, जहां नाम अद्वितीय हैं और इसके संबंधित नाम के माध्यम से मूल्य तक पहुंचा जा सकता है। | ||
==== | ==== प्रोनोम अद्वितीय पहचानकर्ता ==== | ||
[[PRONOM तकनीकी रजिस्ट्री]] | [[PRONOM तकनीकी रजिस्ट्री|प्रोनोम तकनीकी रजिस्ट्री]] परसिस्टेंट यूनीक आइडेंटिफ़ायर योजना, प्रोनोम पर्सिस्टेंट यूनिक आइडेंटिफ़ायर फ़ाइलप्रारूपों के लिए निरंतर, अद्वितीय और स्पष्ट पहचानकर्ताओं की एक एक्स्टेंसिबल योजना है, जिसे [[राष्ट्रीय अभिलेखागार (यूके)|राष्ट्रीय अभिलेखागार]] द्वारा विकसित किया गया है इसकी प्रोनोम तकनीकी रजिस्ट्री सेवा का भाग है। पीयूआईडी को उपयोग करके [[यूनिफॉर्म रिसोर्स पहचानकर्ता]] के रूप में व्यक्त किया जा सकता है। यद्यपि यूके सरकार और कुछ [[डिजिटल संरक्षण]] प्रोग्राम के बाहर अभी तक व्यापक रूप से उपयोग नहीं किया गया है। पीयूआईडी योजना अधिकांश वैकल्पिक योजनाओं के सापेक्ष में अधिक कणिकता प्रदान करती है। | ||
==== [[माइम]] प्रकार ==== | ==== [[माइम]] प्रकार ==== | ||
[[माइम]] प्रकार इंटरनेट से संबंधित अनेक अनुप्रयोगों में व्यापक रूप से प्रयोग किए जाते हैं, और इनका प्रयोग बढ़ते हुए अन्य स्थानों में भी होता है, हालांकि इनका इंटरनेट पर जानकारी संबंधी डिस्क पर उपयोग अत्यधिक दुर्लभ होता है। इनमें पहचानकर्ताओं की एक मानकीकृत प्रणाली सम्मिलित है जिसमें एक प्रकार और एक उप-प्रकार सम्मिलित है, जो [[स्लैश (विराम चिह्न)|स्लैश]] द्वारा अलग किया गया है - उदाहरण के लिए, {{Mono|text/html}} या {{Mono|image/gif}}. इन्हें मूलतः ईमेल के साथ संलग्न होने वाले फ़ाइल के प्रकार की पहचान करने के उद्देश्य से बनाया गया था, जो स्रोत और लक्ष्य ऑपरेटिंग सिस्टम से स्वतंत्र था। [[माइम]] प्रकार बीओएस, अमीगाओएस 4.0 और मॉर्फओएस पर फ़ाइलों की पहचान करते हैं, साथ ही एप्लिकेशन लॉन्चिंग के लिए अद्वितीय आवेदन हस्ताक्षर संग्रहीत करते हैं। अमीगाओएस और मॉर्फओएस में, माइम प्रकार प्रणाली अमीगा-विशिष्ट डेटाटाइप प्रणाली के साथ समानांतर रूप से कार्य करती है। | |||
माइम प्रकार के साथ कुछ समस्याएं होती हैं; कई संगठन और लोग आईएएनए को उनके द्वारा स्वयं के माइम प्रकार बनाने की जानकारी सही ढंग से पंजीकृत नहीं करते हैं, जिससे कुछ विषयो में इस मानक का उपयोग असामान्य बना देता है। | |||
==== फ़ाइल स्वरूप पहचानकर्ता ( | ==== फ़ाइल स्वरूप पहचानकर्ता (एफएफआईडीस) ==== | ||
फ़ाइल प्रारूप पहचानकर्ता एक अन्य, व्यापक रूप से उपयोग नहीं किया जाने वाला विधि है जो फ़ाइलप्रारूपों को उनके मूल और उनकी फ़ाइल श्रेणी के अनुसार पहचानने के लिए उपयोग किया जाता है। इसे सॉफ्टवेयर के | फ़ाइल प्रारूप पहचानकर्ता एक अन्य, व्यापक रूप से उपयोग नहीं किया जाने वाला विधि है जो फ़ाइलप्रारूपों को उनके मूल और उनकी फ़ाइल श्रेणी के अनुसार पहचानने के लिए उपयोग किया जाता है। इसे सॉफ्टवेयर के विवरण एक्सप्लोरर सूट के लिए निर्मित किया गया था। यह {{code|NNNNNNNNN-XX-YYYYYYY}} फॉर्म के कई अंकों से बना होता है। पहला भाग संगठन के मूल/रखरखाव को इंगित करता है यह संख्या कंपनी/मानक संगठन डेटाबेस में एक मान का प्रतिनिधित्व करती है, और बाद के 2 अंक हेक्साडेसिमल में फ़ाइल के प्रकार को वर्गीकृत करते हैं। अंतिम भाग फ़ाइल के सामान्य फ़ाइल नाम एक्सटेंशन या फ़ाइल की अंतर्राष्ट्रीय मानक संख्या से बना है, जो शून्य के साथ संदर्भित है। उदाहरण के लिए, पीएनजी फ़ाइल विनिर्देशन का एफएफआईडी {{code|000000001-31-0015948}} है जहाँ {{code|31}} एक छवि फ़ाइल इंगित करता है, {{code|0015948}} मानक संख्या है और {{code|000000001}} मानकीकरण के लिए अंतर्राष्ट्रीय संगठन (आईएसओ) को इंगित करता है। | ||
==== फ़ाइल | ==== फ़ाइल कंटेंट पर आधारित प्रारूप पहचान, ==== | ||
फ़ाइल | फ़ाइल प्रारूप की पहचान करने का एक और कम लोकप्रिय विधि फ़ाइल प्रकारों के बीच विभिन्न पैटर्न के लिए फ़ाइल कंटेंट की जांच करना है। एक फ़ाइल की कंटेंट बाइट्स का एक क्रम है और एक बाइट में 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 119: | ||
== फ़ाइल संरचना == | == फ़ाइल संरचना == | ||
किसी फ़ाइल में डेटा की संरचना करने के कई | किसी फ़ाइल में डेटा की संरचना करने के कई विधि हैं। सबसे सामान्य नीचे वर्णित हैं। | ||
=== असंरचित प्रारूप ( | === असंरचित प्रारूप (अपरिष्कृत मेमोरी डंप) === | ||
पहले के | पहले के फ़ाइल प्रारूपों में अपरिष्कृत डेटा प्रारूपों का उपयोग किया जाता था जिसमें फ़ाइल में एक या अधिक संरचनाओं की मेमोरी छवियों को सीधे डंप करना सम्मिलित था। | ||
इसके कई हानियाँ होती हैं। यदि मेमोरी इमेज में भविष्य के विस्तारों के लिए रिजर्व स्थान नहीं होता है, तो इस प्रकार के संरचित फ़ाइल को विस्तारित और सुधारना बहुत कठिन हो जाता है। यह ऐसी फ़ाइलें बना देता है जो एक प्लेटफ़ॉर्म या प्रोग्रामिंग भाषा के लिए विशिष्ट हो सकती हैं उदाहरण के लिए, पैस्कल स्ट्रिंग को सी में उसी रूप में मान्य नहीं माना जाता है। दूसरी ओर, इस प्रकार की फाइलों को पढ़ने और लिखने के लिए उपकरण विकसित करना बहुत सरल है। | |||
असंरचित प्रारूपों की सीमाओं ने उन्हें पिछले संगत प्रारंभ करने और सुधारने के लिए अन्य प्रकार के फ़ाइल प्रारूपों के विकास की ओर प्रेरित किया। ये प्रारूप सरलता से विस्तारित किए जा सकते हैं और उसी समय पिछले संगत रह सकते हैं। | |||
=== चंक-आधारित प्रारूप === | === चंक-आधारित प्रारूप === | ||
इस तरह की फ़ाइल संरचना में, डेटा का प्रत्येक | इस तरह की फ़ाइल संरचना में, डेटा का प्रत्येक भाग एक कंटेनर में संयोजित होता है जो किसी तरह डेटा की पहचान करता है। कंटेनर के सीमा को किसी प्रकार के प्रारंभ तथा अंत चिन्ह द्वारा, स्पष्ट लंबाई क्षेत्र द्वारा, या फ़ाइल प्रारूप की परिभाषा की निश्चित आवश्यकताओं द्वारा पहचाना जा सकता है। | ||
1970 के दशक के | 1970 के दशक के समय, कई प्रोग्रामों ने इस सामान्य प्रकार के प्रारूपों का उपयोग किया। उदाहरण के लिए, वर्ड-प्रोसेसर जैसे [[ ट्राफ ]], एससीआरआईपीटी, तथा [[ मुंशी (मार्कअप भाषा) |स्क्रीब]], और डेटाबेस निर्यात फाइल जैसे अल्पविराम से अलग किए गए मान। [[इलेक्ट्रॉनिक आर्ट]] और [[कमोडोर इंटरनेशनल]]-[[अमिगा]] ने भी 1985 में अपने आइएफएफ फाइल प्रारूप के साथ इस प्रकार के फाइल प्रारूपों का उपयोग किया था। | ||
एक कंटेनर को कभी-कभी चंक कहा जाता है, यद्यपि चंक का अर्थ यह भी हो सकता है कि प्रत्येक | एक कंटेनर को कभी-कभी चंक कहा जाता है, यद्यपि चंक का अर्थ यह भी हो सकता है कि प्रत्येक भाग छोटा है, और/या उस भाग में अन्य टुकड़े नहीं होते हैं; कई प्रारूप उन आवश्यकताओं को लागू नहीं करते हैं। | ||
एक विशेष "चंक" की पहचान करने वाली जानकारी को प्रायः विभिन्न वस्तुओ के नाम से कहा जा सकता है, जिसमें "फ़ील्ड नाम", "पहचानकर्ता", "लेबल", या "टैग" जैसे शब्द सम्मिलित होते हैं। पहचानकर्ता प्रायः मानव-पठनीय होते हैं और डेटा के भागों को वर्गीकृत करते हैं: उदाहरण के लिए, "उपनाम", "पता", "आयत", "फ़ॉन्ट नाम", आदि। ये एक डेटाबेस की कुंजी या क्रमांक के पहचानकर्ताओं के परिप्रेक्ष्य में उन्ही के समान नहीं होतें है। यद्यपि एक पहचानकर्ता प्रायः अपने संबंधित डेटा को एक ऐसे कुंजी के रूप में पहचानता है। | |||
इस प्रकार | इस प्रकार के फ़ाइल संरचना के साथ, ऐसे टूल्स जो कुछ चंक पहचानकर्ताओं को नहीं जानते हैं, वे उन्हें जो उन्हें समझ नहीं पाते हैं, उन्हें छोड़ देते हैं। छोड़े गए डेटा के असली अर्थ के आधार पर, यह सहायक हो सकता है या नहीं हो सकता है। [[सीएसएस]] ने विशेष रूप से ऐसा व्यवहार परिभाषित किया है। | ||
छोड़े गए डेटा | |||
यह अवधारणा रिफ, पीएनजी, जेपेग संग्रह, डीईआर एन्कोडिंग स्ट्रीम और फ़ाइलों जिन्हें पहले सीसीआईटीटी X.409:1984 में वर्णित किया गया था और इसलिए IFF से पहले हैं, और संरचित डेटा विनिमय प्रारूप द्वारा बार-बार उपयोग की गई है। | |||
वास्तव में, किसी भी डेटा प्रारूप को किसी भी तरीके से अपने घटक भागों के महत्व की पहचान करनी चाहिए, और एम्बेडेड बाउंड्री-मार्कर्स इसे करने का एक स्पष्ट तरीका निम्नलिखित है: | |||
* | * माइम हैडर्स इसे प्रत्येक तार्किक पंक्ति द्वयशीर्षक के साथ प्रारंभ करते हैं। माइम हैडर्स में अन्य माइम हैडर्स सम्मिलित नहीं हो सकते हैं, यद्यपि कुछ हैडर्स के डेटा सामग्री में उप-भाग हो सकते हैं जिन्हें अन्य अनुशासनों द्वारा प्राप्त किया जा सकता है। | ||
* | * सीएसवी और इसके समकक्ष फ़ाइलें अक्सर फ़ील्ड नामों के साथ हेडर रिकॉर्ड का उपयोग करके इसे करती हैं, और फ़ील्ड सीमाओं को चिह्नित करने के लिए अल्पविराम का उपयोग करती हैं। माइम की तरह, सीएसवी में एक से अधिक स्तर वाले संरचनाओं के लिए कोई प्रावधान नहीं होता है। | ||
* | * एक्सएमएल और उसके संबंधियों को सामान्यतः एक प्रकार का चंक-आधारित प्रारूप माना जा सकता है, क्योंकि डेटा तत्वों की पहचान मार्कअप द्वारा की जाती है जो चंक आइडेंटिफ़ायर के समान है। यद्यपि, इसमें एक्सएमएल स्कीमा और [[सत्यापन और सत्यापन (सॉफ्टवेयर)|सत्यापन सॉफ्टवेयर]] जैसे औपचारिक लाभ हैं, साथ ही ट्री, निर्देशित विश्वकोश आरेख और [[चार्ट]] जैसे अधिक जटिल संरचनाओं का प्रतिनिधित्व करने की क्षमता है। यदि एक्सएमएल को चंक प्रारूप माना जाता है, तो [[SGML|एसजीएमएल]] और इसके पूर्ववर्ती [[IBM GML|आइबीएम जीएमएल]] आदि ऐसे प्रारूपों के प्रारंभी उदाहरणों में से हैं। | ||
* [[JSON]] स्कीमा, | * [[JSON|जेएसओएन]] एक्सएमएल के समान है लेकिन इसमें स्कीमा, पारसंदर्भ या दोहरे फ़ील्ड नामों के अर्थ के लिए कोई परिभाषा नहीं होती है, और इसका प्रोग्रामरों के लिए उपयोग प्रायः सुविधाजनक होता है। | ||
* [[YAML]] | * [[YAML|वाईएएमएल]] जेएसओएन के समान है, परंतु डेटा चंकों को अलग करने के लिए इंडेंटेशन का उपयोग करता है और जेएसओएन या एक्सएमएल से अधिक मानव-पठनीय होने का उद्देश्य रखता है। | ||
* [[प्रोटोकॉल बफ़र्स]] | * [[प्रोटोकॉल बफ़र्स]] उल्लेखनीय रूप से जेएसओएन के समान हैं, विशेषतः डेटा में बाउंड्री-मार्कर्स को फ़ील्ड नंबर्स के साथ परिवर्तित करते हैं, जो किसी बाहरी यांत्रिकी द्वारा नामों के लिए प्राप्त किए जाते हैं। | ||
=== निर्देशिका-आधारित प्रारूप === | === निर्देशिका-आधारित प्रारूप === | ||
यह एक | यह एक और विस्तारयोग्य प्रारूप है, जो एक फ़ाइल सिस्टम की तरह अत्यधिक समान होता है ओएलई फ़ाइल वास्तव में फ़ाइल सिस्टम होते हैं, जहां फ़ाइल 'निर्देशिका प्रविष्टियाँ' से मिलकर बनी होती है जो फ़ाइल में डेटा की स्थानांतरण की जगह, उसके हस्ताक्षर और कुछ विषयो में इसके प्रकार को सम्मिलित करती हैं। इन प्रकार के फ़ाइल संरचनाओं के अच्छे उदाहरण हैं डिस्क इमेज, कार्यकारी, ओएलई फ़ाइल, टिफ, लाइब्रेरी आदि। | ||
कुछ फ़ाइल | कुछ फ़ाइल प्रारूप जैसे ओडीटी और डॉक्स, [[PKZIP|पीकेज़िप]] पर आधारित होने के कारण, चंकों में विभाजित होते हैं और एक निर्देशक का उपयोग करते हैं। | ||
निर्देशिका-आधारित फ़ाइल प्रारूप की संरचना अनुरूपता या चंक-आधारित प्रारूपों के सापेक्ष में सरलता से संशोधनों के लिए योग्य होती है। इस प्रकार के प्रारूप की प्रकृति उपयोगकर्ताओं को फ़ाइलें सतर्कता पूर्वक बना सकती है जिससे पाठक सॉफ़्टवेयर को कुछ ऐसी कार्रवाई करनी पड़ती है जिसे प्रारूप के लेखकों की योजना में नहीं था। इसका एक उदाहरण है जिपबॉम्ब। निर्देशिका-आधारित फ़ाइल प्रारूप भी मानों का उपयोग करते हैं जो फ़ाइल में अन्य क्षेत्रों का उपयोग करते हैं, परंतु यदि कोई बाद का डेटा मान पूर्व में पढ़े गए डेटा के समान होता है, तो यह पढ़ने वाले सॉफ़्टवेयर के लिए एक अनंत लूप का परिणाम हो सकता है जो मानता है कि निविष्ट फ़ाइल मान्य है और अनंत लूप का समर्थन करता है। | |||
== यह भी देखें == | == यह भी देखें == | ||
| Line 166: | Line 161: | ||
* [[निष्पादन योग्य फ़ाइल स्वरूपों की तुलना|निष्पादन योग्य फ़ाइलप्रारूपों की तुलना]] | * [[निष्पादन योग्य फ़ाइल स्वरूपों की तुलना|निष्पादन योग्य फ़ाइलप्रारूपों की तुलना]] | ||
* डिजिटल कंटेनर प्रारूप | * डिजिटल कंटेनर प्रारूप | ||
* [[दस्तावेज़ फ़ाइल स्वरूप]] | * [[दस्तावेज़ फ़ाइल स्वरूप|फाइल फ़ाइल स्वरूप]] | ||
* PRONOM तकनीकी रजिस्ट्री#DROID फ़ाइल स्वरूप पहचान उपयोगिता | * PRONOM तकनीकी रजिस्ट्री#DROID फ़ाइल स्वरूप पहचान उपयोगिता | ||
* [[फ़ाइल (कमांड)]], एक फ़ाइल प्रकार की पहचान उपयोगिता | * [[फ़ाइल (कमांड)]], एक फ़ाइल प्रकार की पहचान उपयोगिता | ||
| Line 229: | Line 224: | ||
}} | }} | ||
* {{curlie|/Computers/Data_Formats/}} | * {{curlie|/Computers/Data_Formats/}} | ||
* {{citation |url=http://library.stanford.edu/research/data-management-services/data-best-practices/best-practices-file-formats |title=Best Practices for File Formats |publisher=[[Stanford University Libraries]], Data Management Services |location=US }} ("The file formats you use have a direct impact on your ability to open | * {{citation |url=http://library.stanford.edu/research/data-management-services/data-best-practices/best-practices-file-formats |title=Best Practices for File Formats |publisher=[[Stanford University Libraries]], Data Management Services |location=US }} ("The file formats you use have a direct impact on your ability to open thओएसe files at a later date and on the ability of other people to access thओएसe data") | ||
{{Computer files}} | {{Computer files}} | ||
{{Authority control}} | {{Authority control}} | ||
{{DEFAULTSORT:File format}} | {{DEFAULTSORT:File format}} | ||
[[Category:All articles lacking in-text citations|File format]] | |||
[[Category:Articles lacking in-text citations from October 2008|File format]] | |||
[[Category: | [[Category:Articles with Curlie links|File format]] | ||
[[Category:Created On 14/06/2023]] | [[Category:Articles with hatnote templates targeting a nonexistent page|File format]] | ||
[[Category:Articles with invalid date parameter in template|File format]] | |||
[[Category:Collapse templates|File format]] | |||
[[Category:Created On 14/06/2023|File format]] | |||
[[Category:Lua-based templates|File format]] | |||
[[Category:Machine Translated Page|File format]] | |||
[[Category:Missing redirects|File format]] | |||
[[Category:Navigational boxes| ]] | |||
[[Category:Navigational boxes without horizontal lists|File format]] | |||
[[Category:Pages with script errors|File format]] | |||
[[Category:Sidebars with styles needing conversion|File format]] | |||
[[Category:Template documentation pages|Documentation/doc]] | |||
[[Category:Templates Vigyan Ready|File format]] | |||
[[Category:Templates generating microformats|File format]] | |||
[[Category:Templates that add a tracking category|File format]] | |||
[[Category:Templates that are not mobile friendly|File format]] | |||
[[Category:Templates that generate short descriptions|File format]] | |||
[[Category:Templates using TemplateData|File format]] | |||
[[Category:Wikipedia metatemplates|File format]] | |||
[[Category:कंप्यूटर फ़ाइल स्वरूप| कंप्यूटर फ़ाइल स्वरूप ]] | |||
Latest revision as of 11:31, 2 July 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 तक लंबा हो सकता है। कुछ टाइप और नामों के लिए ओएस/2 के अंतर्गत मानकीकृत अर्थ हैं। ऐसा ही एक डॉटटाइप है जहां फ़ाइल प्रकार निर्धारित करने के लिए .TYPE विस्तारित विशेषता का उपयोग किया जाता है। इसके मान में फ़ाइल से जुड़े एक या अधिक फ़ाइल प्रकारों की सूची सम्मिलित होती है, जिनमें से प्रत्येक फाइल एक स्ट्रिंग है, जैसे कि सादा टेक्स्ट या एचटीएमएल फाइल। इस प्रकार की फ़ाइल कई प्रकार की हो सकती है।
एनटीएफएस फाइल सिस्टम ओएस/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, परंतु यह सुविधा केवल ओएस/2 सबसिस्टम का समर्थन करने के लिए उपलब्ध है, इसलिए विन32 सबसिस्टम इस जानकारी को एक अपारदर्शी के रूप में प्रदर्शित करता है। डेटा का खंड और इसका उपयोग नहीं करता है। इसके अतिरिक्त, यह विन32-विशिष्टप्रारूपों में मेटा-सूचना को संग्रहीत करने के लिए अन्य फ़ाइल फोर्क्स पर निर्भर करता है। ओएस/2 विस्तारित विशेषताओं को अभी भी विन32 प्रोग्राम द्वारा पढ़ा और लिखा जा सकता है, परंतु डेटा को एप्लिकेशन द्वारा पूरी तरह से पार्स किया जाना चाहिए।
पीओएसआइएक्स विस्तार विशेषताएँ
यूनिक्स और यूनिक्स जैसी प्रणालियों पर,ईएक्सटी2,ईएक्सटी3,ईएक्सटी4, रेसेरएफएस संस्करण 3, एक्सएफएस, आइबीएम जर्नलेड फाइल सिस्टम 2, बर्कले फास्ट फाइल सिस्टम और एचएफएस प्लस फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देते हैं। इनमें नाम = मूल्य स्ट्रिंग्स की यादृच्छिक सूची सम्मिलित है, जहां नाम अद्वितीय हैं और इसके संबंधित नाम के माध्यम से मूल्य तक पहुंचा जा सकता है।
प्रोनोम अद्वितीय पहचानकर्ता
प्रोनोम तकनीकी रजिस्ट्री परसिस्टेंट यूनीक आइडेंटिफ़ायर योजना, प्रोनोम पर्सिस्टेंट यूनिक आइडेंटिफ़ायर फ़ाइलप्रारूपों के लिए निरंतर, अद्वितीय और स्पष्ट पहचानकर्ताओं की एक एक्स्टेंसिबल योजना है, जिसे राष्ट्रीय अभिलेखागार द्वारा विकसित किया गया है इसकी प्रोनोम तकनीकी रजिस्ट्री सेवा का भाग है। पीयूआईडी को उपयोग करके यूनिफॉर्म रिसोर्स पहचानकर्ता के रूप में व्यक्त किया जा सकता है। यद्यपि यूके सरकार और कुछ डिजिटल संरक्षण प्रोग्राम के बाहर अभी तक व्यापक रूप से उपयोग नहीं किया गया है। पीयूआईडी योजना अधिकांश वैकल्पिक योजनाओं के सापेक्ष में अधिक कणिकता प्रदान करती है।
माइम प्रकार
माइम प्रकार इंटरनेट से संबंधित अनेक अनुप्रयोगों में व्यापक रूप से प्रयोग किए जाते हैं, और इनका प्रयोग बढ़ते हुए अन्य स्थानों में भी होता है, हालांकि इनका इंटरनेट पर जानकारी संबंधी डिस्क पर उपयोग अत्यधिक दुर्लभ होता है। इनमें पहचानकर्ताओं की एक मानकीकृत प्रणाली सम्मिलित है जिसमें एक प्रकार और एक उप-प्रकार सम्मिलित है, जो स्लैश द्वारा अलग किया गया है - उदाहरण के लिए, text/html या image/gif. इन्हें मूलतः ईमेल के साथ संलग्न होने वाले फ़ाइल के प्रकार की पहचान करने के उद्देश्य से बनाया गया था, जो स्रोत और लक्ष्य ऑपरेटिंग सिस्टम से स्वतंत्र था। माइम प्रकार बीओएस, अमीगाओएस 4.0 और मॉर्फओएस पर फ़ाइलों की पहचान करते हैं, साथ ही एप्लिकेशन लॉन्चिंग के लिए अद्वितीय आवेदन हस्ताक्षर संग्रहीत करते हैं। अमीगाओएस और मॉर्फओएस में, माइम प्रकार प्रणाली अमीगा-विशिष्ट डेटाटाइप प्रणाली के साथ समानांतर रूप से कार्य करती है।
माइम प्रकार के साथ कुछ समस्याएं होती हैं; कई संगठन और लोग आईएएनए को उनके द्वारा स्वयं के माइम प्रकार बनाने की जानकारी सही ढंग से पंजीकृत नहीं करते हैं, जिससे कुछ विषयो में इस मानक का उपयोग असामान्य बना देता है।
फ़ाइल स्वरूप पहचानकर्ता (एफएफआईडीस)
फ़ाइल प्रारूप पहचानकर्ता एक अन्य, व्यापक रूप से उपयोग नहीं किया जाने वाला विधि है जो फ़ाइलप्रारूपों को उनके मूल और उनकी फ़ाइल श्रेणी के अनुसार पहचानने के लिए उपयोग किया जाता है। इसे सॉफ्टवेयर के विवरण एक्सप्लोरर सूट के लिए निर्मित किया गया था। यह NNNNNNNNN-XX-YYYYYYY फॉर्म के कई अंकों से बना होता है। पहला भाग संगठन के मूल/रखरखाव को इंगित करता है यह संख्या कंपनी/मानक संगठन डेटाबेस में एक मान का प्रतिनिधित्व करती है, और बाद के 2 अंक हेक्साडेसिमल में फ़ाइल के प्रकार को वर्गीकृत करते हैं। अंतिम भाग फ़ाइल के सामान्य फ़ाइल नाम एक्सटेंशन या फ़ाइल की अंतर्राष्ट्रीय मानक संख्या से बना है, जो शून्य के साथ संदर्भित है। उदाहरण के लिए, पीएनजी फ़ाइल विनिर्देशन का एफएफआईडी 000000001-31-0015948 है जहाँ 31 एक छवि फ़ाइल इंगित करता है, 0015948 मानक संख्या है और 000000001 मानकीकरण के लिए अंतर्राष्ट्रीय संगठन (आईएसओ) को इंगित करता है।
फ़ाइल कंटेंट पर आधारित प्रारूप पहचान,
फ़ाइल प्रारूप की पहचान करने का एक और कम लोकप्रिय विधि फ़ाइल प्रकारों के बीच विभिन्न पैटर्न के लिए फ़ाइल कंटेंट की जांच करना है। एक फ़ाइल की कंटेंट बाइट्स का एक क्रम है और एक बाइट में 256 अद्वितीय क्रम परिवर्तन (0-255) हैं। इस प्रकार, बाइट पैटर्न की घटना की गणना करना जिसे प्रायः बाइट आवृत्ति वितरण के रूप में संदर्भित किया जाता है, फ़ाइल प्रकारों की पहचान करने के लिए विभिन्न पैटर्न देता है। कई कंटेंट-आधारित फ़ाइल प्रकार पहचान योजनाएँ हैं जो फ़ाइल प्रकार के लिए प्रतिनिधि प्रारूप बनाने के लिए बाइट आवृत्ति वितरण का उपयोग करती हैं और फ़ाइल प्रकारों की पहचान करने के लिए किसी भी सांख्यिकीय और डेटा माइनिंग तकनीकों का उपयोग करती हैं।[2]
फ़ाइल संरचना
किसी फ़ाइल में डेटा की संरचना करने के कई विधि हैं। सबसे सामान्य नीचे वर्णित हैं।
असंरचित प्रारूप (अपरिष्कृत मेमोरी डंप)
पहले के फ़ाइल प्रारूपों में अपरिष्कृत डेटा प्रारूपों का उपयोग किया जाता था जिसमें फ़ाइल में एक या अधिक संरचनाओं की मेमोरी छवियों को सीधे डंप करना सम्मिलित था।
इसके कई हानियाँ होती हैं। यदि मेमोरी इमेज में भविष्य के विस्तारों के लिए रिजर्व स्थान नहीं होता है, तो इस प्रकार के संरचित फ़ाइल को विस्तारित और सुधारना बहुत कठिन हो जाता है। यह ऐसी फ़ाइलें बना देता है जो एक प्लेटफ़ॉर्म या प्रोग्रामिंग भाषा के लिए विशिष्ट हो सकती हैं उदाहरण के लिए, पैस्कल स्ट्रिंग को सी में उसी रूप में मान्य नहीं माना जाता है। दूसरी ओर, इस प्रकार की फाइलों को पढ़ने और लिखने के लिए उपकरण विकसित करना बहुत सरल है।
असंरचित प्रारूपों की सीमाओं ने उन्हें पिछले संगत प्रारंभ करने और सुधारने के लिए अन्य प्रकार के फ़ाइल प्रारूपों के विकास की ओर प्रेरित किया। ये प्रारूप सरलता से विस्तारित किए जा सकते हैं और उसी समय पिछले संगत रह सकते हैं।
चंक-आधारित प्रारूप
इस तरह की फ़ाइल संरचना में, डेटा का प्रत्येक भाग एक कंटेनर में संयोजित होता है जो किसी तरह डेटा की पहचान करता है। कंटेनर के सीमा को किसी प्रकार के प्रारंभ तथा अंत चिन्ह द्वारा, स्पष्ट लंबाई क्षेत्र द्वारा, या फ़ाइल प्रारूप की परिभाषा की निश्चित आवश्यकताओं द्वारा पहचाना जा सकता है।
1970 के दशक के समय, कई प्रोग्रामों ने इस सामान्य प्रकार के प्रारूपों का उपयोग किया। उदाहरण के लिए, वर्ड-प्रोसेसर जैसे ट्राफ , एससीआरआईपीटी, तथा स्क्रीब, और डेटाबेस निर्यात फाइल जैसे अल्पविराम से अलग किए गए मान। इलेक्ट्रॉनिक आर्ट और कमोडोर इंटरनेशनल-अमिगा ने भी 1985 में अपने आइएफएफ फाइल प्रारूप के साथ इस प्रकार के फाइल प्रारूपों का उपयोग किया था।
एक कंटेनर को कभी-कभी चंक कहा जाता है, यद्यपि चंक का अर्थ यह भी हो सकता है कि प्रत्येक भाग छोटा है, और/या उस भाग में अन्य टुकड़े नहीं होते हैं; कई प्रारूप उन आवश्यकताओं को लागू नहीं करते हैं।
एक विशेष "चंक" की पहचान करने वाली जानकारी को प्रायः विभिन्न वस्तुओ के नाम से कहा जा सकता है, जिसमें "फ़ील्ड नाम", "पहचानकर्ता", "लेबल", या "टैग" जैसे शब्द सम्मिलित होते हैं। पहचानकर्ता प्रायः मानव-पठनीय होते हैं और डेटा के भागों को वर्गीकृत करते हैं: उदाहरण के लिए, "उपनाम", "पता", "आयत", "फ़ॉन्ट नाम", आदि। ये एक डेटाबेस की कुंजी या क्रमांक के पहचानकर्ताओं के परिप्रेक्ष्य में उन्ही के समान नहीं होतें है। यद्यपि एक पहचानकर्ता प्रायः अपने संबंधित डेटा को एक ऐसे कुंजी के रूप में पहचानता है।
इस प्रकार के फ़ाइल संरचना के साथ, ऐसे टूल्स जो कुछ चंक पहचानकर्ताओं को नहीं जानते हैं, वे उन्हें जो उन्हें समझ नहीं पाते हैं, उन्हें छोड़ देते हैं। छोड़े गए डेटा के असली अर्थ के आधार पर, यह सहायक हो सकता है या नहीं हो सकता है। सीएसएस ने विशेष रूप से ऐसा व्यवहार परिभाषित किया है।
यह अवधारणा रिफ, पीएनजी, जेपेग संग्रह, डीईआर एन्कोडिंग स्ट्रीम और फ़ाइलों जिन्हें पहले सीसीआईटीटी X.409:1984 में वर्णित किया गया था और इसलिए IFF से पहले हैं, और संरचित डेटा विनिमय प्रारूप द्वारा बार-बार उपयोग की गई है।
वास्तव में, किसी भी डेटा प्रारूप को किसी भी तरीके से अपने घटक भागों के महत्व की पहचान करनी चाहिए, और एम्बेडेड बाउंड्री-मार्कर्स इसे करने का एक स्पष्ट तरीका निम्नलिखित है:
- माइम हैडर्स इसे प्रत्येक तार्किक पंक्ति द्वयशीर्षक के साथ प्रारंभ करते हैं। माइम हैडर्स में अन्य माइम हैडर्स सम्मिलित नहीं हो सकते हैं, यद्यपि कुछ हैडर्स के डेटा सामग्री में उप-भाग हो सकते हैं जिन्हें अन्य अनुशासनों द्वारा प्राप्त किया जा सकता है।
- सीएसवी और इसके समकक्ष फ़ाइलें अक्सर फ़ील्ड नामों के साथ हेडर रिकॉर्ड का उपयोग करके इसे करती हैं, और फ़ील्ड सीमाओं को चिह्नित करने के लिए अल्पविराम का उपयोग करती हैं। माइम की तरह, सीएसवी में एक से अधिक स्तर वाले संरचनाओं के लिए कोई प्रावधान नहीं होता है।
- एक्सएमएल और उसके संबंधियों को सामान्यतः एक प्रकार का चंक-आधारित प्रारूप माना जा सकता है, क्योंकि डेटा तत्वों की पहचान मार्कअप द्वारा की जाती है जो चंक आइडेंटिफ़ायर के समान है। यद्यपि, इसमें एक्सएमएल स्कीमा और सत्यापन सॉफ्टवेयर जैसे औपचारिक लाभ हैं, साथ ही ट्री, निर्देशित विश्वकोश आरेख और चार्ट जैसे अधिक जटिल संरचनाओं का प्रतिनिधित्व करने की क्षमता है। यदि एक्सएमएल को चंक प्रारूप माना जाता है, तो एसजीएमएल और इसके पूर्ववर्ती आइबीएम जीएमएल आदि ऐसे प्रारूपों के प्रारंभी उदाहरणों में से हैं।
- जेएसओएन एक्सएमएल के समान है लेकिन इसमें स्कीमा, पारसंदर्भ या दोहरे फ़ील्ड नामों के अर्थ के लिए कोई परिभाषा नहीं होती है, और इसका प्रोग्रामरों के लिए उपयोग प्रायः सुविधाजनक होता है।
- वाईएएमएल जेएसओएन के समान है, परंतु डेटा चंकों को अलग करने के लिए इंडेंटेशन का उपयोग करता है और जेएसओएन या एक्सएमएल से अधिक मानव-पठनीय होने का उद्देश्य रखता है।
- प्रोटोकॉल बफ़र्स उल्लेखनीय रूप से जेएसओएन के समान हैं, विशेषतः डेटा में बाउंड्री-मार्कर्स को फ़ील्ड नंबर्स के साथ परिवर्तित करते हैं, जो किसी बाहरी यांत्रिकी द्वारा नामों के लिए प्राप्त किए जाते हैं।
निर्देशिका-आधारित प्रारूप
यह एक और विस्तारयोग्य प्रारूप है, जो एक फ़ाइल सिस्टम की तरह अत्यधिक समान होता है ओएलई फ़ाइल वास्तव में फ़ाइल सिस्टम होते हैं, जहां फ़ाइल 'निर्देशिका प्रविष्टियाँ' से मिलकर बनी होती है जो फ़ाइल में डेटा की स्थानांतरण की जगह, उसके हस्ताक्षर और कुछ विषयो में इसके प्रकार को सम्मिलित करती हैं। इन प्रकार के फ़ाइल संरचनाओं के अच्छे उदाहरण हैं डिस्क इमेज, कार्यकारी, ओएलई फ़ाइल, टिफ, लाइब्रेरी आदि।
कुछ फ़ाइल प्रारूप जैसे ओडीटी और डॉक्स, पीकेज़िप पर आधारित होने के कारण, चंकों में विभाजित होते हैं और एक निर्देशक का उपयोग करते हैं।
निर्देशिका-आधारित फ़ाइल प्रारूप की संरचना अनुरूपता या चंक-आधारित प्रारूपों के सापेक्ष में सरलता से संशोधनों के लिए योग्य होती है। इस प्रकार के प्रारूप की प्रकृति उपयोगकर्ताओं को फ़ाइलें सतर्कता पूर्वक बना सकती है जिससे पाठक सॉफ़्टवेयर को कुछ ऐसी कार्रवाई करनी पड़ती है जिसे प्रारूप के लेखकों की योजना में नहीं था। इसका एक उदाहरण है जिपबॉम्ब। निर्देशिका-आधारित फ़ाइल प्रारूप भी मानों का उपयोग करते हैं जो फ़ाइल में अन्य क्षेत्रों का उपयोग करते हैं, परंतु यदि कोई बाद का डेटा मान पूर्व में पढ़े गए डेटा के समान होता है, तो यह पढ़ने वाले सॉफ़्टवेयर के लिए एक अनंत लूप का परिणाम हो सकता है जो मानता है कि निविष्ट फ़ाइल मान्य है और अनंत लूप का समर्थन करता है।
यह भी देखें
- ऑडियो फ़ाइल स्वरूप
- रासायनिक फ़ाइल स्वरूप
- निष्पादन योग्य फ़ाइलप्रारूपों की तुलना
- डिजिटल कंटेनर प्रारूप
- फाइल फ़ाइल स्वरूप
- 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 thओएसe files at a later date and on the ability of other people to access thओएसe data")
