JSON ↔ YAML Converter — Mag-convert sa pagitan ng JSON at YAML Online _

Ano ang JSON ↔ YAML conversion?

JSON (JavaScript Object Notation, RFC 8259) ay isang mahigpit, brace-delimited na text format para sa structured data; YAML (YAML Ain't Markup Language, version 1.2) ay isang superset ng JSON na gumagamit ng indentation, line break, at human-readable syntax para sa parehong value model. Ang pag-convert sa pagitan ng mga ito ay nagpapahintulot sa iyo na palitan ang parehong configuration sa pagitan ng machine-friendly form (JSON para sa mga API, schema validation, programmatic transform) at human-friendly form (YAML para sa code review, Kubernetes manifest, GitHub Actions workflow) nang hindi muling nagta-type ng kahit isang key.

Paano gumagana ang JSON ↔ YAML conversion?

Ang bawat conversion ay tumatakbo nang lokal sa iyong browser gamit ang bundled na js-yaml library (MIT, version 4.1.0). Ang mga pangunahing hakbang ay:

1. Ang mode selector (Auto-detect / JSON → YAML / YAML → JSON) ang nagpapasya kung aling pipeline ang tatakbo. Sa Auto-detect mode, ang unang non-whitespace na character ng input ang pumipili ng direksyon — ang { o [ ay nangangahulugang JSON; ang iba ay nangangahulugang YAML.
2. JSON → YAML: ang JSON.parse ay nagva-validate ng input at gumagawa ng JavaScript value; ang jsyaml.dump(value, { indent, lineWidth: -1, sortKeys: false }) ay nagsusulat ng YAML 1.2 form. Kapag naka-on ang Multi-document, ang input array ay ini-dump nang isang element bawat dokumento at sinasama ng --- separator.
3. YAML → JSON: ang jsyaml.loadAll ay nag-a-parse ng bawat dokumento sa input (awtomatikong hinahawakan ang --- separator) sa isang array; ang mga single-document input ay ina-unwrap para ang JSON output ay ang dokumento mismo, hindi isang one-element array.
4. Ang Indent (2 o 4 spaces) at Pretty-print ay configurable. Kapag naka-off ang Pretty-print, mag-eemit ng minified JSON via JSON.stringify(value) nang walang whitespace.
5. Ang output ay isinusulat sa read-only textarea. Sa mga YAML parse failure, kasama sa error message ang 1-indexed na linya at column na iniulat ng e.mark ng js-yaml para makatuon ka agad sa bug.

Bakit gamitin ang tool na ito para mag-convert ng JSON at YAML?

• Privacy: ang bawat parse, transform, at emit pass ay nangyayari sa iyong browser. Ang data — kasama na ang mga Kubernetes secret, signed JWT, at proprietary config — ay hindi kailanman umaabot sa aming mga server.
• Multi-document YAML: kinikilala ng jsyaml.loadAll ang mga --- separator at nagbabalik ng array ng mga dokumento, na ina-unwrap ng converter para sa single-doc na kaso o pinapanatili bilang JSON array para sa multi-doc na kaso.
• Nare-resolve na ang mga anchor at alias: ang mekanismo ng &anchor / *alias ng YAML ay hinahawakan ng default schema ng js-yaml. Ang isang value na tinukoy nang isang beses at nire-reference nang dalawang beses ay nag-ro-round-trip sa isang JSON object kung saan ang lahat ng reference ay may pantay na value.
• Walang CDN, walang telemetry: ang js-yaml.min.js library ay ipinapadala mula sa parehong origin ng page, kaya gumagana ang tool offline, sa likod ng corporate proxy, at sa loob ng mga air-gapped environment.

Ano ang mga karaniwang gamit ng JSON ↔ YAML conversion?

Ang pagpapalit sa pagitan ng JSON at YAML ay lumalabas sa DevOps, platform engineering, at API tooling:

• Kubernetes manifest: pag-convert ng YAML Deployment, ConfigMap, o HelmRelease sa JSON para ang isang in-house policy validator (Joi, Ajv, OPA Rego) ay makakapaglint nito nang programmatically, tapos pabalik sa YAML para sa cluster apply.
• CI/CD workflow: pag-round-trip ng GitHub Actions workflow.yml sa pamamagitan ng JSON para ang isang code-generator ay makakapagsulat muli ng matrix o job dependency, tapos pag-emit ng cleaned-up na YAML para sa PR.
• OpenAPI spec: pag-paste ng JSON openapi.json mula sa auto-generated docs ng backend at pag-convert sa openapi.yaml para sa human-edited reference na naka-check in sa repo.

Ano ang hitsura ng JSON ↔ YAML round-trip na halimbawa?

Ang pag-paste ng {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"web"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"web"}}}} at pagpindot ng CONVERT sa JSON → YAML mode ay gumagawa ng walong linya ng indented YAML na may apiVersion: apps/v1 sa unang linya. Ang pagpapakain ng YAML na iyon pabalik sa YAML → JSON mode na may Pretty-print on ay nagbabalik ng orihinal na object byte-for-byte pagkatapos ng stable na JSON.stringify(value, null, 2), na may napanatiling key order dahil ang default schema ng js-yaml ay sumusunod sa insertion order sa parehong direksyon.

Tumatakbo ba nang buo ang JSON ↔ YAML converter na ito sa aking browser?

Oo. Ang bawat parse, transform, at emit pass ay tumatakbo nang lokal bilang JavaScript sa loob ng iyong browser tab. Ang bundled na js-yaml library ay ipinapadala mula sa parehong origin ng page — walang CDN, walang fetch, walang XMLHttpRequest, walang navigator.sendBeacon sa input. Gumagana rin ang tool offline kapag na-load na ang page, dahil ito ay isang static HTML/CSS/JS bundle na may vendor library na nakakopya sa tabi nito. Ang mga Kubernetes secret, JWT payload, signed CloudFormation YAML, at proprietary config ay nananatili sa iyong device.

Paano hinahawakan ng converter ang multi-document YAML?

Sinusuportahan ng YAML ang maraming dokumento sa isang stream na pinaghihiwalay ng mga linya na naglalaman lang ng ---. Sa YAML → JSON, ang converter ay tumatawag ng jsyaml.loadAll, na nagbabalik ng bawat dokumento bilang JavaScript value. Kung eksakto isang dokumento lang ang nahanap, ang JSON output ay ang dokumentong iyon nang direkta; kung dalawa o higit pa ang nahanap, ang JSON output ay isang array. Sa JSON → YAML, kapag ang input ay isang JSON array AT naka-on ang Multi-document toggle, ang bawat array element ay ini-emit bilang sariling dokumento na may --- separator sa pagitan — kapaki-pakinabang para sa pagbuo ng kubectl apply-friendly bundle mula sa JSON array ng mga resource.

Sinusuportahan ba ang mga YAML anchor at alias?

Oo — ang mga &anchor definition at *alias reference ay nireresolba ng default schema ng js-yaml sa panahon ng load step. Ang YAML input na tulad ng defaults: &d\n retries: 3\n timeout: 30\njob_a:\n <<: *d\njob_b:\n <<: *d ay nag-a-parse sa JSON object kung saan ang parehong job_a at job_b ay naglalaman ng retries: 3, timeout: 30. Sinusuportahan din ang merge key na << (isang YAML 1.1 extension na kinikilala pa rin ng js-yaml) sa default schema.

Napapanatili ba ang mga YAML comment kapag na-convert sa JSON at pabalik?

Hindi — ang js-yaml ay nag-aalis ng mga comment sa panahon ng parse step, kaya ang isang YAML → JSON → YAML round-trip ay mawawala ang bawat #-prefixed na linya. Ito ay isang kilalang limitasyon ng load/dump model; kung mahalaga ang pagpapanatili ng comment, gumamit ng isang comment-aware library tulad ng yaml npm package (na nagpapadala ng CST + AST API na dinisenyo para mapanatili ang trivia) kaysa sa js-yaml. Para sa karamihang config-conversion workflow, ang trade-off ay katanggap-tanggap: pinapanatili ng round-tripped YAML ang bawat key, value, anchor, at alias — kung wala lang ang mga author-sulat na comment.

Ano ang nangyayari sa mga custom YAML tag?

Gumagamit ang converter ng DEFAULT_SCHEMA ng js-yaml, na nauunawaan ang !!str, !!int, !!float, !!bool, !!null, !!seq, !!map, !!binary, at !!timestamp — bawat tag sa YAML 1.2 core at JSON schema. Ang mga custom o application-specific tag (hal. !Ref sa CloudFormation, !vault sa Ansible) ay hindi kinikilala at lumalabas bilang malinaw na error na binabanggit ang hindi sinusuportahang tag. Para sa CloudFormation lalo na, gamitin ang daloy ng aws cloudformation package + --output-template-file para palawakin ang mga custom tag bago i-paste sa converter na ito.

Ang JSON ↔ YAML converter na ito ay may kasamang js-yaml@4.1.0 na naka-bundle sa parehong origin, sinusuportahan ang multi-document stream at anchors/aliases nang out of the box, at nag-uulat ng mga YAML parse error na may linya at column para maayos mo ang source. Walang upload, walang CDN, walang telemetry — ang bawat byte ay nananatili sa iyong browser.