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

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

एक्सटेंशन .toml है और पूरा नाम Tom's Obvious Minimal Language। दोनों उतना नहीं बताते जितना यह कि फ़ाइल अंदर क्या-क्या रख सकती है — और इस पन्ने का बाक़ी हिस्सा इसी के बारे में है।

यह 2013 तक पीछे जाता है। विनिर्देश TOML 1.0 है।

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

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

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

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

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

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

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

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

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

TOML INI जैसा दिखता है और डेटा फ़ॉर्मेट जैसा बरतता है। 30 लिखा मूल्य पूर्णांक है, 30.0 फ़्लोट है, true बूलियन है, "30" स्ट्रिंग है, और 2026-08-05 तारीख़ है — फ़ॉर्मेट इन सबको परिभाषित करता है, इसलिए हर पार्सर सहमत होता है और किसी प्रोग्राम को अंदाज़ा नहीं लगाना पड़ता।

यही अकेली विशेषता इसके अस्तित्व की ज़्यादातर वजह है। कॉन्फ़िगरेशन बग ठीक इसी अस्पष्टता के इर्द-गिर्द जमा होते हैं: "false" स्ट्रिंग की तरह पढ़ा गया फ़्लैग सच निकलना, वर्शन संख्या चुपचाप फ़्लोट बन जाना। प्रकार वाला फ़ॉर्मेट यह पूरी श्रेणी हटा देता है।

YAML ज़्यादा सक्षम है और उतना ही आसानी से ग़लत होता है, और TOML इसी के सीधे जवाब में लिखा गया। YAML में संरचना इंडेंटेशन से बयान होती है, इसलिए ग़लत जगह का स्पेस बिना एरर दिए दस्तावेज़ का मतलब बदल देता है।

फिर प्रकार का अनुमान है। पुराना YAML no को बूलियन पढ़ता है, इसलिए देश कोड false बन जाता है। 1.20 जैसी वर्शन संख्या फ़्लोट 1.2 बन जाती है। इनमें से हर एक ने असली आउटेज किए हैं। TOML में इनमें से कोई नहीं: संरचना साफ़ है, और मूल्य वही है जो उसकी वाक्य-रचना कहती है।

Rust ने इसे सबसे पहले हर जगह पहुँचाया — हर Cargo प्रोजेक्ट में Cargo.toml है — और Python ने निर्णायक रूप से पीछा किया: pyproject.toml अब बिल्ड कॉन्फ़िगरेशन की मानक जगह है, और भाषा अपनी स्टैंडर्ड लाइब्रेरी में TOML रीडर भेजती है।

इनके अलावा: Hugo और कई स्टैटिक-साइट जनरेटर, Netlify, Poetry, Ruff, और नए औज़ारों की लगातार धारा जो इंडेंटेशन जोखिम के बिना इंसान के संपादन योग्य कॉन्फ़िगरेशन चाहते थे।

ब्रैकेट वाला हेडर टेबल है, जो TOML में सेक्शन का शब्द है। नेस्टिंग बिंदु से होती है: [tool.ruff.lint] एक टेबल के भीतर टेबल के भीतर टेबल घोषित करता है, और बिंदु नाम का हिस्सा नहीं, संरचना हैं।

दोहरे ब्रैकेट वह हिस्सा हैं जो सबको पकड़ लेते हैं। [[bin]] तीन बार लिखने का मतलब टेबल को तीन बार दोबारा परिभाषित करना नहीं; यह tables की सरणी घोषित करता है, सूची में तीन एंट्री। यही है «एक जैसी कई चीज़ें» बताने का तरीक़ा — तीन बाइनरी, चार dependency।

TOML तारीख़ और समय सीधे समझता है: अकेली तारीख़, अकेला समय, और offset के साथ या बिना टाइमस्टैंप। ये पूर्णांक जैसे ही मूल्य हैं, बाद में पार्स की जाने वाली स्ट्रिंग नहीं।

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

गहरे नेस्टेड डेटा। TOML सपाट और पढ़ने लायक़ रहने के लिए डिज़ाइन है, और संरचना तीन-चार स्तर गहरी होते ही हेडर नाम लंबे हो जाते हैं और फ़ाइल उस JSON से ज़्यादा पालन करने में मुश्किल हो जाती है जिसे बदलने की कोशिश हो रही थी।

मशीन-बनाया डेटा दूसरी हालत है। TOML इंसान द्वारा संपादित फ़ाइलों के लिए है; JSON प्रोग्राम के बीच बदले जाने वाली फ़ाइलों के लिए, और यह छोटा, तेज़ पार्स होने वाला और हर जगह समर्थित है।

कोई भी टेक्स्ट एडिटर, और किसी भी असली काम के लिए TOML समर्थन वाला एडिटर रखने लायक़ है — यह बिना बंद हुई स्ट्रिंग या बिगड़ा टेबल हेडर तुरंत दिखा देगा।

दो आदतें ज़्यादातर ग़लतियाँ रोकती हैं। हर कुंजी को उसके सही टेबल हेडर के भीतर रखिए, क्योंकि पहले हेडर से ऊपर लिखी कुंजी top level में जाकर चुपचाप कुछ नहीं करती। और संख्या या बूलियन को उद्धरण में मत डालिए।