INI फाइलें या रजिस्ट्री या व्यक्तिगत फाइलें?

Question

मैं अपनी परियोजना के विन्यास को बचाना चाहता हूं जिसमें शामिल है

1. स्क्रीन का आकार
2. स्क्रीन की स्थिति
3. फ़ोल्डर पथ
4. उपयोगकर्ता सेटिंग्स और इतने पर।

मानक स्थान जहाँ आप इन्हें सहेज सकते हैं, कॉन्फ़िगरेशन मान हैं:

1. रजिस्ट्री
2. INI फाइलें
3. व्यक्तिगत फ़ाइलें (जैसे * .cfg)

आप इन स्थानों के बीच कैसे चयन करते हैं? इसके अलावा, क्या उनमें से किसी का उपयोग करने का कोई पेशेवरों और विपक्ष हैं?

Comments

आप किन उपकरणों का उपयोग कर रहे हैं? कुछ प्रौद्योगिकियों विन्यास प्रबंधन उपकरण में बहुत अच्छा निर्माण के साथ आता है।

@ Pierre303 वर्तमान में वीसी ++ के लिए वीएस 2008 का उपयोग कर रहा है

— शिरीष 11

क्या उपयोगकर्ताओं को परिवर्तन करने की आवश्यकता होगी?

— जेएफओ

क्या आपने YAML पर विचार किया है, आपको ini और xml en.wikipedia.org/wiki/YAML

— JF Dion

Answer 1

इसके अलावा क्या उनमें से किसी का उपयोग करने का कोई नियम और विपक्ष है?

रजिस्ट्री:

• + विंडोज वातावरण में अपेक्षाकृत मानक।
• + आम तौर पर इंस्टॉलर आदि से अच्छा समर्थन।
• - यदि आप कभी भी अपने एप्लिकेशन को पोर्ट करना चाहते हैं तो प्लेटफॉर्म विशिष्ट एपीआई।
• - विशेष रूप से मानव पठनीय नहीं।

INI फाइलें:

• + सरल प्रारूप।
• + पोर्टेबल।
• + मानव पठनीय।
• - अधिक जटिल जानकारी संग्रहीत करना मुश्किल हो सकता है (उदाहरण के लिए, कुछ भी दो स्तरों से अधिक नेस्टेड है)।
• ?अपने खुद के पार्सर (हालांकि मुश्किल नहीं है) को लिखना है या सिंपलइनी जैसी बाहरी लाइब्रेरी का उपयोग करना है (टिप्पणी के लिए जोनाथन मेरलेट के लिए धन्यवाद)।

XML फ़ाइलें (मुझे लग रहा है कि यह .cfg विकल्प है):

• + एक मानक प्रारूप।
• + पोर्टेबल।
• + गहरी नेस्टेड संरचनाओं का समर्थन करता है।
• - विशेष रूप से मानव पठनीय नहीं।

व्यक्तिगत रूप से, विंडोज़ अनुप्रयोगों के लिए मैं C # का उपयोग करता हूं, और XML के रूप में संग्रहीत उपयोगकर्ता के लिए एक व्यक्तिगत फ़ाइल के साथ जाता हूं। मैं आमतौर पर ऐसा करता हूं क्योंकि मानव पठनीयता आमतौर पर मेरे द्वारा लिखे जाने वाले अनुप्रयोगों के प्रकार में प्राथमिकता नहीं है (और आवेदन में किसी भी मामले में कॉन्फ़िगरेशन संपादक होना चाहिए), और .NET वातावरण में, XML के साथ काम करना बहुत आसान है। मैं बहुत बार एक UserConfiguration ऑब्जेक्ट के साथ समाप्त होता हूं, जो केवल कॉन्फ़िगरेशन फ़ाइल से और लगभग क्रमबद्ध हो जाता है - जिसमें लगभग कोई भी विकास शामिल नहीं है (पार्सिंग, कास्टिंग सामग्री), और आपके पास एक मजबूत टाइप किए गए वातावरण में उपयोग करने के लिए तैयार है।

Comments

मैंने कुछ समय पहले INI फ़ाइलों को पार्स करने के लिए SimpleIni का उपयोग किया था और यह अच्छी तरह से काम कर रहा था।

— जोनाथन मेरलेट

@JonathanMerlet धन्यवाद, मैंने पोस्ट में SimpleIni को जोड़ा है।

— डैनियल बी

Answer 2

मैं आईएनआई फाइलों के साथ जाऊंगा, वे अधिक मानवीय अनुकूल विकल्प हैं:

[window]
width       = 600
height      = 350
position.x  = 400
position.y  = 200

[paths]
path1       = "/some/random/path/"
path2       = "/some/other/random/path/"

[user]
name        = "Yannis"
preference  = "INI"

XML एक अच्छा विकल्प हो सकता है, लेकिन यह INI की सादगी और लालित्य को नहीं हरा सकता है:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <window>
        <width>600</width>
        <height>350</height>
        <position>
            <x>400</x>
            <y>200</y>
        </position>
    </window>
    <paths>
        <path1>/some/random/path/</path1>
        <path2>/some/other/random/path/</path1>
    </paths>
    <user>
        <name>Robert</name>
        <preference>XML</preference>
    </user>
</configuration>

INI बहुत अच्छी तरह से समझे जाते हैं और प्लेटफार्म स्वतंत्र होते हैं। XML फ़ाइलों के लिए संभवतः उनके लिए उतने उपकरण उपलब्ध नहीं हैं, क्योंकि, एक INI फ़ाइल को पढ़ने और संपादित करने के लिए किसी विशेष उपकरण की आवश्यकता है?

Comments

अजीब बात है, लेकिन मुझे XML अच्छे दिखने वाले और पढ़ने में आसान लगता है। उन लोगों के लिए जो क्रियाशीलता पसंद नहीं करते हैं, JSON एक उपयुक्त विकल्प है।

— रॉबर्ट हार्वे

@RobertHarvey JSON मुझे पसंद है (और अगर मुझे गहरी घोंसले के शिकार की आवश्यकता होती है) का उपयोग करेंगे, लेकिन XML वास्तव में मेरी चाय का कप नहीं है ...

— yannis

एक्सएमएल को विशेषताओं में मूल्यों को रोल करके अच्छा बनाया जा सकता है। उदाहरण के लिए,<window width="600" height="350" />

— रॉबर्ट हार्वे

मैं वास्तव में आश्चर्यचकित हूं कि किसी का उल्लेख यमरल नहीं है। मुझे लगता है कि यह JSON की तुलना में एक स्पर्श अधिक मानवीय अनुकूल है, लेकिन क्षमता और वाक्य रचना में काफी समान है। Yaml.org वेबसाइट शायद किसी को भी डराती है, हालांकि पहले से कोई परिचित नहीं है।

— डेनियल बी

@ डैनियलबी किसी ने YAML ;) का उल्लेख किया है

— yannis

Answer 3

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

Comments

लेकिन बुरी तरह से क्रिया और मानव के बाद पठनीय नहीं होते हैं (नाम स्थान की घोषणा और अन्य बी एस के साथ अधिकतम करने के लिए प्रेरित या फूला हुआ नहीं लगता है)।

— मनबज़्स

@Manjabes: ऐसी विशेषताएं जो कॉन्फ़िगरेशन फ़ाइलों के लिए महत्वपूर्ण होने की संभावना नहीं हैं।

— रॉबर्ट हार्वे

@ स्ट्रोब हार्वे: बहुत महत्वपूर्ण जहां मैं रहता हूं। आप जिस सेटिंग का उपयोग करते हैं, उसके साथ मूल ध्यान के लिए, आप जिस एडिट को संपादित करते हैं, उसके लिए आप आईएनआई को एडिट करते हैं।

— पीटर बी

Answer 4

YAML के जेफ डी के सुझाव का विस्तार करने के लिए , यहां संक्षिप्त परिचय दिया गया है।

YAML JSON के समान है (वास्तव में, JSON YAML मानक के संस्करण 1.2 के बाद से YAML का सबसेट है, और इस प्रकार मान्य JSON को YAML पार्सर्स द्वारा पार्स किया जा सकता है)। पहली नज़र में, मुख्य अंतर यह है कि YAML (डिफ़ॉल्ट रूप से) पदानुक्रम दिखाने के लिए ब्रैकेटिंग के बजाय इंडेंटेशन का उपयोग करता है। स्ट्रिंग्स के लिए उद्धरणों का ध्यान देने योग्य अभाव भी है। ऊपर से एक त्वरित उदाहरण:

configuration:
  window: 
    width:       600
    height:      350
    position:
      x:         400
      y:         200
  paths:
    path1:       some/random/path
    path2:       some/other/random/path
  user:
    name:        Joe Soap
    preference:  YAML

बेहतर उदाहरणों के लिए विकिपीडिया के YAML पृष्ठ देखें । अधिकांश प्रमुख भाषाओं के लिए YAML का समर्थन मौजूद है ( विवरण के लिए yaml.org देखें)।

Answer 5

आप एक विकल्प भूल गए: डेटाबेस। यह ज्यादातर उन परिदृश्यों में उपयोग किया जाता है जहां आपके उपयोगकर्ता आपके एप्लिकेशन में लॉग इन करते हैं जब आपका एप्लिकेशन विंडोज़ उपयोगकर्ता के लॉग पर भरोसा नहीं कर सकता है। यह उदाहरण के लिए है जब आपका ऐप कियोस्क मोड विंडो में चल रहा है।

Comments

डेटाबेस के लिए कनेक्शन विवरण / स्ट्रिंग को पकड़ने के लिए आपको एक INI फ़ाइल या रजिस्ट्री कुंजी की आवश्यकता हो सकती है

— कक्षा कंकाल

@CamelCase Inifile या रजिस्ट्री कुंजी पहले ही प्रश्न में उल्लिखित थी, लेकिन डेटाबेस नहीं। मेरे कहने का मतलब यह नहीं था कि आप एक ही समय में कई तरीकों का उपयोग नहीं कर सकते।

— पीटर बी।

Answer 6

मेरी व्यक्तिगत प्राथमिकता XML फाइलें हैं:

ज्यादातर मामलों में मुझे उम्मीद नहीं है कि उपयोगकर्ता को अपनी कॉन्फ़िगरेशन सेटिंग्स को संपादित करना होगा, इसलिए मानव पठनीयता का मुद्दा इस मामले में एक तर्क नहीं है।

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

ध्यान दें कि आपको अभी भी सावधान रहने की आवश्यकता है कि आपको अपनी फ़ाइल को संग्रहीत करने की अनुमति है क्योंकि कुछ स्थानों पर विंडोज 7 आदि में डिफ़ॉल्ट रूप से लिखने की पहुंच नहीं है।

---

INI फ़ाइलें कॉन्फ़िगरेशन को संग्रहीत करने का एक अच्छा मानक तरीका है और कोशिश की जाती है और परीक्षण किया जाता है, लेकिन वे सिर्फ मुझे थोड़ा 'विंडोज 3.1' महसूस करते हैं!

संभवत: सबसे अच्छा विकल्प यदि आप चाहते हैं कि उपयोगकर्ता अपने डेटा के साथ छेड़छाड़ करने में सक्षम हो

---

मैं व्यक्तिगत रूप से रजिस्ट्री से दूर जाऊंगा। एक बात के लिए आप इस बात की गारंटी नहीं दे सकते हैं कि उपयोगकर्ता के पास आपके डेटा को संग्रहीत करने के लिए जहाँ कहीं भी पढ़ने / लिखने की आवश्यक अनुमतियाँ हैं।

अधिक हाल के ओएस में, जहां रजिस्ट्री वर्चुअलाइजेशन खेलने में आता है, यह बड़ी उलझन पैदा कर सकता है क्योंकि आप वर्चुअलाइज्ड सेटिंग्स को 'नहीं' देख सकते हैं - इससे हमें एक बार से अधिक काट लिया गया है जहां घंटों बिताए हैं यह जानने की कोशिश करें कि कुछ काम क्यों नहीं कर रहा था।

Comments

यदि आप रजिस्ट्री स्थानों के लिए अनुमतियों के बारे में चिंतित हैं, तो आप शायद उन्हें गलत स्थान पर संग्रहीत करने का प्रयास कर रहे हैं। उपयोगकर्ता के पास HKey_Current_User हाइव के लिए अनुमतियाँ होनी चाहिए, और यहीं प्रति उपयोगकर्ता सेटिंग होनी चाहिए!

— नील श्वेत

@NeilWhite - सहमत हैं कि उनके पास अनुमति होनी चाहिए लेकिन एक अति उत्साही आईटी व्यवस्थापक इसे बदल सकता है (या पढ़ने / लिखने दे लेकिन अनुमतियाँ नहीं बना सकता)। साथ ही ओपी ने यह उल्लेख नहीं किया कि ये सेटिंग्स आवश्यक रूप से प्रति उपयोगकर्ता थीं , वे प्रति मशीन हो सकती हैं।

— मैट विल्को

साथ ही, रजिस्ट्री की आकार सीमा हो सकती है। फ़ाइलें नहीं।

— अलंकृत