JSON ไม่ใช่รูปแบบข้อมูลโครงสร้างเดียวที่มีอยู่ — YAML, CSV, XML และ TOML ต่างเกิดขึ้นจากความต้องการที่ต่างกัน และการแปลงไปมาระหว่างรูปแบบเหล่านี้เป็นงานที่พบได้บ่อย โดยเฉพาะเมื่อต้องเชื่อมระบบเก่าที่ใช้ XML เข้ากับ API แบบ JSON สมัยใหม่
แต่ละรูปแบบใช้ทำอะไร
- YAML — ใช้การเยื้องบรรทัดแทนวงเล็บปีกกา เป็นมาตรฐานของไฟล์ตั้งค่า CI/CD, Kubernetes และ Docker Compose
- CSV — แบนราบแบบตาราง เป็นตัวเลือกร่วมที่ใช้กันมากที่สุดสำหรับสเปรดชีตและเครื่องมือวิเคราะห์ข้อมูล
- XML — เก่ากว่า มี attribute และ namespace ยังคงเป็นพื้นฐานของบริการ SOAP และระบบราชการ/องค์กรรุ่นเก่าหลายแห่ง
- TOML — ออกแบบมาให้ไม่กำกวมและแก้ไขด้วยมือได้ง่าย รู้จักกันดีผ่าน
Cargo.tomlของ Rust
ปัญหาการเข้ารหัสเมื่อ CSV มีข้อความภาษาไทย
ระบบไทยเก่าจำนวนมากเคยเก็บข้อความด้วยรหัส TIS-620 แทน Unicode ทำให้ไฟล์ CSV ที่มีภาษาไทยเมื่อเปิดด้วยโปรแกรมที่ไม่รองรับ UTF-8 อาจแสดงเป็นอักขระเพี้ยน เครื่องมือนี้ส่งออก CSV เป็น UTF-8 เสมอ ดังนั้นเมื่อเปิดใน Excel ควรใช้ฟีเจอร์นำเข้าข้อมูล (Import/Get Data) แล้วระบุการเข้ารหัสเป็น UTF-8 แทนการดับเบิลคลิกเปิดไฟล์ตรง ๆ เพื่อให้สระและวรรณยุกต์ภาษาไทยแสดงผลถูกต้อง
สิ่งที่อาจสูญหายระหว่างการแปลง
ไม่ใช่ทุกการแปลงจะปลอดภัยเท่ากัน JSON → CSV จะสูญเสียโครงสร้างที่ซ้อนกัน — ออบเจกต์ที่ลึกและอาร์เรย์ที่มีความยาวต่างกันไม่สามารถใส่ลงตารางสี่เหลี่ยมได้พอดี จึงต้องทำให้แบนราบ (flatten) หรือทำให้ง่ายขึ้นก่อน ในทางกลับกัน JSON ↔ YAML และ JSON ↔ TOML มักไม่สูญเสียข้อมูลเลย เพราะทั้งสองรูปแบบรองรับโครงสร้างซ้อนแบบเดียวกับ JSON
กับดักการเดาชนิดข้อมูลอัตโนมัติใน YAML
ตัวแปลง YAML พยายามเดาชนิดของค่าที่ไม่มีเครื่องหมายคำพูด: version: 1.20 อาจกลายเป็นตัวเลข 1.2 โดยสูญเสียเลข 0 ท้ายสุด และข้อความ NO อาจกลายเป็นค่าบูลีน false ตามกฎของ YAML 1.1 ที่ถือว่า yes/no เป็นค่าบูลีน ค่าที่ต้องคงเป็นข้อความควรใส่เครื่องหมายคำพูดอย่างชัดเจนก่อนแปลงเป็น JSON
ใช้ทำอะไรในทางปฏิบัติ
- ย้ายการตั้งค่าจากเครื่องมือที่ต้องการ YAML ไปยังเครื่องมือที่ต้องการ JSON หรือกลับกัน
- ส่งออกข้อมูลจาก API เป็น CSV เพื่อดูอย่างรวดเร็วในสเปรดชีต
- เชื่อมระบบเก่าที่ใช้ XML/SOAP เข้ากับ API JSON สมัยใหม่