ตัวตรวจสอบความถูกต้อง JSON
ตรวจสอบว่าข้อความเป็นไปตามไวยากรณ์ JSON มาตรฐานหรือไม่ และเข้าใจสาเหตุที่ input ถูกยอมรับหรือปฏิเสธ
ตรวจสอบ JSON ก่อนใช้ข้อมูล
เครื่องหมายคำพูด comma หรือ bracket ที่หายไปเพียงหนึ่งตำแหน่งอาจทำให้ API configuration หรือ build step หยุดทำงาน validator นี้จะพยายาม parse source text เป็น JSON เพื่อแยกปัญหา syntax ออกจาก application validation ในขั้นถัดไป
Validation ที่นี่หมายถึงการลอง parse text เป็น JSON value หนึ่งค่าเท่านั้น การ parse สำเร็จบอกว่าโครงสร้างถูกยอมรับโดย JSON แต่ไม่ได้ยืนยัน required field business rule หรือ JSON Schema
เมื่อ payload เดินทางระหว่าง service การตรวจ syntax ก่อนจะช่วยจำกัดขอบเขต debugging ให้แคบลง ให้ตรวจ quote comma escape และ nesting ก่อน แล้วจึงตรวจ schema และ domain rule ของ project
ใช้หน้านี้ตรวจ request body fixture การตั้งค่าที่ export หรือ configuration snippet ลบ token password และข้อมูลส่วนตัวออกจาก test copy และปฏิบัติตาม privacy policy ขององค์กร
Syntax ไม่ใช่ความหมายของข้อมูล
JSON มาตรฐานประกอบด้วย object array string number true false และ null ชื่อ property และ string ใช้ double quote สมาชิกคั่นด้วย comma และ bracket ต้องปิดตามลำดับที่ถูกต้อง comment และ trailing comma ไม่อยู่ใน JSON grammar มาตรฐาน
คำถามของ validator มีเพียงว่า source สามารถ parse เป็น JSON value เดียวได้หรือไม่ tool ไม่ซ่อม source ไม่รัน code ไม่เรียก API และไม่ตัดสินว่า value มีความหมายต่อ application หรือไม่ แยก schema และ domain check ออกต่างหาก
Whitespace มักใช้เพื่อความอ่านง่ายได้ แต่ character ภายใน string เป็นข้อมูล ให้ตรวจ escape sequence newline Unicode และ encoding ด้วย parser เดียวกับที่ production consumer ใช้
JSON document ที่ valid ไม่ได้ทำให้ transport valid โดยอัตโนมัติ HTTP header content type authentication compression และ size limit เป็นคนละ layer
วิธีตรวจ JSON
- วาง JSON value ที่สมบูรณ์หนึ่งค่าใน source field ลบ comment code fence และ programming language wrapper ออกจาก test copy
- เรียกใช้ validator แล้วอ่าน status และ diagnostic ตรวจ token ก่อนและหลัง marker ด้วย เพราะสาเหตุจริงอาจอยู่ก่อนตำแหน่งที่แสดง
- ถ้าถูกปฏิเสธให้ตรวจ quote comma bracket escape และ nesting document ขนาดใหญ่ควรแยกเป็นส่วนเล็กเพื่อหา failing section แล้วส่งฉบับแก้ไขใหม่
- เมื่อ syntax ผ่านแล้วให้ตรวจ schema type required property range permission และ business rule ของ project อย่ารายงานผลเหล่านี้เป็น syntax result
- เก็บ original payload และ redacted copy แยกกัน อย่าใส่ secret ใน public example screenshot หรือ URL
- ทำ integration test ด้วย parser และ encoding เดียวกับ consumer จริง language หรือ library ต่างกันอาจจัดการ duplicate key และ number precision ต่างกัน
วิธีการ validation
- อ่าน grammar
Validator ใช้กฎ token quote delimiter และ nesting เพื่อพยายาม parse source ทั้งหมดเป็น JSON value เดียว
- รายงานผล
Valid หมายถึง parsing เสร็จสมบูรณ์ Failure หมายถึง source ไม่ตรงกับ syntax ที่ tool เข้าใจ
- แยกการตรวจขั้นต่อไป
Schema range permission และ domain เป็น semantic check ต้องใช้กฎและ evidence แยกกัน
ถ้า tool ไม่ได้บันทึก exact line number หรือ error message อย่าแต่งข้อมูลขึ้นเอง หากจำเป็นให้ตรวจซ้ำใน runtime จริง
อ่านผลลัพธ์
Valid หมายถึง text ถูกยอมรับเป็น JSON syntax จากนั้นตรวจ value และเรียก schema หรือ application validation
Invalid หมายถึง parsing หยุดลง ตรวจ character ก่อนและหลังตำแหน่งที่ระบุ ไม่ใช่แก้เฉพาะ marker
ถ้า syntax valid แต่ request ล้มเหลวให้ตรวจ content type endpoint authentication schema และ business rule syntax success ไม่เท่ากับ network success
ถ้า message กว้างเกินไปให้ลด input เพื่อหา failing section การเพิ่มหรือลบ property แล้วผลเปลี่ยนเป็นเพียงเบาะแส ไม่ใช่ policy สากลของ parser ทุกชนิด
ข้อผิดพลาดที่พบบ่อย
การวาง JavaScript ที่มี single quote comment หรือ trailing comma เป็นความผิดพลาดทั่วไป ให้แปลงเป็น standard JSON
อย่าคิดว่า valid result คือ schema validation ตรวจ required field range และ permission แยกกัน
การแก้ character ตรง error marker อาจไม่พอ เพราะ quote หรือ comma ที่หายไปอาจอยู่ก่อนหน้านั้น
อย่าเหมารวม JSON กับ Python dictionary YAML หรือ JavaScript object ใช้ documented JSON grammar
Clipboard อาจนำ smart quote หรือ control character ที่ซ่อนอยู่มา หากผลต่างกันให้ดู source ใน plain text editor
ข้อจำกัด
Input ที่ document คือ JSON text field หนึ่งช่อง ไม่ได้พิสูจน์ว่ารองรับ JSON Schema business rule file processing หรือ parser edge case ทุกแบบ
Duplicate key number ที่ใหญ่มาก document size และ encoding ควร test แยกเมื่อจำเป็น policy อาจต่างกันตาม library
Checker ไม่ทำให้ malicious payload ปลอดภัยขึ้น Server ยังต้องมี size limit nesting limit resource limit และ security review
บันทึก production runtime library version และ error policy แยกต่างหาก ผลทั่วไปจากหน้านี้แทน evidence เหล่านั้นไม่ได้
Examples
ยอมรับ object ง่าย ๆ
object พื้นฐานนี้เป็น valid JSON หรือไม่
ส่ง object ทั้งหมด
ชื่อที่มี double quote string และ boolean รวมกันเป็น valid object structure
ปฏิเสธชื่อที่ไม่มี quote
ทำไม unquoted property name จึง invalid
ส่ง source แล้วอ่าน failure
ใน JSON มาตรฐาน member name ต้องเป็น string ที่อยู่ใน double quote
ยอมรับข้อมูลซ้อนกัน
object สามารถมี array ของ object ได้หรือไม่
ส่ง nested value เป็น document เดียว
Array object number comma และ bracket สร้าง JSON structure ที่ valid
ปฏิเสธ trailing comma
comma หลัง member สุดท้ายทำให้เกิดอะไร
ส่ง object ที่มี trailing comma
JSON มาตรฐานไม่อนุญาต trailing comma ลบ comma แล้วตรวจอีกครั้ง
ใช้ค่า null
null เป็น valid JSON value หรือไม่
ส่ง object แล้วอ่าน status
null เป็น JSON value มาตรฐาน ความหมายใน application ขึ้นกับ contract
ปฏิเสธ bracket ที่หายไป
ทำไม opening bracket ต้องปิด
ส่ง structure ที่ไม่สมดุล
Array เปิดด้วย [ แต่ไม่ได้ปิดด้วย ] แก้ nesting ก่อนใช้ data
Frequently asked questions
Valid JSON หมายความว่า application data valid ด้วยหรือไม่
ไม่ หมายถึง text parse ได้เท่านั้น Required field type range status และ business rule ต้องตรวจแยก
Validator ซ่อม source อัตโนมัติหรือไม่
ใช้เป็น checker แก้ source ด้วยตัวเอง เก็บ diff แล้วส่ง copy ที่ตรวจแล้วอีกครั้ง
ใช้ comment ได้หรือไม่
JSON มาตรฐานไม่มี comment หากต้องการคำอธิบายให้เก็บใน source format อื่น สร้าง strict JSON ใน build step แล้ว validate output
ทำไม single quote จึงถูกปฏิเสธ
ชื่อและ string ใน JSON มาตรฐานใช้ double quote ใช้ JSON serializer แทนการเปลี่ยน quote ด้วยมือ
Tool นี้ตรวจ JSON Schema หรือไม่
ไม่ ให้ใช้ schema validator ที่มี schema และ draft version ถูกต้อง แล้วบันทึกผลแยกจาก syntax result
Top-level value เป็น array ได้หรือไม่
JSON อนุญาต array เป็น top-level value แต่ endpoint อาจต้องการ object จึงต้อง test endpoint contract แยก
Duplicate key ถูกปฏิเสธเสมอหรือไม่
ไม่มี policy สากล Parser อาจเก็บค่าแรก ค่าสุดท้าย หรือแจ้ง error หลีกเลี่ยง duplicate name และทดสอบ consumer จริง
หลัง validation ผ่านควรทำอะไร
เรียก schema permission range และ integration test ตรวจ content type encoding size timeout logging แล้วทดสอบ redacted payload ใน staging