Alat pengembang · JSON pemformat & validator
Karakter tak terlihat yang melanggar JSON: BOM, kutipan cerdas, dan NBSP
· Cara kerjanya
json alur kerja pengembang validasi
Ketika validator melaporkan kesalahan pada karakter pertama dan file terlihat sempurna, biasanya karakter yang tidak terlihat adalah penyebabnya. Posting ini menjelaskan tanda urutan byte, tanda kutip tipografi, dan spasi tanpa putus, serta cara masing-masing dilaporkan.
Baris 1, kolom 1, tidak ada yang salah untuk dilihat
Baris 1, kolom 1, tidak ada yang salah untuk dilihat — dokumen JSON dapat dimulai dengan karakter yang menempati posisi sebenarnya tetapi ditampilkan tanpa mesin terbang yang terlihat. Kurung kurawal pembuka kemudian muncul menjadi yang pertama meskipun tanda urutan byte atau karakter lebar nol mendahuluinya. Pengurai yang ketat menemukan titik kode tersembunyi tersebut sebelum mencapai `{`, jadi pelaporan kolom pertama akurat dan tidak kabur. Tampilan dan urutan karakternya menceritakan kisah yang berbeda.
Jangan menghapus tanda kurung kurawal yang terlihat benar hanya karena tanda sisipan muncul di sampingnya. Periksa titik kode pada offset yang dilaporkan, aktifkan spasi putih yang terlihat, atau alihkan ke tampilan heksadesimal. ToolAcre tidak secara diam-diam menghapus BOM di depan sebelum penguraian, dan pemindainya melaporkan karakter pertama yang tidak terduga.
Tanda urutan UTF-8 byte
Tanda urutan byte UTF-8 — urutan byte EF BB BF diterjemahkan menjadi U+FEFF di awal file. Urutan byte tidak ambigu di UTF-8, sehingga tanda tidak diperlukan, namun beberapa editor dan alat ekspor masih menambahkannya sebagai tanda tangan pengkodean. RFC 8259 mengatakan generator JSON tidak boleh menambahkan BOM ke JSON jaringan, meskipun parser dapat memilih untuk mengabaikannya demi interoperabilitas. Toleransi tersebut tidak dapat diterapkan pada seluruh alat.
Dalam string JavaScript, BOM adalah satu karakter meskipun representasi UTF-8-nya menggunakan tiga byte. ToolAcre melaporkan posisi dalam karakter string, sehingga tanda terdepan muncul pada baris 1, kolom 1. Konfigurasikan editor untuk menyimpan UTF-8 tanpa BOM atau hapus U+FEFF sebelum mendistribusikan file.
Kutipan cerdas dari pengolah kata
Kutipan cerdas dari pengolah kata — tanda kutip pembuka dan penutup tipografi tampak halus dalam bentuk prosa, namun JSON hanya mengenali tanda kutip ASCII U+0022 sebagai pembatas string. U+201C dan U+201D adalah karakter Unicode biasa. Di luar string, mereka tidak dapat memulai nama atau nilai properti, sehingga validator melaporkan kutipan cerdas itu sendiri. Koreksi otomatis dalam obrolan, email, atau editor dokumen sering kali menyebabkan perubahan setelah JSON awalnya valid.
Ganti pembatas dengan tanda kutip ganda lurus, lalu periksa tanda kutip dan tanda kutip yang termasuk dalam nilai tersebut. Kutipan keriting sepenuhnya legal sebagai konten di dalam string JSON yang dibatasi dengan benar, seperti `"She said “go”"`; mereka gagal hanya ketika diminta untuk melakukan tugas tata bahasa pembatas.
Spasi tanpa putus dan karakter dengan lebar nol
Spasi tak putus-putus dan karakter lebar nol — JSON spasi sengaja dibuat menjadi daftar pendek: spasi biasa U+0020, tab U+0009, umpan baris U+000A, dan kembalinya U+000D. Spasi non-breaking U+00A0 mungkin terlihat identik dengan spasi normal antara titik dua dan nilai, namun tidak ada dalam daftar tersebut. Spasi lebar nol U+200B tidak menunjukkan apa pun, namun tetap merupakan karakter yang tidak diharapkan di luar string yang dikutip.
Halaman web menggunakan spasi yang tidak dapat dipisahkan untuk menyatukan kata-kata, dan sistem pesan dapat menyisipkan karakter dengan lebar nol untuk pembungkusan atau penanganan skrip. Menyalin cuplikan yang diformat dapat membawanya ke konfigurasi. Ganti karakter struktural NBSP dengan spasi biasa dan hapus karakter lebar nol yang tidak diinginkan, dipandu oleh offset yang dilaporkan.
Contoh praktis: konfigurasi disalin dari pesan obrolan
Contoh praktis: konfigurasi disalin dari pesan obrolan — misalkan teks yang terlihat menyerupai `{"mode": "safe"}`, tetapi validasi gagal di awal. Tampilan hex memperlihatkan EF BB BF sebelum kurung kurawal. Menghapus BOM itu akan memajukan laporan berikutnya ke kutipan sebelum `mode`, yang sebenarnya adalah U+201C. Mengganti kedua pembatas pintar dengan U+0022 kemudian menampilkan U+00A0 antara titik dua dan nilainya.
Ubah ruang struktural non-breaking menjadi U+0020 dan validasi sekali lagi. Hasil yang diterima sekarang dapat diformat secara normal. Urutan ini menunjukkan mengapa memperbaiki hanya apa yang tampak di layar tidak dapat diandalkan: beberapa karakter yang tidak terlihat atau mirip dapat menempati posisi tata bahasa yang berbeda. Ikuti setiap baris dan kolom, identifikasi titik kode sebenarnya, buat satu penggantian yang disengaja, dan jalankan kembali validasi.
Cara melihat yang tak kasat mata
Cara melihat yang tidak terlihat — aktifkan opsi render-spasi putih editor untuk membedakan tab dari spasi dan menampilkan celah yang tidak biasa, lalu gunakan inspektur Unicode atau tampilan hex untuk karakter yang masih terlihat identik. UTF-8 BOM muncul sebagai EF BB BF, spasi tak putus sebagai C2 A0 dan spasi dengan lebar nol sebagai E2 80 8B. Kutipan pembuka dan penutup cerdas muncul sebagai E2 80 9C dan E2 80 9D.
Cocokkan sistem koordinat diagnostik sebelum menghitung. ToolAcre memindai string JavaScript, sehingga kolomnya menghitung UTF-16 unit kode, bukan UTF-8 byte. Oleh karena itu, editor hex berorientasi byte dapat menampilkan offset numerik yang lebih besar setelah karakter non-ASCII. Gunakan baris yang dilaporkan untuk mempersempit pencarian, periksa titik kode yang berdekatan dan terjemahkan hanya jika diperlukan.
Hal ini tidak tercakup dalam hal ini
Apa yang tidak tercakup dalam hal ini — mojibake seperti `café` dapat sepenuhnya valid JSON. Parser melihat urutan karakter string biasa dan tidak memiliki bukti bahwa UTF-8 byte sebelumnya didekodekan sebagai pengkodean lain. Demikian pula, karakter spasi tanpa putus atau karakter dengan lebar nol di dalam nilai yang dikutip valid secara sintaksis. Validasi menangkap karakter yang melanggar tata bahasa JSON; ia tidak dapat memutuskan apakah konten Unicode yang valid sesuai dengan maksud penulis.
Memperbaiki kerusakan pengkodean pada batas di mana byte menjadi teks, menggunakan pengetahuan tentang pengkodean asli dan kesalahan. Jangan menyandikan dan mendekode string JSON berulang kali hingga terlihat lebih baik, karena dapat merusak karakter yang sudah benar. Normalisasi tingkat aplikasi juga merupakan keputusan terpisah: jaringan Unicode yang identik secara visual dapat dibandingkan secara berbeda namun tetap valid.
Kesimpulan: percayai kolom yang dilaporkan bahkan ketika barisnya terlihat bersih
Kesimpulan: percayai kolom yang dilaporkan meskipun barisnya terlihat bersih — karakter yang tidak terlihat dan tanda baca yang mirip masih menempati posisi yang tepat di sumbernya. Tanda BOM di depan, pembatas keriting, spasi tidak putus, atau tanda lebar nol dapat mencegah parser mencapai kurung kurawal atau tanda kutip yang tampak benar. Tampilkan spasi putih, periksa titik atau byte kode, dan ganti karakter yang identitasnya bertentangan dengan peran tata bahasanya, alih-alih mengedit JSON di dekatnya secara acak.
Ingatlah bahwa posisi dapat menghitung karakter sementara alat hex menghitung byte yang disandikan, jadi bandingkan teks di sekitarnya daripada mengharapkan setiap nomor offset cocok. Hapus BOM hanya pada batas dokumen, ubah pembatas cerdas menjadi U+0022 dan ganti spasi struktural yang tidak valid tanpa menghapus Unicode yang sah di dalam string.