เหตุใดจึงมี TOML: เป้าหมายการออกแบบที่อยู่เบื้องหลัง Cargo.toml และ pyproject.toml

รูปแบบการกำหนดค่าสามรูปแบบในที่เก็บเดียว — JSON สำหรับตัวแก้ไข, YAML สำหรับ CI, TOML สำหรับรุ่น และคำถามที่ว่าทำไมรูปแบบที่สามจึงมีอยู่

พื้นที่เก็บข้อมูลสามารถใช้ JSON, YAML และ TOML สำหรับพื้นผิวการกำหนดค่าที่แตกต่างกัน ToolAcre ไม่สามารถอธิบายตัวเลือกของทุกโปรเจ็กต์ได้ แต่การแปลงทำให้ความแตกต่างทางโครงสร้างเป็นรูปธรรม: TOML เริ่มต้นเป็นตารางราก ใช้ส่วนหัวและเส้นทางเส้นประสำหรับการซ้อน และมีค่าชั่วคราวที่ไม่มีใน JSON

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

เป้าหมายการออกแบบ — ความหมายน้อยที่สุด ชัดเจน อ่านง่าย และรูปแบบที่แมปกับตารางแฮชอย่างชัดเจน

Parser ที่จัดส่งเปิดเผยความหมายของตารางที่ชัดเจน: ส่วนหัวคือเส้นทาง การมอบหมายเป็นของตารางที่ใช้งานอยู่ และโทเค็นสเกลาร์ได้กำหนดประเภท TOML สตริงไม่ได้ถูกพิมพ์เพียงเพราะเนื้อหาดูเหมือนวันที่ ไวยากรณ์ชั่วคราวที่เกิดขึ้นจริงจะสร้างวัตถุวันที่ที่ ToolAcre ทำให้เป็นมาตรฐานโดยเจตนา

พื้นที่เก็บข้อมูลไม่ได้มาจากผู้สร้างรูปแบบ วันที่ หรือปรัชญาที่ระบุไว้ ดังนั้นบทความนี้จึงหลีกเลี่ยงการนำเสนอประวัติศาสตร์ที่จดจำไว้ตามความเป็นจริง รายงานพฤติกรรมที่ทดสอบใน smol-toml และเลเยอร์การทำให้เป็นมาตรฐานของตัวแปลงเอง

คุณสมบัติการออกแบบที่สังเกตได้ในตัวแยกวิเคราะห์ที่จัดส่ง โดยไม่มีการอ้างสิทธิ์แหล่งกำเนิดที่ไม่มีแหล่งที่มา

TOML ไม่มีค่าว่าง และรูทเอกสารต้องไม่เป็นอาร์เรย์หรือสเกลาร์ ไม่มีจุดยึดหรือนามแฝงสไตล์ YAML ในการแมปนี้ ความคิดเห็นมีอยู่ใน TOML ผู้เขียน แต่ไม่ได้เก็บรักษาไว้โดยตัวแยกวิเคราะห์ค่า ดังนั้นจึงไม่สามารถแปลงผ่าน JSON หรือ YAML ได้

ค่าเปล่าที่ไม่ได้ใส่เครื่องหมายคำพูดจะเป็นไปตามไวยากรณ์ TOML มากกว่าการเลือกสคีมาของ YAML parser ยอมรับค่าที่พิมพ์หรือรายงาน TOML ที่ไม่ถูกต้องพร้อมข้อมูลตำแหน่ง ToolAcre ไม่ได้เพิ่มโหมดสตริงโดยนัยสำหรับการมอบหมายที่มีรูปแบบไม่ถูกต้อง

สิ่งที่รูปแบบค่าที่รองรับไม่รวมหรือจัดการต่างกัน

แบบจำลองนี้ประกอบด้วยสตริง จำนวนเต็มที่มีเครื่องหมาย ทศนิยม บูลีน ชนิดชั่วคราวสี่ชนิด อาร์เรย์ และตาราง อาร์เรย์ของตารางแสดงบันทึกวัตถุที่ซ้ำกัน จำนวนเต็มขนาดใหญ่ที่มีเครื่องหมายเกิน 2^53 จะกลายเป็นสตริงทศนิยมในการแปลง ดังนั้น JavaScript จะไม่ปัดเศษโดยไม่โต้ตอบ

ค่าชั่วคราวจะกลายเป็นข้อความเชิงแหล่งที่มาสำหรับวันที่-เวลาออฟเซ็ต วันที่-เวลาท้องถิ่น วันที่ท้องถิ่น หรือเวลาท้องถิ่น คำเตือนจะคงประเภทไว้ในร้อยแก้ว แต่ JSON รับเฉพาะสตริงเท่านั้น การแปลงกลับจึงเสนอราคาและสูญเสียประเภท TOML ดั้งเดิม

การนำมาใช้ — สินค้าตั้งแต่ยุคแรกสุดของ Rust, PEP 518 การเลือก pyproject.toml และข้อกำหนด 1.0.0 ใน 2021

การนำ Cargo และ pyproject มาใช้เป็นการอ้างสิทธิ์ในอดีตและระบบนิเวศที่ต้องการแหล่งที่มาที่ไม่ปรากฏในที่เก็บตัวแปลง พวกเขาละเว้นที่นี่โดยเจตนา เส้นทางหรือชื่อไฟล์ไม่ใช่หลักฐานสำหรับลำดับเหตุการณ์ การเผยแพร่ข้อมูลจำเพาะ หรือการตัดสินใจมาตรฐาน

คำถามในการปฏิบัติงานคือเครื่องมือเป้าหมายอ่าน TOML และตารางใดที่คาดหวัง ตรวจสอบเอกสารปัจจุบันของเครื่องมือนั้น ตัวแปลงไวยากรณ์รู้การแมปไวยากรณ์และการแมปค่า ไม่ใช่สัญญาการกำหนดค่าตัวจัดการแพ็คเกจ

ประวัติการนำระบบนิเวศมาใช้จะถูกละเว้นโดยไม่มีแหล่งที่มาของพื้นที่เก็บข้อมูล

การซ้อนแบบลึกอาจสแกนได้ยากกว่าเนื่องจากบริบทของตารางยังคงมีข้ามบรรทัด ในขณะที่อาร์เรย์ขนาดใหญ่ของตารางจะกระจายรายการลอจิคัลหนึ่งรายการไปยังส่วนหัวที่ซ้ำกัน JSON ทำให้ลำดับชั้นทั้งหมดชัดเจน แต่เพิ่มเครื่องหมายปีกกาและเครื่องหมายคำพูด การเป็นตัวแทนทั้งสองแบบไม่ได้ขจัดความซับซ้อนออกจากการกำหนดค่าพื้นฐาน

parser caps ซ้อนอยู่ที่ 100 และความยาวของต้นฉบับอยู่ที่ 2 ล้านอักขระ สิ่งเหล่านั้นคือขอบเขตการปฏิเสธ ไม่ใช่ข้อความเกี่ยวกับขนาดการกำหนดค่าในอุดมคติหรือขีดจำกัดสากล TOML

สิ่งนี้ไม่ครอบคลุม — TOML ตัวเลือกพาร์เซอร์ในแต่ละภาษา และลักษณะการอ่านอย่างเดียวของการใช้งานไลบรารีมาตรฐานบางอย่าง

ตัวเลือก Parser ในแต่ละภาษาอยู่นอกขอบเขต เช่นเดียวกับความสามารถในการเขียนไลบรารีมาตรฐาน ToolAcre ใช้ smol-toml แบบไดนามิกและตัดข้อผิดพลาด การใช้งานอื่นสามารถจัดรูปแบบเอาต์พุตที่ถูกต้องแตกต่างออกไปหรือเปิดเผย API อื่นในขณะที่แสดงข้อมูลเดียวกัน

ใช้อุปกรณ์จับยึดเครื่องมือไขว้สำหรับค่าชั่วคราว จำนวนเต็มขนาดใหญ่ อาร์เรย์ และคีย์จุด เมื่อความสามารถในการทำงานร่วมกันมีความสำคัญ ไฟล์ที่ยอมรับที่นี่ไม่ได้รับการยอมรับโดยอัตโนมัติจากผู้บริโภค TOML ทุกคน

ประเด็นสำคัญ: TOML ให้ความเห็นเกี่ยวกับการเป็นรูปแบบการกำหนดค่า และวิธีที่แผงตัวแปลงไวยากรณ์ช่วยให้คุณเห็นไฟล์ JSON หรือ YAML ในรูปแบบนั้น

TOML ให้ความคิดเห็นในรูปแบบที่สังเกตได้: รูทของตาราง ค่าที่พิมพ์อย่างชัดเจน ประเภทชั่วคราวดั้งเดิม และไม่มีค่าว่าง Conversion เปิดเผยตัวเลือกเหล่านั้นและความเข้ากันไม่ได้กับเป้าหมายที่มีรูปทรง JSON โดยไม่จำเป็นต้องมีความเชื่อผิดๆ เกี่ยวกับต้นกำเนิด

ใช้แผงควบคุมเพื่อตรวจสอบต้นไม้และระบุคำเตือน จากนั้นกลับไปที่สคีมาของปลายทางและเขียนเค้าโครงตารางที่มนุษย์จะรักษาไว้ ตัวแปลงจะให้หลักฐานเกี่ยวกับค่าต่างๆ ไม่ใช่คำตัดสินเกี่ยวกับการตั้งค่ารูปแบบ

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