จัดรูปแบบ JSON

JSON—JavaScript Object Notation—เป็นรูปแบบข้อความที่แพร่หลายสำหรับการแลกเปลี่ยนข้อมูลที่มีโครงสร้าง มันถูกกำหนดมาตรฐานโดยทั้ง IETF ในชื่อ RFC 8259 และโดย Ecma International ในชื่อ ECMA-404ซึ่งร่วมกันกำหนดไวยากรณ์ที่กะทัดรัดและไม่ขึ้นอยู่กับภาษาที่ขับเคลื่อน API, บันทึก, การกำหนดค่า และฐานข้อมูลสมัยใหม่

ไวยากรณ์และการเข้ารหัส: บิตที่แม่นยำที่ทำให้ระบบสื่อสารกันได้

ค่า JSON คือ อ็อบเจกต์, อาร์เรย์, สตริง, ตัวเลข, หรือหนึ่งในค่าตามตัวอักษร true, false, หรือ null; อ็อบเจกต์จับคู่สตริงกับค่าและ อาร์เรย์เก็บค่าตามลำดับ—โดยอนุญาตให้มีช่องว่างที่ไม่สำคัญรอบๆ อักขระโครงสร้าง (RFC 8259, ECMA-404) แม้ว่า JSON จะมีต้นกำเนิดมาจาก JavaScript แต่ก็ ไม่ขึ้นอยู่กับภาษา และรองรับได้แทบทุกที่ (MDN: JSON) ในการส่งข้อมูล การเข้ารหัสโดยพฤตินัยและที่แนะนำคือ UTF-8 (RFC 8259 §8.1) เพื่อความปลอดภัยในการทำงานร่วมกันเพิ่มเติม โปรไฟล์ I-JSON (RFC 7493) จะเข้มงวดกฎเกี่ยวกับการเข้ารหัสและช่วงตัวเลข

ใน JavaScript อ็อบเจกต์ส่วนกลาง JSON เปิดเผยสองเครื่องมือหลัก:JSON.parse (พร้อม reviver ที่เป็นตัวเลือก) และ JSON.stringify (พร้อม replacer/spacing สำหรับการพิมพ์ที่สวยงาม) ตามที่บันทึกไว้ใน MDN (parse, stringify)

ตัวเลข: เรียบง่ายอย่างหลอกลวง คมชัดอย่างน่าประหลาดใจ

ไวยากรณ์ตัวเลขของ JSON เป็นทศนิยม แต่ข้อกำหนดไม่ได้กำหนดความแม่นยำหรือ ความแตกต่างระหว่างจำนวนเต็ม/จำนวนจริง การใช้งานเลือกว่าจะแสดงอย่างไร (RFC 8259 §6) ใน JavaScript และ Node.js Number คือความแม่นยำสองเท่าของ IEEE-754 ซึ่งหมายความว่าเฉพาะจำนวนเต็มในช่วง [−(2^53−1), 2^53−1] เท่านั้นที่ปลอดภัยอย่างแท้จริง—ดู Number.MAX_SAFE_INTEGER และประเภท BigIntนี่คือเหตุผลที่ API สาธารณะมักส่ง ID เป็นสตริงและตรวจสอบ "จำนวนเต็ม ที่ปลอดภัย" อย่างชัดเจน

นอกเหนือจาก JSON ธรรมดา: พอยน์เตอร์ แพตช์ และเมิร์จแพตช์

เมื่อการใช้งานเติบโตขึ้น มาตรฐานต่างๆ ก็เกิดขึ้นเพื่อ ระบุตำแหน่ง และ แก้ไข JSON ณ ที่นั้น JSON Pointer (RFC 6901) เป็นไวยากรณ์ขนาดเล็กที่คั่นด้วยเครื่องหมายทับสำหรับระบุตำแหน่งค่า (เช่น /a/b/0) พร้อมกฎการหลีกสำหรับ ~ และ / JSON Patch (RFC 6902) จำลองการอัปเดตบางส่วนเป็นการดำเนินการตามลำดับ (add, remove, replace, move, copy, test) และเดินทางเป็น application/json-patch+json สำหรับความแตกต่างที่ง่ายกว่า JSON Merge Patch (RFC 7386) ใช้การผสานรูปทรงเอกสาร: ฟิลด์ที่มีอยู่จะถูกเพิ่ม/แทนที่; การตั้งค่า ฟิลด์เป็น null จะลบมันออกไป หลายเฟรมเวิร์กรองรับรูปแบบใดรูปแบบหนึ่งหรือทั้งสอง รูปแบบตั้งแต่แกะกล่อง

สคีมาและประเภท: การตรวจสอบและการสร้าง

JSON เองไม่มีสคีมา แต่ระบบนิเวศอาศัยสคีมาสำหรับการตรวจสอบ เอกสาร และการสร้างโค้ด ตระกูล JSON Schema 2020-12 ระบุข้อจำกัดเช่น type, properties, items, และคำหลัก σύνθεσης, และสอดคล้องกับ OpenAPI 3.1สำหรับเวิร์กโฟลว์ที่เน้นการสร้างโค้ด JSON Type Definition (RFC 8927) นำเสนอภาษาที่จงใจให้แสดงออกน้อยกว่าซึ่งจับคู่กับ ระบบประเภทหลักได้อย่างคาดเดาได้

สตรีมมิ่งและข้อมูลขนาดใหญ่: JSON Lines และลำดับ

JSON แบบคลาสสิกคาดหวังข้อความที่สมบูรณ์หนึ่งข้อความต่อเพย์โหลด ซึ่งทำให้ การสตรีมบันทึกและการตอบสนองที่ยาวนานซับซ้อนขึ้น สองรูปแบบช่วยได้:

• ลำดับข้อความ JSON (RFC 7464): สตรีมของข้อความ JSON UTF-8 ซึ่งแต่ละข้อความนำหน้าด้วยตัวคั่นระเบียน (U+001E) และลงท้ายด้วย LF; ลงทะเบียนเป็น application/json-seq
• NDJSON / JSON Lines: แต่ละบรรทัดเป็นค่า JSON แบบสแตนด์อโลน— ง่ายต่อการติดตาม, gzip, และ map-reduce (ndjson.org, jsonlines.org) เป็นที่นิยมใน API จำนวนมาก เช่น Bulk APIของ Elasticsearch

ญาติไบนารี: เมื่อข้อความไม่กะทัดรัดพอ

เมื่อแบนด์วิดท์หรือความเร็วมีความสำคัญ รูปแบบ "JSON ไบนารี" จะรักษา โมเดลข้อมูลของ JSON ในขณะที่แลกเปลี่ยนความสามารถในการอ่านของมนุษย์เพื่อประสิทธิภาพ:

• BSON (รูปแบบดั้งเดิมของ MongoDB) เพิ่มประเภทเช่นไบนารี datetime, และจำนวนเต็มที่มีประเภท (bsonspec.org)
• MessagePack กะทัดรัดและไม่มีสคีมา ถูกนำไปใช้อย่างแพร่หลาย ในภาษาต่างๆ (msgpack.org)
• CBOR กำหนดมาตรฐานรูปแบบที่ขยายได้และกะทัดรัด (พร้อม คำแนะนำการแปลงรหัส JSON) และเป็นเรื่องปกติในบริบท IoT/ที่จำกัด (RFC 8949, cbor.io)
• Smile (จากระบบนิเวศของ Jackson) เข้ารหัส JSON ด้วย การอ้างอิงย้อนกลับที่เป็นตัวเลือกสำหรับชื่อ/ค่าที่ซ้ำกัน (jackson-dataformat-smile)

หมายเหตุด้านความปลอดภัย: เทคนิคเก่าและการแก้ไขที่ทันสมัย

เนื่องจาก JSON เป็นเพียงข้อความ ความเสี่ยงส่วนใหญ่มาจากการที่คุณขนส่งและ จัดการมัน:

• JSONP (การขอข้อมูลผ่าน <script> พร้อมการเรียกกลับ) เป็นวิธีแก้ปัญหาชั่วคราวก่อน CORS สำหรับคำขอข้ามแหล่งที่มาแต่ อันตราย—มันรันสคริปต์ตามอำเภอใจ ควรใช้ CORS กับการตอบสนอง application/json จริง (OWASP: การใช้ JSONP ในทางที่ผิด)
• การจี้ JSON: ปลายทาง GET ที่ไร้เดียงสาที่ส่งคืนอาร์เรย์ที่ละเอียดอ่อน อาจถูกขโมยผ่านแท็กสคริปต์ข้ามแหล่งที่มาในเบราว์เซอร์รุ่นเก่า; มาตรการลดหย่อนรวมถึง POST พร้อมการป้องกัน CSRF หรือการนำหน้าด้วย sentinel ที่ไม่ใช่ JSON (OWASP: การจี้ JSON)
• การฉีด JSON: ปฏิบัติกับ JSON เป็นข้อมูล ไม่ใช่โค้ด; หลีกเลี่ยง อย่างขยันขันแข็งและตรวจสอบอินพุต (OWASP: การฉีด JSON)

ประเภทสื่อและมรดก

JSON เปิดตัวภายใต้ RFC 4627 (2006); ประเภทสื่อที่ลงทะเบียนคือ application/jsonซึ่งข้อกำหนดตอนนี้ชี้ไปที่ RFC 8259พารามิเตอร์ "charset" ในการตอบสนอง JSON โดยทั่วไปไม่จำเป็นเพราะ UTF-8 เป็นค่าเริ่มต้นบนอินเทอร์เน็ตสาธารณะ

เคล็ดลับเชิงปฏิบัติสำหรับ JSON ที่แข็งแกร่งในการผลิต

• ใช้ UTF-8 เป็นค่าเริ่มต้นทุกที่; สมมติว่า UTF-8 ที่อินพุตและเอาต์พุต (RFC 8259 §8.1)
• ชัดเจนกับจำนวนเต็มขนาดใหญ่: หาก ID อาจเกิน 2^53−1 ให้ส่งเป็น สตริง และบันทึกไว้ (MDN: MAX_SAFE_INTEGER)
• ตรวจสอบเพย์โหลดด้วย JSON Schema 2020-12 (หรือ JTD สำหรับสแต็กที่เน้นการสร้างโค้ด) เผยแพร่สคีมาข้างเอกสาร API ของคุณ (OpenAPI 3.1)
• แพตช์อย่างชาญฉลาด: ใช้ JSON Patch สำหรับความแตกต่างระดับการดำเนินการและ Merge Patch สำหรับการอัปเดตรูปทรงเอกสารอย่างง่าย
• สตรีมในระดับใหญ่: เลือก ลำดับข้อความ JSON หรือ NDJSON สำหรับบันทึกและการตอบสนองที่ยาวนาน; ทำให้ประเภทสื่อชัดเจน
• เข้าถึงไบนารี ( BSON, MessagePack, CBOR, Smile) เมื่อข้อความเป็นคอขวด—แต่ต้องแน่ใจว่าทั้งสองฝ่ายเห็นด้วยกับประเภท

คำสั้นๆ เกี่ยวกับ "JSON ที่เป็นมิตรมากขึ้น"

นักพัฒนามักต้องการความคิดเห็น, เครื่องหมายจุลภาคต่อท้าย, หรือสตริงที่ล้อมรอบด้วยเครื่องหมายคำพูดเดี่ยว ในการกำหนดค่า นั่นอยู่นอกเหนือ JSON มาตรฐาน แต่ JSON5 ให้ชุดย่อยที่จัดทำเอกสารไว้อย่างดีสำหรับไฟล์ที่แก้ไขโดยมนุษย์ หลีกเลี่ยงการส่ง JSON5 ผ่าน API สาธารณะเว้นแต่คุณจะควบคุมทั้งสองฝ่าย

ความสำเร็จของ JSON มาจากพื้นที่ผิวขนาดเล็ก, การสนับสนุนภาษาที่กว้างขวาง, และ วงแหวนของมาตรฐานที่อยู่ติดกัน—พอยน์เตอร์, การแพตช์, สคีมา, ลำดับ—ที่ ครอบคลุมความเป็นจริงที่ยุ่งเหยิงของระบบกระจาย ทำความเข้าใจ พื้นฐาน (ไวยากรณ์, การเข้ารหัส, ตัวเลข), พึ่งพามาตรฐานที่อยู่ติดกันที่ ถูกต้อง, และมันจะยังคงให้ผลตอบแทนในสแต็กและบริการต่างๆ (RFC 8259, ECMA-404, RFC 6901, RFC 6902, RFC 7386, JSON Schema, JTD, RFC 7464, NDJSON)