เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
UUID เวอร์ชัน 1 ถึง 8 อธิบาย: คุณควรสร้างเวอร์ชันใด
· พื้นหลัง
uuid การเข้ารหัส เบราว์เซอร์-apis
แปดเวอร์ชันใช้รูปแบบเดียวกัน แต่แก้ปัญหาที่แตกต่างกัน: การเรียงลำดับเวลา ความสามารถในการทำซ้ำ การสุ่ม หรือเค้าโครงแบบกำหนดเอง โพสต์นี้จะอธิบายแต่ละรายการและให้เส้นทางการตัดสินใจ
หนึ่งรูปแบบ แปดสูตรอาหาร — ทำไมเวอร์ชันตอดจึงมีความสำคัญเมื่อคุณเลือกฟังก์ชันไลบรารี
มาตรฐาน UUID กำหนดรูปแบบ 128 บิตเป็นอักขระเลขฐานสิบหก 36 ตัวพร้อมยัติภังค์ RFC 9562 กำหนดสูตรที่แตกต่างกันแปดสูตร—เวอร์ชันหนึ่งถึงแปด—สำหรับการเติมบิตเหล่านั้นด้วยรูปแบบและความหมายที่แตกต่างกัน เวอร์ชัน nibble (อักขระตัวแรกของกลุ่มที่สาม) ระบุว่าวิธีใดที่สร้างค่า โดยทำหน้าที่เป็นป้ายกำกับ การเลือกเวอร์ชันที่ไม่ถูกต้องหมายถึงการจัดเก็บข้อมูลชั่วคราวที่ไม่จำเป็น การขาดการรับประกันการสั่งซื้อสำหรับประสิทธิภาพของฐานข้อมูล หรือบทบาทความปลอดภัยของตัวระบุที่เข้าใจผิด โพสต์นี้จะอธิบายแต่ละเวอร์ชัน ปัญหาที่เป็นรูปธรรมที่แก้ไขได้ เมื่อนักพัฒนาพบปัญหาดังกล่าวในทางปฏิบัติ และให้กรอบการตัดสินใจในการเลือกเวอร์ชันที่เหมาะสมสำหรับความต้องการระบบเฉพาะของคุณ
v1 และ v6: time plus node — เค้าโครงตามเวลาดั้งเดิมและเวอร์ชันที่เรียงลำดับใหม่ซึ่งเรียงลำดับอย่างถูกต้อง
เวอร์ชัน 1 รวมการประทับเวลา 60 บิตเข้ากับตัวระบุโหนด (แต่เดิมเป็นที่อยู่ MAC แม้ว่าการใช้งานสมัยใหม่จะใช้ค่าสุ่มเพื่อหลีกเลี่ยงการรั่วไหลของข้อมูลฮาร์ดแวร์) การประทับเวลาบันทึก 100-ช่วงเวลานาโนวินาทีตั้งแต่เดือนตุลาคม 15, 1582 ฟิลด์โหนดสามารถเปิดเผยได้ว่าตัวระบุถูกสร้างขึ้นเมื่อใดและมาจากที่ใดในทางภูมิศาสตร์ ซึ่งเป็นเหตุผลว่าทำไมการใช้งานสมัยใหม่จึงหลีกเลี่ยงที่อยู่ MAC เวอร์ชัน 6 จัดเรียงการประทับเวลาและข้อมูลโหนดเดียวกันใหม่เพื่อปรับปรุงความสามารถในการจัดเรียงโดยการย้ายบิตเวลาที่มีลำดับสูงไปไว้ด้านหน้า ทำให้ v6 UUID เรียงลำดับอย่างถูกต้องตามลำดับพจนานุกรม หากแอปพลิเคชันของคุณต้องการ UUID ที่จัดเรียงตามธรรมชาติตามเวลาการสร้างพร้อมตำแหน่งดัชนีที่เหนือกว่า v6 คือตัวเลือกที่ทันสมัย
v2: DCE ความปลอดภัย — รูปแบบที่ไม่ค่อยได้ใช้ซึ่งฝังตัวระบุ POSIX
เวอร์ชัน 2 ไม่ค่อยได้ใช้ในระบบใหม่ โดยฝังตัวระบุผู้ใช้หรือกลุ่ม POSIX ไว้ในเค้าโครง UUID ทำให้มีประโยชน์เฉพาะในสภาพแวดล้อมแบบเดิมที่ตัวระบุเหล่านั้นมีความหมายเชิงองค์กร การออกแบบ v2 จะใช้โมเดลการประมวลผลเฉพาะ (DCE ความปลอดภัย) ซึ่งพบไม่บ่อยในระบบแบบกระจายสมัยใหม่ องค์กรส่วนใหญ่เชื่อมโยง UUID กับผู้ใช้หรือกลุ่มในชั้นแอปพลิเคชันของตนผ่านการเข้าร่วมฐานข้อมูลหรือตารางการค้นหา ไม่ใช่โดยการเข้ารหัส ID ผู้ใช้ลงในตัวระบุเอง การแยกข้อกังวลนี้ช่วยให้เปลี่ยนรูปแบบการอนุญาต ย้ายข้อมูลผู้ใช้ และรักษาเส้นทางการตรวจสอบได้ง่ายขึ้น การเข้ารหัสข้อมูลประจำตัวลงใน UUID โดยตรงทำให้เกิดการเชื่อมต่อที่แน่นหนา และทำให้ระบบพัฒนาได้ยากขึ้น
v3 และ v5: ตามชื่อ — ID ที่กำหนดขึ้นซึ่งแฮชจากเนมสเปซและชื่อที่มี MD5 หรือ SHA-1
เวอร์ชัน 3 และ 5 UUID ถูกกำหนดไว้: เนมสเปซและชื่อเดียวกันจะสร้างตัวระบุเดียวกันเสมอ ซึ่งเหมาะสำหรับการแสดงการแมปที่เสถียรจากข้อมูลภายนอก เวอร์ชัน 3 ใช้ MD5 และเวอร์ชัน 5 ใช้ SHA-1 เป็นอัลกอริทึมแฮช ซึ่งสะท้อนถึงอายุและการนำไปใช้ตามลำดับ เมื่อบันทึกลูกค้ามาถึงสำหรับการนำเข้า v5 UUID ที่ได้มาจากเนมสเปซคงที่จะเหมือนกันในการนำเข้าหลายครั้ง เพื่อป้องกันบันทึกที่ซ้ำกัน ระดับนี้หมายความว่า UUID สามารถทำซ้ำและคาดเดาได้สำหรับทุกคนที่รู้เนมสเปซและอินพุต คุณค่าเชิงปฏิบัติจะส่องประกายในสถานการณ์การรวมข้อมูล: การปรับบันทึกลูกค้าจากหลายระบบ การป้องกันข้อมูลซ้ำในการนำเข้าที่เกิดซ้ำ และการกำหนด ID ที่เสถียรให้กับรายการ
v4: สุ่ม — 122 bits จาก CSPRNG และตัวเลือกเริ่มต้นเมื่อการสั่งซื้อไม่สำคัญ
เวอร์ชัน 4 เป็นตัวเลือกเริ่มต้นเมื่อไม่จำเป็นต้องสั่งซื้อ และคุณต้องการการสร้างแบบอิสระโดยไม่มีการประสานงานจากส่วนกลาง v4 UUID ประกอบด้วย 122 bits จากแหล่งสุ่มที่ปลอดภัยด้วยการเข้ารหัส โดยมีการตั้งค่าหกบิตเป็นค่าคงที่ (เวอร์ชัน nibble 4 และ RFC 9562 บิตรูปแบบ 10) การสุ่มเป็นจุดรวม: การเรียกแต่ละครั้งจะสร้างค่าที่แตกต่างกัน การชนกันไม่น่าจะหายไปเลย และไม่จำเป็นต้องมีสถานะหรือการประสานงานภายนอก เป็นเวอร์ชัน ToolAcre ที่สร้างโดยใช้ crypto.randomUUID() หรือ crypto.getRandomValues() เวอร์ชันนี้เหมาะสำหรับการอ้างอิงออบเจ็กต์ ข้อมูลที่ไม่มีโครงสร้าง และบทบาทส่วนใหญ่ที่อยู่นอกคีย์หลักหรือบริบทการเรียงลำดับ
v7 และ v8: เวลา Unix และกำหนดเอง — เวอร์ชันที่เรียงลำดับตามเวลาสมัยใหม่สำหรับคีย์ฐานข้อมูลและ Escape Hatch สำหรับเลย์เอาต์ที่ออกแบบตามความต้องการ
เวอร์ชัน 7 ซึ่งเป็นมาตรฐานใน RFC 9562 นำคุณสมบัติที่เรียงลำดับตามเวลาสมัยใหม่มาในรูปแบบ UUID ใช้การประทับเวลามิลลิวินาทีของ Unix 48 บิต, 12 bits ความแม่นยำต่ำกว่ามิลลิวินาที และบิตสุ่ม 62 รวมกัน การประทับเวลามิลลิวินาทีของ Unix นั้นใช้ได้จนถึงปี 10889 ทำให้เหมาะสำหรับระบบ ผลลัพธ์จะเรียงลำดับอย่างถูกต้องตามลำดับพจนานุกรมและพอดีกับคอลัมน์ 128-บิต UUID มาตรฐาน โดยไม่มีการจัดการพิเศษหรือการแปลงการเข้ารหัส หากแอปพลิเคชันของคุณต้องการตัวระบุที่จัดเรียงตามเวลาที่สร้างภายในรูปแบบ UUID มาตรฐาน v7 คือแนวทางปฏิบัติที่ดีที่สุดในปัจจุบัน เวอร์ชัน 8 เป็นแบบที่รับทั้งหมดที่เป็นมาตรฐานสำหรับรูปแบบที่กำหนดโดยการใช้งาน ซึ่งมีประโยชน์เฉพาะในกรณีที่คุณต้องการเลย์เอาต์บิตเฉพาะที่ไม่ครอบคลุมใน v1-v7
ตัวอย่างการทำงาน — เส้นทางการตัดสินใจที่ใช้กับสามสถานการณ์: การอ้างอิง API สาธารณะ คีย์หลัก และ ID ที่เสถียรสำหรับบันทึกที่นำเข้า
สถานการณ์จริงสามสถานการณ์แสดงให้เห็นการเลือกเวอร์ชัน: ประการแรก การอ้างอิง API สาธารณะจะต้องมีความเสถียรในอินสแตนซ์ API ต้องไม่ทำให้เวลาในการสร้างรั่วไหล และจะต้องเหมือนกันตลอดทั้งเซิร์ฟเวอร์ที่รีสตาร์ท เพื่อให้อินสแตนซ์ที่แตกต่างกันสร้างการอ้างอิงเดียวกันสำหรับเอกสารเดียวกัน ใช้ v5 กับเนมสเปซที่เสถียรและชื่อเอกสาร ประการที่สอง คีย์หลักสำหรับตารางที่เติบโตอย่างต่อเนื่องจะต้องไม่ซ้ำกัน ไม่ควรทำให้เกิดการกระจายตัวของดัชนี และต้องสร้างได้โดยอินสแตนซ์ของแอปพลิเคชันใดๆ ที่ไม่มีการประสานงานจากส่วนกลาง ใช้ v7 สำหรับตัวระบุที่จัดเรียงได้พร้อมการสนับสนุนระบบนิเวศ UUID มาตรฐาน ประการที่สาม บันทึกที่เก็บถาวรซึ่งต้องการการค้นหาที่เสถียรจำเป็นต้องมีตัวระบุที่ไม่เปลี่ยนรูป
ประเด็นสำคัญ: เลือกตามคุณสมบัติ ไม่ใช่ตามนิสัย — ตัวสร้าง ToolAcre สร้าง UUID แบบสุ่มจาก CSPRNG ของเบราว์เซอร์สำหรับกรณีที่เรียกใช้ v4
การเลือกเวอร์ชันเป็นไปตามการออกแบบสคีมาและข้อกำหนดของระบบ ไม่ใช่จากแบบแผนหรือความคุ้นเคย UUID แบบสุ่ม (v4) เป็นค่าเริ่มต้นเนื่องจากไม่จำเป็นต้องมีสถานะหรือการประสานงาน และสร้างตัวระบุอิสระที่เหมาะสมสำหรับบทบาทส่วนใหญ่ เวอร์ชันที่เรียงลำดับตามเวลา (v6, v7) แก้ปัญหาตำแหน่งดัชนีโดยเสียค่าใช้จ่ายจากการรั่วไหลของข้อมูลชั่วคราวหรือข้อกำหนดในการซิงโครไนซ์นาฬิกา เวอร์ชันที่กำหนด (v3, v5) ป้องกันการนำเข้าซ้ำและเปิดใช้งานการแมปภายนอกที่มีความเสถียรโดยเสียค่าใช้จ่ายในการคาดการณ์ ใครก็ตามที่รู้จักเนมสเปซของคุณสามารถคำนวณใหม่ได้ ToolAcre สร้าง UUID v4 แบบสุ่มจากตัวสร้างที่ปลอดภัยด้วยการเข้ารหัสของเบราว์เซอร์ เมื่อคุณต้องการเวอร์ชันอื่น การตรวจสอบที่มีรูปแบบถูกต้องจะยืนยันว่าตัวระบุแยกวิเคราะห์ว่าถูกต้อง