Bolehkah JSON mempunyai komen
Inti pati: RFC 8259 tidak mempunyai sintaks komen, jadi // dan komen blok menyebabkan JSON.parse melontar ralat. Gunakan JSON5 atau JSONC, medan _comment, penerangan Schema, atau YAML sebagai alternatif.
Pokoknya: jangan sekali-kali meletakkan komen dalam JSON standard; gunakan JSONC atau JSON5 untuk konfigurasi setempat yang hanya disunting manusia, pindahkan penjelasan ke dalam description JSON Schema apabila fail merentasi sistem, dan beralih kepada YAML atau TOML sebaik sahaja jumlah anotasi bertambah.
Tidak.
Mana-mana penghurai yang mematuhi standard menolak ini:
{
"port": 8080 // local development only
}
Chrome melaporkan SyntaxError: Unexpected token }. Penghurai menemui /, yang tidak boleh memulakan mana-mana nilai JSON, dan berhenti.
Mengapa spesifikasi sengaja mengecualikan komen
RFC 8259 mentakrifkan enam nilai: objek, tatasusunan, nombor, rentetan, true/false, null. Tiada pengeluaran komen.
Komen telah dicadangkan pada awal dan ditolak atas sebab konkrit: sebaik komen sah, seseorang menggunakannya untuk membawa arahan — sertakan bersyarat, pemboleh ubah templat — dan setiap penghurai mengembangkan dialeknya sendiri. Kesalingoperasian terputus pada lompatan pertama. JSON sengaja hanya data, tanpa apa-apa yang boleh dilaksanakan di dalamnya.
Empat cara untuk menyimpan nota anda
1. Gunakan superset. JSON5 dan JSONC menerima kedua-dua gaya komen. settings.json dan tsconfig.json VS Code ialah JSONC.
Kosnya nyata: JSON.parse masih menolaknya, dan API, saluran log serta baris gilir mesej biasanya hanya menerima JSON standard. Komen anda digugurkan secara senyap atau melontar ralat di suatu tempat hiliran.
2. Letakkan nota dalam data.
{
"_comment": "port assigned by ops, do not change",
"port": 8080
}
Berfungsi di mana-mana, tetapi mencemarkan model: setiap pengguna perlu tahu kunci mana yang perlu diabaikan, dan definisi jenis anda bertambah medan yang bukan sebenarnya data.
3. Gunakan penerangan Schema. description ditujukan untuk manusia dan alat. Pengesah memaparkannya, editor menunjukkannya pada hover, dan ia tidak pernah masuk ke dalam muatan. Ini satu-satunya pilihan yang bertahan dalam penyelenggaraan jangka panjang tanpa merosakkan keserasian.
4. Tukar format fail. Jika fail itu wujud untuk disunting dengan tangan, YAML atau TOML menyokong komen secara asli. Melawan JSON di sini ialah usaha yang sia-sia.
Memilih
| Situasi | Jawapan |
|---|---|
| Dihantar ke sistem lain, melalui API atau baris gilir | Tiada komen; dokumentasikan dalam Schema atau dokumen luaran |
| Konfigurasi hanya dibaca oleh manusia dan editor | JSONC, dengan sambungan .jsonc |
| Memerlukan perkakas universal dan penjelasan sebaris | JSON standard serta description Schema |
| Konfigurasi panjang dengan banyak anotasi | Beralih kepada YAML |
Soalan Lazim
Mengapa medan _comment mencemarkan model?
Kerana ia menjadi sebahagian daripada data. Setiap pengguna perlu tahu kunci mana yang perlu diabaikan, dan definisi jenis mendapat medan yang bukan sebenarnya data perniagaan.
Patutkah penjelasan disimpan dalam penerangan JSON Schema?
Ya. description kekal di luar muatan, manakala pengesah memaparkannya dan editor menunjukkannya pada hover, jadi ia satu-satunya pilihan yang bertahan dalam penyelenggaraan jangka panjang tanpa merosakkan keserasian.
Bolehkah JSONC atau JSON5 dihuraikan oleh JSON.parse?
Tidak. JSON.parse masih menolak komen, dan API, saluran log serta baris gilir mesej biasanya hanya menerima JSON standard, jadi komen itu digugurkan atau melontar ralat di suatu tempat hiliran.
Alat
- Penghurai JSON5 — tampal konfigurasi berkomen dan lihat struktur yang diselesaikan
- Pemformat dan pengesah JSON — JSON tidak sah dilaporkan dengan baris dan lajur, jadi komen yang bermasalah jelas kelihatan