YAML को JSON में और वापस कन्वर्ट करें

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

फाइलें यहां छोड़ें

.yaml, .yml, .json, .txt · 300 MB तक

फाइलें चुनें

अपने आप पहचानेंYAML से JSONJSON से YAML

और सेटिंग

इंडेंटेशनYAML स्कीमासिर्फ पहला नहीं, हर डॉक्यूमेंट पढ़ेंकुंजियों को वर्णक्रम में लगाएंइस गहराई से इनलाइन स्टाइलकोट

YAML को JSON में और वापस कैसे कन्वर्ट करें

1
YAML या JSON फाइल डालें
एक फाइल डालें या बीस तक। .yaml, .yml और .json, तीनों एक्सटेंशन पहचाने जाते हैं, और एक बैच में ये किसी भी तरह मिले हो सकते हैं।
2
तय हुई दिशा जांचें
दिशा एक्सटेंशन से चुनी जाती है, और सादे टेक्स्ट के लिए कंटेंट से। अगर अपने आप लगाया गया अंदाजा वह नहीं है जो आप चाहते थे, तो दिशा बदल दें।
3
कन्वर्ट करें और डाउनलोड करें
बटन दबाएं और कन्वर्ट की गई फाइल सेव करें। कई फाइलें एक ZIP आर्काइव में वापस मिलती हैं।

दिशा का अंदाजा सावधानी से क्यों लगाना पड़ता है

हर सही JSON डॉक्यूमेंट सही YAML भी है। इसलिए अगर फाइल को पहले YAML पार्सर से जांचा जाए, तो सादी .json फाइल YAML मानी जाएगी और खुद में ही कन्वर्ट हो जाएगी। इसीलिए एक्सटेंशन जीतता है: .json, YAML में बदलती है, और .yaml और .yml, JSON में। सिर्फ .txt और बिना एक्सटेंशन वाले इनपुट में कंटेंट फैसला करता है, और ठीक इसी वजह से पहले JSON आजमाया जाता है।

दोहराई गई key गड़बड़ी है, पसंद का मामला नहीं

JSON में दोहराई गई key की आखिरी वैल्यू चुपचाप जीत जाती है। YAML में यही दोहराव ऐसी गलती है जिस पर रुकना चाहिए, क्योंकि यह कॉन्फिग फाइलों में होता है। अगर docker-compose.yml में एक ही लेवल पर ports दो बार लिखा है, तो पहली सूची चुपचाप रद्द हो जाती है, और इसका पता आम तौर पर प्रोडक्शन में चलता है। दोनों लाइन नंबर बताए जाते हैं, ताकि आप देख सकें कि कौन-सी परिभाषा गायब होने वाली थी।

चार स्कीमा, और छोटी स्कीमा से क्या मिलता है

default स्कीमा YAML के आम टाइप पहचानती है, तारीख और बाइनरी डेटा भी। core और json एक के बाद एक ज्यादा सख्त हैं, और failsafe सिर्फ स्ट्रिंग, मैप और सीक्वेंस पहचानती है। जब कॉन्फिग को अक्षरशः डेटा की तरह पढ़ना हो, तब छोटी स्कीमा चुनें: इससे YAML के मशहूर झटके रुकते हैं, जैसे वर्जन नंबर का float बन जाना और no का false बन जाना।

कॉन्फिग आपकी मशीन पर ही रहते हैं

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

अक्सर पूछे जाने वाले सवाल

कन्वर्जन की दिशा कैसे चुनी जाती है?

पहले फाइल के एक्सटेंशन से: .json, YAML में जाती है, और .yaml और .yml, JSON में। .txt और बिना एक्सटेंशन वाली फाइलों में कंटेंट फैसला करता है: टेक्स्ट को पहले JSON के रूप में आजमाया जाता है, फिर YAML के रूप में। अगर दोनों में से कोई पार्स नहीं होता, तो आपको बताया जाता है और आप दिशा खुद चुन सकते हैं।

कई डॉक्यूमेंट वाली YAML फाइल का क्या होता है?

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

दोहराई गई key को गड़बड़ी क्यों माना जाता है?

क्योंकि YAML में दूसरी परिभाषा पहली को बिना किसी संकेत के बदल देती है। कॉन्फिग फाइल में पोर्ट मैपिंग या एनवायरनमेंट वेरिएबल खोने का यह आम तरीका है। कन्वर्जन रुक जाता है और key के साथ दोनों लाइन नंबर बताता है, ताकि आप तय करें कि कौन-सी परिभाषा चाहिए थी।

failsafe स्कीमा क्या है और इसकी जरूरत कब है?

failsafe सिर्फ स्ट्रिंग, मैपिंग और सीक्वेंस पहचानती है; कुछ भी संख्या, boolean, तारीख या null में नहीं बदलता। यह तब सही है, जब कॉन्फिग को अक्षरशः बचाना हो, जैसे जब 1.10 जैसी वैल्यू संख्या नहीं, वर्जन हो, या जब Norway problem देश के कोड no को false में बदल रहा हो।

क्या YAML के कमेंट JSON में बचे रहते हैं?

नहीं, और बच भी नहीं सकते। JSON में कमेंट के लिए कोई सिंटैक्स है ही नहीं, इसलिए # के बाद का सब कुछ कन्वर्जन में हट जाता है। यह टूल की कमी नहीं, बल्कि आउटपुट फॉर्मेट की खासियत है, इसलिए अगर कमेंट आपके लिए जरूरी हैं, तो YAML को ही मूल फाइल रखें।

flow level से क्या बदलता है?

यह तय करता है कि नेस्टिंग की किस गहराई पर YAML आउटपुट ब्लॉक स्टाइल, यानी डैश और इंडेंट, से इनलाइन स्टाइल, जैसे [a, b] और {a: b}, में बदलता है। डिफॉल्ट में हर लेवल ब्लॉक स्टाइल में रहता है, जो हाथ से एडिट किए जाने वाले कॉन्फिग के लिए सबसे पढ़ने लायक है। कोई धनात्मक गहराई सेट करने पर उसके नीचे का सब कुछ छोटा हो जाता है, जो बहुत गहराई तक नेस्टेड डेटा के लिए ठीक है।

क्या anchors और aliases चलते हैं?

नहीं। Anchors, aliases और merge keys (&defaults, *defaults और <<), साथ ही कस्टम एप्लिकेशन टैग, इस टूल की पढ़ाई से बाहर हैं। इन्हें इस्तेमाल करने वाली फाइल पर चुपचाप गलत परिणाम की जगह लाइन बताने वाली साफ गड़बड़ी मिलती है। जिस कॉन्फिग को आप डिप्लॉय करने वाले हैं, उसके लिए यही ज्यादा सुरक्षित नाकामी है।

क्या मेरी फाइल कहीं अपलोड होती है?

नहीं। दोनों पार्सर पेज के साथ आते हैं और आपके ब्राउजर टैब के अंदर चलते हैं, इसलिए आपका कॉन्फिगरेशन कभी नेटवर्क पर नहीं जाता। इसे सेव करने वाला कोई सर्वर हिस्सा नहीं है, और टैब बंद होने के बाद कुछ भी नहीं रखा जाता।