เปรียบเทียบไลบรารีสำหรับ Parse และประมวลผล JSON

สรุปสั้น: จำแนกความต้องการก่อน แล้วจึงเปรียบเทียบ implementation — ใช้ JSON.parse พื้นเมืองสำหรับค่าที่อ่านอย่างเดียว ใช้ jsonc-parser เมื่อต้องการ offset หรือต้องรักษาการจัดรูปแบบเดิม และเพิ่มไลบรารี query หรือ patch เฉพาะจุดที่จำเป็น; lazy-load ไลบรารีขนาดใหญ่ทีละหน้า และตัดไลบรารีที่ไม่มีการดูแลออก

ทุกไลบรารีอ้างว่าตัวเอง "เร็ว เล็ก และครบถ้วน" สิ่งที่แยกมันออกจากกันจริง ๆ คือข้อมูลมากแค่ไหนที่มันให้คุณได้เมื่อเกิดเรื่องผิดพลาด

1. สี่หมวดตามจุดประสงค์

ระบุให้ได้ก่อนว่าคุณอยู่ในหมวดไหน แล้วจึงเปรียบเทียบ implementation เจาะจง ไม่อย่างนั้น легкоใช้ไลบรารี query ไปทำงานของ parser

2. เปรียบเทียบเคียงข้างกัน

ข้อความ error ของ JSON.parse แตกต่างกันมากระหว่างเอนจิน V8 ให้อะไรทำนอง Unexpected token } in JSON at position 42 แต่ตำแหน่งแม่นยำหรือไม่ขึ้นกับเวอร์ชันของเอนจิน; jsonc-parser กลับคืน { error, offset, length } แบบมีโครงสร้างที่เสถียร ซึ่งเหมาะกับ marker ใน editor

3. จุดตัดสินใจสำคัญสี่ข้อ

3.1 ต้องการ offset หรือไม่

หากคุณกำลังสร้าง editor และต้องการให้ "คลิกที่ error เพื่อกระโดดไปยังบรรทัดที่เกี่ยวข้อง" คุณต้องมี offset การทดสอบง่ายมาก: ถ้าข้อความ error ของคุณพิมพ์ได้เพียง "invalid JSON" ผู้ใช้จะต้องไปตามหาเอง

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}

3.2 ต้องรักษาข้อความต้นฉบับหรือไม่

อ่านค่าอย่างเดียว → parser ไหนก็ได้ "เปลี่ยนฟิลด์หนึ่งและคงที่เหลือไว้ทุกอย่างเหมือนเดิม" → ต้องใช้ API สไตล์แก้ไข ไม่ใช่ "parse → เปลี่ยน object → serialize"

วิธีหลังสูญเสีย: comment, ลำดับคีย์ (ในบาง implementation), สไตล์การย่อหน้า, การเขียนจำนวนแบบ literal (1e3 กลายเป็น 1000) และรูปแบบ escape (\u4e2d กลายเป็นอักขระจริง)

3.3 พฤติกรรมขอบชัดเจนหรือไม่

ก่อนเลือกไลบรารี ให้ตรวจเอกสารสามเรื่อง:

1. คีย์ซ้ำถูกจัดการอย่างไร (เก็บตัวหลัง / โยน error);
2. จำนวนเต็มขนาดใหญ่สูญเสียความแม่นยำหรือไม่ (ไลบรารี JS ส่วนใหญ่สูญเสีย เพราะผ่าน Number ทั้งหมด);
3. ขอบเขตที่รองรับสำหรับ BOM, comment และ trailing comma

หากไม่มีเอกสาร ให้เขียนตัวอย่างเล็ก ๆ แล้วทดสอบเอง ซึ่งเชื่อถือได้มากกว่าการอ่าน README

3.4 สถานะการดูแลรักษา

ความเสี่ยงของไลบรารี JSON ไม่ใช่ฟีเจอร์ที่ขาด แต่คือ การถูกละเลยในระยะยาว: จะไม่มีใครออก security patch (prototype pollution, ReDoS) อีกต่อไป

4. เปรียบเทียบกับภาษาอื่น

เมื่อแลกเปลี่ยนข้อมูลข้ามภาษา สิ่งที่สะดุดง่ายที่สุดยังคงเป็นความแม่นยำของจำนวนและรูปแบบเวลา การเลือกไลบรารีช่วยบรรเทาได้เท่านั้น ไม่สามารถกำจัดได้

5. ชุดค่าผสมทั่วไป

ตัวเลือกที่ 1: เว็บยูทิลิตี้ (ฝั่ง browser)

复制Parsing and error location: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Query: jsonpath-plus
Patch: fast-json-patch
Share links: lz-string

ลักษณะเด่นของชุดนี้คือ ทุกอย่างรันในเครื่องและไม่มีข้อมูลถูกอัปโหลด ซึ่งสอดคล้องกับความคาดหวังด้านความเป็นส่วนตัวของเว็บยูทิลิตี้

ตัวเลือกที่ 2: API gateway ฝั่งเซิร์ฟเวอร์

复制Validation: Ajv (compile the schema once, reuse it)
Parsing: native JSON.parse (together with a body size limit)
Deferred parsing of large fields: keep the raw string, parse only when needed

อย่านำไลบรารี query/patch เข้าชั้น gateway เพื่อ implement ตรรกะธุรกิจ — นั่นคืองานของชั้นธุรกิจ

ตัวเลือกที่ 3: CLI และสคริปต์

复制Pick fields: jq
Format conversion: yq / dasel
Interactive browsing: jless
Batch validation: ajv-cli

6. ผลกระทบจริงของขนาด bundle และประสิทธิภาพ

• jsonc-parser เล็กมากและเหมาะกับ bundle หลัก;
• json5 ใหญ่กว่า jsonc-parser เล็กน้อยเพราะรองรับไวยากรณ์มากกว่า;
• jsonpath-plus มีการประเมิน expression รวมอยู่ด้วยและใหญ่ขึ้นอย่างชัดเจน จึงควร lazy-load ทีละหน้า;
• fast-json-patch ขนาดกลาง และจำเป็นเฉพาะเมื่อคุณมีฟีเจอร์เปรียบเทียบ

กลยุทธ์ปรับแต่งนั้นตรงไปตรงมา: import แบบ dynamic ทีละหน้า และอย่าใส่มันใน chunk ของหน้าจอแรก

复制const { JSONPath } = await import('jsonpath-plus');

7. รายการตรวจสอบ

• [ ] เลือกไลบรารีตามจุดประสงค์ อย่าใช้ไลบรารี query ในการ parse;
• [ ] ใช้ jsonc-parser เมื่อต้องการตำแหน่ง error ที่แม่นยำ;
• [ ] ใช้ API สไตล์แก้ไขเมื่อต้องรักษา comment และการจัดรูปแบบ;
• [ ] ทดสอบพฤติกรรมขอบสามข้อในทางปฏิบัติ: คีย์ซ้ำ, จำนวนเต็มขนาดใหญ่ และ BOM;
• [ ] จับตาสถานะการดูแลรักษาและ security advisory ของไลบรารี;
• [ ] import ไลบรารีขนาดใหญ่แบบ dynamic ตามต้องการ

คำถามที่พบบ่อย

จะเลือกไลบรารี JSON ตามขนาดโปรเจกต์อย่างไร?

เครื่องมือเล็กที่อ่านข้อมูล API อย่างเดียวใช้ JSON.parse พื้นเมืองได้ โปรเจกต์ที่ต้องการตำแหน่ง error ระดับ editor หรือต้องรักษาการจัดรูปแบบเดิมควรใช้ jsonc-parser API gateway ฝั่งเซิร์ฟเวอร์ต้องการเพียงการตรวจสอบและการ parse โดยปล่อยไลบรารี query และ patch ให้ชั้นธุรกิจ ส่วนสคริปต์ CLI ใช้ jq, yq และ ajv-cli ได้โดยตรง

ทำไมสถานะการดูแลรักษาจึงสำคัญกว่าจำนวนฟีเจอร์?

ความเสี่ยงจริงของไลบรารี JSON คือการถูกละเลยในระยะยาว ไม่ใช่ฟีเจอร์ที่ขาด: จะไม่มีใครออก security patch สำหรับ prototype pollution หรือ ReDoS ให้ ต่อให้รายการฟีเจอร์ครบถ้วนเพียงใด ไลบรารีที่หยุดพัฒนาแล้วก็ทำให้คุณต้อง patch เอง ให้ถือการดูแลรักษาและ security advisory เป็นเกณฑ์แข็ง แทนการเทียบตารางฟีเจอร์

ควรใช้ JSON.parse เพื่อเปลี่ยนฟิลด์เดียวและเก็บ comment กับการย่อหน้าไว้หรือไม่?

ไม่ การ parse แล้วเปลี่ยน object แล้ว serialize สูญเสีย comment, ลำดับคีย์, สไตล์การย่อหน้า, การเขียนจำนวนแบบ literal (1e3 กลายเป็น 1000) และรูปแบบ escape (\u4e2d กลายเป็นอักขระจริง) การเปลี่ยนฟิลด์เดียวโดยคงที่เหลือไว้ครบต้องใช้ API สไตล์แก้ไข เช่น modify และ applyEdits ใน jsonc-parser