เครื่องมือสำหรับนักพัฒนา · JSON ฟอร์แมตเตอร์ & เครื่องมือตรวจสอบความถูกต้อง
ประวัติมาตรฐานของ JSON: RFC 4627 ถึง RFC 8259 และ ECMA-404
· พื้นหลัง
json มาตรฐาน การตรวจสอบ
JSON ได้รับการระบุอย่างน้อยสี่ครั้งโดยหน่วยงานมาตรฐานสองแห่ง โพสต์นี้ติดตามเส้นทางจาก json.org ของ Douglas Crockford ไปยัง RFC 8259 และ ECMA-404 ของ Douglas Crockford และอธิบายสิ่งที่เปลี่ยนแปลงจริง ๆ สำหรับนักพัฒนาตลอดเส้นทาง
parser ของฉันติดตามข้อมูลจำเพาะใด
parser ติดตามข้อกำหนดใด คำตอบมักจะมองเห็นได้ที่ขอบ แทนที่จะมองเห็นในวัตถุและอาร์เรย์ธรรมดา ทดสอบสตริงระดับบนสุด เช่น `"ready"` ซึ่งเป็นเครื่องหมายลำดับไบต์นำหน้า ชื่อสมาชิกที่ซ้ำกัน และตัวเลขที่มีขนาดใหญ่ผิดปกติ เอกสารต่างๆ จะหารือเกี่ยวกับไวยากรณ์และการทำงานร่วมกันในระดับต่างๆ ในขณะที่การใช้งานจะเพิ่มประเภทข้อมูลและพฤติกรรมข้อผิดพลาดของตนเอง การตั้งชื่อมาตรฐานจะมีประโยชน์ก็ต่อเมื่อสัญญาพาร์เซอร์ที่สังเกตถูกแยกออกจากสมมติฐานเกี่ยวกับการใช้งาน JSON ทุกครั้ง
หลักฐานที่เก็บสำหรับ ToolAcre นั้นเป็นรูปธรรมและแคบกว่าประวัติมาตรฐานทั่วไป ตัวจัดรูปแบบใช้ `JSON.parse` เพื่อสร้างค่าและ `JSON.stringify` เพื่อปล่อยค่าเหล่านั้น หลังจากความล้มเหลวในการแยกวิเคราะห์ เครื่องสแกนในเครื่องจะระบุตำแหน่งและเหตุผลในการวินิจฉัยที่มั่นคง
json.org และคำอธิบายเบื้องต้นของ JSON
json.org นำเสนอ JSON ในรูปแบบย่อที่ได้มาจากไวยากรณ์อ็อบเจกต์-ลิเทอรัลของ JavaScript และบันทึกโครงสร้างหลักด้วยไวยากรณ์ขนาดเล็ก คำอธิบายเบื้องต้นดังกล่าวช่วยให้นักพัฒนามีชื่อที่ใช้ร่วมกันและการอ้างอิงสำหรับอ็อบเจ็กต์ อาร์เรย์ สตริง ตัวเลข บูลีน และ null การอธิบายหน้าดังกล่าวเป็นการอธิบายต่อสาธารณะตั้งแต่เนิ่นๆ ปลอดภัยกว่าการอ้างว่าหน้าหรือบุคคลหนึ่งค้นพบรูปแบบหรือยอมรับรูปแบบนั้นโดยลำพัง โดยไม่ต้องอ้างอิงหลักฐานทางประวัติศาสตร์ที่นี่
แหล่งที่มาของพื้นที่เก็บข้อมูลปัจจุบันไม่รวมประวัติการเก็บถาวรของ json.org การใช้งานเบราว์เซอร์ หรือการอภิปรายของคณะกรรมการ พวกเขาแสดงให้เห็นว่าแอปพลิเคชันนี้แยกวิเคราะห์และวินิจฉัย JSON อย่างไรในวันนี้ ดังนั้น ข้อความในอดีตในบทความนี้จึงใกล้เคียงกับเอกสารมาตรฐานที่ล้าสมัย และหลีกเลี่ยงการระบุถึงแรงจูงใจหรือผลกระทบต่อตลาดที่ไฟล์ในเครื่องเหล่านั้นไม่สามารถพิสูจน์ได้
RFC 4627 ใน 2006 — คำอธิบาย IETF แรก แอปพลิเคชัน/json ประเภทสื่อ และกฎที่ข้อความต้องเป็นวัตถุหรืออาร์เรย์
RFC 4627เผยแพร่ใน 2006อธิบายไว้ JSON สำหรับการแลกเปลี่ยนอินเทอร์เน็ตและลงทะเบียน `application/json` ประเภทสื่อ คำจำกัดความของมัน JSON ข้อความจำเป็นต้องมีออบเจ็กต์หรืออาร์เรย์ที่ระดับบนสุด แม้ว่าจะมีสตริง ตัวเลข และตัวอักษรเป็นค่าภายในคอนเทนเนอร์เหล่านั้นก็ตาม ข้อจำกัดดังกล่าวเป็นข้อแตกต่างทางประวัติศาสตร์ที่มีประโยชน์เนื่องจากเอกสารประกอบด้วยเท่านั้น `"ready"` อาจเป็นค่าที่ถูกต้องในสูตรภายหลังขณะตกอยู่ด้านนอก RFC 4627ของ JSONคำจำกัดความของข้อความ
เอกสารนี้ยังกล่าวถึงข้อกังวลด้านการเข้ารหัสและความปลอดภัยในบริบทของการใช้งานที่มีอยู่ในขณะนั้น ไม่ควรอ่านเป็นบันทึกการเปลี่ยนแปลงสำหรับที่เก็บนี้: ToolAcre ไม่มีโหมดความเข้ากันได้ RFC 4627 และพาธพาร์เซอร์จะมอบหมายการสร้างค่าให้กับกลไกโฮสต์ JavaScript
ECMA-404 ใน 2013 — มาตรฐานไวยากรณ์ขั้นต่ำสุดของ Ecma เท่านั้น และเหตุใดองค์กรทั้งสองจึงลงเอยด้วยการอธิบายรูปแบบเดียว
ECMA-404 เผยแพร่ครั้งแรกใน 2013 ระบุไวยากรณ์ JSON ในรูปแบบที่กะทัดรัดโดยเจตนา จุดสนใจอยู่ที่ไวยากรณ์ของข้อความ JSON ที่ถูกต้อง แทนที่จะเป็นโปรไฟล์การแลกเปลี่ยนที่สมบูรณ์สำหรับการใช้งานในเครือข่ายทุกครั้ง ขอบเขตนั้นช่วยอธิบายว่าทำไมเอกสาร ECMA-404 และ IETF จึงสามารถอธิบายสัญกรณ์พื้นฐานเดียวกันได้ ในขณะที่ต่างกันในแนวทางการทำงานร่วมกันโดยรอบที่พวกเขาเน้นย้ำ การมีอยู่ของเนื้อหามาตรฐานสองรายการไม่ได้หมายความถึงรูปแบบที่เข้ากันไม่ได้สองรูปแบบในการใช้งานทั่วไป
การกล่าวอ้างว่าเหตุใดองค์กรจึงเลือกเส้นทางการเผยแพร่โดยเฉพาะจึงจำเป็นต้องมีแหล่งสารคดีที่อยู่นอกเหนือโค้ดเบสนี้ ดังนั้นบทความนี้จึงไม่อนุมานแรงจูงใจของคณะกรรมการจากวันที่ของมาตรฐาน ประเด็นในทางปฏิบัติที่เกี่ยวข้องคือ RFC 8259 และ ECMA-404 มีวัตถุประสงค์เพื่อให้สอดคล้องกับไวยากรณ์ ในขณะที่ RFC 8259 ให้คำแนะนำที่สำคัญสำหรับการแลกเปลี่ยนที่ทำงานร่วมกันได้
RFC 7159 และ RFC 8259
RFC 7159 แทนที่ RFC 4627 ใน 2014 และขยายคำจำกัดความของข้อความ JSON ให้เป็นค่าอนุกรมใด ๆ โดยลบกฎระดับบนสุดของวัตถุหรืออาร์เรย์เท่านั้น RFC 8259 แทนที่ RFC 7159 ใน 2017 และยังคงเป็นข้อมูลอ้างอิง IETF ที่ปกติอ้างถึงสำหรับ JSON ต้องใช้ UTF-8 สำหรับ JSON ที่แลกเปลี่ยนระหว่างระบบที่อยู่นอกระบบนิเวศแบบปิด และบันทึกคำเตือนเกี่ยวกับการทำงานร่วมกันเกี่ยวกับตัวเลข ชื่อที่ซ้ำกัน Unicode และเครื่องหมายลำดับไบต์ แทนที่จะแสร้งทำเป็นว่าไวยากรณ์เพียงอย่างเดียวรับประกันผลลัพธ์ที่เหมือนกันทุกที่
ระดับบนสุด `true` เป็นวิธีที่กะทัดรัดในการสังเกตกฎค่ารูตสมัยใหม่ใน ToolAcre เพราะ `JSON.parse` ยอมรับกฎดังกล่าว ผลลัพธ์ดังกล่าวแสดงให้เห็นถึงพฤติกรรมของการดำเนินการนี้ มันไม่ได้สร้างขึ้นใหม่เมื่อทุกเบราว์เซอร์ เซิร์ฟเวอร์ หรือ API นำคำจำกัดความที่กว้างขึ้นมาใช้
สิ่งที่เปลี่ยนแปลงไปสำหรับนักพัฒนาที่ทำงาน
สำหรับนักพัฒนาที่ทำงาน การเปลี่ยนแปลงข้อกำหนดที่ชัดเจนที่สุดคือการยอมรับค่า JSON ใดๆ ที่รากและคำแนะนำที่แข็งแกร่งยิ่งขึ้นสำหรับการเข้ารหัสที่ทำงานร่วมกันได้ บทเรียนที่มองเห็นได้น้อยกว่าคือไวยากรณ์ที่ถูกต้องยังคงเหลือทางเลือกในการนำไปปฏิบัติ ชื่อออบเจ็กต์ที่ซ้ำกันอาจถูกยุบ การเรียงลำดับสมาชิกไม่ใช่สัญญาเชิงความหมาย จำนวนที่มากอาจสูญเสียความแม่นยำ และลำดับ Unicode ที่ผิดปกติสามารถเดินทางผ่านไลบรารีที่แตกต่างกันได้ เอกสารที่เป็นไปตามมาตรฐานจึงสมควรได้รับข้อจำกัดเพิ่มเติมจากสคีมาของแอปพลิเคชัน
ในตัวจัดรูปแบบนี้ ชื่อและโทเค็นหมายเลขที่ซ้ำกันจะผ่าน `JSON.parse` ก่อน ดังนั้นการจัดรูปแบบในภายหลังจึงสะท้อนถึงค่า JavaScript ผลลัพธ์แทนที่จะเป็นเอกสารคำศัพท์ดั้งเดิม เครื่องสแกนมีส่วนช่วยในการวินิจฉัยหลังจากเกิดความล้มเหลว ไม่รักษาสมาชิกที่ซ้ำกันหรือตัวเลขที่มีความแม่นยำตามอำเภอใจ สิ่งเหล่านี้เป็นการสังเกตที่ได้รับการสนับสนุนจากที่เก็บข้อมูล
สิ่งนี้ไม่ครอบคลุมถึง
สิ่งที่ไม่ครอบคลุมถึงคือข้อกำหนดที่ซ้อนกันอยู่ด้านบนของ JSON JSON Schema อธิบายข้อจำกัดเกี่ยวกับรูปร่างและค่าของเอกสาร JSON ตัวชี้ระบุตำแหน่งภายในเอกสาร JSON โปรแกรมแก้ไขแสดงถึงการเปลี่ยนแปลง พวกเขาแก้ปัญหาที่แตกต่างจากไวยากรณ์พื้นฐาน และไม่ควรถือเป็นเวอร์ชันที่ใหม่กว่าของ JSON เอง JSONC, JSON5 และรูปแบบการเขียนที่คล้ายกันยังขยายหรือเปลี่ยนแปลงไวยากรณ์ที่ยอมรับ และจำเป็นต้องมีตัวแยกวิเคราะห์ของตนเอง แทนที่จะรวมเข้ากับการตรวจสอบที่เข้มงวดอย่างเงียบๆ
บทความนี้ยังหลีกเลี่ยงประวัติทางสังคมที่ครอบคลุมของการนำไปใช้ JSON การสนับสนุนเบราว์เซอร์ หรือการแข่งขันกับ XML เนื่องจากแหล่งที่มาของพื้นที่เก็บข้อมูลที่ระบุไว้ไม่สามารถยืนยันการบรรยายนั้นได้ ไม่มีการคิดค้นการอ้างอิงภายนอกเพื่อเติมเต็มช่องว่าง
ประเด็นสำคัญ: RFC 8259 เป็นข้อมูลอ้างอิงสำหรับการอ้างอิง
RFC 8259 เป็นการอ้างอิง IETF ที่ใช้งานได้จริงเพื่ออ้างอิงสำหรับไวยากรณ์ JSON ปัจจุบันและคำแนะนำด้านการทำงานร่วมกัน โดยมี ECMA-404 ที่ให้มาตรฐานไวยากรณ์ Ecma ที่สอดคล้องกัน RFC 4627 และ RFC 7159 ยังคงมีประโยชน์สำหรับการทำความเข้าใจว่าคำจำกัดความที่เผยแพร่เปลี่ยนแปลงไปอย่างไร โดยเฉพาะอย่างยิ่งในระดับบนสุด อ้างอิงเอกสารที่สนับสนุนการอ้างสิทธิ์ที่แน่นอนแทนที่จะใช้ "ข้อกำหนด JSON" เป็นการอุทธรณ์ที่คลุมเครือต่อผู้มีอำนาจ และแยกแยะกฎเกณฑ์เชิงบรรทัดฐานจากพฤติกรรมการใช้งานที่สังเกตได้ในตัวแยกวิเคราะห์เฉพาะ
สำหรับ ToolAcre คำสั่งที่สามารถป้องกันได้คือที่เก็บข้อมูลใช้ตัวแยกวิเคราะห์และซีเรียลไลเซอร์ JavaScript ของ JSON และเพิ่มเครื่องสแกนภายในเครื่องที่เข้มงวดสำหรับการวินิจฉัยหลังจากเกิดความล้มเหลว การทดสอบค่าระดับบนสุด เครื่องหมายวรรคตอนที่มีรูปแบบไม่ถูกต้อง และการจัดการตัวเลขจะอธิบายเส้นทางนั้น ไม่ใช่แหล่งประวัติศาสตร์