JSON को YAML में बदलें

यह इस पेज समूह का इकलौता रूपांतरण है जहाँ "क्या क़ीमत चुकानी है" का जवाब सचमुच कुछ नहीं है। YAML 1.2, 2009 में प्रकाशित, हर वैध JSON दस्तावेज़ को अपना subset बताता है। रूपांतरण वही tree एक अलग style में दोबारा serialise करता है।

यह बाक़ी पेज को असामान्य बनाता है। कोई lossy कदम चेतावनी देने को नहीं, कोई flattening नहीं। इसकी बजाय वहाँ नतीजा कैसे पढ़ा जाएगा इसके बारे में सवाल हैं, और वे किसी भी डेटा नुक़सान से ज़्यादा मायने रखते हैं।

Writer YAML 1.2 का पालन करता है, जिसके तहत no, yes, on और off साधारण strings हैं। तो JSON value "no", बिना quote के no लिखी जाती है, और इसे 1.2 parser से वापस पढ़ने पर वही string मिलती है।

YAML 1.1 असहमत है। यह इन्हीं शब्दों को booleans के रूप में resolve करता है, और PyYAML — जिसे Ansible और बहुत सा Python tooling इस्तेमाल करता है — 1.1 reader है। अगर किसी data में value no है, converting के बाद उन्हें हाथ से quote कीजिए।

Quoting हर value के हिसाब से तय होती है, सिर्फ़ वहाँ जहाँ bare रूप कुछ और पढ़ी जाए। "1.0" quote होता है क्योंकि बिना quote के यह संख्या है। "null" quote होता है क्योंकि बिना quote यह null value है।

नियम consistent है और यह 1.2 का नियम है। जो कुछ writer quote करता है वह सब YAML 1.2 के तहत मतलब बदलता; जिन शब्दों को यह bare छोड़ता है वे सिर्फ़ 1.1 के तहत मतलब बदलते हैं।

JSON string में literal newline नहीं हो सकता, इसलिए किसी JSON manifest में embed किया shell script एक विशाल लाइन होती है जिसमें breaks की जगह backslash-n होता है। ऐसे बदलाव की समीक्षा करना मुमकिन नहीं होता।

YAML writer उन values को block scalars के रूप में लिखता है — एक pipe character, फिर टेक्स्ट अपनी indented लाइनों पर, breaks अपनी जगह पर। बारह-लाइन का entrypoint script बारह लाइनों में बदल जाता है।

Objects का JSON array उस dash-prefixed list में बदल जाता है जिसमें हर Kubernetes और GitHub Actions उदाहरण लिखा है — hyphen, फिर पहली key उसी लाइन पर और बाक़ी उसके नीचे indented।

यह सुधार review के लिए है, correctness के लिए नहीं, और review ही फ़ाइल का मक़सद है। छह deployment steps देखता reviewer braces गिने बिना उनकी सीमाएँ देख सकता है।

JSON कोई comment नहीं रखता, जो RFC 8259 की grammar से निकलता है, किसी parser की चूक से नहीं। YAML इन्हें कहीं भी रख सकता है जहाँ लाइन hash से शुरू हो सके। किसी generated manifest को YAML में बदलना अक्सर syntax के बारे में नहीं होता।

आउटपुट में कोई comment नहीं, क्योंकि input के पास देने को कुछ नहीं था। इन्हें जोड़ना पहला सार्थक edit है, और सबसे उपयोगी वे हैं जो कभी field की व्याख्या नहीं होते — बल्कि यह बताते क्यों replica count तीन है।

YAML में anchors और aliases हैं, जो किसी एक block को एक बार परिभाषित करने और तीन जगह इस्तेमाल करने देते हैं, और एक फ़ाइल में तीन hyphen से अलग किए कई documents हो सकते हैं। इनमें से कोई भी JSON स्रोत से नहीं आ सकता।

तो बदली फ़ाइल सही और flat है — JSON में जो दोहराया गया वह YAML में भी दोहराया गया है। दोहराव को anchor से हटाना एक हाथ से किया गया edit है।

Writer keys उसी क्रम में रखता है जिसमें वे आईं, इसलिए apiVersion, kind और metadata अपनी जगह रहते हैं, sorted नहीं होते। न JSON न YAML mapping order को अर्थपूर्ण मानते हैं, पर alphabetised keys वाला manifest पढ़ने में कठिन है।

यह जानना ज़रूरी है जब आउटपुट repository में पहले से मौजूद फ़ाइल के साथ तुलना करें। अगर दोनों सिर्फ़ order में अलग हैं, फ़र्क़ इस रूपांतरण से नहीं, जो JSON बनाया उससे आया।

सबसे सस्ती जाँच टूल की अपनी dry run है — kubectl apply with --dry-run=client, docker compose config। हर एक दस्तावेज़ parse करता है और वह आकार बताता है जो उसने पाया।

quoting समस्या पकड़ने वाली जाँच अलग है और जान-बूझकर करनी होती है — बदली फ़ाइल में बिना quote yes, no, on, off ढूँढिए और हर एक के लिए सोचिए कि क्या कोई YAML 1.1 reader इसे कभी देखेगा।

रूपांतरण इसी टैब में चलता है। JSON ब्राउज़र के अपने parser से पढ़ी जाती है और YAML किसी on-demand loaded library से लिखी जाती है, इसलिए कोई request दस्तावेज़ कहीं नहीं ले जाता।

किसी cluster से निकाला manifest internal hostnames, registry paths और infrastructure की आकृति रखता है, और कई संगठन इसे किसी सार्वजनिक web converter में paste करना घटना मानते हैं। यहाँ paste करने या भेजने को कुछ नहीं है।