Pengonversi YAML ke JSON

Tempel YAML yang valid — manifest Kubernetes, file Compose, playbook Ansible, spesifikasi OpenAPI, atau dokumen YAML 1.2 apa pun — dan konverter akan menghasilkan padanan JSON secara real time.

Konversi berjalan sepenuhnya di peramban Anda menggunakan parser YAML 1.2, lalu menelusuri pohon yang diuraikan dan mengeluarkan JSON melalui JSON.stringify (per ECMA-404 / RFC 8259).

Pilih gaya keluaran Anda:

• 2-spasi (baku, ramah pembaca)
• 4-spasi (beberapa basis kode perusahaan)
• diperkecil (API, payload jaringan)

Keluaran siap ditempel ke file `.json` atau disalurkan ke `kubectl apply -f -` (yang menerima JSON melalui stdin). Panel sebelah kanan menampilkan hitungan byte dan baris secara langsung sehingga Anda dapat memeriksa ukuran sebelum melakukan commit.

Mengubah YAML ke JSON membutuhkan tiga langkah:

• Langkah 1: Tempel YAML Anda ke editor. Parser memvalidasi saat Anda mengetik — YAML yang tidak valid menunjukkan galat penguraian yang tepat beserta baris dan kolomnya.
• Langkah 2: Keluaran JSON muncul secara langsung di panel kanan. Tidak perlu mengklik tombol; setiap ketukan tombol akan mengurai ulang.
• Langkah 3: Klik Salin (papan klip) atau Unduh (file `.json`).

Untuk alur kerja terprogram, logika yang sama diekspos melalui endpoint `/api/calculate` — POST YAML ke endpoint tersebut dan terima JSON di dalam isi respons.

Keamanan bolak-balik: ubah JSON kembali ke YAML dengan Konverter JSON ke YAML yang terkait; model data dipertahankan secara akurat (komentar dan jangkar khusus YAML dan tidak terbawa dalam proses bolak-balik).

YAML dan JSON merepresentasikan model data yang sama — peta (objek), urutan (susunan), dan skalar (string/angka/boolean/null) — tetapi dengan sintaksis permukaan yang sangat berbeda.

YAML digerakkan oleh indentasi: nesting disiratkan oleh indentasi 2 spasi, urutan menggunakan awalan `- `, dan sebagian besar string tidak memerlukan tanda kutip. JSON sarat dengan kurung kurawal dan tanda kutip: setiap kunci menggunakan `"`, setiap peta menggunakan `{}`, setiap susunan menggunakan `[]`, dan setiap pemisah bersifat eksplisit (`:` dan `,`).

YAML mendukung komentar (`#`), jangkar dan alias untuk penggunaan ulang (`&name` / `*name`), aliran multi-dokumen (`---`), dan tag tipe eksplisit (`!!str`, `!!int`) — keunggulan yang menjadikannya pilihan tepat untuk konfigurasi yang dikontrol sumbernya. JSON diuraikan 5–10× lebih cepat, bebas dari ambiguitas, dan merupakan pilihan tepat untuk API dan penyimpanan.

Lakukan konversi pada batasnya: YAML untuk manusia, JSON untuk mesin.

Nesting yang dalam adalah keunggulan dari konversi YAML ke JSON — melacak indentasi secara manual pada 5+ level rentan terhadap galat. Konverter menelusuri pohon YAML yang diuraikan secara rekursif.

• Untuk setiap peta blok, kunci dipancarkan sesuai urutan sumber dengan sintaksis JSON `"key": value`; nilai bersarang mendapatkan kurung kurawal `{...}`.
• Untuk setiap urutan blok, item dipancarkan sebagai susunan JSON `[...]`; objek bersarang di bawah tanda `-` menjadi elemen susunan `{...}`.

Struktur campuran — urutan peta, peta yang berisi urutan peta, secara rekursif — semuanya dikonversi secara benar. Kedalaman maksimum hanya dibatasi oleh tumpukan panggilan peramban Anda (~10.000+ bingkai di peramban modern, jauh melampaui konfigurasi realistis apa pun).

Uji dengan fixture Anda sendiri: uraikan kembali keluaran JSON ke YAML dan pastikan kesamaan struktural dengan masukan.

Inferensi tipe YAML yang longgar adalah sumber dari banyak bug dalam konfigurasi dunia nyata. YAML 1.2 (standar modern, target dari konverter ini) memperketat aturan agar lebih aman.

• Boolean: HANYA `true` dan `false` (tidak sensitif huruf besar-kecil). YAML 1.1 juga memperlakukan `yes`/`no`/`on`/`off` sebagai boolean, yang secara terkenal merusak konfigurasi yang berisi kode negara Norwegia `NO` (secara diam-diam diubah menjadi `false`) — yang disebut 'masalah Norwegia'. Sebagian besar parser modern (js-yaml, PyYAML 6+, Snakeyaml) secara bawaan menggunakan perilaku 1.2.
• Null: `null`, `~`, atau nilai kosong semuanya menjadi JSON null.
• Angka: pola digit yang cocok dengan sintaksis integer/float JSON menjadi angka JSON; selebihnya tetap berupa string.
• String: nilai bertanda kutip akan selalu tetap menjadi string; string numerik seperti kode pos (`"01234"`) dan tanggal kalender memerlukan tanda kutip dalam YAML agar selamat dari konversi — ketika sebuah konfigurasi menyimpan tanggal yang pertama kali Anda hitung dengan kalkulator tanggal, bungkus dalam tanda kutip agar parser menyimpannya secara utuh alih-alih memaksa mengubahnya.

Konverter mematuhi aturan-aturan ini secara ketat.

Kubernetes menerima format YAML dan JSON melalui API server, kubectl, dan pustaka klien. Sebagian besar tim menyimpan YAML dalam kontrol sumber (PR lebih mudah ditinjau) tetapi memberikan JSON ke alat terprogram — pengontrol kustom, alur GitOps, penampil pasca-render Helm, atau webhook.

Tempelkan manifes Anda (Pod, Deployment, Service, ConfigMap, dll.) dan salin hasil JSON-nya. Pengonversi ini mempertahankan hierarki apiVersion, kind, metadata, dan spec dalam urutan kolom — Kubernetes mengharapkan kunci camelCase secara keseluruhan, jadi jika Anda memindahkan kolom dari sumber snake_case, pengonversi huruf besar-kecil memperbaiki penamaannya sebelum Anda menempelkannya.

Validasi dengan `kubectl apply --dry-run=client -f -` (yang menerima JSON pada stdin) sebelum melakukan commit. Untuk manifes multi-sumber yang dipisahkan oleh `---`, pisahkan terlebih dahulu menjadi dokumen individu — JSON tidak memiliki sintaks multi-dokumen.

Tiga kasus penggunaan bervolume tinggi di luar Kubernetes:

• Docker Compose: tempel `docker-compose.yaml` dan salin JSON untuk alat seperti Kompose (memigrasikan Compose ke K8s), orkestrator kustom, atau transformasi konfigurasi terprogram.
• Ansible: konversi buku panduan (playbooks) ke JSON untuk alat dokumentasi, integrasi CI kustom, atau API REST/GraphQL yang menyimpan definisi buku panduan.
• Alur CI/CD: GitHub Actions (`.github/workflows/*.yml`), GitLab CI (`.gitlab-ci.yml`), CircleCI, Travis — konversi salah satu dari ini ke JSON untuk analitik, pengeditan terprogram, atau pengarsipan log audit. Pemicu `cron` terjadwal mereka disematkan ke UTC, sehingga pengonversi zona waktu mencegah Anda salah membaca kapan sebuah alur benar-benar berjalan dalam waktu lokal Anda.

Catatan: Ekspresi Jinja2 (`{{ var }}`), sintaks templat Helm (`{{ .Values.x }}`), dan pemformatan serupa tetap berupa string biasa di JSON — ekspresi tersebut tidak dievaluasi oleh pengonversi.

Spesifikasi OpenAPI 3.x umumnya ditulis dalam YAML (lebih mudah dibaca untuk hierarki jalur/parameter) tetapi dikonsumsi sebagai JSON oleh alat yang lebih lama — build UI Swagger lama, gateway API perusahaan tertentu, dan beberapa pembuat kode.

Tempelkan `openapi.yaml` (atau `swagger.yaml`) Anda dan unduh `openapi.json`. Pengonversi ini mempertahankan penunjuk `$ref` secara persis (tanpa resolusi), definisi skema, contoh respons, dan skema keamanan.

Setelah konversi, validasi dengan validator OpenAPI resmi (Spectral CLI, openapi-cli, swagger-cli) untuk mengonfirmasi kepatuhan skema. Banyak tim menyimpan YAML dalam kontrol sumber dan menghasilkan JSON pada waktu pembuatan — baik `swagger.yaml` maupun `swagger.json` sepenuhnya setara untuk konsumen API.

Enam kesalahan menyumbang 95% dari kegagalan penguraian YAML:

• Tab di mana saja dalam indentasi — YAML melarang tab sepenuhnya, bahkan satu karakter tab saja akan merusak penguraian.
• Indentasi tidak konsisten — kunci tingkat yang sama harus sejajar pada kolom yang persis sama.
• Spasi hilang setelah `:` pada peta — `key:value` tidak valid; `key: value` sudah benar.
• Spasi hilang setelah `-` pada urutan — `-item` adalah string yang dimulai dengan tanda hubung; `- item` adalah entri urutan.
• Karakter khusus tanpa tanda kutip di awal nilai — `@`, `` ` ``, `%`, `*`, `&` memerlukan tanda kutip.
• Fitur yang tidak didukung dalam pengonversi: jangkar (`&name`), alias (`*name`), dan aliran multi-dokumen (`---`) — untuk ini, gunakan pustaka YAML lengkap seperti js-yaml, PyYAML, atau `yq`.

Pesan kesalahan menunjukkan baris dan kolom tempat penguraian gagal.

Tiga fitur YAML tidak memiliki padanan langsung di JSON dan memerlukan penanganan khusus:

• Jangkar (`&name`) dan alias (`*name`) memungkinkan YAML mereferensikan sebuah node dan menggunakannya kembali di tempat lain — umum dalam file Compose untuk templat layanan bersama dan CloudFormation untuk parameter bersama. JSON tidak memiliki sintaks referensi, sehingga pengonversi memperluas alias secara inline (setiap alias menjadi salinan lengkap). Data dipertahankan tetapi ukuran JSON menjadi lebih besar dan struktur referensi bersama menjadi hilang.
• Aliran multi-dokumen (pemisah `---`) mewakili beberapa nilai tingkat atas dalam satu file — umum untuk menggabungkan sumber daya Kubernetes. JSON hanya memiliki nilai akar tunggal per dokumen. Pisahkan YAML menjadi file terpisah terlebih dahulu atau bungkus dokumen dalam array JSON `[doc1, doc2, doc3]`.
• Komentar (`#`) khusus untuk YAML — komentar dihapus sepenuhnya selama konversi. Pertahankan YAML sebagai sumber kebenaran jika komentar penting.

Lima pertimbangan pulang-pergi yang harus diketahui setiap pengembang:

• Model data: YAML → JSON → YAML mempertahankan kunci, nilai, jenis data, dan penyarangan secara persis. Datanya identik saat masuk dan keluar kembali.
• Komentar: hilang selamanya — JSON tidak memiliki sintaks komentar. Pertahankan YAML sebagai sumber kebenaran jika Anda memiliki dokumentasi inline.
• Jangkar/alias: diperluas saat menuju JSON, tidak pernah dibuat ulang saat kembali. YAML keluaran memiliki konten duplikat di tempat sumber memiliki referensi bersama.
• Urutan kunci: YAML mempertahankan urutan sumber; pengonversi mempertahankannya hingga JSON; pulang-pergi kembali ke YAML mempertahankan urutan yang sama.
• Tag tipe (`!!str`, `!!int`) — hanya dikeluarkan saat diperlukan untuk penghilangan ambiguitas. String `"01234"` bertahan dalam pulang-pergi karena JSON menjaganya tetap bertanda kutip; YAML tanpa tanda kutip `01234` diurai sebagai bilangan bulat dan melakukan pulang-pergi sebagai angka 1234, sehingga menghilangkan angka nol di depan.

Beri tanda kutip pada nilai yang ambigu sebagai perlindungan.

Pemetaan tipe sekilas:

• Peta YAML → Objek JSON
• Urutan YAML → Array JSON
• Skalar YAML (per inferensi tipe) → String/angka/boolean/null JSON
• Tag YAML !!str → String JSON (dipaksa)
• YAML null/~/kosong → JSON null
• YAML true/false → Boolean JSON
• Pola bilangan bulat YAML → Bilangan bulat JSON
• Pola float YAML → Angka JSON

Perbandingan alat:

• pengonversi ini (peramban, instan, tanpa instalasi, 95% dari YAML asli)
• `yq -o json` (CLI, file besar, kueri JSONPath)
• `js-yaml`/`PyYAML` (pustaka lengkap, jangkar dan multi-dokumen didukung, penggunaan terprogram)

Praktik terbaik:

• Selalu beri tanda kutip pada nilai yang ambigu (yes/no/on/off/null/ID numerik) dalam sumber YAML.
• Gunakan indentasi 2 spasi (standar de facto).
• Validasi keluaran JSON terhadap skema konsumen hilir Anda (Skema JSON, OpenAPI, K8s OpenAPI) — kesalahan tipe muncul di sini.
• Pertahankan YAML sebagai sumber kanonis dan buat ulang JSON pada waktu pembuatan jika memungkinkan.