मुफ्त YAML से JSON कन्वर्टर

YAML को तुरंत JSON में कन्वर्ट करें। सूचियों, मैप और एंकर समेत सभी YAML सिंटैक्स को संभालता है। पूरी तरह से आपके ब्राउज़र में चलता है।

आपका डेटा कभी आपका डिवाइस नहीं छोड़ता
YAML फाइल यहाँ ड्रॉप करें या ब्राउज़ करने के लिए क्लिक करें (अधिकतम 5 MB)

YAML क्या है?

YAML (YAML ऐन्ट मार्कअप लैंग्वेज) एक मानव-अनुकूल डेटा सीरियलाइजेशन फॉर्मेट है जिसका उपयोग आमतौर पर कॉन्फिगरेशन फाइलों के लिए किया जाता है। इंडेंटेशन और सरल सिंटैक्स का उपयोग करके सूचियों, डिक्शनरी और स्केलर मानों जैसी डेटा संरचनाओं का प्रतिनिधित्व करता है।

YAML को JSON में क्यों कन्वर्ट करें?

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

कौन सी YAML सुविधाएँ समर्थित हैं?

कन्वर्टर मैप, सूचियाँ, स्ट्रिंग, संख्याएँ, बूलियन, नल, मल्टीलाइन स्ट्रिंग, एंकर और उपनाम समेत सभी मानक YAML सुविधाओं का समर्थन करता है।

क्या मेरी जटिल YAML संरचना सही ढंग से कन्वर्ट होगी?

हाँ। कन्वर्टर नेस्टेड संरचनाएँ, ऑब्जेक्ट्स की सूचियाँ, टिप्पणियाँ (जो हटा दी जाती हैं) और सभी YAML सिंटैक्स संभालता है। यदि सिंटैक्स त्रुटि है, तो आपको स्पष्ट त्रुटि संदेश मिलेगा।

क्या YAML टिप्पणियाँ संरक्षित रहती हैं?

नहीं। टिप्पणियाँ डेटा संरचना का हिस्सा नहीं हैं, इसलिए वे JSON आउटपुट में शामिल नहीं होतीं।

YAML का एक संक्षिप्त इतिहास, 2001 का mailing-list spin-off

YAML की prehistory sml-dev mailing list से शुरू होती है, जो xml-dev से निकला एक 2000s का offshoot था जिसने ऐसे लोगों को एकत्र किया जो सोचते थे कि XML human-edited data के लिए overkill है। दो parallel tracks converge हुए: Inline Perl module के लिए serialization format के रूप में लिखा गया Ingy döt Net का Perl module Data::Denter, और Oren Ben-Kiki और Clark Evans का joint work जो XML को simplify करने पर aimed था। 11 मई 2001 को, Clark Evans ने sml-dev पर «YAML Draft 0.1» post किया, और format को अगले दिन एक xmlhack article में पहली बार publicize किया गया।

acronym का initial expansion tongue-in-cheek था: Yet Another Markup Language, 2001 में markup formats की proliferation पर एक jab। दिसंबर 2001 और अप्रैल 2002 के बीच authors ने recursive backronym YAML Ain't Markup Language को retrofit किया: आंशिक रूप से यह underline करने के लिए कि YAML XML या HTML जैसे document-markup format के बजाय एक data-serialization format है, और आंशिक रूप से इसलिए कि joke पुरानी हो गई थी। recursive expansion आज भी yaml.org पर official tagline है।

विनिर्देश समयरेखा

1.2.2 spec स्पष्ट है कि «there are no normative changes from the YAML specification v1.2»; काम में source को DocBook से Markdown में convert करना, plain-text LaTeX से diagrams regenerate करना, और development process को open करना शामिल था ताकि external contributors spec के विरुद्ध pull requests file कर सकें। 2009 के बाद से कोई language नहीं आई: तब से हर parser-conformance bug या तो 1.1 holdover है या उस spec से deviation है जो अब पंद्रह से अधिक वर्षों से बरकरार है। official MIME type application/yaml 2024 में finalised हुआ; file extensions .yaml और .yml दोनों 2006 से recognized हैं, .yaml recommended है।

JSON relationship, «almost a superset»

YAML 1.2.2 spec इसे carefully कहता है: «By sheer coincidence, JSON was almost a complete subset of YAML.» JSON, YAML 1.0 (2004) और YAML 1.1 (2005) के बीच appear हुआ; YAML authors ने overlap को retroactively discover किया। 1.2 revision का explicit goal, इसके अपने words में, था «making YAML a strict superset of JSON», और यह JSON-formatted YAML 1.2 documents के लिए almost true है लेकिन YAML 1.1 के लिए not true है।

practical terms में: हर JSON document valid YAML 1.2 है, flow-style mapping {"a": 1, "b": [true, null]} दोनों में identically parse होता है। अधिकांश JSON documents YAML 1.1 में valid नहीं हैं boolean और Norway gotchas के कारण: literal string "NO" वाला JSON document 1.1 parser द्वारा default settings से round-tripped होने पर false के रूप में re-emitted होगा। reverse कभी true नहीं है: YAML ऐसी चीज़ें express कर सकता है जो JSON नहीं कर सकता, comments (conversion पर lost), anchors और aliases (conversion पर resolved), tags (typically discarded), multi-document streams (केवल first या all-as-array survive), और mappings पर non-string keys।

Norway Problem

YAML का सबसे अधिक cited gotcha। इसका नाम Norway के नाम पर है क्योंकि Norway का ISO 3166-1 two-letter country code NO है, और YAML 1.1 का boolean regex NO को boolean false के रूप में match करता है। YAML 1.1 में (या किसी भी 1.2 parser में जो अभी भी 1.1 behaviour पर default है, जो उनमें से अधिकांश हैं) country: NO लिखें, parse करें, JSON के रूप में dump करें, और आपको {"country": false} मिलता है। bug silent है, कोई warning नहीं, कोई type error नहीं, बस data corruption।

official yaml.org/type/bool.html schema से full YAML 1.1 boolean regex है:

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

यह छह lexemes (y/n, yes/no, on/off, true/false) तीन case variants प्रत्येक के साथ हैं, बाईस strings जो सभी बिना warning के booleans बन जाती हैं। valid responses की एक list [y, n, maybe], [true, false, "maybe"] बन जाती है; एक feature flag dark_mode: on, dark_mode: true के रूप में parse होता है; एक port-mode setting OFF, false बन जाती है। YAML 1.2 ने spec level पर इसे fix किया: JSON-aligned core schema केवल true, True, TRUE, false, False, FALSE को recognize करता है और y/n/yes/no/on/off को बिल्कुल recognize नहीं करता। लेकिन यह fix field तक नहीं पहुँची, PyYAML और LibYAML सभी currently shipping versions में अभी भी 1.1-default हैं। यह converter js-yaml v4 use करता है, जो YAML 1.2 / JSON-compatible schema पर default है; यही एक reason है कि browser-side converter वास्तव में PyYAML में yaml.load() run करने और वहाँ से convert करने से safer है।

अन्य implicit-typing landmines

Octal numbers। YAML 1.1 C convention follow करता था: leading zero का अर्थ octal था। इसलिए 010 integer 8 के रूप में parse होता था, और permissions: 0777 (Unix file mode लिखने का एक perfectly natural तरीका) 511 के रूप में parse होता था। YAML 1.2 का fix modern Python से matching explicit 0o prefix की आवश्यकता करना था, 0o777 511 है, और 0777 बस 777 है। 1.1 defaults पर stuck parsers अभी भी इसे गलत करते हैं।

Sexagesimal numbers। YAML 1.1 ने earlier serialization formats से convention inherit की कि colons द्वारा separated decimal digit groups के किसी भी sequence को base-60 (sexagesimal) integer या float के रूप में parse किया जाना चाहिए। advertised use case time durations था: 1:11:00 integer 4260 (एक घंटा, ग्यारह मिनट seconds में) के रूप में parse होता। यह rule practice में अभी भी लोगों को तब परेशान करती है जब वे 21:00 जैसे timestamps या 2:3:4 जैसे version numbers लिखते हैं और उन्हें silently integers में coerce पाते हैं। Sexagesimal को YAML 1.2 में silently remove किया गया, लेकिन PyYAML और अन्य 1.1-default parsers अभी भी इसे apply करते हैं।

Datetime auto-coercion। YAML 1.1 ISO 8601 timestamps को भी auto-detect करता है और उन्हें host language के native date/time type के रूप में parse करता है, जो एक problem है अगर आप string चाहते थे। version: 2024-01-15 लिखें और आपको Python date object मिलता है, string "2024-01-15" नहीं। Ruud van Asseldonk के «YAML document from hell» essay द्वारा hammered home यह general lesson: हमेशा उन strings को quote करें जो conceivably किसी और चीज़ के रूप में parse हो सकती हैं। Country codes, version numbers, file modes, timestamps, और fixed vocabulary से drawn कोई भी value को single या double quotes में wrap करना चाहिए।

Anchors, aliases, और merge key

YAML का anchor/alias system आपको किसी node को &name से label करने और बाद में *name के साथ reuse करने देता है। classic example:

defaults: &defaults
  timeout: 30
  retries: 3
production:
  <<: *defaults
  host: prod.example.com

यहाँ &defaults mapping को anchor करता है, और <<: *defaults (merge key, जो अधिकांश parsers द्वारा retained एक 1.1 schema feature है) इसे production block में splice करता है। जब यह JSON में convert होता है, alias fully resolved हो जाता है, JSON output में literal repeated content होती है, reference नहीं। Anchors और aliases गायब हो जाते हैं, और कोई भी merge keys flatten हो जाती हैं।

इस system का प्रसिद्ध failure mode billion laughs attack है: क्योंकि anchors को multiple times alias किया जा सकता है और alias targets खुद anchors contain कर सकते हैं, एक छोटी YAML file एक enormous in-memory structure तक expand हो सकती है (10 levels × 10-fold nesting = 10¹⁰ string elements)। PyYAML, LibYAML, और अन्य को इसे mitigate करने के लिए expansion limits जोड़नी पड़ीं। Browser-side converters के natural memory caps हैं (tab host के suffer करने से बहुत पहले OOM हो जाएगा), लेकिन structural risk real है।

Multi-document streams और front matter

एक YAML stream में एक से अधिक documents हो सकते हैं। Documents को --- वाली एक line से separate किया जाता है (पहले document की शुरुआत में एक directives-end marker के रूप में भी use किया जाता है, यही कारण है कि Jekyll, Hugo, और Eleventy में front matter --- lines से bracketed है)। ... वाली एक line एक document के end को mark करती है बिना नया शुरू किए, streaming protocols में useful।

Kubernetes एक file में multiple resource manifests bundle करने के लिए --- use करता है। JSON का कोई equivalent नहीं है। एक converter के पास multi-document YAML hit करने पर तीन choices होती हैं: केवल first document emit करें, documents का JSON array emit करें, या --- से separated प्रत्येक JSON document को newlines द्वारा separated emit करें (JSON Lines)। अधिकांश converters first या second option पर default हैं; js-yaml का loadAll एक array return करता है।

Multi-line strings, folded बनाम literal

YAML के दो block-scalar styles हैं। literal style (|) newlines को exactly preserve करती है। folded style (>) single line breaks को spaces से replace करती और blank lines को paragraph separators के रूप में preserve करती है। दोनों chomping indicators accept करती हैं: |- और >- सभी trailing newlines strip करती हैं, |+ और >+ उन्हें सभी keep करती हैं, और unmodified | या > («clip») एक single trailing newline preserve करती है। JSON में convert होने पर, दोनों styles ordinary string values produce करती हैं, folded block केवल preserved blank lines पर embedded \n के साथ एक long string बन जाती है; literal block में हर line break पर \n होता है।

conversion में क्या खो जाता है

YAML वास्तव में कहाँ use होता है

YAML आधुनिक infrastructure में हर जगह है: Kubernetes manifests (पूरा object model YAML convention द्वारा है; --- से separated multi-document files standard हैं), Docker Compose (services, networks, volumes के लिए docker-compose.yml), GitHub Actions (.github/workflows/*.yml: strict YAML 1.2 schema mostly observed लेकिन parser अभी भी on: को एक key के रूप में recognize करता है, एक Norway-Problem near-miss जिसे GitHub explicitly work around करता है), GitLab CI/CD, Ansible playbooks, CircleCI / Travis CI / Drone / Bitbucket Pipelines, Jekyll / Hugo / Eleventy / Gatsby / Astro front matter, OpenAPI / Swagger specs (officially «a JSON object that may be represented either in JSON or YAML»), Prometheus / Grafana / Loki / Tempo monitoring stack configuration, cloud-init (EC2/GCE/Azure VM first-boot provisioning), और AWS CloudFormation / Azure Resource Manager / Google Cloud Deployment Manager। इनमें से अधिकांश के लिए, YAML-to-JSON conversion तब essential है जब आप JSON-only protocols में configuration embed कर रहे हों, jq के साथ files compare कर रहे हों, या output को किसी ऐसे tool को feed कर रहे हों जो JSON expect करता है।

Browser-side conversion server-side से safer क्यों है

default settings के साथ PyYAML का yaml.load() किसी भी untrusted input पर !!python/object tag के माध्यम से arbitrary Python code execute कर सकता था, जो side effects वाले actual Python objects में deserialise होता है, CVE-2017-18342, CVSS v3.1 score 9.8 (Critical), PyYAML 5.1 (मार्च 2019) में unsafe default को deprecate करके और safe_load() को recommended entry point बनाकर fix किया। Java के SnakeYAML का अपना equivalent था (CVE-2022-1471, भी CVSS 9.8) arbitrary instantiation allow करने वाले Constructor class के आसपास। Rust के de-facto serde_yaml crate को मार्च 2024 में deprecate किया गया; ecosystem अभी भी एक successor (serde_yml, serde_yaml_ng, serde_norway) पर settle हो रहा है।

browser में js-yaml v4 के माध्यम से parsing run करना इन सब को sidestep करता है: compromise करने के लिए कोई server नहीं है, js-yaml में tags के माध्यम से arbitrary code execution का कोई concept नहीं है (unknown tags constructed objects के बजाय plain scalars बन जाते हैं), और v4 safer 1.2 schema पर default है। Absolutool tool इससे default रूप से benefit करता है।

अधिक प्रश्न

converter multi-document YAML files को कैसे handle करता है?

यह js-yaml के loadAll से load करता है, जो parsed documents का एक array return करता है, JSON output इसलिए एक JSON array है जिसमें प्रत्येक --- separated document के लिए एक element है। अगर आपके पास केवल single document है, तो आपको एक element वाला JSON array मिलेगा; explicit single-document semantics के लिए अपना input ---/... markers में wrap करें।

क्या मेरा Kubernetes manifest सही convert होगा?

लगभग हमेशा हाँ। Kubernetes mostly YAML 1.2-compatible content use करता है, और js-yaml v4 सभी standard primitives (strings, integers, booleans, nulls, sequences, mappings) plus anchors और aliases handle करता है। जो दो pieces survive नहीं करते वे हैं comments (stripped) और कोई भी anchors जो references के बजाय repeated content तक expand हो जाते हैं।

मेरा country code NO boolean के रूप में क्यों read हो रहा है?

इस converter में ऐसा नहीं होना चाहिए, js-yaml v4 YAML 1.2 / JSON-compatible schema पर default है, जो y/n/yes/no/on/off को booleans के रूप में recognize नहीं करता। अगर आप इसे किसी अन्य tool (PyYAML, उदाहरण के लिए) में hit कर रहे हैं, तो fix यह है कि value को quotes में wrap करें: country: "NO"।

file size limit क्या है?

upload widget पर 5 MB, लेकिन pasted content बड़ा हो सकता है अगर आपके browser में memory हो। bottleneck in-memory representation है, network नहीं, loop में कोई server नहीं है। ~50 MB से बड़ी files के लिए, एक desktop YAML toolchain (command line पर yq, उदाहरण के लिए) consider करें।

संबंधित टूल

JSON फ़ॉर्मैटर

JSON को तुरंत फ़ॉर्मैट, मिनिफाइ और मान्य करें।

XML से JSON

पूर्ण विशेषता समर्थन के साथ XML को JSON में कन्वर्ट करें।

Base64 एन्कोडर

Base64 टेक्स्ट और फाइलों को एन्कोड और डीकोड करें।