เครื่องมือสำหรับนักพัฒนา · JSON ฟอร์แมตเตอร์ & เครื่องมือตรวจสอบความถูกต้อง
เครื่องมือตรวจสอบ JSON ค้นหาบรรทัดและคอลัมน์ของข้อผิดพลาดได้อย่างไร
· มันทำงานอย่างไร
json การตรวจสอบ นักพัฒนาเวิร์กโฟลว์
เอ็นจิ้นเบราว์เซอร์รายงานความล้มเหลว JSON.parse แตกต่างออกไป และบางตัวให้ค่าชดเชยอักขระเท่านั้น โพสต์นี้จะอธิบายว่าเครื่องมือตรวจสอบความถูกต้องเปลี่ยนสิ่งนั้นให้เป็นบรรทัดและคอลัมน์ได้อย่างไร และเหตุใดตำแหน่งจึงทำเครื่องหมายว่าการแยกวิเคราะห์หยุดที่จุดใด แทนที่จะเป็นจุดที่คุณทำผิดพลาด
ข้อความแสดงข้อผิดพลาดที่ไม่บอกอะไรคุณ — เหตุใด 'โทเค็นที่ไม่คาดคิดใน JSON ที่ตำแหน่ง 1432' จึงไม่มีประโยชน์ในไฟล์ 400-line
ข้อผิดพลาด เช่น “โทเค็นที่ไม่คาดคิด” สร้างความหงุดหงิดในการกำหนดค่าที่ยาว เนื่องจากไม่มีตำแหน่งที่คุณสามารถเปิดในโปรแกรมแก้ไขของคุณได้ JSON.parse เป็นตัวแยกวิเคราะห์ที่เชื่อถือได้ของเบราว์เซอร์ แต่ข้อความวินิจฉัยจะแตกต่างกันไปตามกลไกและเวอร์ชันของ JavaScript ToolAcre ไม่คาดเดาตำแหน่งโดยการจับคู่สตริงข้อผิดพลาดภาษาอังกฤษที่ไม่เสถียร หาก JSON.parse ล้มเหลว เครื่องสแกนที่เข้มงวดแยกต่างหากจะเดินไปยังข้อความต้นฉบับเพื่อระบุอักขระตัวแรกที่ไวยากรณ์ JSON ไม่สามารถยอมรับได้
สิ่งที่ parser JSON ทำได้จริงในขณะที่อ่าน — การเดินผ่านโทเค็นและไวยากรณ์แบบเรียกซ้ำที่ใช้ค่าครั้งละหนึ่งค่า
JSON มีอักขระโครงสร้างหกตัว ได้แก่ วงเล็บปีกกา วงเล็บ เครื่องหมายทวิภาคและจุลภาค และค่าที่สามารถเป็นสตริง ตัวเลข อาร์เรย์ อ็อบเจ็กต์ จริง เท็จ หรือ null เครื่องสแกนจำเป็นต้องทราบว่าอยู่ในสตริงที่มีเครื่องหมายคำพูดหรือไม่ ก่อนที่จะเรียกเครื่องหมายจุลภาคว่าตัวคั่น: {"note": "A, B"} มีค่าหนึ่งค่า ไม่ใช่สองค่า โดยจะก้าวผ่านค่าหรือสมาชิกของออบเจ็กต์ และตรวจสอบสิ่งที่สามารถปฏิบัติตามได้ตามกฎหมายต่อไป RFC 8259 กำหนดไวยากรณ์นี้ และไม่เหมือนกับ JavaScript อ็อบเจ็กต์ตัวอักษรตรงที่ไม่อนุญาตให้แสดงความคิดเห็นหรือลูกน้ำต่อท้าย
จากออฟเซ็ตอักขระไปจนถึงบรรทัดและคอลัมน์ - การนับขึ้นบรรทัดใหม่จนถึงออฟเซ็ตความล้มเหลว และเหตุใดการลงท้ายด้วย CRLF และอักขระแบบหลายไบต์จึงทำให้การนับซับซ้อน
เครื่องสแกนมักจะเริ่มต้นด้วยออฟเซ็ตแบบศูนย์ในสตริง JavaScript ดั้งเดิม เพื่อให้มีประโยชน์ ให้นับตัวแบ่งบรรทัดก่อนออฟเซ็ต และค้นหาว่าความล้มเหลวอยู่ไกลแค่ไหนจากตัวแบ่งครั้งล่าสุด CRLF ควรถือเป็นการสิ้นสุดบรรทัดเดียว ไม่ใช่สองบรรทัด ตำแหน่งในสตริง JavaScript นับหน่วยโค้ด UTF-16 ไม่ใช่ UTF-8 ไบต์บนดิสก์ อีโมจิที่ไม่ใช่ BMP สามารถครอบครองสองหน่วยโค้ดในโปรแกรมแก้ไขที่แสดงสัญลักษณ์เดียว UI จะรายงานบรรทัด คอลัมน์ และข้อความที่ตัดตอนมา เพื่อให้คุณสามารถตรวจสอบเครื่องหมายรูปหมวกกับไฟล์ที่คุณวางได้
ในกรณีที่การแยกวิเคราะห์หยุดไม่ใช่จุดที่เกิดข้อผิดพลาด - เครื่องหมายจุลภาคหายไปจะถูกรายงานที่คีย์ถัดไป และเครื่องหมายคำพูดที่หลงทางสามารถดันข้อผิดพลาดลงได้หลายบรรทัด
โทเค็นแรกที่เป็นไปไม่ได้มักจะเกิดขึ้นหลังจากข้อผิดพลาดเดิม ในอ็อบเจ็กต์ การลืมเครื่องหมายจุลภาคหลัง true จะทำให้เครื่องหมายคำพูดที่ขึ้นต้นคุณสมบัติถัดไปไม่ถูกต้อง: parser คาดว่าจะมีเครื่องหมายจุลภาคหรือวงเล็บปีกกาปิด สตริงที่ไม่สิ้นสุดอาจทำให้เกิดข้อผิดพลาดปรากฏขึ้นที่ตัวแบ่งบรรทัดในภายหลังหรือจุดสิ้นสุดของอินพุต อ่านย้อนกลับจากจุดที่รายงานเพื่อค้นหาตัวคั่นที่หายไป อย่าถือว่าอักขระภายใต้เครื่องหมายรูปหมวกต้องถูกลบออก
ตัวอย่างการทำงาน: การกำหนดค่าโดยมีเครื่องหมายจุลภาคหายไปหนึ่งตัว — ตำแหน่งที่รายงาน โทเค็นโดยรอบ และวิธีการย้อนกลับไปยังสาเหตุที่แท้จริง
ลองใช้เอกสารสามบรรทัดตามตัวอักษร {"name"demo" ตามด้วย "enabled":true ในบรรทัดที่สอง และ "port":8080} ในบรรทัดที่สาม โดยไม่มีลูกน้ำอยู่หลัง true ToolAcre บรรทัดรายงาน 3 คอลัมน์ 1 ออฟเซ็ต 31: คาดว่าจะมีเครื่องหมายจุลภาคหรือ } หลังคุณสมบัติก่อนหน้า และจะแสดงเครื่องหมายรูปหมวกใต้เครื่องหมายคำพูดแรกของ "พอร์ต" ใส่ลูกน้ำที่ท้ายบรรทัดที่สอง จากนั้นตรวจสอบอีกครั้ง นี่เป็นการวินิจฉัยอุปสรรคทางไวยากรณ์ประการแรก ไม่ใช่การตัดสินว่าคำว่า "พอร์ต" ผิด
กลไกของเบราว์เซอร์แตกต่างกันอย่างไร — V8, SpiderMonkey และ JavaScriptCore วลีความล้มเหลวเดียวกันแตกต่างกัน ซึ่งเป็นเหตุผลว่าทำไมรายงานบรรทัดและคอลัมน์ที่สอดคล้องกันจึงช่วยได้
V8, SpiderMonkey และ JavaScriptCore ใช้ถ้อยคำที่แตกต่างกันและบางครั้งตัวอย่างข้อมูลบริบทที่แตกต่างกันสำหรับความล้มเหลว JSON.parse เดียวกัน เครื่องสแกนของ ToolAcre จะให้เหตุผลเชิงโครงสร้างและตำแหน่งของตัวเองเมื่อตัวแยกวิเคราะห์ดั้งเดิมปฏิเสธค่า หากเครื่องสแกนไม่เห็นด้วยกับ JSON.parse เครื่องมือจะส่งคืนข้อผิดพลาดของกลไกแทนที่จะสร้างตำแหน่ง ทางเลือกนั้นปลอดภัยกว่าการชี้ไปที่ตัวละครที่เดาได้อย่างมั่นใจ
สิ่งนี้ไม่ครอบคลุมถึงปัญหาด้านความหมาย เช่น ประเภทผิด ฟิลด์หายไป หรือการละเมิดสคีมา ซึ่งเครื่องมือตรวจสอบไวยากรณ์จะไม่ติดธง
ออบเจ็กต์ที่ถูกต้องตามหลักไวยากรณ์ยังคงอาจผิดสำหรับแอปพลิเคชันของคุณ: ไม่มีฟิลด์บังคับ อายุที่เขียนเป็นข้อความ คีย์ที่ซ้ำกันสองคีย์ หรือการอ้างอิงไปยังไฟล์ที่ไม่มีอยู่จะไม่ใช่ JSON ที่ไม่ถูกต้องโดยอัตโนมัติ RFC 8259 กล่าวว่าชื่อสมาชิกไม่ควรซ้ำกันสำหรับการทำงานร่วมกัน แต่การแยกวิเคราะห์เพียงอย่างเดียวไม่ได้บังคับใช้สคีมา API ของคุณ ตรวจสอบไวยากรณ์ที่นี่และตรวจสอบข้อจำกัดทางความหมายในโปรแกรมที่ใช้เอกสาร
ประเด็นสำคัญ: อ่านตำแหน่งว่าเป็น 'โทเค็นแรกที่ไวยากรณ์ไม่สามารถยอมรับได้' - และวิธีที่ JSON ตัวจัดรูปแบบและเครื่องมือตรวจสอบรายงานบรรทัดและคอลัมน์นั้นโดยไม่ต้องอัปโหลดข้อความ
ถือว่าตำแหน่งที่รายงานเป็น "โทเค็นแรกไวยากรณ์นี้ไม่สามารถยอมรับได้" ย้อนกลับไปหาสาเหตุ แก้ไขปัญหาหนึ่งประเด็นแล้วดำเนินการใหม่ JSON ฟอร์แมตเตอร์และเครื่องมือตรวจสอบความถูกต้องทำสิ่งนี้ในเครื่องโดยไม่ต้องอัปโหลดการกำหนดค่าที่วาง อย่าวางข้อมูลรับรองการผลิตจริงลงในเว็บไซต์สาธารณะใดๆ หากโปรแกรมแก้ไขออฟไลน์สามารถวินิจฉัยไฟล์แทนได้