เครื่องมือสำหรับนักพัฒนา · JSON ฟอร์แมตเตอร์ & เครื่องมือตรวจสอบความถูกต้อง
คีย์ที่ซ้ำกันใน JSON: สิ่งที่ RFC 8259 อนุญาตและสิ่งที่ parsers ทำได้
· พื้นหลัง
json มาตรฐาน การตรวจสอบ
ไวยากรณ์ของ JSON อนุญาตให้ใช้คีย์เดียวกันสองครั้ง ข้อมูลจำเพาะระบุว่าชื่อ 'ควร' ไม่ซ้ำกัน และผู้แยกวิเคราะห์ไม่เห็นด้วยว่าค่าใดจะชนะ โพสต์นี้จะอธิบายว่าเหตุใดจึงมีความสำคัญต่อความถูกต้องและความปลอดภัย
เซิร์ฟเวอร์อ่าน 'บทบาท' ใด
พิจารณา `{"role":"viewer","role":"editor"}` สมาชิกทั้งสองมีไวยากรณ์ครบถ้วน ดังนั้น ToolAcre รายงานถูกต้อง JSON เมื่อข้อความถึง `JSON.parse` วัตถุผลลัพธ์จะมีคุณสมบัติ `role` หนึ่งรายการซึ่งมีค่าเป็น `"editor"` สมาชิกก่อนหน้านี้จะไม่ถูกเก็บไว้เป็นประวัติที่ซ่อนอยู่ การตรวจสอบไวยากรณ์ที่ประสบความสำเร็จจึงไม่ตอบคำถามว่าชื่ออ็อบเจ็กต์ปรากฏมากกว่าหนึ่งครั้งหรือไม่
การจัดรูปแบบทำให้มองเห็นการสูญเสียได้หลังจากที่มันเกิดขึ้นแล้วเท่านั้น: ผลลัพธ์จะมี `{"role":"editor"}` ในรูปแบบที่เลือก ไม่สามารถสร้างสมาชิก `viewer` ที่ถูกละทิ้งได้ เนื่องจากการทำให้เป็นอนุกรมได้รับออบเจ็กต์ที่แยกวิเคราะห์ ไม่ใช่ลำดับสมาชิกดั้งเดิม หากชื่อซ้ำมีความสำคัญต่อการตรวจสอบ ให้เก็บรักษาและตรวจสอบข้อความต้นฉบับก่อนที่จะกดรูปแบบ แทนที่จะอาศัยผลลัพธ์ที่ทำให้เป็นมาตรฐาน
ไวยากรณ์อนุญาต สเป็คทำให้ท้อถอย
RFC 8259 กล่าวว่าชื่อภายในวัตถุไม่ควรซ้ำกัน “ควร” นั้นส่งเสริมผลลัพธ์ที่ทำงานร่วมกันได้โดยไม่ทำให้ส่วนหนึ่งของไวยากรณ์วัตถุพื้นฐานไม่ซ้ำกัน ชื่อที่ซ้ำยังคงประกอบด้วยสตริง ทวิภาค และค่าที่ถูกต้องในตำแหน่งที่คั่นด้วยเครื่องหมายจุลภาคที่ถูกต้อง ด้วยเหตุนี้ เครื่องมือตรวจสอบไวยากรณ์จึงสามารถยอมรับเอกสารได้ในขณะที่นโยบายแอปพลิเคชันปฏิเสธเอกสารดังกล่าว
ความแตกต่างนี้พลาดได้ง่ายเนื่องจากข้อผิดพลาดจำนวนมากเป็นความล้มเหลวทางไวยากรณ์ที่จำเป็น: เครื่องหมายทวิภาคที่หายไปหรือเครื่องหมายจุลภาคต่อท้ายไม่สามารถสร้างอ็อบเจ็กต์ JSON ได้เลย ซ้ำกันจะแตกต่างกัน พวกเขาสร้างคำถามเกี่ยวกับการทำงานร่วมกันหลังจากที่ parser รู้จักทุกโทเค็น ToolAcre จงใจหยุดที่ไวยากรณ์และไม่เพิ่มกฎชื่อซ้ำ ดังนั้นผลลัพธ์ที่ถูกต้องจะต้องไม่ถูกอ่านเพื่อรับประกันความเป็นเอกลักษณ์
JSON.parse และ ToolAcre ทำอะไร
`JSON.parse` ใช้เหตุการณ์ภายหลังเมื่อชื่อวัตถุซ้ำ ToolAcre สืบทอดลักษณะการทำงานดังกล่าวเนื่องจากจะแยกวิเคราะห์ก่อนการจัดรูปแบบ สำหรับ `{"limit":10,"limit":25,"unit":"items"}` การตรวจสอบความถูกต้องจะสำเร็จ ขีดจำกัดการแยกวิเคราะห์คือ 25 และเอาต์พุตที่จัดรูปแบบจะมี `limit` หนึ่งรายการ การเรียงลำดับคีย์เพิ่มเติมสามารถเปลี่ยนตำแหน่งทรัพย์สินที่ยังเหลืออยู่ได้ แต่ไม่สามารถเปิดเผยเหตุการณ์ที่ถูกเขียนทับได้
อย่าสรุปผลลัพธ์นั้นกับทุกตัวแยกวิเคราะห์หรือการกำหนดค่า บางระบบสามารถปฏิเสธรายการที่ซ้ำกัน และสแต็กการประมวลผลอื่นๆ อาจใช้นโยบายอื่นหรือตรวจสอบโทเค็นก่อนสร้างออบเจ็กต์ ข้อความข้ามระบบที่ปลอดภัยนั้นแคบ: ชื่อที่ซ้ำกันไม่สามารถทำงานร่วมกันได้อย่างน่าเชื่อถือ ตรวจสอบโหมดพาร์เซอร์จริงที่ใช้ในแต่ละขอบเขตเมื่อความแตกต่างมีความสำคัญ แทนที่จะอาศัยการอ้างสิทธิ์ทั่วทั้งภาษา
เมื่อความขัดแย้งของผู้แยกวิเคราะห์กลายเป็นความเสี่ยง
การซ้ำกันกลายเป็นข้อกังวลด้านความปลอดภัยเฉพาะในเส้นทางหลายขั้นตอนที่เป็นรูปธรรมเท่านั้น โดยที่ส่วนประกอบต่างๆ ตีความข้อความเดียวกันแตกต่างกัน ตัวอย่างเช่น ตัวกรองคำขออาจตรวจสอบรายการหนึ่งในขณะที่แอปพลิเคชันใช้งานอีกรายการหนึ่ง ไม่ว่าสิ่งนั้นจะเกิดขึ้นได้หรือไม่นั้นขึ้นอยู่กับ parsers ตัวเลือก พฤติกรรมการส่งต่อ และการใช้งานภาคสนาม ไวยากรณ์ที่ซ้ำกันเพียงอย่างเดียวไม่สามารถพิสูจน์ได้ว่าเป็นการบายพาสที่สามารถหาประโยชน์ได้
การควบคุมที่สามารถป้องกันได้คือการสร้างนโยบายหนึ่งนโยบายที่ขอบเขตความน่าเชื่อถือและทดสอบสแต็กจริง ปฏิเสธชื่อที่ซ้ำกันก่อนที่จะสร้างออบเจ็กต์ที่สูญเสียไป เมื่อยอมรับความกำกวมไม่ได้ หรือตรวจสอบให้แน่ใจว่าทุกองค์ประกอบได้รับการเป็นตัวแทนที่แยกวิเคราะห์แล้วเหมือนกัน ToolAcre สามารถสาธิตลักษณะการจัดรูปแบบการชนะครั้งสุดท้ายของตนเองได้ แต่ไม่สามารถตรวจสอบเกตเวย์ เฟรมเวิร์ก หรือบริการที่ไม่ได้เป็นส่วนหนึ่งของเครื่องมือเบราว์เซอร์
ตัวอย่างการทำงาน: เอกสารที่มีคีย์ซ้ำ
วาง `{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}` ToolAcre ยอมรับข้อความเนื่องจากสมาชิกทุกคนมีความถูกต้องทางวากยสัมพันธ์ การแยกวิเคราะห์จะปล่อยให้ธีมรูทเป็น `dark` และความหนาแน่นที่ซ้อนกันเป็น `compact` การจัดรูปแบบจะปล่อยสำเนาหนึ่งสำเนาของแต่ละชื่อ ดังนั้นค่าก่อนหน้าทั้งสองค่าจะหายไปจากเอกสารที่แสดง
ตัวอย่างดังกล่าวยังแสดงให้เห็นว่าเหตุใดการค้นหาผลลัพธ์ที่จัดรูปแบบจึงสายเกินไป การตรวจหารายการซ้ำจะต้องสังเกตชื่อสมาชิกขณะอ่านสตรีมโทเค็นต้นฉบับที่ความลึกของวัตถุทุกจุด อาร์เรย์ไม่จำเป็นต้องมีกฎชื่อที่ซ้ำกัน แม้ว่ากฎการใช้งานที่แยกจากกันอาจสนใจค่าองค์ประกอบที่ซ้ำกันก็ตาม คงแหล่งที่มาไว้ไม่เปลี่ยนแปลง เรียกใช้ parser ที่รับรู้ซ้ำหรือ linder กับแหล่งที่มา และตัดสินใจว่านโยบายนั้นเป็นคำเตือนหรือปฏิเสธ
การตรวจจับรายการที่ซ้ำกันโดยตั้งใจ
ใช้เครื่องมือที่รับประกันการตรวจจับชื่อซ้ำในแหล่งที่มา JSON อย่างชัดเจน วิธีการที่เหมาะสม ได้แก่ โหมด parser ที่ล้มเหลวในการทำซ้ำ ตัวจัดการโทเค็นการสตรีมที่ติดตามชื่อสำหรับแต่ละอ็อบเจ็กต์ที่เปิดอยู่ หรือ linter ที่มีกฎคีย์ซ้ำกันที่บันทึกไว้ ตรวจสอบวัตถุที่ซ้อนกันและชื่อที่ใช้ Escape: `"name"` และ `"name"` ถอดรหัสเป็นชื่อสมาชิกเดียวกัน แม้ว่าการสะกดแหล่งที่มาจะต่างกันก็ตาม
JSON Schema ไม่สามารถทดแทนได้เมื่อการแยกวิเคราะห์แบบธรรมดาได้ละทิ้งเหตุการณ์ที่เกิดขึ้นก่อนหน้านี้ โดยทั่วไปเครื่องมือตรวจสอบสคีมาจะได้รับค่าที่สร้างขึ้นและเห็นคุณสมบัติเดียว ไม่ใช่ประวัติโทเค็นที่ซ้ำกัน เรียกใช้การตรวจสอบเอกลักษณ์ก่อนหรือระหว่างการแยกวิเคราะห์ จากนั้นใช้การตรวจสอบสคีมากับค่าที่ไม่คลุมเครือ ToolAcre ไม่ดำเนินการตรวจจับซ้ำหรือตรวจสอบสคีมา ดังนั้น ทั้งสองจึงต้องมีขั้นตอนที่สร้างขึ้นตามวัตถุประสงค์แยกต่างหาก
สิ่งนี้ไม่ครอบคลุมถึง
ชื่อออบเจ็กต์ที่ซ้ำกันไม่เหมือนกับค่าที่ซ้ำกันในระเบียน `[ {"id":7}, {"id":7} ]` มีสองวัตถุแยกกัน โดยแต่ละวัตถุมี `id` หนึ่งอัน; การตรวจจับตัวระบุที่ซ้ำกันนั้นมีกฎชุดข้อมูล ในทำนองเดียวกัน องค์ประกอบอาร์เรย์สองรายการที่มีสตริงเดียวกันยังคงเป็นสองตำแหน่งโดยเจตนา เว้นแต่สัญญาแอปพลิเคชันจะบอกว่าอาร์เรย์แสดงถึงชุด
บทความนี้ไม่ได้อ้างถึงนโยบายสากลแบบชนะก่อน ชนะครั้งสุดท้าย หรือปฏิเสธสำหรับระบบนิเวศที่ใช้ภาษากว้างๆ โดยจะบันทึกพฤติกรรม `JSON.parse` ที่สังเกตได้ของ ToolAcre และอธิบายว่าทำไมจึงต้องตรวจสอบส่วนประกอบอื่นโดยตรง นอกจากนี้ยังไม่ได้กำหนดความสามารถในการหาประโยชน์จากรายการที่ซ้ำกันเพียงอย่างเดียว ผลกระทบด้านความปลอดภัยจำเป็นต้องมีหลักฐานว่าการตีความที่แตกต่างกันข้ามขอบเขตการอนุญาต การกำหนดเส้นทาง หรือการตรวจสอบที่เกี่ยวข้อง
ประเด็นสำคัญ: ที่ถูกต้อง JSON นั้นไม่ได้คลุมเครือเสมอไป JSON
ToolAcre ผลลัพธ์ที่ถูกต้องหมายความว่าลำดับโทเค็นเข้มงวด JSON; ไม่ได้หมายความว่าทุกชื่อวัตถุจะไม่ซ้ำกัน `JSON.parse` เก็บค่าสุดท้ายสำหรับชื่อที่ซ้ำกัน และการจัดรูปแบบจะจัดลำดับเฉพาะผู้รอดชีวิตรายนั้นเท่านั้น เนื่องจากเหตุการณ์ก่อนหน้านี้ถูกลบไปแล้ว เอาต์พุตที่จัดรูปแบบแล้วจึงเป็นหลักฐานที่ไม่เหมาะสมในการตัดสินว่าแหล่งข้อมูลต้นฉบับมีข้อมูลซ้ำกันหรือไม่
เมื่อความเป็นเอกลักษณ์เป็นสิ่งสำคัญ ให้ตรวจสอบข้อความต้นฉบับด้วยเครื่องมือที่รับรู้ถึงสำเนาก่อนการแยกวิเคราะห์หรือการจัดรูปแบบตามปกติ ใช้การตรวจสอบความถูกต้องของสคีมาและโดเมนหลังจากนั้นกับค่าผลลัพธ์ที่ไม่คลุมเครือ สำหรับการตรวจสอบความปลอดภัย ให้ติดตามเส้นทางคำขอจริงและการตั้งค่าตัวแยกวิเคราะห์ แทนที่จะถือว่าไม่เห็นด้วย กฎการปฏิบัตินั้นเรียบง่าย: การยอมรับไวยากรณ์ นโยบายชื่อซ้ำ และความหมายขั้นปลายเป็นการตรวจสอบแยกกันโดยมีหลักฐานแยกกัน