INI फ़ाइल क्या होती है?

INI एक सादा टेक्स्ट फ़ॉर्मेट है, जो किसी भी एडिटर में खुल जाता है। इसका इस्तेमाल एडिटिंग के लिए होता है।

एक्सटेंशन .ini है और पूरा नाम INI Configuration। दोनों उतना नहीं बताते जितना यह कि फ़ाइल अंदर क्या-क्या रख सकती है — और इस पन्ने का बाक़ी हिस्सा इसी के बारे में है।

यह 1985 तक पीछे जाता है।

जो फ़ॉर्मेट इतने लंबे समय तक पढ़ा जाता रहा हो, उसे वह चीज़ सौंपी जा सकती है जो आपको दस साल बाद वापस चाहिए।

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

यह अब भी हर जगह खुलता है और पुराने प्रोग्राम इसे अब भी लिखते हैं, पर इसके इर्द-गिर्द नया कुछ नहीं बन रहा। जो सहेजकर रखना है उसे बदल लीजिए, और आज शुरू हो रहे किसी काम के लिए इसे मत चुनिए।

INI फ़ाइल में टिप्पणी लिखने का तरीक़ा मौजूद है — और यही उस फ़ाइल में, जिसे कोई इंसान सँभालता है, और उसमें, जिसे कोई प्रोग्राम लिखता है, फ़र्क़ करता है। बिना टिप्पणी वाले फ़ॉर्मेट में बदलते समय सबसे पहले यही जाती हैं, और चेतावनी कोई नहीं देता।

Notepad और Visual Studio Code इसे पढ़ते हैं, और इसी तरह के ज़्यादातर दूसरे प्रोग्राम भी।

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

इसे कोई भी ब्राउज़र नहीं पढ़ता।

इसे बदलने की सबसे आम वजह यही है: फ़ॉर्मेट ख़राब है, ऐसा नहीं — बात यह है कि जहाँ आप फ़ाइल दिखाना चाहते हैं वह जगह उसे पढ़ ही नहीं सकती।

INI इसलिए बना है कि इसे खोला और बदला जाए। जब तक काम चल रहा है फ़ाइल इसी फ़ॉर्मेट में रखिए, और जब भी बनी हुई प्रति चाहिए हो, इसी से निर्यात कीजिए।

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

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

timeout=30 लिखिए तो फ़ाइल में सिर्फ़ अक्षर 3 और 0 हैं। यह संख्या बनेगी या नहीं, और सेकंड मानी जाएगी या मिलीसेकंड, यह पूरी तरह पढ़ने वाला प्रोग्राम तय करता है। true, yes, on और 1 — बूलियन लिखने के ये सभी आम तरीक़े हैं, कोई भी फ़ॉर्मेट से परिभाषित नहीं, हर लाइब्रेरी अलग उपसमूह स्वीकार करती है।

यही JSON, YAML या TOML से असली फ़र्क़ है — उन सबमें प्रकार होते हैं। इसीलिए INI कॉन्फ़िगरेशन फ़ाइलों के साथ अक्सर दस्तावेज़ या टिप्पणियाँ होती हैं जो मूल्यों का अर्थ बताती हैं, और यही वजह है कि एक ही प्रोग्राम के दो कार्यान्वयनों के बीच फ़ाइल ले जाना दिखने से ज़्यादा जोखिम भरा है।

नेस्टेड JSON, YAML या XML को यहाँ INI में बदलने पर हर पत्ती-मूल्य के लिए एक कॉलम बनता है, नाम बिंदु-जुड़े पथ के रूप में — जैसे server.port या tags.0। INI सपाट करके लिखे जाने वाले लक्ष्यों की उस सूची में शामिल है, ठीक CSV, TSV, SQL और XLSX की तरह।

दूसरी दिशा में — INI से पढ़ते वक़्त — कुंजियों का क्रम सुरक्षित रहता है, इस पूरे इंजन में कहीं कोई क्रमबद्ध करने वाला कोड नहीं है। जो नहीं बचता वह टिप्पणियाँ हैं: फ़ाइल में जो भी अर्धविराम या हैश से शुरू लाइनें थीं, वे पढ़ते वक़्त सीधे छोड़ दी जाती हैं, और कोई भी लेखक टिप्पणी वापस नहीं लिखता।

Windows में अब भी कुछ जगह: desktop.ini जो बताता है फ़ोल्डर कैसे दिखे, बूट और ड्राइवर सेटिंग्स, और बहुत से एप्लिकेशन जिन्हें बदलने की कभी ज़रूरत नहीं पड़ी। गेम इसका बड़ा स्रोत हैं — बहुत सारे PC गेम अपनी ग्राफ़िक्स और इनपुट सेटिंग्स INI में रखते हैं।

बाक़ी जगह यह उन औज़ारों में बचा है जो आधुनिक विकल्पों से पहले के हैं: PHP का php.ini, Git की कॉन्फ़िगरेशन, Python के setup.cfg जैसे पैकेजिंग औज़ार, systemd यूनिट फ़ाइलें। नई परियोजनाएँ अक्सर TOML या YAML चुनती हैं, पर मौजूदा इंस्टॉलेशन में जो पहले से है वह दोबारा नहीं लिखा जाने वाला।

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

फिर वे बारीकियाँ जो असल में गड़बड़ी करती हैं। UTF-8 में बिना byte order mark के सहेजिए, क्योंकि शुरुआत के अदृश्य बाइट्स कई पार्सरों में पहला सेक्शन-शीर्षक तोड़ देते हैं। बराबर-चिह्न के इर्द-गिर्द अनावश्यक रिक्त स्थान न जोड़ें, क्योंकि कुछ पाठक उन्हें नहीं काटते और मूल्य में एक अगला रिक्त स्थान जुड़ जाता है।

साफ़ समझ में आने में। जिस व्यक्ति ने यह फ़ाइल कभी नहीं देखी, वह भी इसे खोल सकता है, fullscreen नाम की सेटिंग ढूँढ़ सकता है, false को true में बदल सकता है, और सही होगा। यही वजह है कि यह फ़ॉर्मेट 1990 के दशक में इसे बदलने के लिए बने हर विकल्प से आगे टिका रहा।

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

जब कॉन्फ़िगरेशन साधारण स्ट्रिंग-सेक्शन से आगे बढ़ जाए। नेस्टेड ढाँचा, सूचियाँ, तारीख़ें, संख्याएँ जिन्हें सचमुच संख्या होना चाहिए, या कोई भी मूल्य जहाँ स्ट्रिंग "false" और बूलियन false का फ़र्क़ मायने रखे — यहाँ INI मदद करना बंद कर देता है और चुपचाप गड़बड़ी छिपाने लगता है।

TOML को ठीक इसी सवाल के जवाब में डिज़ाइन किया गया: यह INI जैसा दिखता है, इसलिए किसी को नया आकार सीखना नहीं पड़ता, और इसका एक विनिर्देश है, असली प्रकार हैं, परिभाषित नेस्टिंग है। अगर कोई फ़ाइल बढ़ने वाली है, TOML छोटा और सुरक्षित क़दम है।