Alat pembangun · JSON pemformat & pengesah
Aksara halimunan yang memecahkan JSON: BOM, petikan pintar dan NBSP
· Bagaimana ia berfungsi
json aliran kerja pembangun pengesahan
Apabila pengesah melaporkan ralat pada aksara pertama dan fail kelihatan sempurna, watak yang tidak kelihatan biasanya dipersalahkan. Siaran ini menerangkan tanda pesanan bait, petikan tipografi dan ruang tidak pecah, dan cara setiap satu itu dilaporkan.
Baris 1, lajur 1, tiada salah untuk dilihat
Baris 1, lajur 1, tiada salah untuk dilihat — dokumen JSON boleh bermula dengan aksara yang menduduki kedudukan sebenar tetapi dipaparkan tanpa glyph yang kelihatan. Dakap pembukaan kemudiannya kelihatan yang pertama walaupun tanda tertib bait atau aksara lebar sifar mendahuluinya. Penghurai yang ketat menemui titik kod tersembunyi itu sebelum ia mencapai `{`, jadi melaporkan lajur pertama adalah tepat dan bukannya kabur. Paparan dan urutan watak sahaja menceritakan kisah yang berbeza.
Jangan padamkan pendakap yang kelihatan betul sahaja kerana tanda tanda muncul di sebelahnya. Periksa titik kod pada offset yang dilaporkan, dayakan ruang kosong yang boleh dilihat atau tukar kepada paparan heksadesimal. ToolAcre tidak mengalih keluar BOM terkemuka secara senyap sebelum menghuraikan dan pengimbasnya melaporkan aksara pertama yang tidak dijangka.
Tanda pesanan UTF-8 bait
Tanda pesanan UTF-8 bait — jujukan bait EF BB BF menyahkod kepada U+FEFF pada permulaan fail. Pesanan bait tidak samar-samar dalam UTF-8, jadi tanda itu tidak diperlukan, tetapi sesetengah editor dan alat eksport masih menambahkannya sebagai tandatangan pengekodan. RFC 8259 mengatakan JSON penjana tidak boleh menambah BOM pada rangkaian JSON, walaupun penghurai boleh memilih untuk mengabaikan satu untuk saling kendali. Toleransi itu tidak boleh diandaikan merentasi alat.
Dalam rentetan JavaScript, BOM ialah satu aksara walaupun perwakilan UTF-8nya menggunakan tiga bait. ToolAcre melaporkan kedudukan dalam aksara rentetan, jadi tanda utama muncul pada baris 1, lajur 1. Konfigurasikan editor untuk menyimpan UTF-8 tanpa BOM atau alih keluar U+FEFF sebelum mengedarkan fail.
Petikan pintar daripada pemproses perkataan
Petikan pintar daripada pemproses perkataan — tanda pembuka dan penutup tipografi kelihatan digilap dalam bentuk prosa, tetapi JSON sahaja mengenali tanda petikan ASCII U+0022 sebagai pembatas rentetan. U+201C dan U+201D ialah aksara Unicode biasa. Di luar rentetan, mereka tidak boleh memulakan nama atau nilai harta, jadi pengesah melaporkan petikan pintar itu sendiri. Autopembetulan dalam sembang, e-mel atau editor dokumen selalunya memperkenalkan perubahan selepas JSON pada asalnya sah.
Gantikan pembatas dengan petikan berganda lurus, kemudian periksa apostrof dan tanda petikan yang tergolong dalam nilai tersebut. Petikan kerinting adalah sah sebagai kandungan dalam rentetan JSON yang dibataskan dengan betul, seperti `"She said “go”"`; mereka gagal sahaja apabila diminta melaksanakan kerja tatabahasa pembatas.
Ruang tidak pecah dan aksara lebar sifar
Ruang tidak pecah dan aksara lebar sifar — JSON ruang kosong ialah senarai pendek yang sengaja dibuat: ruang biasa U+0020, tab U+0009, suapan talian U+000A dan pemulangan pengangkutan U+000D. Ruang tidak pecah U+00A0 mungkin kelihatan sama dengan ruang biasa antara titik bertindih dan nilai, tetapi ia tidak terdapat dalam senarai itu. Ruang lebar sifar U+200B tidak menunjukkan apa-apa, namun ia kekal sebagai watak yang tidak dijangka di luar rentetan yang dipetik.
Halaman web menggunakan ruang yang tidak putus untuk menyimpan kata-kata bersama, dan sistem pemesejan boleh memasukkan aksara lebar sifar untuk pembalut atau pengendalian skrip. Menyalin coretan berformat boleh membawanya ke dalam konfigurasi. Gantikan aksara NBSP struktur dengan ruang biasa dan alih keluar aksara lebar sifar yang tidak diingini, berpandukan offset yang dilaporkan.
Contoh yang berfungsi: konfigurasi yang disalin daripada mesej sembang
Contoh berfungsi: konfigurasi yang disalin daripada mesej sembang — katakan teks yang kelihatan menyerupai `{"mode": "safe"}`, tetapi pengesahan gagal pada mulanya. Pandangan hex mendedahkan EF BB BF sebelum pendakap. Mengalih keluar BOM itu memajukan laporan seterusnya kepada petikan sebelum `mode`, yang sebenarnya ialah U+201C. Menggantikan kedua-dua pembatas pintar dengan U+0022 kemudian mendedahkan U+00A0 antara titik bertindih dan nilai.
Tukar ruang tidak pecah struktur itu kepada U+0020 dan sahkan sekali lagi. Hasil yang diterima kini boleh diformat seperti biasa. Urutan ini menunjukkan sebab pembaikan sahaja perkara yang dipaparkan oleh skrin tidak boleh dipercayai: beberapa aksara yang tidak kelihatan atau serupa boleh menduduki kedudukan tatabahasa yang berbeza. Ikuti setiap baris dan lajur, kenal pasti titik kod sebenar, buat satu penggantian yang disengajakan dan jalankan semula pengesahan.
Bagaimana untuk melihat yang tidak kelihatan
Cara melihat yang tidak kelihatan — dayakan pilihan ruang kosong render editor untuk membezakan tab daripada ruang dan mendedahkan jurang yang luar biasa, kemudian gunakan pemeriksa Unicode atau paparan hex untuk aksara yang masih kelihatan sama. A UTF-8 BOM muncul sebagai EF BB BF, ruang tidak pecah sebagai C2 A0 dan ruang lebar sifar sebagai E2 80 8B. Petikan pembukaan dan penutup pintar muncul sebagai E2 80 9C dan E2 80 9D.
Padankan sistem koordinat diagnostik sebelum mengira. ToolAcre mengimbas rentetan JavaScript, jadi lajurnya mengira UTF-16 unit kod dan bukannya UTF-8 bait. Oleh itu, editor heks berorientasikan bait boleh menunjukkan offset berangka yang lebih besar selepas aksara bukan ASCII. Gunakan baris yang dilaporkan untuk mengecilkan carian, periksa titik kod bersebelahan dan terjemah sahaja mengikut keperluan.
Perkara ini tidak meliputi
Perkara yang tidak dilindungi ini — mojibake seperti `café` boleh sah sepenuhnya JSON. Penghurai melihat urutan biasa aksara rentetan dan tidak mempunyai bukti bahawa UTF-8 bait sebelum ini dinyahkodkan sebagai pengekodan lain. Begitu juga, ruang tidak pecah atau aksara lebar sifar dalam nilai yang disebut adalah sah dari segi sintaksis. Pengesahan menangkap aksara yang melanggar tatabahasa JSON; ia tidak boleh memutuskan sama ada kandungan Unicode yang sah sepadan dengan niat pengarang.
Membaiki kerosakan pengekodan di sempadan tempat bait menjadi teks, menggunakan pengetahuan tentang pengekodan asal dan tersilap. Jangan berulang kali mengekod dan menyahkod rentetan JSON sehingga ia kelihatan lebih baik, kerana itu boleh merosakkan aksara yang sudah betul. Normalisasi peringkat aplikasi juga merupakan keputusan yang berasingan: urutan Unicode yang serupa secara visual mungkin dibandingkan secara berbeza sambil kekal sah.
Bawa pulang: mempercayai lajur yang dilaporkan walaupun barisan kelihatan bersih
Bawa pulang: percaya kepada lajur yang dilaporkan walaupun baris kelihatan bersih — aksara halimunan dan tanda baca yang serupa masih menduduki kedudukan tepat dalam sumber. BOM, pembatas kerinting, ruang tidak pecah atau tanda lebar sifar boleh menghalang penghurai daripada mencapai pendakap atau petikan yang kelihatan betul. Dedahkan ruang kosong, periksa titik atau bait kod dan gantikan watak yang identitinya bercanggah dengan peranan tatabahasanya dan bukannya mengedit JSON yang berdekatan secara rawak.
Ingat bahawa kedudukan mungkin mengira aksara manakala alat hex mengira bait yang dikodkan, jadi bandingkan teks di sekeliling dan bukannya mengharapkan setiap nombor mengimbangi sepadan. Alih keluar BOM sahaja di sempadan dokumen, tukarkan pembatas pintar kepada U+0022 dan gantikan jarak struktur yang tidak sah tanpa memadamkan Unicode yang sah di dalam rentetan.