TOML vs JSON vs YAML: Format Konfigurasi Mana yang Dipilih?

Berikut versi singkat dari TOML vs JSON vs YAML: JSON adalah pilihan bawaan untuk pertukaran antar-mesin yang bisa diurai (parse) oleh setiap bahasa, YAML adalah format ramah-manusia yang menjalankan Kubernetes dan pipeline CI, sementara TOML adalah format eksplisit dan bertipe yang dibangun untuk konfigurasi alat dan aplikasi seperti Cargo.toml dan pyproject.toml. Tidak ada satu format pun yang unggul di segala situasi. Format file konfigurasi yang tepat bergantung pada tiga hal: siapa yang menyuntingnya, apakah Anda butuh komentar, dan seberapa ketat tipe datanya harus dipatuhi.

Aturan praktis singkatnya begini. Jika mesin yang menulis dan mesin yang membaca, pilihlah JSON. Jika seseorang menyunting secara manual infrastruktur yang sangat bersarang (nested) setiap hari, kompleksitas YAML sepadan dengan usahanya. Jika Anda menginginkan konfigurasi bertipe yang jelas dan sulit disalahtulis, TOML adalah pilihan paling aman. Ketiga format ini sebenarnya bukan pesaing; mereka menempati jalur yang berbeda: JSON untuk mesin, YAML untuk DevOps, TOML untuk konfigurasi tooling. Sisa panduan ini mendukung pernyataan itu dengan contoh berdampingan, perbedaan yang benar-benar memicu bug, dan matriks keputusan yang bisa Anda terapkan pada proyek berikutnya.

Jawaban 30 Detik

Jika Anda hanya punya waktu setengah menit, tabel inilah perbandingan format file konfigurasi (config file format comparison) yang Anda cari.

	JSON	YAML	TOML
Komentar	Tidak	Ya (#)	Ya (#)
Tipe data	Eksplisit, minimal	Implisit (disimpulkan dari bentuk)	Eksplisit, kaya
Tanggal native	Tidak	Bergantung versi	Ya (empat tipe)
Gaya penyusunan bersarang	Kurung kurawal {}	Indentasi	Header [section]
Sensitif terhadap indentasi	Tidak	Ya (tab dilarang)	Tidak
String multi-baris	Tidak (hanya \n)	Ya (| dan >)	Ya (""")
Koma di akhir (trailing comma)	Dilarang	Tidak berlaku	Diizinkan pada array
Superset dari JSON	—	Ya (1.2)	Tidak
Paling cocok untuk	API, pertukaran data	K8s, CI, Ansible	Konfigurasi tooling Rust/Python

Tiga vonis satu baris menyusul dari tabel itu:

• Pilih JSON ketika file dihasilkan dan dikonsumsi oleh program: payload API, package.json, tsconfig.json, apa pun yang melintasi batas sistem.
• Pilih YAML ketika manusia menyunting secara manual konfigurasi yang dalam dan bersarang, dan ekosistemnya memang sudah mengharapkannya: manifest Kubernetes, GitHub Actions, Docker Compose, playbook Ansible.
• Pilih TOML ketika Anda menginginkan konfigurasi yang jelas dan bertipe untuk sebuah alat atau aplikasi, kebanyakan datar dengan beberapa bagian, disunting oleh kontributor dengan tingkat keahlian yang beragam: Cargo.toml, pyproject.toml, Hugo, Netlify.

Alasan di balik vonis-vonis itu penting dipahami, karena justru di situlah bug yang sesungguhnya bersembunyi.

Konfigurasi yang Sama, Tiga Cara

Tidak ada yang menjelaskan perbedaannya lebih cepat daripada satu konfigurasi yang ditulis tiga kali. Berikut konfigurasi layanan kecil: nama dan versi, beberapa flag tingkat atas, daftar fitur, dan satu blok basis data bersarang.

JSON:

{
  "name": "acme-api",
  "version": "2.4.0",
  "debug": false,
  "released": "2026-07-02",
  "features": ["auth", "metrics", "tracing"],
  "database": {
    "host": "db.internal",
    "port": 5432,
    "max_connections": 100
  }
}

YAML:

name: acme-api
version: "2.4.0"
debug: false
released: "2026-07-02"
features:
  - auth
  - metrics
  - tracing
database:
  host: db.internal
  port: 5432
  max_connections: 100

TOML:

name = "acme-api"
version = "2.4.0"
debug = false
released = "2026-07-02"
features = ["auth", "metrics", "tracing"]

[database]
host = "db.internal"
port = 5432
max_connections = 100

Ketiganya menggambarkan data yang identik; yang berbeda adalah seberapa banyak tanda baca yang harus dibaca mata Anda. JSON membawa tanda baca paling banyak: setiap key diapit tanda kutip ganda, setiap level menambah kurung kurawal, dan satu koma di akhir yang tercecer saja sudah menjadi kesalahan sintaks. YAML membuang hampir semua itu, sehingga strukturnya berasal dari indentasi saja, yang terbaca indah sampai sebuah tab menyelinap masuk. TOML berada di antaranya: tanda kutip hanya pada string, pasangan key = value, dan sebuah header [database] yang menamai blok bersarang seperti yang dilakukan file INI zaman dulu. Field released adalah string ber-tanda-kutip pada ketiganya, jadi datanya tetap identik di sini. Itu disengaja: tanggal justru merupakan titik di mana format-format ini berhenti sepakat, dan itu hal berikutnya yang layak dipahami.

JSON — Pilihan Bawaan untuk Pertukaran Antar-Mesin

JSON adalah format yang Anda pilih tanpa berpikir panjang, dan biasanya insting itu benar. Setiap bahasa arus utama menyertakan parser, setiap API HTTP menuturkannya, dan tata bahasanya cukup kecil untuk dipegang di kepala. JSON ketat dan tak ambigu: sebuah string adalah string, 5432 adalah angka, true adalah boolean, dan hanya ada satu cara untuk menulis masing-masing. Keketatan itulah yang membuat JSON aman dikirim antar-sistem yang belum pernah “bertemu”. Ketika sebuah layanan Node mengirim JSON ke layanan Go, keduanya sepakat soal maknanya bita demi bita.

Kekakuan yang sama itulah mengapa JSON mendominasi wilayahnya sendiri. package.json, tsconfig.json, dan composer.json berformat JSON karena alat-alat menghasilkan dan menulis ulang mereka terus-menerus, dan konfigurasi yang ditulis mesin memang menginginkan format yang ketat secara mesin. Untuk payload API dan antrean pesan (message queue), tidak ada alasan sama sekali untuk memilih yang lain.

Semua kelemahan JSON muncul begitu seorang manusia harus menyuntingnya secara manual. Tidak ada komentar. Tidak ada koma di akhir, sehingga menyusun ulang sebuah daftar berarti membetulkan koma. Tidak ada string multi-baris, hanya escape \n. Setiap key butuh tanda kutip ganda. Dan tidak ada tipe tanggal, sehingga 2026-07-02 harus hidup sebagai string ber-tanda-kutip dan diurai berdasarkan konvensi. Untuk file konfigurasi yang dirawat seseorang, celah-celah itu menumpuk menjadi hambatan.

Masalah “JSON tidak punya komentar”

Fitur JSON yang paling banyak diminta justru yang sengaja ditinggalkan Douglas Crockford: komentar. Alasannya, komentar mengundang orang untuk menyelundupkan direktif parsing ke dalam file konfigurasi, sehingga merusak interoperabilitas. Apa pun pendapat Anda soal keputusan itu, Anda tidak bisa memberi anotasi pada konfigurasi JSON polos, yang menyakitkan untuk apa pun yang dirawat manusia. Solusi praktisnya adalah sebuah superset. JSON5 menambahkan komentar, koma di akhir, key tanpa tanda kutip, dan tanda kutip tunggal; JSONC (JSON with Comments) adalah varian yang lebih ringan yang dipakai VS Code untuk pengaturannya. Keduanya mempertahankan bentuk JSON sambil membuatnya bisa disunting. Jika Anda butuh komentar tapi ingin tetap dalam keluarga JSON, baca panduan pemformatan JSON5 dan JSONC kami untuk kapan memakai masing-masing dan bagaimana menjaga tooling tetap senang.

YAML — Standar DevOps yang Ramah Manusia

YAML dioptimalkan untuk manusia di depan keyboard. Ia mendukung komentar, tata letak berbasis indentasinya menjaga struktur yang sangat bersarang tetap rapi, dan anchor memungkinkan Anda mendefinisikan sebuah blok sekali lalu memakainya ulang dengan sebuah alias alih-alih menyalin-tempel:

defaults: &defaults
  timeout: 30
  retries: 3

staging:
  <<: *defaults
  host: staging.internal

production:
  <<: *defaults
  host: prod.internal

Anchor &defaults menamai sebuah blok, dan <<: *defaults menggabungkannya ke dalam kedua environment, sehingga perubahan pada timeout bersama itu terjadi di satu tempat. Baik JSON maupun TOML tidak punya yang seperti itu. Keterbacaan itulah mengapa YAML menjadi lingua franca operasi: manifest Kubernetes, workflow GitHub Actions, file Docker Compose, dan playbook Ansible semuanya YAML. Ketika konfigurasi Anda dalam lima level dan seorang manusia mengubahnya setiap hari, minimnya tanda baca pada YAML adalah kelegaan yang nyata.

Ongkosnya adalah kompleksitas dan kejutan. Spesifikasi YAML 1.2 itu besar, dan kepatuhan penuh jarang terjadi, sehingga parser yang berbeda berselisih di tepi-tepinya. Indentasi bermakna, tab dilarang mentah-mentah, dan sebuah spasi yang salah sejajar bisa mengubah makna atau gagal diurai. Sisi paling tajam adalah pengetikan implisit (implicit typing): YAML menebak tipe sebuah skalar tanpa tanda kutip dari bentuknya, dan ia salah menebak cukup sering hingga punya julukan sendiri.

Masalah Norwegia dalam satu paragraf

Tulis country: NO di YAML dan banyak parser akan memberi Anda boolean false, bukan string "NO", karena YAML 1.1 — yang masih diikuti sebagian besar tooling Kubernetes — memperlakukan NO, YES, ON, OFF, Y, dan N sebagai boolean. Kode negara Norwegia berubah menjadi false, secara diam-diam, tanpa kesalahan apa pun. Pengetikan implisit yang sama mengubah 0755 menjadi angka oktal dan 1.20 menjadi 1.2. Solusinya membosankan tapi andal: beri tanda kutip pada string yang bisa disalahartikan sebagai sesuatu yang lain. Jebakan ini cukup terkenal hingga pantas mendapat ulasan mendalamnya sendiri, termasuk gangguan (outage) nyata dan sejarah YAML 1.1-lawan-1.2, dalam panduan masalah Norwegia YAML kami. Untuk artikel ini, intinya sederhana: kenyamanan YAML dan bahayanya berasal dari fitur yang sama.

YAML menang ketika orang menyunting konfigurasi yang sangat bersarang setiap hari dan ekosistem di sekelilingnya memang menuntutnya. Jika Anda menulis sebuah Helm chart, Anda sedang menulis YAML, dan itu tidak masalah.

TOML — Konfigurasi Eksplisit yang Dibangun untuk Tooling

TOML (Tom’s Obvious, Minimal Language, dibuat oleh Tom Preston-Werner) dirancang untuk menjadi format konfigurasi yang diidam-idamkan pengguna YAML: mudah dibaca, tapi tanpa tebak-tebakan. Ciri utamanya adalah eksplisitas. Tipe-tipenya tak ambigu, sehingga port = 5432 selalu integer dan name = "acme" selalu string, tanpa inferensi berbasis bentuk yang membuat tersandung. Sintaks TOML meminjam header [section] dari file INI, yang membuat tingkat atas sebuah konfigurasi mudah dipindai (scannable), dan ia tidak sensitif terhadap indentasi, sehingga spasi tak pernah mengubah makna. Spesifikasi TOML 1.0.0 kecil dan stabil, dan itu adalah sebuah fitur: lebih sedikit yang bisa salah diingat.

Kemampuan andalan TOML adalah tipe tanggal dan waktu native, yang tidak ditangani secara bersih oleh JSON maupun YAML polos. TOML punya empat di antaranya: offset date-time dengan zona waktu (1979-05-27T07:32:00Z), local date-time tanpanya, local date (1979-05-27, sekadar sebuah hari kalender), dan local time (07:32:00). Itu berarti sebuah tanggal deployment tetap menjadi tanggal sungguhan alih-alih string yang harus Anda urai ulang.

Tiga potong sintaks TOML mengerjakan sebagian besar pekerjaannya. Sebuah header [section] membuka sebuah tabel; sebuah header bertitik seperti [tool.ruff] menyarangkan satu tabel di dalam tabel lain tanpa indentasi tambahan; dan sebuah inline table { version = "1.0", features = ["derive"] } mengemas sebuah objek kecil ke dalam satu baris. Bagian yang berulang memakai header ganda, yaitu array of tables:

[[servers]]
name = "alpha"
ip = "10.0.0.1"

[[servers]]
name = "beta"
ip = "10.0.0.2"

Blok itu menjadi sebuah array JSON berisi dua objek di bawah key servers. Ia terbaca baik untuk sebuah daftar datar, yang justru merupakan kebutuhan sebagian besar konfigurasi alat.

Kelemahannya nyata tapi sempit. TOML tidak punya tipe null, sehingga sebuah nilai yang absen cukup menjadi key yang dihilangkan. Penyusunan bersarang yang dalam menjadi bertele-tele, karena setiap level dari struktur bersarang yang berulang mengulang seluruh header [[path]], yang tumbuh lebih berisik daripada padanan YAML-nya. Dan TOML lebih muda dan kurang universal dibandingkan JSON atau YAML, sehingga tidak setiap alat menuturkannya. TOML bersinar untuk konfigurasi yang kebanyakan datar dengan segelintir bagian berlabel, yang menggambarkan mayoritas besar konfigurasi alat.

Mengapa TOML untuk Rust dan Python?

Kebangkitan TOML mengikuti dua ekosistem yang mengadopsinya sebagai standar. Manajer paket Rust, Cargo, memakai Cargo.toml untuk setiap crate, sehingga setiap pengembang Rust membaca dan menulis TOML sejak hari pertama. Python menyusul: PEP 518 memperkenalkan pyproject.toml untuk mendeklarasikan kebutuhan build, dan PEP 621 membakukan metadata proyek (name, version, dependencies, dan bagian [tool.*]) di file yang sama itu, menggantikan sebaran setup.py, setup.cfg, dan konfigurasi per-alat. Di luar keduanya, Hugo, Netlify, Poetry, dan Foundry semuanya memakai TOML secara bawaan. Benang merahnya adalah konfigurasi tooling yang disunting kontributor secara manual dan yang diuntungkan dengan menjadi jelas alih-alih pintar.

Adu Langsung — Perbedaan yang Benar-Benar Menggigit

Tabel fitur itu rapi. Bug tidak. Perbedaan-perbedaan spesifik berikut memicu masalah nyata, masing-masing dengan contoh kecil yang bisa Anda jalankan melalui parser mana pun.

Komentar

JSON tidak punya sintaks komentar sama sekali. TOML dan YAML keduanya memakai # hingga akhir baris.

# TOML: komentar di awal
port = 5432  # dan satu di akhir

# YAML: gaya komentar identik
port: 5432   # komentar di akhir

Begitu Anda menempelkan // atau # ke dalam JSON yang ketat, parsing gagal. Ini bukan sekadar kosmetik. Sebuah konfigurasi yang dirawat manusia tanpa komentar mengumpulkan pengetahuan tak tertulis yang hanya hidup di kepala seseorang.

Tipe data dan tanggal

Tipe-tipe JSON eksplisit tapi sedikit, tanpa tipe tanggal. Tipe-tipe TOML eksplisit dan kaya. Tipe-tipe YAML implisit dan, sebagaimana dibahas di atas, sesekali salah. Tanggal adalah pembatas paling jelas. TOML mengekspresikan keempat jenisnya secara native:

odt = 1979-05-27T07:32:00Z   # offset date-time (punya zona waktu)
ldt = 1979-05-27T07:32:00    # local date-time (tanpa zona waktu)
ld  = 1979-05-27             # local date (sebuah hari kalender)
lt  = 07:32:00               # local time

Konversikan TOML itu ke JSON dan setiap nilai menjadi sebuah string yang mempertahankan maknanya: sebuah local date tetap "1979-05-27" alih-alih dikembungkan menjadi timestamp tengah malam palsu. Konverter TOML ke JSON kami mempertahankan jenis tanggal itu secara persis, yang sering disalahtangani oleh banyak konverter naif. Sementara itu YAML mungkin memperlakukan 1979-05-27 sebagai tanggal atau tidak, bergantung pada parser dan versi skema, yang justru merupakan ambiguitas yang tidak Anda inginkan pada konfigurasi produksi.

Kedalaman penyusunan bersarang

Semakin dalam konfigurasi Anda bersarang, semakin format-format itu berbeda arah. Ambil sebuah pohon kecil bergaya Docker Compose:

services:
  web:
    build:
      context: .
      args:
        NODE_ENV: production
    ports:
      - "8080:8080"

YAML mengekspresikan kedalaman dengan indentasi murni, dan ia tetap ringkas. Struktur yang sama dalam TOML memaksa Anda mengeja seluruh jalur di setiap header, dan memindahkan nilai skalar sebelum tabel anak:

[services.web]
ports = ["8080:8080"]

[services.web.build]
context = "."

[services.web.build.args]
NODE_ENV = "production"

JSON membawa pohon itu dalam kurung kurawal bersarang, yang tak ambigu tapi padat tanda baca. Untuk konfigurasi dangkal ketiganya terasa serupa; melewati tiga atau empat level, YAML kelihatan lebih ramping dan TOML kelihatan lebih berulang. Perbedaan tunggal itu menjelaskan mengapa Kubernetes memilih YAML dan Cargo memilih TOML.

Sensitivitas indentasi

Hanya YAML yang peduli pada spasi. Di JSON dan TOML Anda bisa mengindentasi sesuka hati, atau sama sekali tidak, dan maknanya identik. Di YAML, indentasi adalah strukturnya, dan tab ilegal, sehingga sebuah editor yang menyisipkan tab atau sebuah blok yang ditempel pada kedalaman yang salah secara diam-diam mengubah dokumen atau menolak untuk dimuat. Sebuah item daftar yang terindentasi satu spasi terlalu jauh bisa menempel ke key induk yang salah tanpa kesalahan apa pun, yang merupakan bug menjengkelkan untuk dikenali dengan mata karena filenya masih terlihat wajar. Jika kontributor Anda memakai editor dan pengaturan yang beragam, itu adalah pajak tetap yang dibebankan YAML dan tidak dibebankan dua format lainnya, dan itu adalah alasan kuat untuk menjalankan sebuah linter di CI pada konfigurasi YAML besar mana pun.

String multi-baris

JSON tidak bisa menampung baris baru literal di dalam sebuah string; Anda meng-escape-nya sebagai \n. YAML dan TOML keduanya punya string multi-baris sungguhan.

{ "note": "line one\nline two" }

note: |
  line one
  line two

note = """
line one
line two
"""

| pada YAML mempertahankan baris baru (blok > melipatnya menjadi spasi), dan """ pada TOML berperilaku serupa, memangkas baris baru yang langsung mengikuti tanda kutip pembuka. Untuk skrip tersemat, SQL, atau teks bantuan, hal ini saja bisa menentukan formatnya.

Koma di akhir dan keketatan

JSON adalah yang paling ketat dari ketiganya. Sebuah koma di akhir setelah elemen array terakhir adalah kesalahan sintaks:

# TOML valid — koma di akhir tidak masalah
ports = [
  8001,
  8002,
]

Koma di akhir yang sama setelah 8002 di JSON gagal diurai, itulah mengapa menambahkan sebuah baris ke sebuah array JSON begitu sering berarti juga membetulkan koma pada baris di atasnya. TOML mengizinkan koma di akhir, dan sintaks daftar tanda-hubung-per-baris pada YAML menghindari persoalan itu sepenuhnya. Keketatan adalah kebajikan untuk pertukaran antar-mesin dan gangguan untuk penyuntingan manual, yang merupakan tarik-ulur yang sama dilihat dari sisi lain. Ini juga merupakan hambatan yang hendak dihilangkan JSON5 dan JSONC khusus untuk JSON.

Integer besar dan batas atas 2^53

Ketiga format bisa menulis sebuah integer 64-bit sebagai teks. Persoalan mulai muncul ketika nilai itu melewati JavaScript, karena angka JSON di peramban adalah double IEEE-754 dan hanya bisa merepresentasikan integer secara persis hingga 2^53 − 1 (9007199254740991). Sebuah ID Snowflake atau timestamp nanodetik lebih besar dari itu, sehingga perjalanan bolak-balik (round-trip) melalui alat berbasis JS akan membulatkannya dan merusak nilainya:

snowflake = 1420070400000000000   # persis dalam teks TOML

{ "snowflake": "1420070400000000000" }

Solusi andal di setiap format adalah menyimpan nilai seperti itu sebagai string ber-tanda-kutip, sehingga tidak ada parser numerik yang pernah menyentuhnya. Ini bukan cacat pada salah satu format; ini adalah keterbatasan runtime yang melakukan konversi. Konverter kami memperingatkan Anda ketika sebuah integer melewati batas itu alih-alih merusaknya secara diam-diam.

Cara Memilih — Matriks Keputusan & Diagram Alir

Ketika Anda benar-benar memutuskan format konfigurasi mana yang dipakai (which config format to use), telusuri pertanyaan-pertanyaan berikut secara berurutan dan berhentilah pada “ya” yang kuat pertama.

1. Apakah file ditulis dan dibaca terutama oleh program, atau ekosistemnya sudah mewajibkan sebuah format? Jika ya, pakai JSON. Payload API adalah JSON. File di samping package.json adalah JSON. Jangan melawan tooling.
2. Apakah manusia menyunting secara manual konfigurasi yang dalam dan bersarang setiap hari, di dalam stack yang mengharapkannya (Kubernetes, CI, Ansible)? Jika ya, pakai YAML, dan adopsi sebuah konvensi pemberian tanda kutip untuk menghindari masalah Norwegia.
3. Apakah ini konfigurasi alat atau aplikasi, kebanyakan datar dengan beberapa bagian, disunting oleh kontributor dengan tingkat keahlian beragam, di mana bertipe dan jelas lebih unggul daripada ringkas? Jika ya, pakai TOML.

Jika dua jawaban seri, pecahkan dengan peta sumbu ini:

Kebutuhan	Paling cocok	Alasan
Komentar di dalam file	TOML atau YAML	JSON tidak punya
Nilai tanggal/waktu native	TOML	Empat tipe tanggal eksplisit
Penyusunan bersarang sangat dalam	YAML	Indentasi tetap ringkas
Nol kejutan spasi	JSON atau TOML	Tidak sensitif terhadap indentasi
Terkunci pada file ekosistem	JSON	package.json, tsconfig.json
Suntingan manusia, sedikit bagian	TOML	Tipe eksplisit, header mirip-INI
Pertukaran mesin-ke-mesin	JSON	Universal, ketat, cepat
Inferensi tipe tak boleh menebak	JSON atau TOML	YAML menyimpulkan secara implisit

Sebagian besar proyek berakhir memakai lebih dari satu. Sebuah repositori bisa saja punya package.json berformat JSON yang tak pernah disentuh secara manual, sebuah pyproject.toml berformat TOML untuk tooling Python-nya, workflow YAML di .github, dan sebuah file .env untuk rahasia lokal yang tidak mengikuti satu pun tata bahasa ini. Campuran itu normal, dan justru itulah intinya: setiap file hidup dalam format yang cocok bagi penyuntingnya. Jika lapisan .env adalah bagian dari setup Anda, panduan format file .env kami membahas di mana ia cocok berdampingan dengan konfigurasi JSON dan bagaimana mengonversi di antara keduanya.

Mengonversi Antara TOML, JSON, dan YAML

Anda akan lebih sering mengonversi antar-format ini daripada yang Anda kira. Sebuah job CI membaca pyproject.toml yang ditulis manual dan membutuhkannya sebagai JSON untuk memberi makan dashboard dependensi. Migrasi memindahkan aplikasi dari konfigurasi YAML ke TOML demi pengetikan yang lebih ketat. Code review pun lebih mudah ketika Anda membandingkan (diff) bentuk JSON dari dua file alih-alih versi aslinya yang sensitif terhadap spasi. Setiap arah punya jebakan yang layak diketahui sebelum Anda menempel.

TOML ke JSON. Risiko utamanya adalah tanggal. Sebuah local date seperti 1979-05-27 seharusnya tetap menjadi tanggal kalender, bukan menjadi timestamp UTC tengah malam yang mengarang waktu dan zona waktu. Komentar juga dibuang, karena JSON tidak bisa menampungnya. Konverter TOML ke JSON mempertahankan setiap jenis tanggal dengan setia sehingga perjalanan bolak-balik tetap tanpa kehilangan (lossless).

JSON ke TOML. TOML lebih ketat soal struktur, sehingga dua hal bisa menghalangi sebuah konversi. Tingkat atas harus berupa sebuah objek, karena sebuah dokumen TOML selalu berupa tabel di akarnya; sebuah array atau skalar telanjang tak punya tempat untuk pergi. Dan TOML tidak punya null, sehingga sebuah nilai objek null akan dibuang (dengan sebuah peringatan yang mencantumkan key mana), sementara sebuah null di dalam sebuah array sama sekali tidak punya representasi TOML yang valid. Konverter JSON ke TOML menampilkan kedua kasus secara eksplisit alih-alih menghasilkan output yang rusak.

JSON dan YAML, kedua arah. Di sini masalah Norwegia adalah hal yang perlu diwaspadai: sebuah NO atau 0755 tanpa tanda kutip bisa berganti tipe saat melintasi batas. Konverter JSON ke YAML dan konverter YAML ke JSON menangani pemberian tanda kutip sehingga sebuah string tetap menjadi string.

Setelah konversi apa pun, ada baiknya memvalidasi hasilnya. Menjalankan output melalui JSON Formatter memastikan JSON-nya terbentuk baik (well-formed) dan terindentasi secara konsisten sebelum Anda commit atau kirim ke hilir. Dan karena file konfigurasi membawa rahasia (token registry, kredensial basis data, kunci deploy), semua alat ini berjalan sepenuhnya di peramban Anda: tidak ada yang diunggah, sehingga sebuah Cargo.toml dengan token registry privat atau sebuah file values dengan kredensial tak pernah meninggalkan mesin Anda.

FAQ

Apakah TOML lebih baik daripada YAML?

Tidak ada yang secara universal lebih baik; pilihan TOML vs YAML bergantung pada bentuknya. TOML lebih sulit ditulis salah berkat tipe eksplisit dan tanpa jebakan indentasi, sehingga ia menang untuk konfigurasi tooling yang kebanyakan datar. YAML mengekspresikan penyusunan bersarang yang dalam secara lebih ringkas, sehingga ia menang untuk infrastruktur berlapis yang besar seperti Kubernetes.

Sebaiknya saya pakai JSON atau YAML untuk file konfigurasi?

Untuk konfigurasi yang disunting manusia, lebih baik YAML: ia mengizinkan komentar dan terbaca bersih, yang tidak dimiliki JSON. Untuk konfigurasi yang dihasilkan dan dikonsumsi program, lebih baik JSON: ia ketat, cepat, dan universal. Garis pemisahnya adalah siapa yang menyunting, manusia atau mesin.

Mengapa JSON tidak mengizinkan komentar?

Pencipta JSON, Douglas Crockford, menghapus komentar dengan sengaja. Ia khawatir orang akan menyematkan direktif parsing di dalamnya dan merusak interoperabilitas antar-parser. Jika Anda butuh komentar dalam sebuah file berbentuk JSON, pakai JSON5 atau JSONC, yang menambahkannya kembali tanpa mengubah struktur inti.

Apa itu masalah Norwegia di YAML?

Itu adalah YAML 1.1 yang memperlakukan kata-kata tertentu tanpa tanda kutip sebagai boolean, sehingga country: NO menjadi false alih-alih string "NO". YES, ON, dan OFF berperilaku serupa. Memberi tanda kutip pada nilainya mencegahnya; lihat panduan khusus yang ditautkan di atas untuk cerita lengkapnya.

Apakah TOML mendukung komentar?

Ya. TOML memakai # untuk komentar, baik pada barisnya sendiri maupun di akhir sebuah nilai, persis seperti YAML. Komentar hilang ketika Anda mengonversi TOML ke JSON, karena JSON tidak punya sintaks komentar untuk menampungnya.

Bisakah TOML merepresentasikan semua yang bisa direpresentasikan JSON?

Hampir. Kesenjangan JSON vs TOML kecil tapi nyata: TOML tidak punya tipe null, sehingga null pada JSON dibuang atau ditolak saat konversi, dan sebuah dokumen TOML harus berupa sebuah tabel di tingkat atas, sehingga sebuah array atau skalar JSON telanjang tak bisa dikonversi tanpa dibungkus di bawah sebuah key terlebih dahulu.

Apakah YAML merupakan superset dari JSON?

Sejak YAML 1.2, ya: setiap dokumen JSON yang valid juga merupakan YAML yang valid, sehingga sebuah parser YAML bisa membaca JSON secara langsung. Ini fakta yang berguna, tapi jangan menyandarkannya sebagai batas keamanan, karena parser YAML menambahkan fitur (seperti anchor) yang tidak dimiliki JSON.

Format konfigurasi mana yang tercepat diurai?

JSON umumnya tercepat, dengan parser paling matang dan paling teroptimasi di setiap bahasa. YAML paling lambat dan paling kompleks untuk diurai karena spesifikasinya yang besar dan pengetikan implisitnya. TOML berada di tengah, lebih dekat ke JSON dalam hal kecepatan dibandingkan ke YAML.