YAML फॉर्मेटर

YAML को फ़ॉर्मेट और सत्यापित करने के लिए पेस्ट करें। त्रुटियाँ तुरंत देखें, इंडेंटेशन ठीक करें और JSON में कनवर्ट करें।

स्थानीय रूप से प्रसंस्कृत · कुछ भी सर्वर पर नहीं भेजा जाता
सत्यापित करने के लिए YAML पेस्ट करें

YAML क्या है?

YAML (YAML Ain't Markup Language) एक मानव-पठनीय डेटा सीरियलाइज़ेशन प्रारूप है, जिसका उपयोग कॉन्फ़िगरेशन फ़ाइलों के लिए होता है।

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

सत्यापक कौन सी त्रुटियों का पता लगाता है?

इंडेंटेशन त्रुटियाँ, लापता कोलन, डुप्लिकेट कुंजियाँ, अमान्य वर्ण, अनबंद स्ट्रिंग्स, ग़लत नेस्टिंग और अन्य समस्याएँ।

क्या मैं YAML को JSON में रूपांतरित कर सकता हूँ?

हाँ! अपने YAML को अच्छी तरह फ़ॉर्मेट किए गए JSON में रूपांतरित करने के लिए "→ JSON" बटन पर क्लिक करें। उल्टे रूपांतरण के लिए, हमारे JSON से YAML टूल का उपयोग करें।

YAML का एक Quick Tour

YAML 1.0 2001 में Clark Evans, Ingy döt Net, और Oren Ben-Kiki द्वारा publish किया गया था; YAML 1.1 2005 में follow हुआ, और current version YAML 1.2.2 है, जिसने कई historical gotchas fix किए (notably «Norway problem», नीचे देखें) और JSON के strict superset बनने के लिए designed किया गया था। Official spec yaml.org/spec/1.2.2 पर है। यह formatter open-source js-yaml library use करता है, जो default रूप से YAML 1.2 schema के against parse करती है, इसलिए अधिकांश legacy 1.1 quirks यहां format किए गए text पर apply नहीं होते, लेकिन वे अधिकांश server-side YAML tooling पर apply होते हैं जहां आप output भेजेंगे।

YAML वास्तव में कहां Use होती है

YAML cloud-native infrastructure के लिए configuration format के रूप में जीत चुकी है। जिन जगहों पर आप इसे सबसे ज़्यादा मिलेंगे:

Whitespace Trap (केवल Spaces)

YAML structure denote करने के लिए indentation use करती है, और spec explicit है कि tabs indentation के लिए allowed नहीं हैं। केवल spaces। यह handwritten YAML में bugs का सबसे common source है, especially इसलिए क्योंकि कई editors उनकी settings के आधार पर silently tabs और spaces mix करते हैं। Strict parser से जो error message आएगा वह कुछ इस तरह होगा «found character '\t' that cannot start any token», translation: «you used a tab somewhere.» Fix universal है: अपने editor में «show whitespace» enable करें और हर tab को दो या चार spaces में convert करें।

Indent size convention है, spec नहीं। 2 spaces Kubernetes manifests, GitHub Actions, और modern web पर जो अधिकांश YAML आप पढ़ेंगे उसका de facto standard है। 4 spaces Ansible में अधिक common है। जो rule matter करती है: एक single file के अंदर consistent रहें। Sibling keys के बीच 2 और 4 spaces mix करना parsers को trip करता है, न कि आप कौन सा size choose करते हैं।

Norway Problem (और Ambiguous Strings को Quote क्यों करें)

YAML 1.1 (अभी भी PyYAML, snakeyaml, और कई अन्य server-side parsers में default) unquoted boolean spellings की एक long list को actual booleans के रूप में interpret करती है: true, True, TRUE, false, False, FALSE, yes, Yes, YES, no, No, NO, y, n, on, off। Famous trap: Norway का ISO country code NO है। एक YAML config जो countries को unquoted strings के रूप में list करती है silently Norway को boolean false के रूप में parse करती है, और downstream code जो countries[0] == 'NO' read करता है confusingly fail होता है।

YAML 1.2 (और js-yaml का default schema) booleans को केवल true / false तक restrict करता है, जो parser level पर Norway problem fix करता है। लेकिन कई real-world tools backward compatibility के लिए YAML 1.1 schema को default रखते हैं। Defensive habit: किसी भी string को quote करें जो boolean, number, date, या version जैसी लग सकती है। country: "NO", postal_code: "01234", version: "1.10", time: "10:30"। Quotes universal disambiguator हैं।

अन्य Type-Coercion Gotchas

Block Style बनाम Flow Style

YAML same data के लिए दो notations support करती है:

# Block style (the standard, indentation-based)
person:
  name: Alice
  tags:
    - admin
    - billing

# Flow style (JSON-like inline)
person: { name: Alice, tags: [admin, billing] }

Block style वह है जो आप 99% hand-written YAML में देखेंगे, यही format को readable बनाती है। Flow style short single-line values के लिए या programmatically YAML generate करते समय एक useful escape hatch है जहां आप indentation track नहीं करना चाहते। Formatter input में जो style use हुई उसकी परवाह किए बिना output के लिए block style में normalise करता है (more readable form)।

Anchors और Aliases (DRY Trick)

YAML की reusability feature: &name anchor के साथ एक बार value define करें, *name alias के साथ elsewhere reference करें। Long config files के लिए convenient जहां same block of values multiple times appear होता है।

defaults: &defaults
  region: us-east-1
  log_level: info

production:
  <<: *defaults
  log_level: warn   # override

staging:
  <<: *defaults

कुछ caveats: हर YAML processor anchors और aliases support नहीं करता (notably कुछ older Kubernetes manifest tools और certain Helm contexts)। <<: «merge key» syntax ऊपर दिखाया गया YAML 1.1 extension है और 1.2 में officially deprecated है, js-yaml इसे support करता है, लेकिन pure 1.2 parsers नहीं कर सकते।

बहु-दस्तावेज़ फ़ाइलें

एक single YAML file में multiple documents हो सकते हैं, --- से separated। Kubernetes में common, एक file में एक Deployment, एक Service, और एक ConfigMap, --- से separated, एक kubectl apply -f के साथ apply किया गया:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc

YAML बनाम JSON बनाम TOML

यदि आपके पास new config के लिए choice है: flat configuration के लिए TOML, YAML यदि आपको deep nesting चाहिए और ecosystem ने इस पर standardise किया हो (Kubernetes, Ansible), JSON यदि machine इसे लिखती हो। YAML सही format है जब humans को deeply nested config read करना हो और meaningful comments inline लिखने हों।

Privacy

YAML configs में frequently secrets होते हैं जो किसी और के server से नहीं जाने चाहिए: Kubernetes Secret base64 blobs, application.yml में database passwords, CI workflows में API keys, deployment configs में internal hostnames। Formatter पूरी तरह आपके browser में open-source js-yaml library के माध्यम से run होता है, pasted content locally parse और re-emit होती है, बिना किसी fetch / upload / logging के। Tab बंद करने से सब कुछ wipe हो जाता है।

सामान्य गलतियाँ

  1. Indentation में tabs और spaces mix करना। सबसे common error। Tabs spec द्वारा forbidden हैं; कुछ editors उन्हें silently insert करते हैं। अपने editor में whitespace show करें।
  2. Siblings के बीच inconsistent indentation। Sibling keys को same column पर aligned होना चाहिए। Mixed 2/4-space indentation parse break करती है।
  3. Unquoted values जो booleans, numbers, dates, या times जैसी लगती हैं। NO, 012, 1.10, 10:30, yes: उन्हें quote करें।
  4. Colon के बाद missing space। key: value काम करता है; key:value invalid है (एक single string के रूप में parse)।
  5. Trailing whitespace। कुछ parsers trailing spaces को significant treat करते हैं; कुछ नहीं। Cross-tool-safe habit trailing whitespace strip करना है।
  6. सही block scalar के बिना multi-line strings। Long strings को | (literal, newlines preserve करता है) या > (folded, lines join करता है) चाहिए। Plain unquoted multi-line text rarely उस तरह behave करती है जैसी आप expect करते हैं।
  7. Anchors / aliases everywhere assume करना। Helm और कुछ Kubernetes contexts &/* को fully support नहीं करते। अपने real pipeline में depend करने से पहले test करें।
  8. Encoding mismatches। YAML files UTF-8 होनी चाहिए। BOM के साथ UTF-16 के रूप में save करने वाला एक Windows editor ऐसी files produce करता है जिन्हें कुछ parsers read नहीं कर सकते।

अधिक Frequently Asked Questions

क्या formatter मेरे comments preserve करेगा?

नहीं। js-yaml library YAML को एक JavaScript value में parse करती है और उस value से re-emit करती है, जिसका मतलब है comments (# like this) drop हो जाते हैं, वे source text में live करते हैं, parsed structure में नहीं। यदि comments preserve करना matter करता है (यह hand-curated config files के लिए usually करता है), तो eemeli/yaml जैसा comment-preserving alternative use करें इसके CST API के माध्यम से, या इस formatter से round-trip करने के बजाय hand से small edits करें।

मेरा NO मेरे server के YAML parser द्वारा boolean के रूप में क्यों treat किया जाता है?

क्योंकि वह parser YAML 1.1 use कर रहा है (PyYAML, snakeyaml, और कई अन्य के लिए default), जो NO को boolean false के रूप में interpret करता है। यह formatter default रूप से YAML 1.2 use करता है (js-yaml के माध्यम से) इसलिए यहां bug trigger नहीं होता, लेकिन जैसे ही आप file को YAML 1.1 environment में ship करते हैं trap activate हो जाता है। हमेशा ambiguous strings quote करें: country: "NO"

क्या मैं YAML को JSON में convert कर सकता हूं?

हां, «→ JSON» click करें। Conversion उन सभी चीज़ों के लिए lossless है जो JSON में represent हो सकती हैं (strings, numbers, booleans, null, arrays, objects)। जो survive नहीं करते: comments (JSON में उनके लिए कोई syntax नहीं), anchors और aliases (JSON में कोई equivalent नहीं), और YAML के date / time-stamp types (जो JSON में strings बनते हैं)। Reverse direction के लिए, dedicated JSON to YAML tool use करें।

क्या कुछ server पर भेजा जाता है?

नहीं। सभी parsing, formatting, और JSON conversion आपके browser में js-yaml के माध्यम से run होती हैं। Pasted YAML कभी किसी server पर transmit नहीं होती। यह important है क्योंकि YAML configs में frequently secrets होते हैं (Kubernetes Secret values, database passwords, API keys, internal endpoints) जिन्हें third-party service पर upload नहीं किया जाना चाहिए।

Size limit क्या है?

कोई hard limit नहीं, formatter आपके browser की memory में run होता है। Typical Kubernetes manifests (कुछ KB) और Helm charts (tens of KB) instantly format होते हैं। बहुत large multi-document files (multiple MB) slow हो सकती हैं लेकिन generally काम करती हैं; यदि आपके पास 10-MB Helm chart है, तो इसके बजाय CLI tool से locally format करें।

YAML इतनी error-prone क्यों है?

तीन reasons जो compound होते हैं: (1) significant whitespace का मतलब है typos silent semantic changes cause करते हैं; (2) YAML 1.1 का permissive type coercion ambiguous strings को unintended booleans / numbers में turn करता है; (3) format में same चीज़ लिखने के बहुत तरीके हैं (block vs flow, single vs double quotes, multi-line strings के तीन flavours। Defensive habits) हमेशा quote करें, indentation के साथ हमेशा consistent रहें, deploy करने से पहले validate करें, जो ज़्यादातर surface area fix करते हैं।

संबंधित टूल