फ़ाइल फ़ारमैट

"फाइल प्रकार" redirects here. फाइल प्रकार may also refer to यूनिक्स प्रकार की फाइल या फ़ाइल नाम एक्सटेंशन.

ओग-फाइल: 154 किलोबाइट।

फ़ाइल प्रारूप कंप्यूटर फ़ाइल में संग्रहीत जानकारी को कोड करने का एक मानक विधि होता है। यह निर्धारित करता है कि बिट कैसे डिजिटल संग्रहण माध्यम में जानकारी को कोड करने के लिए उपयोग होते हैं। फ़ाइल प्रारूप संपत्रित या मुक्त दोनों हो सकते हैं। कुछ फ़ाइल प्रारूप विशेष रूप से निर्दिष्ट प्रकार के डेटा के लिए प्रारूपित किए गए होते हैं: उदाहरण के लिए, पोर्टेबल नेटवर्क ग्राफ़िक्स फ़ाइल दोषरहित डेटा संपीड़न का उपयोग करके लाइन ग्राफिक्स को संग्रहित करती हैं।

यद्यपि, अन्य फ़ाइलप्रारूपों को विभिन्न प्रकार के डेटा के संग्रह के लिए प्रारूपित किए गए होते हैं,ओजीजी प्रारूप विभिन्न प्रकार की मल्टीमीडिया के लिए एक कंटेनर के रूप में कार्य कर सकता है, जिसमें ऑडियो और वीडियो की किसी भी संयोजन, पाठ उदाहरण के लिए उपशीर्षक और मेटाडेटा, सम्मिलित हो सकते हैं।

एक पाठ फ़ाइल में संभावित नियंत्रण वर्णों सहित वर्णों की कोई भी धारा हो सकती है, और विभिन्न अक्षरों को सांकेतिक अक्षरों में परिवर्तन में से एक में एन्कोड किया जाता है। कुछ फ़ाइल प्रारूप, जैसे कि एचटीएमएल, स्केलेबल वेक्टर ग्राफिक्स, और कंप्यूटर सॉफ्टवेयर का स्रोत कोड परिभाषित सिंटैक्स वाली टेक्स्ट फ़ाइलें हैं जो उन्हें विशिष्ट उद्देश्यों के लिए उपयोग करने की अनुमति देती हैं।

विशेष विवरण

फ़ाइल प्रारूपों में प्रायः एक प्रकाशित विनिर्देश होता है जो एन्कोडिंग विधि का वर्णन करता है और प्रोग्राम के इच्छित कार्यक्षमता के परीक्षण को सक्षम करता है। सभी प्रारूपों में स्वतंत्र रूप से विनिर्देश दस्तावेज़ उपलब्ध नहीं हैं, आंशिक रूप से क्योंकि कुछ डेवलपर्स अपने विनिर्देश दस्तावेज़ों को व्यापार रहस्य के रूप में देखते हैं, और आंशिक रूप से क्योंकि अन्य डेवलपर्स औपचारिक विनिर्देश दस्तावेज़ को कभी भी लेखक नहीं बनाते हैं, प्रारूप का उपयोग करने वाले अन्य पहले से उपलब्ध प्रोग्रामों द्वारा उदाहरण स्थापित करते हुए प्रारूप को परिभाषित करते हैं कि कैसे ये प्रोग्राम इसका उपयोग करते हैं।

यदि किसी प्रारूप का डेवलपर, मुक्त विनिर्देशों को प्रकाशित नहीं करता है, तो उस प्रकार की फ़ाइल का उपयोग करने के इच्छुक अन्य डेवलपर को उत्क्रम अभियांत्रिकी का उपयोग करना होगा जिससे यह पता लगाया जा सके कि इसे कैसे पढ़ा जाए या प्रारूप के डेवलपर्स से शुल्क के लिए और हस्ताक्षर करके विनिर्देश दस्तावेज़ कैसे प्राप्त किया जाए। बाद वाला दृष्टिकोण तभी संभव है जब एक औपचारिक विनिर्देश दस्तावेज उपलब्ध हो। दोनों रणनीतियों के लिए महत्वपूर्ण समय, धन या दोनों की आवश्यकता होती है; इसलिए, सार्वजनिक रूप से उपलब्ध विनिर्देशों वाले फ़ाइल प्रारूपों को अधिक प्रोग्रामो द्वारा समर्थित किया जाता है।

एकस्व

कॉपीराइट के अतिरिक्त एकस्व कानून का उपयोग प्रायः फ़ाइल स्वरूप की सुरक्षा के लिए किया जाता है। यद्यपि अमेरिकी कानून के अंतर्गत फ़ाइलप्रारूपों के एकस्व की सीधे अनुमति नहीं है, कुछ प्रारूप एकस्व किए गए विधिकलन का उपयोग करके डेटा को एन्कोड करते हैं। उदाहरण के लिए, जीआईएफ फ़ाइल प्रारूप के साथ संपीड़न का उपयोग करने के लिए किसी एकस्व कलन विधि के उपयोग की आवश्यकता होती है, और यद्यपि एकस्व मालिक ने प्रारंभ में अपने एकस्व को लागू नहीं किया था, बाद में उन्होंने रॉयल्टी भुगतान एकत्र करना प्रारंभ कर दिया। इसके परिणामस्वरूप जीआईएफ के उपयोग में उल्लेखनीय कमी आई है, और वैकल्पिक पोर्टेबल नेटवर्क ग्राफिक्स प्रारूप के विकास के लिए आंशिक रूप से उत्तरदायी है। यद्यपि, जीआईएफ एकस्व अमेरिका में 2003 के मध्य में और दुनिया भर में 2004 के मध्य में समाप्त हो गया।

फ़ाइल प्रकार की पहचान करना

विभिन्न ऑपरेटिंग सिस्टम ने पारंपरिक रूप से एक विशेष फ़ाइल के प्रारूप को निर्धारित करने के लिए विभिन्न दृष्टिकोण अपनाए हैं, प्रत्येक दृष्टिकोण के अपने लाभ और हानि हैं। अधिकांश आधुनिक ऑपरेटिंग सिस्टम और व्यक्तिगत अनुप्रयोगों को विदेशी फ़ाइलप्रारूपों को पढ़ने के लिए निम्नलिखित सभी दृष्टिकोणों का उपयोग करने की आवश्यकता होती है, यदि उनके साथ पूरी तरह से कार्य नहीं किया जाता है।

फ़ाइल नाम एक्सटेंशन

Main article: फ़ाइल नाम एक्सटेंशन

माइक्रोसॉफ्ट विंडोज़, मैकओएस, सीपी/एम, डॉस, ओपन वीएमएस, और वीएम वीएम/सीएमएस सहित कई ऑपरेटिंग सिस्टम द्वारा उपयोग की जाने वाली एक लोकप्रिय विधि फ़ाइल के नाम के अंत, विशेष रूप से अंतिम अवधि के बाद के अक्षर के आधार पर उसके प्रारूप का निर्धारण करता है। फ़ाइल नाम के इस भाग को फ़ाइल नाम एक्सटेंशन के रूप में जाना जाता है। उदाहरण के लिए, एचटीएमएल दस्तावेज़ों को उन नामों से पहचाना जाता है जिनके साथ समाप्त होता है .html (या .htm), और जीआईएफ छवियां .gif. मूल फ़ाइल आवंटन तालिका फाइल सिस्टम में, फ़ाइल नाम आठ-वर्ण पहचानकर्ता और तीन-वर्ण एक्सटेंशन तक सीमित थे, जिसे 8.3 फ़ाइल नाम के रूप में जाना जाता है। सीमित संख्या में तीन-अक्षर वाले एक्सटेंशन हैं, जो एक दिए गए एक्सटेंशन को एक से अधिक प्रोग्राम द्वारा उपयोग करने का कारण बन सकते हैं। कई प्रारूप अभी भी तीन-वर्ण एक्सटेंशन का उपयोग करते हैं, यद्यपि आधुनिक ऑपरेटिंग सिस्टम और एप्लिकेशन प्रोग्राम में अब यह सीमा नहीं है। चूंकि एक्सटेंशन की कोई मानक सूची नहीं है, एक से अधिक प्रारूप एक ही एक्सटेंशन का उपयोग कर सकते हैं, जो ऑपरेटिंग सिस्टम और उपयोगकर्ता दोनों को भ्रमित कर सकता है।

इस दृष्टिकोण का एक आर्टिफैक्ट यह है कि सिस्टम को सरलता से एक फ़ाइल को एक अलग प्रारूप के रूप में नाम देकर सरलता से युग्मित किया जा सकता है - उदाहरण के लिए, एक एचटीएमएल फ़ाइल को सरलता से सादे पाठ filename.html को filename.txt. के रूप में संदर्भित किया जा सकता है। यद्यपि यह रणनीति विशेषज्ञ उपयोगकर्ताओं के लिए उपयोगी थी जो इस जानकारी को सरलता से समझ और परिवर्तित कर सकते थे, यह प्रायः कम तकनीकी उपयोगकर्ताओं के लिए भ्रमित करने वाला था, जो इसे गलत तरीके से नाम देकर फ़ाइल को अनुपयोगी बना सकते थे या इसे खो सकते थे।

इसने विंडोज़ और मैक ओएस के अधिकांश संस्करणों को फाइलों को सूचीबद्ध करते समय एक्सटेंशन को छिपाने का नेतृत्व किया। यह उपयोगकर्ता को गलती से फ़ाइल प्रकार को बदलने से रोकता है, और विशेषज्ञ उपयोगकर्ताओं को इस सुविधा को बंद करने और एक्सटेंशन प्रदर्शित करने की अनुमति देता है।

एक्सटेंशन को छिपाने से, एक ही फ़ोल्डर में दो या अधिक अद्वितीय फ़ाइल नामों की उपस्थिति का अनुभव हो सकता है। उदाहरण के रूप में, किसी कंपनी के लोगो को दोनों .eps प्रारूप में (प्रकाशन के लिए) और .png प्रारूप में वेबसाइटों के लिए आवश्यक हो सकता है। एक्सटेंशन दिखाए जाने पर, ये अद्वितीय फ़ाइल नाम के रूप में प्रकट होंगे: "CompanyLogo.eps" और "CompanyLogo.png"। दूसरी ओर, एक्सटेंशन को छिपाने से दोनों "CompanyLogo" के रूप में प्रदर्शित होंगे, जो भ्रम का कारण बन सकता है।

एक्सटेंशन छुपाने से सुरक्षा जोखिम भी हो सकता है।उदाहरण के लिए, कोई दुर्भाग्यपूर्ण उपयोगकर्ता एक एग्ज़िक्यूटेबल प्रोग्राम को एक नाम जैसे "Holiday photo.jpg.exe" देने के बाद बना सकता है। ".exe" छिपा रहेगा और एक असंदेही उपयोगकर्ता "Holiday photo.jpg" देखेगा, जो जेपीईजी छवि के रूप में प्रकट होगी और सामान्यतः कंप्यूटर को क्षति पहुंचाने के लिए असमर्थ होगी। यद्यपि,ऑपरेटिंग सिस्टम फ़ाइल के वास्तविक एक्सटेंशन को देख सकता है और प्रोग्राम को चला सकता है, जिससे कंप्यूटर को क्षति पहुंचाने की संभावना होती है। एक्सटेंशन को छिपाने से, जो फ़ाइल के वास्तविक प्रारूप को दर्शाने के लिए उपयोगकर्ता को प्रदर्शित नहीं किया जाता है, उस फ़ाइल के बारे में कोई जानकारी स्पष्ट रूप से जांच किए बिना नहीं निकाली जा सकती है। यह एक सुरक्षा संबंधी समस्या हो सकती है और उपयोगकर्ताओं को सतर्क रहने की आवश्यकता होती है।कुछ ऑपरेटिंग सिस्टम एक्ज़ेक्यूटेबल फ़ाइल्स (.exe) के लिए आइकन निर्धारण करते हैं और यदि एक प्रोग्राम में आइकन को संग्रहीत किया जाता है, तो वह आइकन सामान्यतः जेपीईजी छवि को प्रतिष्ठित करने के लिए प्रयुक्त एक आइकन के साथ ओवरराइड किया जा सकता है, जिससे प्रोग्राम एक छवि की तरह दिखाई देगा। इससे उपयोगकर्ता को धोखा देना संभव होता है और उन्हें पहचानने में कठिनाई हो सकती है। यह एक और सुरक्षा संबंधी चिंता का कारण हो सकता है, और उपयोगकर्ताओं को सतर्क रहने की आवश्यकता होती है। कुछ माइक्रोसॉफ्ट वर्ड मैक्रो वायरस टेम्पलेट प्रारूप में वर्ड फ़ाइल बनाते हैं और इसे एक.doc विस्तार नाम से सहेजते हैं। चूँकि वर्ड सामान्यतः एक्सटेंशन की उपेक्षा करता है और फ़ाइल के प्रारूप को देखता है, ये टेम्प्लेट के रूप में खुलेंगे, निष्पादित होंगे और वायरस फैलाएंगे। यह विंडोज सिस्टम के लिए एक व्यावहारिक समस्या का प्रतिनिधित्व करता है जहां डिफ़ॉल्ट रूप से एक्सटेंशन-छिपाना प्रारंभ होता है।

आंतरिक मेटाडेटा

फ़ाइल प्रारूप की पहचान करने की दूसरी विधि, फ़ाइल के अंदर संग्रहीत प्रारूप के बारे में जानकारी का उपयोग करना है, या तो इस उद्देश्य के लिए जानकारी या स्ट्रिंग गैर-पाठ स्ट्रिंग्स जो सदैव कुछ फ़ाइलों में विशिष्ट स्थानों में होती हैं। चूंकि उनका पता लगाने का सबसे सरल स्थान प्रारंभ में है, ऐसे क्षेत्र को सामान्यतः फ़ाइल हेडर कहा जाता है जब यह कुछ बाइट्स से अधिक होता है, या मैजिक नंबर अगर यह केवल कुछ बाइट्स लंबा होता है।

फाइल हेडर

हेडर में निहित मेटाडेटा सामान्यतःफ़ाइल के प्रारंभ में संग्रहीत होते हैं, परंतु अन्य क्षेत्रों में भी उपलब्ध हो सकते हैं, प्रायः अंत सहित, फ़ाइल प्रारूप या डेटा के प्रकार के आधार पर टेक्स्ट-आधारित फाइलों में सामान्यतः कैरेक्टर-आधारित हेडर होते हैं, जबकि बाइनरी फॉर्मेट में सामान्यतःबाइनरी हेडर होते हैं, यद्यपि यह कोई नियम नहीं है। टेक्स्ट-आधारित फ़ाइल हेडर सामान्यतःअधिक स्थान लेते हैं, परंतु मानव-पठनीय होने के कारण, उन्हें टेक्स्ट एडिटर या हेक्साडेसिमल एडिटर जैसे सरल सॉफ़्टवेयर का उपयोग करके सरलता से जांचा जा सकता है।

फ़ाइल हैडर में फ़ाइल प्रारूप की पहचान के साथ-साथ फ़ाइल और उसकी सामग्री के बारे में मेटाडेटा भी हो सकती है। उदाहरण के लिए, अधिकांश छवि फ़ाइल में छवि प्रारूप, आकार, रेज़ोल्यूशन और रंग स्थान के बारे में जानकारी संग्रहित की जाती है, और ऐच्छिक रूप से तथ्य संग्रहित की जा सकती है जैसे कि छवि किसने बनाई है, कब और कहां बनाई गई है, कौन सा कैमरा मॉडल और फोटोग्राफिक सेटिंग्स इत्यादि का उपयोग किया गया है। ऐसे मेटाडेटा को फ़ाइल को लोड करते समय और उसके बाद कोई सॉफ़्टवेयर जो फ़ाइल को पढ़ रहा है या इंटरप्रिट कर रहा है, के द्वारा उपयोग किया जा सकता है।

फ़ाइल हैडर्स का उपयोग ऑपरेटिंग सिस्टम द्वारा फ़ाइल के बारे में तत्काल जानकारी इकट्ठा करने के लिए किया जा सकता है, लेकिन ऐसा करने से संगठन मेमोरी में सीधे पढ़ने के सापेक्ष में अधिक कंप्यूटर संसाधनों का उपयोग किया जाता है। उदाहरण के लिए, जब एक ग्राफिक फ़ाइल प्रबंधक को फ़ोल्डर की सामग्री प्रदर्शित करनी होती है, तो इसे उचित आइकन प्रदर्शित करने के लिए इसे कई फ़ाइलों के हैडर्स को पढ़ना होता है, लेकिन ये हेडर भंडारण माध्यम पर विभिन्न स्थानों पर स्थित होंगे, जिससे उन्हें पहुंचने में अधिक समय लगेगा। एक फ़ोल्डर जिसमें संक्षेप जानकारी के रूप में थंबनेल जानकारी जैसे जटिल मेटाडेटा वाली कई फ़ाइलें हों, उन्हें प्रदर्शित करने से पहले बहुत समय लग सकता है।

यदि हेडर बाइनरी रूप में हार्ड-कोड किया जाता है और हेडर को पहचानने के लिए जटिल व्याख्या की आवश्यकता होती है, विशेषतः मेटाडेटा सामग्री की सुरक्षा के लिए, तो इससे फ़ाइल प्रारूप को गलत तरीके से समझा जा सकता है। इससे प्राथमिकता में यह संकेतित करता है कि फ़ाइल प्रारूप की समझ में कठिनाई हो सकती है। यह अवश्यकता के विपरीत हो सकता है कि हेडर का अविरामी रूप में लिखा गया हो या गलतियों से प्रभावित हो जाए। इसके परिणामस्वरूप, मेटाडेटा में क्षति हो सकती है जो अत्यंत खराब मामलों में फ़ाइल को अपठित बना सकती है।

फ़ाइल हेडर के और जटिल उदाहरण हैं वे जो व्रैपर या कंटेनर फ़ाइल प्रारूपों के लिए उपयोग होते हैं।

मैजिक नंबर

See also: Magic number (programming) § In files

फ़ाइल प्रकार मेटाडेटा को शामिल करने का एक विधि, जो प्रायः यूनिक्स और इसके डेरिवेटिव से जुड़ा होता है, फ़ाइल के अंदर एक जादुई संख्या को स्टोर करना है। मूल रूप से, इस शब्द का उपयोग फ़ाइलों की शुरुआत में 2-बाइट पहचानकर्ताओं के एक विशिष्टस्थापित के लिए किया गया था, लेकिन चूंकि किसी भी बाइनरी अनुक्रम को एक संख्या के रूप में माना जा सकता है, फ़ाइल प्रारूप की कोई भी विशेषता जो इसे विशिष्ट रूप से अलग करती है, पहचान के लिए उपयोग की जा सकती है। उदाहरण के लिए, जीआईएफ छवियां हमेशा ASCII प्रतिनिधित्व के साथ शुरू होती हैं GIF87a या GIF89a, उस मानक पर निर्भर करता है जिसका वे पालन करते हैं। कई फ़ाइल प्रकार, विशेष रूप से सादे-पाठ फ़ाइलें, इस पद्धति से स्पॉट करना कठिन हैं। उदाहरण के लिए, HTML फ़ाइलें स्ट्रिंग से शुरू हो सकती हैं <html> (जो केस सेंसिटिव नहीं है), या उपयुक्त दस्तावेज़ प्रकार की परिभाषा जो इससे शुरू होती है <!DOCTYPE HTML>, या, XHTML के लिए, XML पहचानकर्ता, जो से शुरू होता है <?xml. फ़ाइलें HTML टिप्पणियों, यादृच्छिक पाठ या कई खाली पंक्तियों के साथ भी शुरू हो सकती हैं, लेकिन फिर भी प्रयोग करने योग्य HTML हो सकती हैं।

जादू संख्या दृष्टिकोण बेहतर गारंटी प्रदान करता है कि प्रारूप सही ढंग से पहचाना जाएगा, और प्रायः फ़ाइल के बारे में अधिक सटीक जानकारी निर्धारित कर सकता है। चूंकि यथोचित रूप से विश्वसनीय जादुई संख्या परीक्षण काफी जटिल हो सकते हैं, और प्रत्येक फ़ाइल को जादू डेटाबेस में हर संभावना के खिलाफ प्रभावी ढंग से परीक्षण किया जाना चाहिए, यह दृष्टिकोण अपेक्षाकृत अक्षम है, विशेष रूप से फाइलों की बड़ी सूची प्रदर्शित करने के लिए (इसके विपरीत, फ़ाइल नाम और मेटाडेटा-आधारित विधियां) डेटा के केवल एक टुकड़े की जांच करने की आवश्यकता है, और इसे सॉर्ट किए गए इंडेक्स के विरुद्ध मिलान करें)। साथ ही, डेटा को फ़ाइल से ही पढ़ा जाना चाहिए, निर्देशिका में संग्रहीत मेटाडेटा के विपरीत विलंबता बढ़ाना। जहां फ़ाइल प्रकार इस तरह से खुद को पहचानने के लिए उधार नहीं देते हैं, सिस्टम को मेटाडेटा पर वापस आना चाहिए। यद्यपि, किसी प्रोग्राम के लिए यह जाँचने का सबसे अच्छा विधि है कि जिस फ़ाइल को संसाधित करने के लिए कहा गया है वह सही प्रारूप की है: जबकि फ़ाइल का नाम या मेटाडेटा इसकी सामग्री से स्वतंत्र रूप से बदला जा सकता है, एक अच्छी तरह से प्रारूपित किए गए जादू संख्या परीक्षण में विफल एक निश्चित संकेत है कि फ़ाइल या तो दूषित है या गलत प्रकार की है। दूसरी ओर, एक मान्य मैजिक नंबर इस बात की गारंटी नहीं देता है कि फ़ाइल दूषित नहीं है या सही प्रकार की है।

स्क्रिप्टिंग भाषा में तथाकथित शेबैंग (यूनिक्स) पंक्तियाँ जादुई संख्याओं का एक विशेष मामला है। यहां, जादू संख्या मानव-पठनीय पाठ है जो एक विशिष्ट दुभाषिया (कंप्यूटिंग) और कमांड दुभाषिया को पास किए जाने वाले विकल्पों की पहचान करता है।

मैजिक नंबरों का उपयोग करने वाला एक अन्य ऑपरेटिंग सिस्टम AmigaOS है, जहां मैजिक नंबरों को मैजिक कुकीज़ कहा जाता था और दोस्त हंक निष्पादन योग्य फ़ाइल प्रारूप में निष्पादनयोग्य को पहचानने के लिए एक मानक प्रणाली के रूप में अपनाया गया था और एकल प्रोग्राम ों, उपकरणों और उपयोगिताओं को उनकी सहेजी गई डेटा फ़ाइलों के साथ स्वचालित रूप से निपटने के लिए भी दिया गया था। या डेटा सहेजते और लोड करते समय किसी अन्य प्रकार की फ़ाइल प्रकार। इस सिस्टम को तब Amiga सपोर्ट और मेंटेनेंस सॉफ्टवेयर#डेटाटाइप्स रिकग्निशन सिस्टम के साथ बढ़ाया गया था। एक अन्य विधि फोरसीसी विधि थी, जो मैकिंटोश पर ओएस टाइप में उत्पन्न हुई थी, जिसे बाद में इंटरचेंज फ़ाइल स्वरूप (आईएफएफ) और डेरिवेटिव द्वारा अनुकूलित किया गया था।

बाहरी मेटाडेटा

फ़ाइल के प्रारूप को संग्रहीत करने का एक अंतिम विधि फ़ाइल सिस्टम में प्रारूप के बारे में जानकारी को स्पष्ट रूप से फ़ाइल के भीतर संग्रहीत करना है।

यह दृष्टिकोण मेटाडेटा को मुख्य डेटा और नाम दोनों से अलग रखता है, लेकिन फ़ाइल नाम एक्सटेंशन या मैजिक नंबरों की तुलना में कम में porting भी करता है, क्योंकि प्रारूप को फ़ाइल सिस्टम से फ़ाइल सिस्टम में बदलना पड़ता है। जबकि यह फ़ाइल नाम एक्सटेंशन के साथ एक हद तक सही है - उदाहरण के लिए, MS-DOS विभाजन तालिका के साथ संगतता के लिए | MS-DOS की तीन वर्ण सीमा - भंडारण के अधिकांश रूपों में फ़ाइल के डेटा और नाम की लगभग समतुल्य परिभाषा होती है, लेकिन हो सकती है आगे के मेटाडेटा का भिन्न या कोई प्रतिनिधित्व नहीं।

ध्यान दें कि ज़िप फ़ाइलें या संग्रह फ़ाइलें मेटाडेटा को संभालने की समस्या को हल करती हैं। एक यूटिलिटी प्रोग्राम प्रत्येक फ़ाइल के बारे में मेटाडेटा के साथ-साथ एक नई फ़ाइल (जैसे एक ज़िप (फ़ाइल प्रारूप) फ़ाइल) के विस्तार के साथ कई फ़ाइलों को एक साथ इकट्ठा करता है। .zip). नई फ़ाइल भी संपीड़ित और संभवतः एन्क्रिप्ट की गई है, लेकिन अब फाइल ट्रांसफर प्रोटोकॉल ट्रांसमिशन द्वारा ऑपरेटिंग सिस्टम में एकल फाइल के रूप में ट्रांसमिसिबल है या अटैचमेंट के रूप में ईमेल द्वारा भेजी गई है। गंतव्य पर, प्राप्त एकल फ़ाइल को उपयोगी होने के लिए एक संगत उपयोगिता द्वारा अनज़िप करना पड़ता है। ज़िप फ़ाइलों या संग्रह फ़ाइलों का उपयोग करके मेटाडेटा को संभालने की समस्या इस तरह हल हो जाती है।

मैक ओएस टाइप-कोड

Macintosh ऑपरेटिंग सिस्टम 'पदानुक्रमित फ़ाइल सिस्टम (Apple) प्रत्येक फ़ाइल के लिए निर्देशिका प्रविष्टि के भाग के रूप में निर्माता कोड और कोड टाइप करें के लिए कोड संग्रहीत करता है। इन कोड को OSTypes कहा जाता है। ये कोड कोई भी 4-बाइट अनुक्रम हो सकते हैं लेकिन प्रायः चुने जाते थे ताकि ASCII प्रतिनिधित्व अर्थपूर्ण वर्णों का अनुक्रम बना सके, जैसे कि एप्लिकेशन के नाम का संक्षिप्त नाम या डेवलपर के आद्याक्षर। उदाहरण के लिए एक हाइपर कार्ड स्टैक फ़ाइल का निर्माता होता है WILD (हाइपरकार्ड के पिछले नाम, वाइल्डकार्ड से) और एक प्रकार का STAK. BBEdit टेक्स्ट एडिटर का क्रिएटर कोड होता है R*ch अपने मूल प्रोग्रामर, समृद्ध मुहर का जिक्र करते हुए। प्रकार कोड फ़ाइल के प्रारूप को निर्दिष्ट करता है, जबकि निर्माता कोड उपयोगकर्ता द्वारा डबल-क्लिक करने पर इसे खोलने के लिए डिफ़ॉल्ट प्रोग्राम निर्दिष्ट करता है। उदाहरण के लिए, उपयोगकर्ता के पास टाइप कोड के साथ कई टेक्स्ट फाइलें हो सकती हैं TEXT, लेकिन विभिन्न निर्माता कोड होने के कारण प्रत्येक एक अलग प्रोग्राम में खुलता है। इस सुविधा का उद्देश्य था, उदाहरण के लिए, मानव-पठनीय सादा-पाठ फ़ाइलें सामान्य-उद्देश्य वाले पाठ संपादक में खोली जा सकती हैं, जबकि प्रोग्रामिंग या HTML कोड फ़ाइलें एक विशेष संपादक या एकीकृत विकास वातावरण में खुलती हैं। यद्यपि, यह सुविधा प्रायः उपयोगकर्ता भ्रम का स्रोत थी, क्योंकि फाइलों पर डबल-क्लिक करने पर कौन सा प्रोग्राम लॉन्च होगा, यह प्रायः अप्रत्याशित होता था। जोखिम एक समान प्रणाली का उपयोग करता है, जिसमें 12-बिट संख्या शामिल होती है जिसे विवरण तालिका में देखा जा सकता है- उदा। हेक्साडेसिमल संख्या FF5 का उपनाम है PoScript, परिशिष्ट भाग फ़ाइल का प्रतिनिधित्व करता है।

macOS यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI)

Main article: Uniform Type Identifier

यूनिफ़ॉर्म टाइप आइडेंटिफ़ायर (UTI) एक ऐसी विधि है जिसका उपयोग macOS में विशिष्ट रूप से टाइप की गई संस्थाओं की श्रेणियों, जैसे फ़ाइलप्रारूपों की पहचान के लिए किया जाता है। इसे Apple Inc. द्वारा OSType (प्रकार और निर्माता कोड) के प्रतिस्थापन के रूप में विकसित किया गया था।

यूटीआई एक कोर फाउंडेशन स्ट्रिंग (कंप्यूटर विज्ञान) है, जो रिवर्स डीएनएस स्ट्रिंग का उपयोग करता है। कुछ सामान्य और मानक प्रकार एक डोमेन का उपयोग करते हैं जिसे कहा जाता है public (उदा public.png पोर्टेबल नेटवर्क ग्राफ़िक्स छवि के लिए), जबकि अन्य डोमेन तृतीय-पक्ष प्रकारों के लिए उपयोग किए जा सकते हैं (उदा. com.adobe.pdf पोर्टेबल दस्तावेज़ स्वरूप के लिए)। यूटीआई को एक पदानुक्रमित संरचना के भीतर परिभाषित किया जा सकता है, जिसे अनुरूपता पदानुक्रम के रूप में जाना जाता है। इस प्रकार, public.png के सुपरटाइप के अनुरूप है public.image, जो स्वयं के सुपरटाइप के अनुरूप है public.data. एक यूटीआई कई पदानुक्रमों में उपलब्ध हो सकता है, जो बहुत अधिक लचीलापन प्रदान करता है।

फ़ाइलप्रारूपों के अलावा, UTI का उपयोग अन्य संस्थाओं के लिए भी किया जा सकता है जो macOS में उपलब्ध हो सकती हैं, जिनमें शामिल हैं:

• पेस्टबोर्ड डेटा
• निर्देशिका (कंप्यूटिंग) (निर्देशिका)
• अनुवाद योग्य प्रकार (अनुवाद प्रबंधक द्वारा नियंत्रित)
• बंडल
• चौखटे
• स्ट्रीमिंग डेटा
• उपनाम और सहानुभूति

वीएसएएम कैटलॉग

IBM OS/VS में z/OS के माध्यम से, VSAM कैटलॉग (डाटा फैसिलिटी स्टोरेज मैनेजमेंट सबसिस्टम (MVS)#ICF कैटलॉग से पहले) और वीएसएएम वॉल्यूम डेटास्थापित (वीवीडीएस) में वीएसएएम वॉल्यूम रिकॉर्ड (आईसीएफ कैटलॉग के साथ) प्रकार की पहचान करता है वीएसएएम डेटासेट का।

वीटीसी

IBM OS/360 में z/OS के माध्यम से, एक प्रारूप 1 या 7 वॉल्यूम सामग्री की तालिका#डेटास्थापित कंट्रोल ब्लॉक प्रकार (DSCB) सामग्री की वॉल्यूम तालिका (VTOC) में पहचान करता है इसके द्वारा वर्णित डेटासेट का डेटासेट संगठन (DSORG)।

OS/2 विस्तारित विशेषताएँ

उच्च प्रदर्शन फाइल सिस्टम, FAT12, और FAT16 (लेकिन FAT32 नहीं) फाइल सिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देता है। इनमें एक नाम के साथ ट्रिपलेट का मनमानास्थापित , मान के लिए एक कोडित प्रकार और एक मान शामिल है, जहां नाम अद्वितीय हैं और मान 64 KB तक लंबा हो सकता है। कुछ प्रकार और नामों के लिए मानकीकृत अर्थ हैं (OS/2 के अंतर्गत)। ऐसा ही एक है कि फ़ाइल प्रकार निर्धारित करने के लिए .TYPE विस्तारित विशेषता का उपयोग किया जाता है। इसके मान में फ़ाइल से जुड़े एक या अधिक फ़ाइल प्रकारों की सूची शामिल होती है, जिनमें से प्रत्येक एक स्ट्रिंग है, जैसे कि सादा पाठ या HTML दस्तावेज़। इस प्रकार एक फ़ाइल कई प्रकार की हो सकती है।

NTFS फाइल सिस्टम OS/2 विस्तारित विशेषताओं के भंडारण की अनुमति देता है, फ़ाइल फोर्क्स में से एक के रूप में, लेकिन यह सुविधा केवल OS/2 सबसिस्टम (XP में उपलब्ध नहीं) का समर्थन करने के लिए उपलब्ध है, इसलिए Win32 सबसिस्टम इस जानकारी को एक अपारदर्शी के रूप में मानता है। डेटा का ब्लॉक और इसका उपयोग नहीं करता है। इसके अतिरिक्त, यह Win32-विशिष्टप्रारूपों में मेटा-सूचना को संग्रहीत करने के लिए अन्य फ़ाइल फोर्क्स पर निर्भर करता है। OS/2 विस्तारित विशेषताओं को अभी भी Win32 प्रोग्राम द्वारा पढ़ा और लिखा जा सकता है, लेकिन डेटा को एप्लिकेशन द्वारा पूरी तरह से पार्स किया जाना चाहिए।

POSIX विस्तारित विशेषताएँ

यूनिक्स और यूनिक्स जैसी प्रणालियों पर, ext2, ext3, ext4, ReiserFS संस्करण 3, XFS, IBM जर्नलेड फाइल सिस्टम 2 (JFS2), बर्कले फास्ट फाइल सिस्टम और HFS Plus|HFS+ फाइलसिस्टम फाइलों के साथ विस्तारित विशेषताओं के भंडारण की अनुमति देते हैं। इनमें नाम = मूल्य स्ट्रिंग्स की मनमाना सूची शामिल है, जहां नाम अद्वितीय हैं और इसके संबंधित नाम के माध्यम से मूल्य तक पहुंचा जा सकता है।

PRONOM अद्वितीय पहचानकर्ता (PUIDs)

PRONOM तकनीकी रजिस्ट्री #PRONOM परसिस्टेंट यूनीक आइडेंटिफ़ायर (PUID) योजना| PRONOM पर्सिस्टेंट यूनिक आइडेंटिफ़ायर (PUID) फ़ाइलप्रारूपों के लिए लगातार, अद्वितीय और स्पष्ट पहचानकर्ताओं की एक एक्स्टेंसिबल योजना है, जिसे राष्ट्रीय अभिलेखागार (यूके) द्वारा विकसित किया गया है इसकी PRONOM तकनीकी रजिस्ट्री सेवा का हिस्सा है। पीयूआईडी को उपयोग करके यूनिफॉर्म रिसोर्स पहचानकर्ता के रूप में व्यक्त किया जा सकता है info:pronom/ नामस्थान। यद्यपि यूके सरकार और कुछ डिजिटल संरक्षण प्रोग्राम ों के बाहर अभी तक व्यापक रूप से उपयोग नहीं किया गया है, पीयूआईडी योजना अधिकांश वैकल्पिक योजनाओं की तुलना में अधिक ग्रैन्युलैरिटी प्रदान करती है।

माइम प्रकार

MIME प्रकार व्यापक रूप से इंटरनेट से संबंधित कई अनुप्रयोगों में और कहीं और तेजी से उपयोग किए जाते हैं, यद्यपि ऑन-डिस्क प्रकार की जानकारी के लिए उनका उपयोग दुर्लभ है। इनमें पहचानकर्ताओं की एक मानकीकृत प्रणाली शामिल है (इंटरनेट असाइन किए गए नंबर प्राधिकरण द्वारा प्रबंधित) जिसमें एक प्रकार और एक उप-प्रकार शामिल है, जो स्लैश (विराम चिह्न) द्वारा अलग किया गया है - उदाहरण के लिए, text/html या image/gif. ये मूल रूप से यह पहचानने के तरीके के रूप में अभिप्रेत थे कि किस प्रकार की फ़ाइल किसी ईमेल से जुड़ी हुई थी, जो स्रोत और लक्ष्य ऑपरेटिंग सिस्टम से स्वतंत्र थी। MIME प्रकार BeOS, AmigaOS 4.0 और MorphOS पर फ़ाइलों की पहचान करते हैं, साथ ही एप्लिकेशन लॉन्चिंग के लिए अद्वितीय एप्लिकेशन हस्ताक्षरों को संग्रहीत करते हैं। AmigaOS और MorphOS में, माइम टाइप सिस्टम Amiga विशिष्ट डेटाटाइप सिस्टम के समानांतर काम करता है।

यद्यपि MIME प्रकारों के साथ समस्याएँ हैं; कई संगठनों और लोगों ने IANA के साथ ठीक से पंजीकृत किए बिना अपने स्वयं के MIME प्रकार बनाए हैं, जो कुछ मामलों में इस मानक के उपयोग को अजीब बनाता है।

फ़ाइल स्वरूप पहचानकर्ता (FFIDs)

फ़ाइल प्रारूप पहचानकर्ता एक अन्य, व्यापक रूप से उपयोग नहीं किया जाने वाला विधि है जो फ़ाइलप्रारूपों को उनके मूल और उनकी फ़ाइल श्रेणी के अनुसार पहचानने के लिए उपयोग किया जाता है। इसे सॉफ्टवेयर के डिस्क्रिप्शन एक्सप्लोरर सूट के लिए बनाया गया था। यह फॉर्म के कई अंकों से बना होता है NNNNNNNNN-XX-YYYYYYY. पहला भाग संगठन के मूल/रखरखाव को इंगित करता है (यह संख्या कंपनी/मानक संगठन डेटाबेस में एक मान का प्रतिनिधित्व करती है), और बाद के 2 अंक हेक्साडेसिमल में फ़ाइल के प्रकार को वर्गीकृत करते हैं। अंतिम भाग फ़ाइल के सामान्य फ़ाइल नाम एक्सटेंशन या फ़ाइल की अंतर्राष्ट्रीय मानक संख्या से बना है, जो शून्य के साथ गद्देदार है। उदाहरण के लिए, PNG फ़ाइल विनिर्देशन का FFID है 000000001-31-0015948 कहाँ 31 एक छवि फ़ाइल इंगित करता है, 0015948 मानक संख्या है और 000000001 मानकीकरण के लिए अंतर्राष्ट्रीय संगठन (आईएसओ) को इंगित करता है।

फ़ाइल सामग्री आधारित प्रारूप पहचान

फ़ाइल स्वरूप की पहचान करने का एक और कम लोकप्रिय विधि फ़ाइल प्रकारों के बीच विभिन्न पैटर्न के लिए फ़ाइल सामग्री की जांच करना है। एक फ़ाइल की सामग्री बाइट्स का एक क्रम है और एक बाइट में 256 अद्वितीय क्रमपरिवर्तन (0-255) हैं। इस प्रकार, बाइट पैटर्न की घटना की गणना करना जिसे प्रायः बाइट आवृत्ति वितरण के रूप में संदर्भित किया जाता है, फ़ाइल प्रकारों की पहचान करने के लिए विभिन्न पैटर्न देता है। कई सामग्री-आधारित फ़ाइल प्रकार पहचान योजनाएँ हैं जो फ़ाइल प्रकार के लिए प्रतिनिधि मॉडल बनाने के लिए बाइट आवृत्ति वितरण का उपयोग करती हैं और फ़ाइल प्रकारों की पहचान करने के लिए किसी भी सांख्यिकीय और डेटा माइनिंग तकनीकों का उपयोग करती हैं।

फ़ाइल संरचना

किसी फ़ाइल में डेटा की संरचना करने के कई तरीके हैं। सबसे सामान्य नीचे वर्णित हैं।

असंरचित प्रारूप (कच्ची मेमोरी डंप)

पहले के फ़ाइलप्रारूपों में कच्चे डेटाप्रारूपों का उपयोग किया जाता था जिसमें फ़ाइल में एक या अधिक संरचनाओं की मेमोरी छवियों को सीधे डंप करना शामिल था।

इसमें कई कमियां हैं। जब तक मेमोरी छवियों में भविष्य के एक्सटेंशन के लिए आरक्षित स्थान नहीं होते हैं, तब तक इस प्रकार की संरचित फ़ाइल का विस्तार और सुधार करना बहुत मुश्किल होता है। यह ऐसी फ़ाइलें भी बनाता है जो एक प्लेटफ़ॉर्म या प्रोग्रामिंग भाषा के लिए विशिष्ट हो सकती हैं (उदाहरण के लिए पास्कल (प्रोग्रामिंग भाषा) स्ट्रिंग वाली संरचना को सी (प्रोग्रामिंग भाषा) में पहचाना नहीं जाता है)। दूसरी ओर, इस प्रकार की फाइलों को पढ़ने और लिखने के लिए उपकरण विकसित करना बहुत आसान है।

असंरचितप्रारूपों की सीमाओं के कारण अन्य प्रकार के फ़ाइलप्रारूपों का विकास हुआ, जिन्हें सरलता से बढ़ाया जा सकता है और एक ही समय में पिछड़े संगत हो सकते हैं।

चंक-आधारित प्रारूप

इस तरह की फ़ाइल संरचना में, डेटा का प्रत्येक टुकड़ा एक कंटेनर में एम्बेडेड होता है जो किसी तरह डेटा की पहचान करता है। कंटेनर के दायरे को किसी प्रकार के स्टार्ट- और एंड-मार्कर द्वारा, कहीं स्पष्ट लंबाई क्षेत्र द्वारा, या फ़ाइल प्रारूप की परिभाषा की निश्चित आवश्यकताओं द्वारा पहचाना जा सकता है।

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-आधारित होने के कारण, दोनों खंडित हैं और एक निर्देशिका रखते हैं।

एक निर्देशिका-आधारित फ़ाइल स्वरूप की संरचना असंरचित या चंक-आधारितप्रारूपों की तुलना में अधिक सरलता से संशोधनों के लिए उधार देती है। इस प्रकार के प्रारूप की प्रकृति उपयोगकर्ताओं को सावधानी से फ़ाइलों का निर्माण करने की अनुमति देती है जो पाठक सॉफ़्टवेयर को उन चीजों को करने का कारण बनती है जो प्रारूप के लेखक कभी नहीं होने का इरादा रखते थे। इसका एक उदाहरण ज़िप बम है। निर्देशिका-आधारित फ़ाइल स्वरूप भी उन मानों का उपयोग करते हैं जो फ़ाइल में अन्य क्षेत्रों को इंगित करते हैं लेकिन यदि कुछ बाद के डेटा मान पहले पढ़े गए डेटा पर वापस जाते हैं, तो इसका परिणाम किसी भी पाठक सॉफ़्टवेयर के लिए अनंत लूप में हो सकता है जो इनपुट फ़ाइल को मान्य करता है और आँख बंद करके पाश का पालन करता है।

यह भी देखें

• ऑडियो फ़ाइल स्वरूप
• रासायनिक फ़ाइल स्वरूप
• निष्पादन योग्य फ़ाइलप्रारूपों की तुलना
• डिजिटल कंटेनर प्रारूप
• दस्तावेज़ फ़ाइल स्वरूप
• PRONOM तकनीकी रजिस्ट्री#DROID फ़ाइल स्वरूप पहचान उपयोगिता
• फ़ाइल (कमांड), एक फ़ाइल प्रकार की पहचान उपयोगिता
• फ़ाइल रूपांतरण
• भविष्य प्रमाण
• ग्राफिक्स फ़ाइल प्रारूप सारांश
• छवि फ़ाइल स्वरूप
• संग्रह प्रारूपों की सूची
• फ़ाइल हस्ताक्षरों की सूची
• फाइल सिग्नेचर, या मैजिक नंबरों की सूची
• फ़ाइल नाम एक्सटेंशन की सूची (वर्णमाला)
• मुफ्त फ़ाइलप्रारूपों की सूची
• मोशन और जेस्चर फ़ाइलप्रारूपों की सूची
• जादू संख्या (प्रोग्रामिंग)
• वस्तु फ़ाइल
• वीडियो फ़ाइल स्वरूप
• विंडोज़ फ़ाइल प्रकार
• फ़ाइल नाम एक्सटेंशन

संदर्भ

• "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.

बाहरी संबंध

• फ़ाइल फ़ारमैट 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")