ตัวแปลง JSON เป็น YAML

ทำไมต้องแปลง JSON เป็น YAML?

JSON เหมาะสำหรับเครื่องและ API แต่ YAML อ่านและแก้ไขได้ง่ายกว่าสำหรับคน: ไม่มีวงเล็บปีกกา ไม่บังคับใส่อัญประกาศ และรองรับคอมเมนต์ เครื่องมือ infrastructure ส่วนใหญ่ รวมถึง Kubernetes, Helm, Docker Compose, GitHub Actions, GitLab CI และ Ansible ตั้งค่าด้วย YAML ในขณะที่ข้อมูลต้นทาง (ผลลัพธ์จาก API, kubectl get -o json, Terraform state) มักเป็น JSON

สไตล์ block vs. flow

สไตล์ block วางแต่ละคีย์และรายการไว้คนละบรรทัด และเป็นตัวเลือกมาตรฐานสำหรับไฟล์ config สไตล์ flow ใช้ {} และ [] แบบอินไลน์เหมือน JSON และทำให้โครงสร้างปลายทางที่สั้นกระชับ “Flow ตั้งแต่ระดับ 2” คงสองระดับบนสุดเป็น block และทำให้ส่วนที่ลึกกว่าเป็นอินไลน์ ซึ่งเหมาะกับรายการยาวของ object เล็ก ๆ เช่น port หรือ env var

การใส่อัญประกาศอย่างปลอดภัย

สตริงที่ YAML parser อาจอ่านผิดจะถูกใส่อัญประกาศอัตโนมัติ: ค่าอย่าง 'no', 'on', '1.0', 'null', สตริงที่ขึ้นต้นด้วย * หรือ & และสตริงที่มี : เลือก เดี่ยวเสมอ หรือ คู่เสมอ หาก style guide ของคุณกำหนดให้ทุกสตริงต้องมีอัญประกาศ

ข้อควรระวังระหว่าง YAML 1.1 กับ 1.2

ตัวแปลงนี้ทำตาม YAML 1.2 ซึ่งเป็นสเปกปัจจุบัน เครื่องมือเก่าหลายตัว (PyYAML, Psych ของ Ruby, Kubernetes และ Ansible บางเวอร์ชัน) ยังอ่านแบบ YAML 1.1 ซึ่งมีกฎต่างกัน:

• ปัญหานอร์เวย์: ใน YAML 1.1 country: no หมายถึง false รหัสประเทศของนอร์เวย์ NO จึงหายไป เช่นเดียวกับ yes, on, off, y และ n ส่วน YAML 1.2 ถือว่าเฉพาะ true และ false เป็น boolean
• เลขฐานแปด: 0755 เป็นเลขฐานแปดใน 1.1 แต่เป็นเลขฐานสิบธรรมดาใน 1.2 ซึ่งใช้ 0o755 ควรใส่อัญประกาศให้ file mode เพื่อความปลอดภัย
• เลขฐานหกสิบ: ใน 1.1 22:30 อาจถูกพาร์สเป็นตัวเลข 1350 ควรใส่อัญประกาศให้เวลาและการแมป port เช่น "8080:80"

ทิศทาง JSON → YAML จะใส่อัญประกาศให้สตริงที่กำกวม ('no', 'on', 'y') อัตโนมัติ YAML ที่สร้างขึ้นจึงอ่านได้เหมือนกันทั้งสองเวอร์ชัน