क्या फ़ाइल प्रारूप बनाने का एक उचित तरीका है?


12

मैं एक एप्लिकेशन के लिए एक मालिकाना फ़ाइल प्रारूप बना रहा हूं जिसे मैंने सी # .NET में लिखा है ताकि जानकारी को सहेजने के लिए और शायद लाइन प्रोजेक्ट परिसंपत्तियों को नीचे रख सके। क्या किसी भी तरह से ऐसा करने का कोई मानक है? मैं बस Serializeअपनी वस्तुओं को बाइनरी में जा रहा था और एक हेडर बनाऊंगा जो मुझे बताएगा कि फ़ाइल को पार्स कैसे किया जाए। क्या यह एक बुरा तरीका है?


2
मैं बचूंगा BinaryFormatter
कोडइन्चोज

3
जो भी दृष्टिकोण (उत्तरों से) आप चुनते हैं, हमेशा प्रारूप में एक संस्करण संख्या शामिल करें! आपका प्रश्न पहले से ही यह बताता है कि यह बदल सकता है, और यदि आपको बैकवार्ड संगत होना है तो संस्करण संख्या आपको बहुत प्रयास करने से बचाएगा।
Jan Doggen

ठीक से प्रारूप करने के लिए दस्तावेज़ को मत भूलना
बेसिल स्ट्रायनेविच 11

जवाबों:


11

XMLSerializerकक्षा का उपयोग करते हुए XML के लिए अपनी संरचना को क्रमबद्ध करने के लिए संभवत: सबसे आगे-आगे की विधि है । आपको शायद एक अलग हेडर और बॉडी स्ट्रक्चर बनाने की आवश्यकता नहीं होगी - लेकिन एक्सएमएल में सभी परिसंपत्तियों को क्रमबद्ध करें। यह आपको अपने प्रोग्राम के बाहर अपनी फ़ाइल संरचना का आसानी से निरीक्षण / संपादन करने की अनुमति देता है, और आसानी से प्रबंधनीय है।

हालाँकि, यदि आपकी फ़ाइल संरचना वास्तव में जटिल है, जिसमें विभिन्न प्रकार की कई अलग-अलग संपत्तियाँ हैं, जैसे कि XML के लिए संपूर्ण संरचना को क्रमबद्ध करना बहुत अधिक बोझिल है, तो आप प्रत्येक परिसंपत्ति को अलग से देख सकते हैं और उन्हें PackagingC # में लाइब्रेरी का उपयोग करके एकल पैकेज में संकलित कर सकते हैं। । यह अनिवार्य रूप से है .docx, .xslx, .pptx, और अन्य कार्यालय फ़ाइल स्वरूपों का निर्माण किया जाता है।


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

7
प्रिय भगवान XML नहीं
जेम्स

2
@ जेम्स हाँ XML के अपने डाउनसाइड हैं, बेशक। मैं ज्यादातर मामलों में एक ही कारण से पैकेजिंग और एक्सएमएल का पक्ष लेता हूं: 1. यह पहले से मौजूद ढांचा है, इसलिए इसमें कम मेहनत करनी पड़ती है। 2. अन्य प्रणालियों के लिए समर्थन करना आसान है, क्योंकि यह एक व्यापक रूप से स्वीकृत मानक है। 3. सीरियलाइज़ेशन प्रक्रिया को सत्यापित करने के लिए परिणामी फ़ाइल का निरीक्षण करना मानव के लिए आसान है।
pswg

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


7

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

  • मैजिक नंबर को बहुत अनूठा बनाएं ताकि अन्य प्रारूपों के लिए लोगों के फाइल फॉर्मेट डिटेक्टर इसे आपकी तरह गलत न समझें। यदि आप बाइनरी का उपयोग करते हैं, तो जादुई संख्या के लिए एक बाइनरी प्रारूप की शुरुआत में 8 या 16 बेतरतीब ढंग से उत्पन्न बाइट आवंटित करें। यदि आप XML का उपयोग करते हैं, तो अपने डोमेन में एक उचित नाम स्थान आवंटित करें ताकि यह अन्य लोगों के साथ टकराव न कर सके। यदि आप JSON का उपयोग करते हैं, तो भगवान आपकी मदद करते हैं। हो सकता है कि किसी ने अब तक किसी प्रारूप के उस निरस्तीकरण के लिए कोई हल निकाला हो।

  • पश्चगामी अनुकूलता के लिए योजना बनाएं। प्रारूप की संस्करण संख्या को किसी तरह स्टोर करें ताकि बाद में आपके सॉफ़्टवेयर के संस्करण मतभेदों से निपट सकें।

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

  • UTF-8 में सभी स्ट्रिंग्स को स्टोर करें।

  • यदि आप लंबे समय तक विस्तार की परवाह करते हैं, तो सभी पूर्णांकों को एक चर-लंबाई के रूप में संग्रहीत करें।

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


+1 मुझे यह महसूस करने के लिए कि मैं अकेला व्यक्ति नहीं हूं जो सोचता है कि यह एक प्रारूप का उन्मूलन है।
रबरडक

कबाड़ से नफरत क्यों? प्रारूप की पहचान करने के लिए एक ज्ञात स्थान पर एक ज्ञात स्ट्रिंग रखें। समस्या सुलझ गयी।
एसेन स्कोव पेडर्सन

यह सही नहीं है, लेकिन यह जावास्क्रिप्ट के साथ मूल रूप से काम करता है, XML से पार्स करने के लिए तेज और छोटे आकार, और अभी भी मानव पठनीय है।
कोरियुलु

1
"JSON के लिए नफरत क्यों?" मानव-पठनीय टिप्पणियों के लिए कोई समर्थन नहीं, यूनिकोड से बचना, और एक अजीब वाक्यविन्यास की मुझे कुंजी उद्धृत करने की आवश्यकता है, भले ही उनके पास कभी व्हाट्सएप न हो। साथ ही चीजों को विस्तारित करने में सामान्य अक्षमता क्योंकि नाम रखने के बारे में किसी ने भी नहीं सोचा था ... जब तक आप उस एक को हल करते हैं, तब तक आप एक ऐसी चीज के साथ समाप्त हो जाते हैं जो कि XML की तुलना में पहले से कहीं ज्यादा खराब दिखती है, सभी के लिए, कुछ कोण से बचने का लाभ कोष्ठक?
तर्जुक

हाँ, लेकिन प्रोग्रामिंग के साथ सभी चीजों के साथ, नौकरी के लिए सही उपकरण का उपयोग करें। ऐसे अनुप्रयोग हैं जहां XML JSON से बेहतर है और इसके विपरीत।
corylulu

4

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

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

पाठ्यक्रम का अन्य विकल्प XML या JSON है। जरूरी नहीं कि द्विआधारी भारी सामग्री के लिए सबसे बड़ा, लेकिन सरल और मानव पठनीय ... दीर्घकालिक व्यवहार्यता के लिए एक बड़ा प्लस।


मैं प्रोटोबॉफ़-नेट ( code.google.com/p/protobuf-net ) का उपयोग करके अनुक्रमित कर रहा हूं जो कि एक्स्टेंसिबल है। लेकिन आपके बिंदु मान्य हैं, हालाँकि, मुझे नहीं लगता कि उनकी फ़ाइल प्रारूप की कोई विधि है जो इसके लिए कारगर हो।
corylulu

हां ... यही कारण है कि मैं कभी-कभी कहता हूं कि आपको सिर्फ अपने हाथों को गंदा करना है और उस क्रम को संभालना है जिसमें डेटा मैन्युअल रूप से लिखा और लोड किया गया है।
ग्रैंडमास्टरबी

मैं जो एप्लिकेशन बना रहा हूं, वह डायनेमिक तक है और कुछ के लिए बहुत अधिक मूल्य हैं।
corylulu

1
आवेदन जितना जटिल होगा, फाइल फॉर्मेट पर उसका उतना ही अच्छा नियंत्रण होना जरूरी है। ध्यान रखें कि मैं यह नहीं कह रहा हूं कि प्रत्येक वर्ग के पास अपना स्ट्रीम करने योग्य आउटपुट नहीं होना चाहिए ... बस आपको प्रत्येक वर्ग के लिए उस पर नियंत्रण रखना चाहिए। तो बस उन दिनचर्या कहते हैं।
ग्रैंडमास्टरबी

हाँ, मेरे पास ऐसे तरीके हैं जो विरासत संस्करणों को आधुनिक संस्करणों में अपग्रेड करते हैं और मेरे पास बहुत स्पष्ट लेआउट है कि मेरी कक्षाएं कैसे लगाई जाती हैं। मैं उस बारे में अधिक चिंतित नहीं हूं, लेकिन मैं मानता हूं कि यह महत्वपूर्ण है। मैं इस पर लगभग एक साल से काम कर रहा हूं, इसलिए मेरे पास इस बारे में बहुत स्पष्ट दृष्टिकोण है कि यह कैसे काम करता है।
corylulu 16

1

मैं इस सवाल का जवाब सुनना भी पसंद करूंगा, जिसमें खुद से ज्यादा अनुभव वाले लोग हैं।

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

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

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


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

@JimmyHoffa जब मेरे जवाब ने भी ओपी के सवाल का समर्थन किया, तो मैंने स्पष्ट कर दिया कि मैं एक XML अर्ध-संरचित दृष्टिकोण का सुझाव दे रहा था .. लेकिन मैं देख रहा हूं कि आपका क्या मतलब है, मैं संपादित कर सकता हूं
एलन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.