วิศวกร DevOps ส่งออกคอนฟิก Kubernetes เป็น YAML แต่ต้องส่งไปยัง API ที่รับเฉพาะ JSON นักวิเคราะห์ได้รับข้อมูลตอบกลับ API เป็น JSON แต่ต้องการในสเปรดชีต นักวิทยาศาสตร์ข้อมูลส่งออก CSV จากฐานข้อมูลแต่ต้องการ JSON ที่มีโครงสร้างสำหรับแดชบอร์ดเว็บ
การแปลงรูปแบบไม่ใช่แค่การดำเนินการทางกลไก แต่ละรูปแบบมีข้อแลกเปลี่ยนที่แตกต่างกัน และการเข้าใจ สิ่งที่สูญหายในการแปลง สำคัญพอ ๆ กับการรู้วิธีแปลง
สามรูปแบบ สามปรัชญา
แต่ละรูปแบบถูกออกแบบมาสำหรับกลุ่มเป้าหมายและปัญหาที่แตกต่างกัน:
| รูปแบบ | เกิด | ออกแบบสำหรับ | ปรัชญาหลัก |
|---|---|---|---|
| CSV | ~1972 | แลกเปลี่ยนข้อมูลระหว่างโปรแกรม | ความเรียบง่ายสูงสุด — แค่แถวกับคอลัมน์ |
| JSON | 2001 | แลกเปลี่ยนข้อมูลเว็บ | ข้อมูลมีโครงสร้างที่เครื่องอ่านได้พร้อมกฎเข้มงวด |
| YAML | 2001 | ไฟล์คอนฟิก | ข้อมูลมีโครงสร้างที่คนอ่านได้พร้อมไวยากรณ์น้อยที่สุด |
CSV สมมติว่าข้อมูลของคุณเป็นตารางแบน ทุกค่าเป็นสตริง ไม่มีแนวคิดเรื่องการซ้อน ประเภท หรือ metadata
JSON สมมติว่าข้อมูลมีโครงสร้าง — ออบเจ็กต์ อาร์เรย์ ประเภท (สตริง ตัวเลข บูลีน null) เข้มงวดและชัดเจน เหมาะสำหรับเครื่องแต่ยาวสำหรับคน
YAML สมมติว่าคนจะอ่านและแก้ไขไฟล์ ใช้การย่อหน้าแทนวงเล็บปีกกา รองรับคอมเมนต์ และมีไวยากรณ์ที่ผ่อนคลายกว่า ในทางเทคนิค YAML เป็น superset ของ JSON — เอกสาร JSON ที่ถูกต้องทุกฉบับก็เป็น YAML ที่ถูกต้องเช่นกัน
YAML เป็น superset ของ JSON คุณสามารถวางเอกสาร JSON ลงใน parser YAML โดยตรงแล้วมันจะทำงานได้ แต่กลับกันไม่ได้ — ฟีเจอร์ YAML เช่น คอมเมนต์ anchor และสตริงหลายบรรทัดไม่มีตัวเทียบเท่าใน JSON
สถานการณ์การแปลงในโลกจริง
การย้ายคอนฟิก (JSON เป็น YAML, YAML เป็น JSON)
นี่คือการแปลงที่พบบ่อยที่สุด เครื่องมือต่าง ๆ คาดหวังรูปแบบคอนฟิกที่ต่างกัน:
- Docker Compose, Kubernetes, GitHub Actions, Ansible ใช้ YAML
- package.json, tsconfig.json, ESLint ใช้ JSON
- การย้ายระหว่างเครื่องมือมักหมายถึงการแปลงคอนฟิก
การแปลงนี้ ไม่สูญเสียข้อมูลทั้งสองทาง สำหรับเนื้อหาข้อมูล — แต่คอมเมนต์ YAML หายไปเมื่อแปลงเป็น JSON เพราะ JSON ไม่มีไวยากรณ์คอมเมนต์
การวิเคราะห์ข้อมูล (JSON เป็น CSV)
การตอบกลับ API มาเป็น JSON นักวิเคราะห์ต้องการสเปรดชีต การแปลงนี้ทำงานได้ดีสำหรับ อาร์เรย์ JSON แบน — อาร์เรย์ของออบเจ็กต์ที่มีคีย์เหมือนกันจับคู่กับแถวและคอลัมน์ได้อย่างเป็นธรรมชาติ
แต่พังกับ ข้อมูลซ้อน ออบเจ็กต์ JSON ที่มีฟิลด์ address.city และอาร์เรย์ skills ไม่มีการแสดง CSV ตามธรรมชาติ ตัวแปลงต้องเลือก: แบนคีย์ซ้อน แปลงค่าซ้อนเป็นสตริง หรือทิ้ง
นำเข้าข้อมูล (CSV เป็น JSON)
สถานการณ์กลับกัน: นำเข้าข้อมูลสเปรดชีตเข้าแอปเว็บหรือ API การแปลง CSV เป็น JSON สร้างอาร์เรย์ของออบเจ็กต์ โดยมีหัวคอลัมน์เป็นคีย์ ปัญหาคือ CSV ไม่มีข้อมูลประเภท — ตัวเลข 42 สตริง "42" และบูลีน true ล้วนเป็นแค่ข้อความใน CSV ตัวแปลงต้องเดาประเภท
ความสามารถอ่านได้ของคน (JSON เป็น YAML)
บางครั้งคุณแค่ต้องทำให้ไฟล์คอนฟิก JSON ที่หนาแน่นอ่านได้ การแปลงเป็น YAML ให้การย่อหน้าที่สะอาดและความสามารถในการเพิ่มคอมเมนต์สำหรับเอกสาร สิ่งนี้มีค่าเป็นพิเศษสำหรับ ไฟล์คอนฟิกขนาดใหญ่ ที่ทีมจะดูแล
สิ่งที่สูญหายในการแปลง
นี่คือความรู้สำคัญที่ช่วยประหยัดเวลาดีบัก:
| การแปลง | สิ่งที่สูญหาย |
|---|---|
| YAML เป็น JSON | คอมเมนต์ (JSON ไม่มีไวยากรณ์คอมเมนต์) |
| JSON เป็น CSV | การซ้อน (CSV แบน), ประเภท (ทุกอย่างเป็นข้อความ), อาร์เรย์ |
| CSV เป็น JSON | ไม่มี (แต่ประเภทต้องอนุมาน — "42" vs 42) |
| CSV เป็น YAML | ไม่มี (ปัญหาการอนุมานประเภทเดียวกัน) |
| JSON เป็น YAML | ไม่มี (YAML เป็น superset ของ JSON) |
| YAML เป็น CSV | คอมเมนต์, การซ้อน, ประเภท, anchor/alias |
รูปแบบชัดเจน: การแปลง ไปยัง CSV สูญเสียข้อมูลมากที่สุด เพราะ CSV เป็นรูปแบบที่ง่ายที่สุด การแปลง ระหว่าง JSON กับ YAML แทบไม่สูญเสีย และ คอมเมนต์ YAML สูญหายเสมอเมื่อออกจาก YAML
สองทาง vs ทางเดียว JSON-เป็น-YAML และ YAML-เป็น-JSON เป็นสองทางอย่างมีประสิทธิภาพ (ไป-กลับปลอดภัย ยกเว้นคอมเมนต์) JSON-เป็น-CSV และ YAML-เป็น-CSV เป็นทางเดียวสำหรับข้อมูลซับซ้อน — คุณไม่สามารถสร้างการซ้อนขึ้นใหม่จาก CSV แบน
ข้อผิดพลาดที่พบบ่อยเมื่อแปลง
กับดักการบีบบังคับประเภทของ YAML
YAML ตีความสตริงบางอย่างเป็นประเภทที่ไม่ใช่สตริงโดยอัตโนมัติ คำว่า no กลายเป็นบูลีน false คำว่า yes กลายเป็น true สตริง 1.0 กลายเป็น float รหัสประเทศเช่น NO (นอร์เวย์) มีชื่อเสียงว่าก่อให้เกิดบัก ใส่เครื่องหมายอัญประกาศรอบค่าที่คลุมเครือ ใน YAML เสมอ
ความสับสนเรื่อง delimiter และ encoding ของ CSV
CSV ไม่ได้ใช้คอมม่าทั้งหมด CSV ยุโรปมักใช้เซมิโคลอน (เพราะคอมม่าเป็นตัวคั่นทศนิยมในรูปแบบตัวเลขยุโรปหลายแบบ) ค่าที่คั่นด้วยแท็บ (TSV) เป็นอีกรูปแบบหนึ่ง และการไม่ตรงกันของ character encoding (UTF-8 vs Latin-1) ทำให้ตัวอักษรที่มีเครื่องหมายเพี้ยน
ปัญหา trailing comma ของ JSON
JSON ไม่อนุญาต trailing comma นี่คือ JavaScript ที่ถูกต้อง: {"a": 1, "b": 2,} — แต่เป็น JSON ที่ไม่ถูกต้อง trailing comma ตัวเดียวทำให้เกิดข้อผิดพลาดในการแยกวิเคราะห์
ประสิทธิภาพของชุดข้อมูลขนาดใหญ่
สำหรับชุดข้อมูลหลายล้านแถว CSV มีประสิทธิภาพมากกว่า JSON หรือ YAML อย่างมาก JSON เพิ่มวงเล็บปีกกา วงเล็บเหลี่ยม และเครื่องหมายอัญประกาศสำหรับทุกค่า CSV 1 ล้านแถวอาจเป็น 50 MB; JSON ที่เทียบเท่าอาจเป็น 150 MB
เลือกรูปแบบที่ถูกต้องตั้งแต่เริ่ม
แทนที่จะแปลงทีหลัง การเลือกรูปแบบที่ถูกต้องตั้งแต่ต้นหลีกเลี่ยงการสูญเสียข้อมูล:
- ข้อมูลตารางสำหรับสเปรดชีตหรือฐานข้อมูล — CSV
- ข้อมูลมีโครงสร้างสำหรับ API หรือเว็บแอป — JSON
- คอนฟิกที่คนจะแก้ไข — YAML
- ข้อมูลซ้อนซับซ้อนพร้อมคอมเมนต์ — YAML
- แลกเปลี่ยนข้อมูลระหว่างระบบ — JSON
เรียนรู้เพิ่มเติม
แปลงระหว่าง JSON, YAML และ CSV ทันทีด้วยเครื่องมือบนเบราว์เซอร์:
- แปลงรูปแบบข้อมูล — วางข้อมูล เลือกรูปแบบเป้าหมาย ดาวน์โหลดผลลัพธ์
- JSON Formatter — ตรวจสอบ จัดรูปแบบ และย่อ JSON
- ตัวแปลง JSON เป็น CSV — แปลงอาร์เรย์ JSON เป็น CSV พร้อมใช้ในสเปรดชีต
- ตัวแปลง YAML-JSON — แปลงระหว่าง YAML กับ JSON พร้อมการรับรู้คอมเมนต์