เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
RFC 4122 กับ RFC 9562: สิ่งที่เปลี่ยนแปลงไปใน 2024 UUID มาตรฐาน
· พื้นหลัง
uuid การเข้ารหัส เบราว์เซอร์-apis
RFC สองตัวถูกอ้างถึงสำหรับ UUID และพวกเขาไม่ได้พูดในสิ่งเดียวกันเลยทีเดียว โพสต์นี้จะอธิบายสิ่งที่ RFC 9562 เพิ่ม ชี้แจง และเลิกใช้แล้วโดยสัมพันธ์กับ RFC 4122
RFC ใดที่ฉันอ้างอิง — ความสับสนเมื่อเอกสารและห้องสมุดอ้างอิงถึงมาตรฐานที่แตกต่างกัน
RFC สองตัวถูกอ้างถึงเป็นประจำในเอกสารประกอบ UUID และพวกเขาไม่ได้พูดสิ่งที่เหมือนกัน RFC 4122 เผยแพร่ใน 2005 กำหนด UUID และห้าเวอร์ชัน (v1 ถึง v5) RFC 9562 เผยแพร่ใน 2024 ล้าสมัย RFC 4122 ทั้งหมด ชี้แจงความคลุมเครือที่ผู้ปฏิบัติงานแก้ไข เพิ่มเวอร์ชันใหม่ 3 เวอร์ชัน (v6, v7, v8) และอัปเดตคำแนะนำในการใช้การสุ่ม เมื่อไลบรารีอ้างอิง RFC 4122 ก็ไม่ผิด ไลบรารีนั้นอาจได้รับการเผยแพร่ก่อนที่ RFC 9562 จะถูกเผยแพร่ หรือผู้ดูแลอาจไม่มีเอกสารที่อัปเดต การตรวจสอบการอ้างอิง RFC จะแจ้งให้คุณทราบเมื่อไลบรารีได้รับการอัปเดตอย่างมีนัยสำคัญครั้งล่าสุด เมื่อเขียนข้อกำหนดใหม่หรือประเมินการใช้งาน RFC 9562 เป็นข้อมูลอ้างอิงเชิงบรรทัดฐาน
ล้าสมัย ไม่ได้แทนที่รูปแบบ — ทุกอย่างที่ถูกต้องภายใต้ RFC 4122 ยังคงใช้ได้ เค้าโครงและบิตตัวแปรไม่มีการเปลี่ยนแปลง
RFC 9562 ล้าสมัยอย่างเป็นทางการ RFC 4122 เป็นเอกสารอ้างอิงปัจจุบัน ในขณะที่ยังคงรักษาการแสดง 128-บิต ที่คุ้นเคย กลุ่มเลขฐานสิบหก ตำแหน่งเวอร์ชัน และโครงร่างตัวแปรหลัก สตริง UUID ที่เก็บไว้ที่มีอยู่ ไม่จำเป็นต้องออกใหม่เพียงเพราะมี RFC ที่ใหม่กว่าอยู่ การโยกย้ายเชิงปฏิบัติอยู่ในเอกสารประกอบ ตัวสร้าง และนโยบายการตรวจสอบ: อ้างอิงมาตรฐานปัจจุบัน ทำความเข้าใจเวอร์ชันที่เพิ่มเข้ามา และตรวจสอบว่าโค้ดเก่าอาศัยความคลุมเครือตามที่แก้ไขชี้แจงหรือไม่ ความเข้ากันได้ควรยังคงได้รับการทดสอบที่ขอบเขตของระบบ โดยเฉพาะอย่างยิ่งเมื่อไลบรารีทำให้โครงสร้าง Microsoft GUID เป็นอนุกรม หรือบังคับใช้ชุดเวอร์ชันที่แคบกว่าที่มาตรฐานอธิบายไว้
สามเวอร์ชันใหม่ — v6 (เวลาที่เรียงลำดับใหม่), v7 (ลำดับเวลาของ Unix-epoch) และ v8 (กำหนดการใช้งาน)
RFC 9562 เพิ่มเวอร์ชันใหม่สามเวอร์ชันให้เป็นมาตรฐาน เวอร์ชัน 6 เรียงลำดับบิตการประทับเวลา v1 ใหม่เพื่อสร้างตัวระบุที่จัดเรียงตามพจนานุกรมได้เพื่อประสิทธิภาพของฐานข้อมูลที่ดีขึ้น เวอร์ชัน 7 ใช้การประทับเวลามิลลิวินาทีของ Unix 48 บิต ตามด้วยบิตแบบสุ่ม ซึ่งให้การสร้างตามกำหนดเวลาโดยไม่ต้องกังวลเรื่องความเป็นส่วนตัวของ v1 เวอร์ชัน 8 เป็นช่องทางหลบหนีสำหรับเค้าโครงที่กำหนดการใช้งาน ไม่มีเวอร์ชันใดที่เปลี่ยนแปลงวิธีการทำงานของ v1-v5 หรือความหมายของเวอร์ชันเหล่านี้ v1 UUID จาก 2005 และ v7 UUID จาก 2024 สามารถอยู่ร่วมกันในฐานข้อมูลเดียวกัน โดยแต่ละเวอร์ชันมีบิตของเวอร์ชันที่ระบุวิธีการสร้างของมัน เวอร์ชันใหม่ทั้งสามกล่าวถึงรูปแบบทั่วไปที่เกิดขึ้นในทางปฏิบัติ
Max UUID รวม Nil — ค่า all-F ที่กำหนดควบคู่ไปกับค่าศูนย์ทั้งหมด
RFC 4122 จัดทำเอกสาร Nil UUID (ศูนย์บิตทั้งหมด) เป็นค่าอ้างอิงพิเศษในตัวอย่างและเอกสารประกอบ RFC 9562 รวมคำจำกัดความ Nil เดียวกัน แต่กำหนด Max อย่างเป็นทางการ UUID (บิตทั้งหมดตั้งค่าเป็นหนึ่ง) สำหรับขอบเขตช่วง ทั้ง Nil และ Max ไม่ใช่เวอร์ชัน 4 สุ่ม UUID เนื่องจากไม่มีเวอร์ชันและบิตตัวแปรที่ถูกต้อง แม็กซ์ UUID มีประโยชน์เป็นขอบเขตบนของขอบเขตบนในการสืบค้นฐานข้อมูล: WHERE uuid_column <= MAX_UUID ตรงกับ UUID ที่เป็นไปได้ทั้งหมด Nil มีประโยชน์ในฐานะ Sentinel สำหรับ Unsigned ใน nullable UUID คอลัมน์ RFC 9562 เอกสารทั้งสองโดยไม่ต้องกำหนดให้ใช้ในข้อมูลแอปพลิเคชัน
คำแนะนำที่ชัดเจน — คำแนะนำที่ชัดเจนในการใช้ CSPRNG สำหรับฟิลด์สุ่ม บนตัวนับแบบโมโนโทนิกภายในมิลลิวินาที และในการเลือกเวอร์ชันตามลำดับเวลาสำหรับท้องถิ่นของฐานข้อมูล
RFC 9562 คำแนะนำแนวทางปฏิบัติที่ดีที่สุดของจะแยกแยะความต้านทานการชนจากความไม่คาดเดาได้ ช่องสุ่มควรใช้แหล่งที่มาที่เหมาะสมกับโมเดลภัยคุกคามของแอปพลิเคชัน และความทึบที่ไวต่อความปลอดภัยเรียกร้องให้ CSPRNG ตัวสร้างตามเวลามีปัญหาเรื่องความซ้ำซากจำเจที่แยกจากกันเมื่อมีตัวระบุหลายตัวแบ่งปันการประทับเวลาเดียว มาตรฐานจะอธิบายตัวนับและความแม่นยำในการประทับเวลาเพิ่มเติมเป็นวิธีการที่เป็นไปได้ โดยแต่ละวิธีมีกฎสถานะและกฎแบบโรลโอเวอร์ เวอร์ชันตามชื่อยังคงเป็นตัวระบุที่กำหนด ไม่ใช่หลักฐานพิสูจน์ความถูกต้อง การชี้แจงเหล่านี้มีความสำคัญเนื่องจาก parser UUID หนึ่งตัวสามารถยอมรับโครงร่างทั้งหมดได้ แม้ว่าข้อกำหนดในการสร้างและคุณสมบัติการเปิดเผยข้อมูลจะแตกต่างกันก็ตาม
แนวคิดของ ULID ปรากฏขึ้นที่ใด — รูปแบบชุมชนมีอิทธิพลต่อการออกแบบของ v7 อย่างไร
RFC 9562 กล่าวว่าผู้เขียนได้วิเคราะห์รูปแบบตัวระบุที่จัดเรียงได้หลายรูปแบบ รวมถึง ULID, Snowflake และ KSUID ในขณะที่พัฒนาเค้าโครงใหม่ ซึ่งสนับสนุนข้อสรุปที่เรียบง่าย: ความต้องการในการปฏิบัติงานสำหรับลำดับเวลา ตัวระบุแบบกระจายแจ้งการแก้ไข ไม่ได้พิสูจน์ว่ารูปแบบชุมชนรูปแบบหนึ่งได้บริจาคเค้าโครงฟิลด์ที่แน่นอนให้กับเวอร์ชัน 7 ความคล้ายคลึงกันในทางปฏิบัตินั้นเพียงพอแล้วสำหรับงานสถาปัตยกรรม: ครอบครัวเหล่านี้วางข้อมูลเวลาไว้ใกล้ด้านหน้า เพื่อให้การเรียงลำดับทั่วไปสามารถรักษาลำดับการสร้างในวงกว้าง จากนั้นจึงแตกต่างกันในการเข้ารหัส การประสานงาน และพฤติกรรมภายใน เลือกระหว่างสิ่งเหล่านั้นตามความเข้ากันได้ของระบบนิเวศและการรับประกันที่เป็นเอกสาร แทนที่จะอ้างถึงบรรพบุรุษโดยตรง
สิ่งนี้ไม่ครอบคลุม — ความแตกต่างแบบทีละบรรทัด; โพสต์นี้ติดตามผลที่ตามมาในทางปฏิบัติสำหรับผู้ดำเนินการ
โพสต์ที่ครอบคลุมนี้ติดตามผลที่ตามมาในทางปฏิบัติและการใช้งาน RFC 9562 สำหรับผู้ใช้และผู้ใช้ ไม่ใช่ความแตกต่างทีละบรรทัดกับ RFC 4122 ข้อกำหนดเฉพาะฉบับเต็มหาได้จากหน่วยงานมาตรฐาน และควรอ่านสำหรับการใช้งานการจัดการ UUID ในภาษาหรือแพลตฟอร์ม ข้อความนี้ให้รายละเอียดที่เชื่อถือได้ นอกเหนือจากที่ภาพรวมจะครอบคลุมได้ โพสต์นี้ไม่ได้อธิบายกลไกระดับบิตว่า v6 เรียงลำดับไบต์ v1 ใหม่หรือวิธีที่ v7 เข้ารหัส Unix มิลลิวินาที ทั้งมาตรฐานและคู่มือการใช้งานยังคงเป็นข้อมูลอ้างอิงหลักที่เชื่อถือได้สำหรับคำถามในการใช้งานที่เกี่ยวข้องกับรูปแบบบิต การเข้ารหัส หรือการตรวจสอบการปฏิบัติตามข้อกำหนด
ประเด็นสำคัญ: อัปเดตการอ้างอิงและค่าเริ่มต้นของคุณ — ตัวสร้าง ToolAcre ปฏิบัติตามคำแนะนำ CSPRNG ที่ RFC ทั้งสองแบ่งปัน
สำหรับงานใหม่ โปรดอัปเดตเอกสารและข้อกำหนดเพื่ออ้างอิง RFC 9562 ทุก UUID จาก RFC 4122 ยังคงใช้ได้ภายใต้ RFC 9562 การโยกย้ายเป็นการมองไปข้างหน้าและในลักษณะการจัดการเท่านั้น คำแนะนำที่ชัดเจนเกี่ยวกับการสุ่มการเข้ารหัสเป็นการตอกย้ำว่าตัวระบุต้องมาจากแหล่งที่มีการเข้ารหัสที่ปลอดภัยในระบบการผลิต ToolAcre ปฏิบัติตามคำแนะนำการสุ่มการเข้ารหัสจาก RFC ทั้งสองโดยใช้ Web Crypto API ของเบราว์เซอร์โดยเฉพาะ เมื่อคุณพบ UUID จากบันทึก การส่งออกฐานข้อมูล หรือการตอบกลับ API เช็คที่มีรูปแบบถูกต้อง ToolAcre จะรายงานเวอร์ชันและตัวแปรเทียบกับ RFC 9562 RFC 9562 เป็นการชี้แจงและปรับปรุงมาตรฐานที่มีเสถียรภาพอยู่แล้วให้ทันสมัย