เครื่องมือสำหรับนักพัฒนา · JSON ฟอร์แมตเตอร์ & เครื่องมือตรวจสอบความถูกต้อง
อักขระที่มองไม่เห็นซึ่งแบ่ง JSON: BOM เครื่องหมายคำพูดอัจฉริยะ และ NBSP
· มันทำงานอย่างไร
json นักพัฒนาเวิร์กโฟลว์ การตรวจสอบ
เมื่อเครื่องมือตรวจสอบรายงานข้อผิดพลาดที่อักขระตัวแรกและไฟล์ดูสมบูรณ์แบบ อักขระที่มองไม่เห็นมักจะถูกตำหนิ โพสต์นี้จะอธิบายเครื่องหมายลำดับไบต์ เครื่องหมายคำพูดแบบพิมพ์ และการเว้นวรรคแบบไม่แยก และวิธีการรายงานแต่ละรายการ
บรรทัด 1 คอลัมน์ 1 ไม่มีอะไรผิดปกติให้เห็น
บรรทัด 1 คอลัมน์ 1 ไม่มีอะไรผิดปกติที่จะเห็น — เอกสาร JSON สามารถเริ่มต้นด้วยอักขระที่ครอบครองตำแหน่งจริง แต่แสดงผลโดยไม่มีสัญลักษณ์ที่มองเห็นได้ วงเล็บปีกกาเปิดจะปรากฏเป็นอันดับแรกแม้ว่าจะมีเครื่องหมายลำดับไบต์หรืออักขระที่มีความกว้างเป็นศูนย์นำหน้าก็ตาม โปรแกรมแยกวิเคราะห์ที่เข้มงวดจะพบจุดโค้ดที่ซ่อนอยู่ก่อนที่จะถึง `{` ดังนั้นการรายงานคอลัมน์แรกจึงมีความถูกต้องมากกว่าคลุมเครือ การแสดงและลำดับตัวละครบอกเล่าเรื่องราวที่แตกต่างกัน
อย่าลบเครื่องหมายปีกกาที่ดูถูกต้องเพียงเพราะเครื่องหมายรูปหมวกปรากฏอยู่ข้างๆ ตรวจสอบจุดโค้ดที่ออฟเซ็ตที่รายงาน เปิดใช้งานช่องว่างที่มองเห็นได้ หรือเปลี่ยนไปใช้มุมมองเลขฐานสิบหก ToolAcre จะไม่ลบ BOM นำหน้าออกอย่างเงียบๆ ก่อนที่จะแยกวิเคราะห์ และเครื่องสแกนจะรายงานอักขระตัวแรกที่ไม่คาดคิด
เครื่องหมายลำดับไบต์ UTF-8
เครื่องหมายลำดับไบต์ UTF-8 - ลำดับไบต์ EF BB BF ถอดรหัสเป็น U+FEFF ที่จุดเริ่มต้นของไฟล์ ลำดับไบต์ไม่คลุมเครือใน UTF-8 ดังนั้นจึงไม่จำเป็นต้องใช้เครื่องหมาย แต่เครื่องมือแก้ไขและเครื่องมือส่งออกบางตัวยังคงเพิ่มเครื่องหมายดังกล่าวเป็นลายเซ็นการเข้ารหัส RFC 8259 กล่าวว่า JSON ตัวสร้างจะต้องไม่เพิ่ม BOM ลงในเครือข่าย JSON แม้ว่า parsers อาจเลือกที่จะเพิกเฉยต่อหนึ่งรายการสำหรับการทำงานร่วมกัน ความอดทนนั้นไม่สามารถสันนิษฐานได้จากเครื่องมือต่างๆ
ในสตริง JavaScript นั้น BOM จะเป็นอักขระหนึ่งตัว แม้ว่าการแสดง UTF-8 จะใช้สามไบต์ก็ตาม ToolAcre รายงานตำแหน่งในอักขระสตริง ดังนั้นเครื่องหมายนำหน้าจะปรากฏที่บรรทัด 1 คอลัมน์ 1 กำหนดค่าตัวแก้ไขให้บันทึก UTF-8 โดยไม่มี BOM หรือลบ U+FEFF ก่อนที่จะแจกจ่ายไฟล์
คำพูดอัจฉริยะจากโปรแกรมประมวลผลคำ
เครื่องหมายคำพูดอัจฉริยะจากโปรแกรมประมวลผลคำ — เครื่องหมายเปิดและปิดตัวพิมพ์ดูสวยงามในรูปแบบร้อยแก้ว แต่ JSON รู้จักเฉพาะเครื่องหมายคำพูด ASCII U+0022 เป็นตัวคั่นสตริง U+201C และ U+201D เป็นอักขระ Unicode ธรรมดา ภายนอกสตริง ไม่สามารถขึ้นต้นชื่อคุณสมบัติหรือค่าได้ ดังนั้นเครื่องมือตรวจสอบจะรายงานเครื่องหมายคำพูดอัจฉริยะเอง การแก้ไขอัตโนมัติในแชท อีเมล หรือเครื่องมือแก้ไขเอกสารมักจะทำให้เกิดการเปลี่ยนแปลงหลังจากที่ JSON ถูกต้องตั้งแต่แรก
แทนที่ตัวคั่นด้วยเครื่องหมายคำพูดคู่ตรง จากนั้นตรวจสอบเครื่องหมายอะพอสทรอฟีและเครื่องหมายคำพูดที่เป็นของค่า เครื่องหมายคำพูดแบบโค้งถูกต้องตามกฎหมายอย่างสมบูรณ์เนื่องจากเนื้อหาภายในสตริง JSON ที่คั่นอย่างถูกต้อง เช่น `"She said “go”"`; แต่จะล้มเหลวเมื่อถูกขอให้ทำงานด้านไวยากรณ์ของตัวคั่นเท่านั้น
ช่องว่างไม่แบ่งและอักขระที่มีความกว้างเป็นศูนย์
ช่องว่างแบบไม่แยกและอักขระที่มีความกว้างเป็นศูนย์ — JSON ช่องว่างเป็นรายการสั้นโดยเจตนา: ช่องว่างปกติ U+0020, แท็บ U+0009, การป้อนบรรทัด U+000A และการขึ้นบรรทัดใหม่ U+000D ช่องว่างที่ไม่แยก U+00A0 อาจดูเหมือนช่องว่างปกติระหว่างเครื่องหมายทวิภาคและค่า แต่ไม่มีอยู่ในรายการนั้น พื้นที่ความกว้างเป็นศูนย์ U+200B ไม่แสดงอะไรเลย แต่ยังคงเป็นอักขระที่ไม่คาดคิดนอกสตริงที่ยกมา
หน้าเว็บใช้ช่องว่างแบบไม่แยกเพื่อรวมคำเข้าด้วยกัน และระบบการรับส่งข้อความอาจแทรกอักขระที่มีความกว้างเป็นศูนย์สำหรับการตัดคำหรือการจัดการสคริปต์ การคัดลอกตัวอย่างข้อมูลที่จัดรูปแบบแล้วสามารถนำไปสู่การกำหนดค่าได้ แทนที่อักขระโครงสร้าง NBSP ด้วยช่องว่างปกติ และลบอักขระที่มีความกว้างเป็นศูนย์โดยไม่ได้ตั้งใจ ซึ่งได้รับคำแนะนำจากออฟเซ็ตที่รายงาน
ตัวอย่างการทำงาน: การกำหนดค่าที่คัดลอกมาจากข้อความแชท
ตัวอย่างการทำงาน: การกำหนดค่าที่คัดลอกมาจากข้อความแชท — สมมติว่าข้อความที่มองเห็นนั้นคล้ายกับ `{"mode": "safe"}` แต่การตรวจสอบความถูกต้องล้มเหลวตั้งแต่เริ่มต้น มุมมองฐานสิบหกเผยให้เห็น EF BB BF ก่อนวงเล็บปีกกา การนำ BOM ออกจะทำให้รายงานถัดไปเลื่อนไปยังใบเสนอราคาก่อน `mode` ซึ่งจริงๆ แล้วคือ U+201C การแทนที่ตัวคั่นอัจฉริยะทั้งสองด้วย U+0022 จากนั้นจะแสดง U+00A0 ระหว่างเครื่องหมายทวิภาคและค่า
เปลี่ยนพื้นที่ไม่แยกโครงสร้างนั้นเป็น U+0020 และตรวจสอบอีกครั้ง ผลลัพธ์ที่ยอมรับสามารถจัดรูปแบบได้ตามปกติแล้ว ลำดับนี้แสดงให้เห็นว่าเหตุใดการซ่อมแซมเฉพาะสิ่งที่ปรากฏบนหน้าจอจึงไม่น่าเชื่อถือ: อักขระที่มองไม่เห็นหรือคล้ายกันหลายตัวสามารถใช้ตำแหน่งทางไวยากรณ์ที่แตกต่างกันได้ ปฏิบัติตามแต่ละบรรทัดและคอลัมน์ ระบุจุดโค้ดจริง ทำการแทนที่โดยเจตนาหนึ่งครั้ง และดำเนินการตรวจสอบความถูกต้องอีกครั้ง
วิธีมองเห็นสิ่งที่มองไม่เห็น
วิธีดูสิ่งที่มองไม่เห็น — เปิดใช้งานตัวเลือกการเรนเดอร์ช่องว่างของตัวแก้ไขเพื่อแยกแท็บออกจากช่องว่างและเผยให้เห็นช่องว่างที่ผิดปกติ จากนั้นใช้ตัวตรวจสอบ Unicode หรือมุมมองฐานสิบหกสำหรับอักขระที่ยังคงมีลักษณะเหมือนกัน A UTF-8 BOM ปรากฏเป็น EF BB BF พื้นที่ไม่แยกเป็น C2 A0 และช่องว่างความกว้างเป็นศูนย์เป็น E2 80 8B ราคาเปิดและปิดอัจฉริยะจะปรากฏเป็น E2 80 9C และ E2 80 9D
จับคู่ระบบพิกัดของการวินิจฉัยก่อนนับ ToolAcre สแกนสตริง JavaScript ดังนั้นคอลัมน์จึงนับหน่วยโค้ด UTF-16 แทนที่จะเป็น UTF-8 ไบต์ ดังนั้นโปรแกรมแก้ไขฐานสิบหกแบบไบต์จึงสามารถแสดงออฟเซ็ตตัวเลขที่ใหญ่กว่าหลังอักขระที่ไม่ใช่ ASCII ใช้บรรทัดที่รายงานเพื่อจำกัดการค้นหาให้แคบลง ตรวจสอบจุดโค้ดที่อยู่ใกล้เคียง และแปลตามความจำเป็นเท่านั้น
สิ่งนี้ไม่ครอบคลุมถึง
สิ่งนี้ไม่ครอบคลุมถึง — mojibake เช่น `café` สามารถใช้ JSON ได้อย่างสมบูรณ์ โปรแกรมแยกวิเคราะห์จะเห็นลำดับอักขระสตริงปกติและไม่มีหลักฐานว่า UTF-8 ไบต์ก่อนหน้านี้ถูกถอดรหัสเป็นการเข้ารหัสอื่น ในทำนองเดียวกัน การเว้นวรรคแบบไม่แบ่งหรืออักขระความกว้างเป็นศูนย์ภายในค่าที่ยกมานั้นถูกต้องตามหลักไวยากรณ์ การตรวจสอบความถูกต้องจะตรวจจับอักขระที่ละเมิดไวยากรณ์ JSON; ไม่สามารถตัดสินใจได้ว่าเนื้อหา Unicode ที่ถูกต้องตรงกับความตั้งใจของผู้เขียนหรือไม่
ซ่อมแซมความเสียหายของการเข้ารหัสที่ขอบเขตที่ไบต์กลายเป็นข้อความ โดยใช้ความรู้เกี่ยวกับการเข้ารหัสดั้งเดิมและการเข้ารหัสที่ผิดพลาด อย่าเข้ารหัสและถอดรหัสสตริง JSON ซ้ำๆ จนกว่าจะดูดีขึ้น เนื่องจากอาจทำให้อักขระที่แก้ไขแล้วเสียหายได้ การทำให้เป็นมาตรฐานระดับแอปพลิเคชันยังเป็นการตัดสินใจแยกต่างหาก: ลำดับ Unicode ที่เหมือนกันทางสายตาอาจเปรียบเทียบแตกต่างกันในขณะที่ยังคงใช้ได้
ประเด็นสำคัญ: เชื่อถือคอลัมน์ที่รายงาน แม้ว่าบรรทัดจะดูสะอาดตาก็ตาม
ประเด็นสำคัญ: เชื่อถือคอลัมน์ที่รายงานแม้ว่าบรรทัดจะดูสะอาดตาก็ตาม อักขระที่มองไม่เห็นและเครื่องหมายวรรคตอนที่เหมือนกันยังคงครองตำแหน่งที่แม่นยำในแหล่งที่มา BOM นำหน้า ตัวคั่นแบบโค้ง ช่องว่างไม่แยก หรือเครื่องหมายความกว้างเป็นศูนย์สามารถป้องกันไม่ให้ parser เข้าถึงวงเล็บปีกกาหรือเครื่องหมายคำพูดที่ปรากฏถูกต้อง เปิดเผยช่องว่าง ตรวจสอบจุดโค้ดหรือไบต์ และแทนที่อักขระที่ข้อมูลเฉพาะตัวขัดแย้งกับบทบาททางไวยากรณ์ แทนที่จะแก้ไข JSON ที่มองเห็นได้ใกล้เคียงโดยการสุ่ม
โปรดจำไว้ว่าตำแหน่งอาจนับอักขระในขณะที่เครื่องมือฐานสิบหกนับไบต์ที่เข้ารหัส ดังนั้นให้เปรียบเทียบข้อความที่อยู่รอบๆ แทนที่จะคาดหวังว่าทุกจำนวนออฟเซ็ตจะตรงกัน ลบ BOM เฉพาะที่ขอบเขตเอกสาร แปลงตัวคั่นอัจฉริยะเป็น U+0022 และแทนที่ระยะห่างของโครงสร้างที่ไม่ถูกต้องโดยไม่ต้องลบ Unicode ภายในสตริงที่ถูกต้องตามกฎหมาย