แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดรูปแบบ JSON

JSON (JavaScript Object Notation) ได้กลายเป็นมาตรฐานโดยพฤตินัยสำหรับการแลกเปลี่ยนข้อมูลบน Web API ส่งคืน JSON ไฟล์กำหนดค่าใช้ JSON และแม้แต่ฐานข้อมูลก็จัดเก็บเอกสาร JSON แม้ว่า JSON จะเรียบง่าย แต่มันมีกฎไวยากรณ์ที่เข้มงวดซึ่งละเมิดได้ง่าย JSON ที่จัดรูปแบบไม่ถูกต้องนำไปสู่การดีบักที่ยาก ปัญหาประสิทธิภาพ และช่องโหว่ด้านความปลอดภัย คู่มือนี้ครอบคลุมทุกสิ่งที่คุณจำเป็นต้องรู้เกี่ยวกับการจัดรูปแบบ JSON อย่างถูกต้อง ตั้งแต่ไวยากรณ์พื้นฐานไปจนถึงหัวข้อขั้นสูงเช่นการตรวจสอบ Schema และการจัดการไฟล์ขนาดใหญ่

JSON คืออะไร?

JSON เป็นรูปแบบการแลกเปลี่ยนข้อมูลแบบข้อความที่มีน้ำหนักเบา มาจากไวยากรณ์ JavaScript Object Literal มันถูกกำหนดโดย Douglas Crockford ในช่วงต้นทศวรรษ 2000 และมาตรฐานเป็น ECMA-404 และ RFC 8259 เป้าหมายการออกแบบของ JSON คือความเรียบง่าย ความสามารถในการอ่านของมนุษย์ และความง่ายในการนำไปใช้ข้ามภาษาโปรแกรม ปัจจุบัน ภาษาโปรแกรมหลักทุกภาษามีการสนับสนุน JSON ในตัว

JSON รองรับประเภทข้อมูลหกชนิด: สตริง (Double Quote), ตัวเลข (จำนวนเต็มและทศนิยม), Boolean (true และ false), ค่า null, Object (ชุด Key-Value แบบไม่เรียงลำดับ) และ Array (รายการแบบเรียงลำดับ) มันไม่รองรับความคิดเห็น วันที่ ข้อมูลไบนารี หรือค่า undefined โดยตรง

กฎไวยากรณ์ JSON

JSON มีไวยากรณ์ที่ต้องปฏิบัติตามอย่างเคร่งครัด แม้แต่ข้อผิดพลาดอักขระเดียวก็ทำให้การ Parse เอกสารทั้งหมดล้มเหลว การเข้าใจกฎเหล่านี้สามารถป้องกันข้อผิดพลาดการจัดรูปแบบที่พบบ่อยที่สุด

สตริงต้องใช้ Double Quote

ค่าสตริงและ Object Key ทั้งหมดต้องอยู่ใน Double Quote Single Quote ไม่ใช่ตัวคั่นสตริง JSON ที่ถูกต้อง นี่เป็นหนึ่งในข้อผิดพลาดที่พบบ่อยที่สุดของนักพัฒนาที่มาจาก JavaScript ซึ่ง Single Quote และ Double Quote ใช้แทนกันได้

// Invalid - single quotes
{'name': 'Alice', 'age': 30}

// Valid - double quotes
{"name": "Alice", "age": 30}

Object Key ต้องใส่เครื่องหมายอัญประกาศ

ต่างจาก JavaScript Object Literal, JSON ต้องการให้ Object Key ทั้งหมดอยู่ใน Double Quote Key ที่ไม่มีเครื่องหมายอัญประกาศเป็นข้อผิดพลาดทางไวยากรณ์

// Invalid - unquoted keys
{name: "Alice", age: 30}

// Valid - quoted keys
{"name": "Alice", "age": 30}

ห้าม Trailing Comma

JSON ไม่อนุญาตให้มีเครื่องหมาย Comma หลังรายการสุดท้ายใน Object หรือ Array นี่เป็นข้อผิดพลาดทั่วไปอีกอย่างของนักพัฒนา JavaScript ซึ่ง Trailing Comma ได้รับอนุญาตใน JavaScript (และได้รับการสนับสนุนใน Style Guide บางฉบับ)

// Invalid - trailing comma
{
  "name": "Alice",
  "age": 30,
}

// Valid - no trailing comma
{
  "name": "Alice",
  "age": 30
}

ไม่รองรับความคิดเห็น

JSON ไม่รองรับความคิดเห็น ความคิดเห็นบรรทัดเดียว // และความคิดเห็นหลายบรรทัด /* */ ไม่ถูกต้องใน JSON หากคุณต้องการรวมเอกสาร ให้พิจารณาใช้ไฟล์เอกสารแยกต่างหากหรือรูปแบบ JSONC (JSON with Comments) ที่บางเครื่องมือรองรับ

ประเภทค่าที่เข้มงวด

ค่า JSON ต้องเป็นหนึ่งในหกประเภทที่รองรับ undefined, NaN, Infinity และ -Infinity ไม่ใช่ค่า JSON ที่ถูกต้อง การรวมค่าใดๆ เหล่านี้จะทำให้เกิดข้อผิดพลาดการ Parse หรือสร้าง JSON ที่ไม่เป็นมาตรฐานซึ่ง Parser จำนวนมากจะปฏิเสธ

ข้อผิดพลาดการจัดรูปแบบที่พบบ่อย

นอกเหนือจากข้อผิดพลาดทางไวยากรณ์ ยังมีข้อผิดพลาดการจัดรูปแบบหลายอย่างที่สร้าง JSON ที่ถูกต้องทางเทคนิคแต่มีปัญหา:

• การเยื้องที่ไม่สม่ำเสมอ: การผสม Tab และ Space หรือใช้ความลึกการเยื้องที่แตกต่างกัน ทำให้ JSON อ่านยากขึ้นในการตรวจสอบโค้ดและการเปรียบเทียบ Diff กำหนดมาตรฐานการใช้การเยื้อง 2 ช่องว่าง ซึ่งเป็นแบบแผนที่พบบ่อยที่สุด
• โครงสร้างที่ซ้อนกันลึก: JSON ที่ซ้อนเกิน 4-5 ชั้นกลายเป็นอ่านและดีบักยาก พิจารณาการทำให้โครงสร้างแบนหรือแยกเป็นเอกสารแยกต่างหาก
• ลำดับ Key ที่ไม่สม่ำเสมอ: แม้ว่า JSON Object จะไม่เรียงลำดับในทางเทคนิค แต่การรักษาลำดับ Key ที่สม่ำเสมอ (เช่น เรียงตามตัวอักษรหรือตามความสำคัญ) ทำให้การเปรียบเทียบ Diff มีความหมายมากขึ้นและลด Merge Conflict ในการควบคุมเวอร์ชัน
• บรรทัดที่ยาวเกินไป: Array ที่มีหลายรายการในบรรทัดเดียวเรียกดูยาก แบ่ง Array ยาวเป็นหลายบรรทัด หนึ่งรายการต่อบรรทัดเพื่อเพิ่มความสามารถในการอ่าน
• การจัดการ null ที่ขาดหายหรือไม่สม่ำเสมอ: ตัดสินใจว่าจะละเว้นค่า null ทั้งหมดหรือรวมอย่างชัดเจน และนำการตัดสินใจนั้นไปใช้อย่างสม่ำเสมอทั่วทั้ง API

Pretty Print กับ Minified

โหมดการจัดรูปแบบหลักสองแบบของ JSON ให้บริการวัตถุประสงค์ที่แตกต่างกัน การใช้รูปแบบที่ถูกต้องในบริบทที่เหมาะสมเป็นสิ่งสำคัญ

JSON แบบ Pretty Print

Pretty Print เพิ่มการเยื้องและอักขระขึ้นบรรทัดใหม่เพื่อทำให้ JSON อ่านได้สำหรับมนุษย์ สิ่งนี้สำคัญอย่างยิ่งระหว่างการพัฒนา การดีบัก และการเขียนเอกสาร ตัวจัดรูปแบบ JSON ส่วนใหญ่ใช้การเยื้อง 2 ช่องว่างเป็นค่าเริ่มต้น:

{
  "users": [
    {
      "id": 1,
      "name": "Alice",
      "email": "alice@example.com"
    },
    {
      "id": 2,
      "name": "Bob",
      "email": "bob@example.com"
    }
  ]
}

JSON แบบ Minified

Minified ลบช่องว่างที่ไม่จำเป็นทั้งหมด สร้าง JSON ที่ถูกต้องและเล็กที่สุดเท่าที่เป็นไปได้ สิ่งนี้สำคัญสำหรับ Production API ที่ทุกไบต์มีความหมาย:

{"users":[{"id":1,"name":"Alice","email":"alice@example.com"},{"id":2,"name":"Bob","email":"bob@example.com"}]}

เมื่อใดควรใช้แบบไหน

การตรวจสอบ JSON Schema

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

JSON Schema คืออะไร?

JSON Schema เป็นเอกสาร JSON ที่อธิบายโครงสร้างของเอกสาร JSON อื่นๆ มันช่วยให้คุณระบุฟิลด์ที่จำเป็น ประเภทที่คาดหวัง ช่วงค่า รูปแบบสตริง และโครงสร้าง Object ที่ซ้อนกัน เอกสาร JSON ที่สอดคล้องกับ Schema เรียกว่า Instance ที่ถูกต้อง

ฟีเจอร์ Schema ทั่วไป

• การตรวจสอบประเภท: ตรวจสอบให้แน่ใจว่าฟิลด์เป็นสตริง ตัวเลข Boolean Object หรือ Array
• ฟิลด์ที่จำเป็น: ระบุว่า Property ใดต้องมีอยู่
• การตรวจสอบสตริง: บังคับใช้ Pattern (Regular Expression), ความยาวต่ำสุด/สูงสุด และรูปแบบ (Email, DateTime, URI)
• การตรวจสอบตัวเลข: ตั้งค่าต่ำสุด, สูงสุด, ขอบเขตแบบ Exclusive และข้อจำกัดผลคูณ
• การตรวจสอบ Array: ควบคุมประเภทของรายการ, จำนวนรายการต่ำสุด/สูงสุด และความเป็นเอกลักษณ์
• การรวม: ใช้ allOf, anyOf, oneOf และ not สำหรับตรรกะการตรวจสอบที่ซับซ้อน

เมื่อใดควรใช้การตรวจสอบ Schema

คุณควรใช้การตรวจสอบ JSON Schema ทุกครั้งที่รับ JSON จากแหล่งภายนอก: API Request Body, ไฟล์กำหนดค่า, การนำเข้าข้อมูล และ Message Queue Payload การตรวจสอบ Schema สามารถจับข้อผิดพลาดได้ตั้งแต่เนิ่นๆ ให้ข้อความแสดงข้อผิดพลาดที่ชัดเจน และทำหน้าที่เป็นเอกสารที่มีชีวิตสำหรับรูปแบบข้อมูล ไลบรารีเช่น Ajv (JavaScript), jsonschema (Python) และ json-schema-validator (Java) ทำให้การรวมการตรวจสอบ Schema เข้ากับแอปพลิเคชันใดๆ เป็นเรื่องง่าย

ผลกระทบด้านประสิทธิภาพของขนาด JSON

ขนาดของเอกสาร JSON ส่งผลโดยตรงต่อประสิทธิภาพของแอปพลิเคชันในหลายด้าน: เวลาการส่งผ่านเครือข่าย เวลาการ Parse และการใช้หน่วยความจำ การเข้าใจผลกระทบเหล่านี้ช่วยให้คุณตัดสินใจอย่างชาญฉลาดเกี่ยวกับการจัดรูปแบบและโครงสร้าง JSON

การส่งผ่านเครือข่าย

ทุกไบต์ของ JSON ต้องถูกส่งผ่านเครือข่ายจากเซิร์ฟเวอร์ไปยังไคลเอนต์ บนการเชื่อมต่อที่รวดเร็ว ความแตกต่างระหว่าง 10KB และ 100KB อาจดูเล็กน้อย แต่สำหรับผู้ใช้บนเครือข่ายมือถือหรือในพื้นที่ที่อินเทอร์เน็ตช้ากว่า ผลกระทบนั้นมีนัยสำคัญ งานวิจัยแสดงให้เห็นว่าทุกๆ 100ms ที่เพิ่มขึ้นของเวลาโหลดลดอัตราการแปลงประมาณ 1% การบีบอัดมักลดขนาด JSON ลง 30-50% และการบีบอัด gzip ลดเพิ่มอีก 70-85% เปิดใช้การบีบอัด gzip หรือ Brotli สำหรับ JSON API Response เสมอ

ประสิทธิภาพการ Parse

การ Parse JSON มีค่าใช้จ่ายสูงอย่างน่าประหลาดใจ สำหรับเอกสารขนาดใหญ่ (เกิน 1MB) การ Parse บนอุปกรณ์มือถืออาจใช้เวลาหลายร้อยมิลลิวินาที ค่าใช้จ่ายเป็นสัดส่วนโดยประมาณกับขนาดเอกสาร กลยุทธ์สำคัญในการลดค่าใช้จ่ายการ Parse รวมถึง: ส่งเฉพาะข้อมูลที่ไคลเอนต์ต้องการ (Field Filtering), การแบ่งหน้าสำหรับชุดผลลัพธ์ขนาดใหญ่ และการใช้รูปแบบ Serialization ที่มีประสิทธิภาพมากขึ้นเช่น Protocol Buffers หรือ MessagePack สำหรับการสื่อสารระหว่างบริการภายในที่ไม่ต้องการความสามารถในการอ่านของมนุษย์

การใช้หน่วยความจำ

JSON ที่ Parse แล้วมักใช้หน่วยความจำมากกว่ารูปแบบ Serialized 3-10 เท่า เพราะแต่ละค่ากลายเป็น Object อิสระที่มีการจัดสรรหน่วยความจำของตัวเอง สตริง JSON 1MB หลัง Parse อาจใช้ RAM 5-10MB สำหรับแอปพลิเคชัน JavaScript ที่ทำงานในเบราว์เซอร์ที่มีหน่วยความจำจำกัด สิ่งนี้อาจทำให้ประสิทธิภาพลดลงหรือแครชบนอุปกรณ์ระดับล่าง

JSON กับ JSONL

JSON Lines (JSONL หรือ NDJSON) เป็นรูปแบบที่เกี่ยวข้องซึ่งแก้ไขข้อจำกัดสำคัญของ JSON: การต้อง Parse เอกสารทั้งหมดเป็นหน่วยเดียว ใน JSONL แต่ละบรรทัดของไฟล์เป็น Object JSON ที่สมบูรณ์และเป็นอิสระ

เมื่อใดควรใช้ JSONL

• ไฟล์บันทึก: แต่ละเรคคอร์ดบันทึกเป็น Object JSON แบบ Self-Contained ในบรรทัดอิสระ คุณสามารถเพิ่มเรคคอร์ดใหม่โดยไม่ต้องแก้ไขข้อมูลที่มีอยู่ และอ่านบรรทัดใดๆ ได้อย่างอิสระ
• Data Stream: ประมวลผลเมื่อเรคคอร์ดมาถึง โดยไม่ต้องรอชุดข้อมูลทั้งหมด แต่ละบรรทัดเป็นข้อความที่สมบูรณ์
• ชุดข้อมูลขนาดใหญ่: Parse และประมวลผลเรคคอร์ดทีละรายการ โดยไม่ต้องโหลดไฟล์ทั้งหมดลงในหน่วยความจำ สิ่งนี้สำคัญสำหรับชุดข้อมูลที่เกิน RAM ที่มีอยู่
• การประมวลผลแบบขนาน: แบ่งไฟล์ JSONL ที่ขอบเขตบรรทัดและแจกจ่ายส่วนให้ Worker Thread ต่างๆ สิ่งนี้เป็นไปไม่ได้สำหรับ JSON มาตรฐาน เพราะการแบ่งที่ตำแหน่งไบต์ตามอำเภอใจจะทำลายโครงสร้าง

เมื่อใดควรใช้ JSON มาตรฐาน

• API Response: JSON มาตรฐานเป็นรูปแบบที่คาดหวังสำหรับ REST API การห่อผลลัพธ์ใน Array หรือ Object เป็นแนวทางปกติและคาดหวัง
• ไฟล์กำหนดค่า: การกำหนดค่ามักต้องโหลดครั้งเดียว ดังนั้นข้อได้เปรียบด้าน Streaming ของ JSONL จึงไม่สำคัญ
• โครงสร้างข้อมูลแบบซ้อน: หากข้อมูลของคุณมีการซ้อนที่ซับซ้อนซึ่งไม่สามารถทำให้แบนเป็นเรคคอร์ดแยกได้ง่าย JSON มาตรฐานเป็นธรรมชาติมากกว่า

การจัดการไฟล์ JSON ขนาดใหญ่

ไฟล์ JSON ขนาดใหญ่ (เกิน 10MB) นำเสนอความท้าทายที่ไม่ซ้ำใครซึ่งต้องการการจัดการพิเศษ วิธีการ Parse มาตรฐานอาจล้มเหลวหรือมีประสิทธิภาพไม่ดีในขนาดนี้

Streaming Parser

Streaming Parser (หรือแบบ SAX) ประมวลผล JSON แบบเพิ่มขึ้น โดยไม่ต้องโหลดเอกสารทั้งหมดลงในหน่วยความจำ มันส่ง Event เมื่อพบองค์ประกอบโครงสร้าง (เช่น การเริ่ม Object, Key-Value Pair และ Array Item) วิธีการนี้ใช้หน่วยความจำคงที่โดยไม่คำนึงถึงขนาดไฟล์ ไลบรารีเช่น oboe.js (JavaScript), ijson (Python) และ Jackson Streaming API (Java) ให้การ Parse JSON แบบ Streaming

เคล็ดลับการใช้งานสำหรับไฟล์ขนาดใหญ่

• แปลงเป็น JSONL ก่อน: หากคุณมี JSON Array ขนาดใหญ่ การแปลงเป็น JSONL (หนึ่ง Object ต่อบรรทัด) ช่วยให้สามารถประมวลผลทีละบรรทัดด้วยเครื่องมือมาตรฐานเช่น grep, awk และ jq
• ใช้เครื่องมือ Command Line: jq เป็นเครื่องมือมาตรฐานสำหรับการประมวลผล JSON จาก Command Line มันสามารถจัดการไฟล์ขนาดใหญ่ได้อย่างมีประสิทธิภาพและรองรับโหมด Streaming สำหรับอินพุตขนาดใหญ่มาก
• แบ่งและประมวลผลแบบขนาน: แบ่งไฟล์ JSONL ขนาดใหญ่ออกเป็นส่วนย่อยและประมวลผลแบบขนาน แต่ละส่วนสามารถประมวลผลได้อย่างอิสระ เพราะแต่ละบรรทัดเป็น Self-Contained
• หลีกเลี่ยงการโหลดลงในหน่วยความจำ: อย่าใช้ JSON.parse() กับไฟล์ที่ใหญ่กว่าหน่วยความจำที่มีอยู่ ใช้ Streaming Parser หรือประมวลผลไฟล์ทีละบรรทัด
• การจัดเก็บแบบบีบอัด: ไฟล์ JSON ขนาดใหญ่บีบอัดด้วย gzip ได้ดีมาก (มักลดลง 80-90%) เก็บสำเนาที่บีบอัดไว้สำหรับการจัดเก็บ และคลายการบีบอัดทันทีระหว่างการประมวลผล

ข้อควรระวังด้านความปลอดภัยของ JSON

แม้ว่า JSON จะเป็นรูปแบบข้อมูลและไม่ใช่สิ่งที่ไม่ปลอดภัยในตัวเอง แต่วิธีที่แอปพลิเคชันจัดการ JSON อาจนำไปสู่ช่องโหว่ การเข้าใจความเสี่ยงเหล่านี้เป็นสิ่งสำคัญสำหรับการสร้างระบบที่ปลอดภัย

อย่าใช้ eval() เพื่อ Parse JSON

กฎความปลอดภัยที่สำคัญที่สุด: อย่าใช้ฟังก์ชัน eval() ของ JavaScript เพื่อ Parse JSON eval() เรียกใช้โค้ด JavaScript ตามอำเภอใจ ซึ่งหมายความว่า JSON Payload ที่เป็นอันตรายสามารถรันโค้ดบนเครื่องของผู้ใช้ได้ ใช้ JSON.parse() เสมอ ซึ่ง Parse เฉพาะ JSON ที่ถูกต้องและปฏิเสธโค้ดที่เรียกทำงานได้ใดๆ นี่เป็นสิ่งที่ต่อรองไม่ได้

JSONP และความเสี่ยง Cross-Domain

JSONP (JSON with Padding) เป็นเทคนิคที่ใช้บายพาสข้อจำกัด Same-Origin Policy ก่อนที่ CORS จะได้รับการสนับสนุนอย่างกว้างขวาง มันทำงานโดยการห่อข้อมูล JSON ในการเรียกใช้ฟังก์ชันที่ทำงานเป็นสคริปต์ สิ่งนี้เป็นอันตรายโดยธรรมชาติเพราะมันเรียกใช้ JavaScript ตามอำเภอใจจากเซิร์ฟเวอร์บุคคลที่สาม หากคุณควบคุมทั้งไคลเอนต์และเซิร์ฟเวอร์ ให้ใช้ CORS แทน JSONP ควรถือว่า JSONP เป็นเทคโนโลยีเดิมและควรหลีกเลี่ยงในแอปพลิเคชันใหม่

Prototype Pollution

เมื่อ Merge หรือ Deep Copy JSON Object ใน JavaScript ระวัง Key เช่น __proto__, constructor และ prototype หาก JSON ที่ผู้ใช้ให้มาถูก Merge แบบ Recursive ลงใน Object ที่มีอยู่โดยไม่ทำความสะอาด Key เหล่านี้ มันสามารถแก้ไข Prototype ของ Object ทั้งหมดในแอปพลิเคชัน นำไปสู่การยกระดับสิทธิ์หรือ Denial of Service ทำความสะอาด Object Key ก่อน Merge เสมอ

Denial of Service ผ่านการซ้อนความลึก

เอกสาร JSON ที่สร้างขึ้นอย่างพิถีพิถันที่มีความลึกการซ้อนมาก (หลายพันชั้น) อาจทำให้เกิด Stack Overflow Error ใน Recursive Parser บรรเทาปัญหานี้โดยการตั้งค่าความลึกการซ้อนสูงสุดใน Parser Parser JSON สำหรับ Production ส่วนใหญ่อนุญาตให้คุณกำหนดค่าขีดจำกัดนี้

การตรวจสอบความถูกต้องของข้อมูลเข้า

อย่าไว้วางใจข้อมูล JSON จากแหล่งภายนอก ตรวจสอบโครงสร้าง ประเภท และช่วงค่าของ JSON ที่เข้ามาก่อนใช้งานเสมอ การตรวจสอบ JSON Schema เป็นวิธีที่แข็งแกร่งที่สุด แต่แม้แต่การตรวจสอบฟิลด์ที่จำเป็นและ Type Assertion ง่ายๆ ก็สามารถให้การป้องกันที่สำคัญต่ออินพุตที่ผิดรูปแบบหรือเป็นอันตราย