ตัวระบุที่ไม่ซ้ำกันทั่วโลก

คำย่อ	UUID
องค์กร	มูลนิธิซอฟต์แวร์เปิด (OSF), ISO / IEC , คณะทำงานด้านวิศวกรรมอินเทอร์เน็ต (IETF)
จำนวน  หลัก	32
ตัวอย่าง	8be4df61-93ca-11d2-aa0d-00e098032b8c
เว็บไซต์	RFC  9562 (แทนที่RFC 4122 )

ตัวระบุที่ไม่ซ้ำกันทั่วโลก ( UUID ) คือ ตัวเลข 128 บิต ที่ใช้ระบุ ^{ข้อมูล}ในระบบคอมพิวเตอร์ คำว่าตัวระบุที่ไม่ซ้ำกันทั่วโลก ( GUID ) ก็มีการใช้เช่นกัน โดยทั่วไปในซอฟต์แวร์ที่สร้างโดยMicrosoft [ ^{1 ]}

เมื่อสร้างขึ้นตามมาตรฐานแล้ว UUID จะมีเอกลักษณ์เฉพาะตัวในทางปฏิบัติ เอกลักษณ์นี้ไม่ขึ้นอยู่กับหน่วยงานลงทะเบียนส่วนกลางหรือการประสานงานระหว่างฝ่ายที่สร้าง UUID ซึ่งแตกต่างจากระบบการกำหนดหมายเลขอื่นๆ ส่วนใหญ่

แม้ว่าโอกาสที่ UUID จะซ้ำกันจะไม่เป็นศูนย์ แต่ก็ใกล้เคียงกับศูนย์มากจนแทบไม่มีนัยสำคัญ^{[ 2 ]}ดังนั้น ทุกคนสามารถสร้าง UUID จำนวนมากและใช้เป็นตัวระบุได้ด้วยความแน่นอนเกือบ 100% ว่าจะไม่ซ้ำกับ UUID ที่ผู้อื่นสร้างขึ้นหรือกำลังจะสร้างขึ้น โดยการประสานงานเพียงอย่างเดียวที่จำเป็นเพื่อให้เกิดความเป็นเอกลักษณ์คือการปฏิบัติตามมาตรฐาน UUID ข้อมูลที่ติดป้ายกำกับด้วย UUID โดยฝ่ายอิสระจึงสามารถอยู่ร่วมกันในฐานข้อมูลหรือช่องทางเดียวกันได้ โดยมีโอกาสซ้ำกันน้อยมาก

การนำ UUID มาใช้เป็นเรื่องที่แพร่หลาย โดยแพลตฟอร์มคอมพิวเตอร์หลายแห่งรองรับการสร้าง UUID และการวิเคราะห์ข้อความที่แสดงแทน UUID

Apollo Computerใช้ UUID ในระบบ Network Computing System (NCS) ซึ่งเปิดตัวในปี 1987 โดยมีดีไซน์ที่ได้รับแรงบันดาลใจจากตัวระบุเฉพาะ 64 บิตของDomain/OSซึ่ง เป็น ระบบปฏิบัติการ Apollo รุ่นก่อนหน้า^{[ 3 ]} แพลตฟอร์ม Microsoft Windowsได้นำดีไซน์ NCS (และต่อมาคือ DCE) มาใช้ในชื่อ "ตัวระบุเฉพาะทั่วโลก" (GUID) ในช่วงต้นทศวรรษที่ 1990

ต่อมาไม่นานOpen Software Foundation (OSF) ได้ใช้ UUID ในสภาพแวดล้อมการประมวลผลแบบกระจาย (DCE) โดยมีการออกแบบที่อิงตาม UUID ของ NCS บางส่วน ซึ่งได้รับการบันทึกไว้ในข้อกำหนด RPC ของ DCE 1.1 ในปี 1996 และในข้อกำหนดบริการการตรวจสอบสิทธิ์และความปลอดภัยของ DCE 1.1 ซึ่งเผยแพร่ในปี 1997 ^{[ 4 ] [ 5 ] [ 6 ]} ISO/IEC ได้บันทึกการออกแบบ DCE ในปี 1996 ในISO / IEC 11578:1996 " เทคโนโลยีสารสนเทศ – การเชื่อมต่อระบบเปิด – การเรียกใช้ขั้นตอนระยะไกล " ^{[ 7 ]}

ในเดือนกรกฎาคม พ.ศ. 2548 คณะทำงานด้านวิศวกรรมอินเทอร์เน็ต (IETF) ได้เผยแพร่ RFC 4122 ที่เป็นมาตรฐาน^{[ 1 ]}ซึ่งได้ลงทะเบียน เนมสเปซ URNสำหรับ UUID ด้วย ในขณะเดียวกัน ITUก็ได้กำหนดมาตรฐาน UUID โดยอิงตามมาตรฐานก่อนหน้าและเวอร์ชันแรกๆ ของ RFC 4122 ใน ITU-T Rec. X.667 ISO/IEC 9834-8 ซึ่งเทียบเท่ากับ RFC 4122 ในทางเทคนิค^{[ 8 ]}

ข้อกำหนด IETF ปัจจุบันคือ RFC 9562 ^{[ 9 ]}ซึ่งเป็นมาตรฐานที่เสนอเผยแพร่ในเดือนพฤษภาคม 2024 โดยกำหนด UUID เวอร์ชันใหม่ 3 เวอร์ชัน (6–8) ของตัวแปร DCE UUID ที่ใช้งานอยู่ในปัจจุบันคือการออกแบบ DCE/IETF โดยมีข้อกำหนดสำหรับความเข้ากันได้แบบย้อนหลังกับ UUID ของ Apollo NCS และ GUID ของ Microsoft "แบบดั้งเดิม"

ผู้เขียน RFC 4122 คือ Paul Leach, Michael MeallingและRich Salzและผู้เขียนร่าง Internet Draft ฉบับแรกในปี 1997 ^{[ 10 ]}คือ Leach และ Salz Leach เคยเป็นสถาปนิกของ Domain/OS และทำงานต่อที่ Apollo ในฐานะนักออกแบบ NCS จากนั้นในฐานะสถาปนิกผู้ทรงคุณวุฒิของ Microsoft ได้มีส่วนร่วมในการออกแบบ OLE/COM/DCOM โดยนำแนวคิดของ UUID ไปใช้ในโครงการนั้น^{[ 11 ]} Leach ยังเป็นหนึ่งในผู้เขียน RFC 9562 ด้วย Salz เป็นสมาชิกของทีม DCE ที่ Open Software Foundation ^{[ 12 ]} Apollo ได้ควบรวมกิจการกับ Hewlett-Packardในปี 1989 ซึ่งเป็นสมาชิกผู้ก่อตั้ง OSF อดีตสมาชิกทีม NCS ที่กลายเป็นพนักงานของ HP ได้นำ UUID มาใช้ใน OSF DCE Mealling เป็นสมาชิก IETF ที่โดดเด่น ดำรงตำแหน่งในกลุ่มคณะกรรมการอำนวยการด้านวิศวกรรมอินเทอร์เน็ต และมีส่วนร่วมอย่างมากในงาน IETF เกี่ยวกับ URN ^{[ 13 ]} RFC 4122 ได้รวบรวมองค์ประกอบทั้งหมดเหล่านี้เข้าด้วยกัน

UUID คือตัวเลข 128 บิต ความหมายของบิตถูกกำหนดโดยรูปแบบ (variant ) ซึ่งมีอยู่สามแบบ โดยรูปแบบที่ใช้กันมากที่สุดคือรูปแบบที่ 1 ส่วนรูปแบบอื่นๆ นั้นใช้เพื่อความเข้ากันได้กับรูปแบบก่อนหน้า หรือเพื่อการกำหนดในอนาคต รูปแบบที่ 1 และ 2 ยังมี "เวอร์ชัน" ซึ่งกำหนดความหมายของ UUID ให้ชัดเจนยิ่งขึ้น

ฟิลด์ตัวแปรจะอยู่ในบิตที่มีค่ามากที่สุดจำนวนหนึ่งของไบต์ที่เก้า ฟิลด์นี้ระบุรูปแบบของ UUID โดยมีการกำหนดตัวแปรดังต่อไปนี้:

• รูปแบบที่ 0 (ระบุด้วยรูปแบบบิตเดียว 0 xxx ₂ ) ใช้เพื่อความเข้ากันได้กับ รูปแบบ UUID ของ ระบบประมวลผลเครือข่าย Apollo 1.5 ที่ล้าสมัยไปแล้ว ซึ่งพัฒนาขึ้นประมาณปี 1987 ฟิลด์รูปแบบใน UUID ปัจจุบันจะทับซ้อนกับอ็อกเท็ตตระกูลที่อยู่ใน UUID ของ NCS ในลักษณะที่ว่า UUID ของ NCS ที่ยังคงใช้งานอยู่จะมีค่า 0 ในบิตแรกของฟิลด์รูปแบบ พื้นที่การกำหนดหมายเลขของรูปแบบที่ 0 ยังรวมถึง UUID ที่เป็นค่าว่าง (Nil UUID) ด้วย

• UUID รุ่นที่ 1 (10 ₂ ) เรียกว่า UUID ตามมาตรฐาน RFC 4122/DCE 1.1 หรือ UUID แบบ "Leach–Salz" ตามชื่อผู้เขียนร่างมาตรฐานอินเทอร์เน็ตฉบับ ดั้งเดิม UUID เหล่านี้เป็น UUID ที่ใช้งานอยู่ในปัจจุบัน

• ตัวแปรที่ 2 (110 ₂ ) มีไว้เพื่อความเข้ากันได้กับ "GUID" ที่ใช้ใน Microsoft COM/DCOM รูปแบบนี้เคยใช้ใน GUID รุ่นแรกๆ บน แพลตฟอร์ม Microsoft Windowsเครื่องมือของ Microsoft ในปัจจุบันสร้าง UUID ตัวแปรที่ 1 ไม่ใช่ตัวแปรนี้ ความแตกต่างหลักระหว่างตัวแปรนี้กับตัวแปรที่ 1 นอกเหนือจากบิตตัวแปรพิเศษแล้ว คือลำดับไบต์ภายใน UUID RFC 9562 ประกาศว่าตัวแปรนี้อยู่นอกขอบเขต ดังนั้นเวอร์ชันใหม่สามเวอร์ชันที่กำหนดไว้สำหรับตัวแปรที่ 1 จึงไม่สามารถนำไปใช้กับตัวแปรที่ 2 ได้

• ตัวแปรที่ 3 (111 ₂ ) ประกอบด้วย UUID สูงสุด แต่ไม่ได้กำหนดไว้อย่างอื่นและสงวนไว้สำหรับการใช้งานในอนาคต

ตัวแปร OSF DCE และ Microsoft COM/DCOM (1 และ 2 ตามลำดับ) มีเวอร์ชันซึ่งระบุโดยค่าของบิตสี่บิตบนสุดของไบต์ที่เจ็ดของ UUID ในการแสดง UUID ในรูปแบบข้อความ นี่คือตัวเลขฐานสิบหกหลังเครื่องหมายขีดกลางตัวที่สอง UUID ของ Apollo NCS ตัวแปร 0 ไม่มีเวอร์ชัน แต่จะถูกจำแนกประเภทย่อยผ่าน "ตระกูลที่อยู่" แทนที่จะเป็นเวอร์ชัน RFC 9562 ^{[ 9 ]}ซึ่งกำหนดเวอร์ชัน 6, 7 และ 8 ระบุว่าตัวแปรอื่นนอกเหนือจากตัวแปร OSF DCE 1 นั้น "อยู่นอกขอบเขต" ของ RFC ทำให้ Microsoft ต้องกำหนดเวอร์ชันใหม่สำหรับตัวแปร 2 อย่างไรก็ตาม เวอร์ชัน 1 ถึง 5 ซึ่งได้รับการกำหนดมาตรฐานใน RFC 4122 ^{[ 1 ]}นั้นเหมือนกันในตัวแปรของ Microsoft ยกเว้นการเรียงลำดับไบต์

เวอร์ชัน 1 จะนำ ที่อยู่ MAC 48 บิตของ "โหนด" (นั่นคือคอมพิวเตอร์ที่สร้าง UUID) มาต่อกับค่าเวลา 60 บิต สำหรับระบบที่มี "ที่อยู่ MAC" EUI-64 64 บิต จะใช้ 48 บิตที่มีค่าน้อยที่สุด นอกจากนี้ยังสามารถใช้เลขสุ่ม 48 บิตได้ด้วย

การประทับเวลาคือจำนวนช่วงเวลา 100 นาโนวินาทีนับตั้งแต่เที่ยงคืนของวันที่ 15 ตุลาคม ค.ศ. 1582 ตามเวลาสากลเชิงพิกัด (UTC) ซึ่งเป็นวันที่ปฏิทินเกรกอเรียนได้รับการนำมาใช้เป็นครั้งแรก RFC 4122 ระบุว่าค่าเวลาจะวนรอบในปี ค.ศ. 3409 ^{[ 1 ]}ขึ้นอยู่กับอัลกอริทึมที่ใช้ ซึ่งหมายความว่าการประทับเวลา 60 บิตเป็นปริมาณที่มีเครื่องหมาย อย่างไรก็ตาม ซอฟต์แวร์บางตัว เช่น ไลบรารี libuuid ถือว่าการประทับเวลาเป็นค่าที่ไม่มีเครื่องหมาย ทำให้เวลาวนรอบอยู่ในปี ค.ศ. 5236 ^{[ 14 ]}

ลำดับสัญญาณนาฬิกา "เฉพาะตัว" 13 บิตหรือ 14 บิตจะขยายการประทับเวลาเพื่อจัดการกับกรณีที่นาฬิกาของโปรเซสเซอร์ไม่เดินหน้าเร็วพอ หรือกรณีที่มีโปรเซสเซอร์และตัวสร้าง UUID หลายตัวต่อโหนด เมื่อ UUID ถูกสร้างขึ้นเร็วกว่าที่นาฬิกาของระบบจะเดินหน้าได้ บิตล่างของการประทับเวลาและลำดับสัญญาณนาฬิกาสามารถเพิ่มขึ้นเพื่อจำลองความแม่นยำที่มากขึ้นและรับประกันความเป็นเอกลักษณ์ ด้วย UUID เวอร์ชัน 1 แต่ละตัวที่สอดคล้องกับจุดเดียวในพื้นที่ (โหนด) และเวลา (ช่วงเวลาและลำดับสัญญาณนาฬิกา) โอกาสที่ UUID เวอร์ชัน 1 สองตัวที่สร้างขึ้นอย่างถูกต้องจะเหมือนกันโดยไม่ได้ตั้งใจนั้นแทบจะเป็นศูนย์ เนื่องจากเวลาและลำดับสัญญาณนาฬิการวมกันเป็น 74 บิต ดังนั้น 2 ⁷⁴ (1.8 × 10^{สามารถสร้าง UUID เวอร์ชัน 1 ได้ 22}หรือ 18 เซ็กซ์ทิลเลียนต่อรหัสโหนด โดยมีอัตราเฉลี่ยสูงสุด 163 พันล้านต่อวินาทีต่อรหัสโหนด ^{[ 1 ]}

โครงสร้างของ UUID เวอร์ชัน 1 มีดังนี้:

เวอร์ชัน 6 เหมือนกับเวอร์ชัน 1 ทุกประการ ยกเว้นลำดับของบิตเวลาประทับ ในเวอร์ชัน 6 บิตเวลาประทับจะเรียงลำดับจากบิตที่มีค่ามากที่สุดไปยังบิตที่มีค่าน้อยที่สุด ซึ่งทำให้ระบบสามารถเรียงลำดับ UUID เวอร์ชัน 6 ตามลำดับการสร้างได้ง่ายๆ โดยการเรียงลำดับตามตัวอักษร การนำลำดับไบต์สูง-ต่ำของ NCS ดั้งเดิมกลับมาใช้เพื่อให้สามารถเรียงลำดับได้ ทำให้เวอร์ชัน 6 มีความคล้ายคลึงกับ UUID ของ NCS รุ่น "ดั้งเดิม" เวอร์ชัน 0 มากกว่าเวอร์ชัน 1

RFC 4122 และ 9562 ^{[ 9 ]}สงวนเวอร์ชัน 2 ไว้สำหรับ UUID "ความปลอดภัย DCE" แต่ไม่ได้ให้รายละเอียดใดๆ RFC 9562 ประกาศว่า "อยู่นอกขอบเขต" การใช้งาน UUID และไลบรารีจำนวนมากละเว้นเวอร์ชัน 2 อย่างไรก็ตาม ข้อกำหนดของ UUID เวอร์ชัน 2 ได้รับการจัดเตรียมโดยข้อกำหนดบริการการตรวจสอบสิทธิ์และความปลอดภัยของ DCE 1.1 ^{[ 6 ]}

UUID เวอร์ชัน 2 คล้ายกับเวอร์ชัน 1 ยกเว้นว่าบิต 8 บิตที่มีความสำคัญน้อยที่สุดของลำดับนาฬิกาจะถูกแทนที่ด้วยหมายเลข "โดเมนท้องถิ่น" และบิต 32 บิตที่มีความสำคัญน้อยที่สุดของไทม์สแตมป์เกรกอเรียน 60 บิตจะถูกแทนที่ด้วยตัวระบุจำนวนเต็มที่มีความหมายภายในโดเมนท้องถิ่นที่ระบุ ใน ระบบ POSIXหมายเลขโดเมนท้องถิ่น 0 และ 1 ใช้สำหรับรหัสผู้ใช้ ( UID ) และรหัสกลุ่ม ( GID ) ตามลำดับ และหมายเลขโดเมนท้องถิ่นอื่นๆ จะถูกกำหนดโดยไซต์^{[ 6 ]}ในระบบที่ไม่ใช่ POSIX หมายเลขโดเมนท้องถิ่นทั้งหมดจะถูกกำหนดโดยไซต์

ดังนั้น UUID เวอร์ชัน 2 จึงเป็นวิธีการรวมตัวระบุแบบโลคอล 32 บิต ที่มีขอบเขตเฉพาะโหนด ซึ่งมีประเภท 8 บิตที่ระบุ ("โดเมน") เข้ากับตัวระบุของโหนดและไทม์สแตมป์ที่มีต้นกำเนิดจากเกรกอเรียน โดยแปลงตัวระบุที่มีขอบเขตเฉพาะโหนดให้เป็นตัวระบุที่ไม่ซ้ำกันทั่วโลก ข้อเสียคือไทม์สแตมป์มีความละเอียดต่ำเมื่อเทียบกับไทม์สแตมป์ในเวอร์ชัน 1 โดยมีการนับเพียงครั้งเดียวทุกๆ 429.49 วินาที ซึ่งมากกว่า 7 นาทีเล็กน้อย ซึ่งแตกต่างจากการนับ 100 นาโนวินาทีในเวอร์ชัน 1 อย่างมาก^{[ 15 ]}

UUID เวอร์ชัน 3 และเวอร์ชัน 5 ถูกสร้างขึ้นโดยการแฮช ตัวระบุเน มสเปซและชื่อ เวอร์ชัน 3 ใช้MD5เป็นอัลกอริธึมการแฮช และเวอร์ชัน 5 ใช้SHA-1 [ ^{9 ] ซึ่ง}มีประโยชน์เมื่อระบบจำเป็นต้องสร้าง UUID เดียวกันอย่างแน่นอนโดยอิงจากชุดชื่อหรือตัวระบุอื่นๆ โดยไม่ต้องมีการประสานงาน

ตัวระบุเนมสเปซนั้นเป็น UUID อย่างหนึ่ง RFC ได้กำหนด UUID คงที่เพื่อใช้แทนเนมสเปซสำหรับ URL ชื่อโดเมนแบบเต็ม ตัวระบุวัตถุ และชื่อที่ระบุเฉพาะของ X.500 แต่สามารถใช้ UUID ใดก็ได้ตามต้องการเป็นตัวกำหนดเนมสเปซ นอกจากนี้ยังมี รีจิสทรี ของ IANAสำหรับรหัสเนมสเปซเพิ่มเติมอีกด้วย

ในการกำหนด UUID เวอร์ชัน 3 ที่สอดคล้องกับเนมสเปซและชื่อที่กำหนด UUID ของเนมสเปซจะถูกแปลงเป็นสตริงของไบต์ ต่อท้ายด้วยชื่อที่ป้อน จากนั้นทำการแฮชด้วย MD5 ซึ่งจะได้ 128 บิต จากนั้นบิตหกหรือเจ็ดบิตจะถูกแทนที่ด้วยค่าคงที่ ได้แก่ เวอร์ชันสี่บิต (เช่น 0011 ₂สำหรับเวอร์ชัน 3) และ "ตัวแปร" UUID สองหรือสามบิต (เช่น 10 ₂ที่ระบุ UUID ตามมาตรฐาน RFC 9562 ^{[ 9 ]}หรือ 110 ₂ที่ระบุ GUID ของ Microsoft รุ่นเก่า) เนื่องจากมีการกำหนดบิตไว้ล่วงหน้า 6 หรือ 7 บิต จึงมีเพียง 121 หรือ 122 บิตเท่านั้นที่ส่งผลต่อความเป็นเอกลักษณ์ของ UUID

UUID เวอร์ชัน 5 มีลักษณะคล้ายกัน แต่ใช้ SHA-1 แทน MD5 เนื่องจาก SHA-1 สร้างค่าแฮชขนาด 160 บิต ค่าแฮชจึงถูกตัดให้เหลือ 128 บิตก่อนที่จะแทนที่บิตเวอร์ชันและบิตตัวแปร

UUID เวอร์ชัน 3 และเวอร์ชัน 5 มีคุณสมบัติที่ว่า เมื่อกำหนดเวอร์ชันแล้ว เนมสเปซและชื่อเดียวกันจะแมปไปยัง UUID เดียวกัน อย่างไรก็ตาม ไม่สามารถระบุเนมสเปซหรือชื่อจาก UUID ได้ แม้ว่าจะระบุอย่างใดอย่างหนึ่งก็ตาม ยกเว้นโดยการค้นหาแบบบรูทฟอร์ซ RFC 4122 แนะนำเวอร์ชัน 5 (SHA-1) มากกว่าเวอร์ชัน 3 (MD5) เนื่องจากเชื่อว่า MD5 มีแนวโน้มที่จะเกิดการชนกันมากกว่า SHA-1 แม้ว่า MD5 จะเร็วกว่าเล็กน้อยก็ตาม RFC เตือนไม่ให้ใช้ UUID เวอร์ชันใด ๆ เป็นความสามารถด้านความปลอดภัย^{[ 1 ] : 16}

UUID เวอร์ชัน 4 ถูกสร้างขึ้นแบบสุ่ม เช่นเดียวกับ UUID อื่นๆ จะใช้สี่บิตเพื่อระบุเวอร์ชัน 4 และสองหรือสามบิตเพื่อระบุตัวแปร (10² _หรือ 110² _{สำหรับ}ตัวแปร 1 และ 2 ตามลำดับ) ดังนั้น สำหรับตัวแปร 1 (นั่นคือ UUID ส่วนใหญ่) UUID เวอร์ชัน 4 แบบสุ่มจะมีบิตตัวแปรและเวอร์ชันที่กำหนดไว้ล่วงหน้าหกบิต เหลือ 122 บิตสำหรับส่วนที่สร้างขึ้นแบบสุ่ม รวมเป็นทั้งหมด 2¹²² บิต^หรือ 5.3 × 10¹² บิต^{มี UUID เวอร์ชัน 4 รูปแบบที่ 1 ที่เป็นไปได้ 36 แบบ} (5.3 อัน เดซิลเลียน ) ส่วน UUID เวอร์ชัน 4 รูปแบบที่ 2 (GUID แบบดั้งเดิม) มีจำนวนน้อยกว่าครึ่งหนึ่ง เนื่องจากมีบิตสุ่มให้ใช้ได้น้อยลงหนึ่งบิต โดยใช้ไปสามบิตสำหรับรูปแบบนั้น

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

โครงสร้างมีดังต่อไปนี้:

นอกเหนือจากไทม์สแตมป์แล้ว ยังมีการจัดสรรบิตทั้งหมด 74 บิตสำหรับโครงสร้างเสริมสามแบบ (ไทม์สแตมป์ความแม่นยำพิเศษ, ตัวนับแบบมีค่าเริ่มต้น, ข้อมูลสุ่ม) แต่ยกเว้นลำดับของโครงสร้างและข้อกำหนดที่ว่าต้องใช้บิตไม่เกิน 12 บิตสำหรับไทม์สแตมป์ความแม่นยำพิเศษ จำนวนบิตที่จัดสรรให้กับแต่ละโครงสร้าง (รวมถึงอาจเป็น 0) และรายละเอียดของโครงสร้างนั้นขึ้นอยู่กับผู้พัฒนา ไทม์สแตมป์ 48 บิตอาจถูกเปลี่ยนแปลง ปรับเปลี่ยน หรือทำให้เบลอเพื่อความสม่ำเสมอและความเป็นส่วนตัว และมีการระบุไว้อย่างชัดเจนว่าไม่มีข้อกำหนดเกี่ยวกับความใกล้เคียงของไทม์สแตมป์กับเวลาจริง (Unix) แต่เจตนาชัดเจนว่าไทม์สแตมป์ควรมีความสม่ำเสมอและใกล้เคียงกับเวลา Unix และ RFC ระบุว่าควรใช้ UUID เวอร์ชัน 8 แบบกำหนดเองสำหรับการออกแบบที่ใช้ไทม์สแตมป์ซึ่งไม่ใช่เวลา Unix แตกต่างจาก UUID เวอร์ชันอื่นๆ UUID เวอร์ชัน 7 ไม่รวมที่อยู่ MAC และสามารถหลีกเลี่ยงปัญหาด้านความเป็นส่วนตัวที่เกี่ยวข้องกับที่อยู่ MAC ได้

ใน UUID แบบกำหนดเอง เวอร์ชันคือ8และบิตตัวแปรต้องเป็น10รวมทั้งหมด 6 บิต ส่วนอีก 122 บิตที่เหลือไม่ได้ระบุไว้

ตามเอกสาร RFC ระบุว่า UUID เวอร์ชัน 8 มีไว้สำหรับกรณีการใช้งานเชิงทดลองและเฉพาะของผู้ผลิต RFC แนะนำว่า ตัวอย่างเช่น เวอร์ชันนี้อาจใช้สำหรับตัวระบุแบบชื่อ/แฮชที่สร้างขึ้นด้วยฟังก์ชันแฮชที่ใหม่กว่าที่ระบุไว้สำหรับ UUID เวอร์ชัน 3 (MD5) และ 5 (SHA-1) นอกจากนี้ RFC ยังแนะนำว่าเวอร์ชัน 8 สามารถใช้สำหรับการออกแบบ UUID แบบอิงตามเวลาที่ไม่เหมาะสมกับเวอร์ชัน 6 หรือ 7 เช่น ยุคที่แตกต่างกัน

แต่เวอร์ชัน 8 ไม่ได้จำกัดอยู่แค่สถานการณ์เหล่านั้น โดยพื้นฐานแล้ว UUID เวอร์ชัน 8 ประกอบด้วยบิตทึบแสง 122 บิต รวมกับบิตเวอร์ชันและบิตตัวแปรอีก 6 บิต ทำให้สามารถแยกออกจากรูปแบบ UUID อื่นๆ ได้

แตกต่างจากเวอร์ชันอื่นๆ RFC ไม่ได้กำหนดรูปแบบบิตหรืออัลกอริธึมการสร้างที่เฉพาะเจาะจง และไม่ควรสันนิษฐานว่าค่าเหล่านั้นจะเป็นเอกลักษณ์ ต่างจาก UUID เวอร์ชัน 4 ซึ่งควรมี 122 บิตจากแหล่งกำเนิดความสุ่มที่มีเอนโทรปีสูง และความเป็นเอกลักษณ์และความต้านทานต่อการชนกันนั้นขึ้นอยู่กับการวิเคราะห์ทางคณิตศาสตร์ ความเป็นเอกลักษณ์ ความไม่สามารถคาดเดาได้ ความต้านทานต่อการชนกัน ความเป็นส่วนตัว ฯลฯ ของ UUID เวอร์ชัน 8 โดยทั่วไป สามารถเชื่อถือได้โดยอาศัยเพียงความเชื่อมั่นในแหล่งที่มา (หากทราบ) การประสานงานนอกระบบ หรือเอกสารภายนอกนอกเหนือจากมาตรฐาน นอกจากนี้ เช่นเดียวกับ UUID เวอร์ชันอื่นๆ ไม่มีแนวคิดเรื่องชนิดย่อยของเวอร์ชัน สิ่งนี้หมายความว่าสำหรับเวอร์ชัน 8 ในสถานการณ์ที่ UUID เวอร์ชัน 8 จากหลายแหล่งที่มาและวิธีการสร้างถูกรวมเข้าไว้ในสตรีมหรือฐานข้อมูลเดียว และบางส่วนพิสูจน์แล้วว่ามีปัญหา ไม่มีวิธีใดที่จะแยก UUID ตามแหล่งที่มาได้ นอกเหนือจากอาจจะโดยการแก้ไข หากเป็นไปได้

ตรงกันข้ามกับ UUID เวอร์ชันอื่นๆ เวอร์ชัน 1, 2 และ 6 นั้นใช้ที่อยู่ MAC จากการ์ดเครือข่าย เป็นพื้นฐาน โดยอาศัยเอกลักษณ์เฉพาะตัวบางส่วนจากตัวระบุที่ออกโดยหน่วยงานลงทะเบียนส่วนกลาง นั่นคือ ส่วน Organizationally Unique Identifier (OUI) ของที่อยู่ MAC ซึ่งออกโดยIEEEส่วนใหญ่ให้กับผู้ผลิตอุปกรณ์เครือข่าย^{[ 16 ]}เอกลักษณ์เฉพาะตัวของ UUID ที่ใช้ที่อยู่ MAC จากการ์ดเครือข่ายยังขึ้นอยู่กับผู้ผลิตการ์ดเครือข่ายที่กำหนดที่อยู่ MAC ที่ไม่ซ้ำกันให้กับการ์ดของตนอย่างถูกต้อง ซึ่งเช่นเดียวกับกระบวนการผลิตอื่นๆ ก็อาจเกิดข้อผิดพลาดได้ ที่อยู่ MAC อาจมาจากแหล่งอื่นที่ไม่ใช่การ์ดเครือข่าย ตัวอย่างเช่น เครื่องเสมือนจะได้รับที่อยู่ MAC จากช่วงที่สามารถกำหนดค่าได้ในไฮเปอร์ไวเซอร์ [ ^{17 ]} และระบบปฏิบัติการบางระบบอนุญาตให้ผู้ ใช้ ปลายทางปรับ ^แต่งที่อยู่ MAC ได้ โดยเฉพาะOpenWrt ^{[ 18 ]}เมื่ออุปกรณ์มี "ที่อยู่ MAC" EUI-64 64 บิต การใช้ 48 บิตที่สำคัญน้อยที่สุดตามที่ RFC แนะนำ อาจส่งผลให้ส่วนรหัสโหนดของ UUID ซ้ำกัน ดังนั้น รหัสโหนดที่อิงตามที่อยู่ MAC อาจไม่ซ้ำกันทั่วโลก

การใช้ที่อยู่ MAC ของการ์ดเครือข่ายของโหนดสำหรับรหัสโหนดมักหมายความว่า UUID เวอร์ชัน 1, 2 และ 6 สามารถติดตามกลับไปยังคอมพิวเตอร์ที่สร้าง UUID เหล่านั้นได้ UUID ดังกล่าวสามารถใช้เพื่ออนุมานประเภทของฮาร์ดแวร์ที่ใช้ในการสร้าง UUID ได้ บางครั้งเอกสารสามารถติดตามไปยังคอมพิวเตอร์ที่สร้างหรือแก้ไขได้ผ่าน UUID ที่ฝังอยู่ในซอฟต์แวร์ประมวลผลคำ ช่องโหว่ ความเป็นส่วนตัวนี้ถูกใช้เมื่อค้นหาผู้สร้างไวรัสMelissa ^{[ 19 ]}

RFC 9562 ^{[ 9 ]}อนุญาตให้แทนที่ที่อยู่ MAC ใน UUID เวอร์ชัน 1, 2 หรือ 6 ด้วยรหัสโหนดแบบสุ่ม 48 บิตได้ ไม่ว่าจะเป็นเพราะโหนดไม่มีที่อยู่ MAC หรือเพราะไม่ต้องการรวมไว้ ในกรณีนั้น RFC กำหนดให้บิตที่มีค่าน้อยที่สุดของอ็อกเท็ตแรกของรหัสโหนดควรตั้งค่าเป็น 1 ^{[ 1 ]}ซึ่งสอดคล้องกับ บิต มัลติแคสต์ในที่อยู่ MAC และการตั้งค่านี้ใช้เพื่อแยกความแตกต่างของ UUID ที่รหัสโหนดถูกสร้างขึ้นแบบสุ่มจาก UUID ที่อิงตามที่อยู่ MAC จากการ์ดเครือข่าย ซึ่งโดยทั่วไปจะมี ที่อยู่ MAC แบบยูนิแคสต์^{[ 1 ]}

เวอร์ชัน 1, 2, 6 และ 7 อิงตามและเปิดเผยเวลาที่สร้าง UUID ซึ่งมักจะตรงกับการสร้างบันทึกหรือเหตุการณ์ทางประวัติศาสตร์ หากเชื่อมโยงกับบุคคลหรือกิจกรรมของพวกเขา อาจสามารถอนุมานอายุของบุคคลหรือเวลาที่แน่นอนของกิจกรรมของพวกเขาจาก UUID ได้ อาจสามารถระบุได้จาก UUID ที่เรียงลำดับตามเวลาที่เพิ่มขึ้นเรื่อยๆ ว่าระบบเริ่มใช้งานเมื่อใด หรือวัตถุใดในระบบเป็นของใหม่หรือได้รับการอัปเดตเมื่อเร็วๆ นี้ หากวัตถุที่ระบุแสดงถึงคำสั่งซื้อผลิตภัณฑ์หรือการลงทะเบียนผู้ใช้ ตัวอย่างเช่น อาจสามารถระบุการเติบโตของผู้ใช้หรือปริมาณการขายเมื่อเวลาผ่านไปจาก UUID ได้ ดังนั้น UUID ที่อิงตามเวลา หากเปิดเผยต่อสาธารณะ อาจทำให้ข้อมูลส่วนบุคคลหรือข้อมูลทางธุรกิจรั่วไหล ก่อให้เกิดความกังวลเกี่ยวกับความเป็นส่วนตัว และอำนวยความสะดวกใน การ ขุด ข้อมูล ที่ไม่พึงประสงค์

ในส่วนของการเรียงลำดับตามเวลาและการจัดเรียง UUID นั้น เวอร์ชัน 1 และ 2 เริ่มต้น "จากตรงกลาง" โดยใช้บิตต่ำสุด 32 บิตของไทม์สแตมป์ เวอร์ชันทั้งสองนี้ รวมถึงเวอร์ชัน 3–5 และ 8 ไม่ได้เรียงลำดับตามเวลาแบบเรียงตามตัวอักษร บทบาทของไทม์สแตมป์ในเวอร์ชัน UUID เหล่านี้ไม่ใช่เพื่อให้ UUID สามารถเรียงลำดับตามเวลาได้ง่าย แต่เพื่อให้เกิดความเป็นเอกลักษณ์สากลโดยการกำหนดรุ่นในพื้นที่และเวลา

เวอร์ชัน 6 และ 7 ให้ความสำคัญกับบทบาทของเวลาประทับในการจัดทำดัชนีฐานข้อมูล ทำให้สามารถเรียงลำดับระเบียนตามลำดับเวลาได้ อย่างไรก็ตาม RFC 9562 ให้ความยืดหยุ่นในการใช้งานอย่างมากสำหรับเวอร์ชัน 7 โดยกำหนดกรอบการทำงานทั่วไปแทนที่จะเป็นรูปแบบบิตที่ตายตัวสำหรับความแม่นยำของเวลาประทับระดับต่ำกว่ามิลลิวินาที ตัวนับ และความสุ่ม

ข้อกำหนดอนุญาตให้ปรับหรือ "ทำให้คลุมเครือ" ไทม์สแตมป์ Unix 48 บิตเพื่อรักษาความเป็นเอกรูป (เพื่อให้แน่ใจว่า ID ที่สร้างขึ้นอย่างรวดเร็วจะเพิ่มขึ้นเสมอ) หรือเพื่อเพิ่มความเป็นส่วนตัว เนื่องจาก RFC ไม่ได้กำหนดค่าเบี่ยงเบนสูงสุดที่เข้มงวดจากเวลา Unix จริง การใช้งานที่แตกต่างกันอาจแตกต่างกันไปในวิธีการสร้างสมดุลระหว่างความถูกต้องตามลำดับเวลาและข้อกำหนดอื่นๆ เหล่านี้^{[ 20 ]}

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

RFC 9562 ไม่ได้กำหนดจำนวนบิตสุ่มขั้นต่ำสำหรับเวอร์ชัน 7 โดยอนุญาตให้ฟิลด์ความแม่นยำระดับมิลลิวินาทีและฟิลด์ตัวนับความสม่ำเสมอครอบครองส่วนที่เหลือของโครงสร้าง 128 บิต ดังนั้น ความต้านทานต่อการชนและการคาดเดาจึงขึ้นอยู่กับการจัดสรรบิตเหล่านี้ของการใช้งานเฉพาะนั้นๆ อย่างสมบูรณ์^{[ 21 ]}

UUID ที่เป็นค่าว่าง00000000-0000-0000-0000-000000000000(นั่นคือ บิตทั้งหมดเป็นค่าว่าง) สามารถใช้เพื่อแสดงแนวคิดของ "ไม่มีค่าดังกล่าว" ได้^{[ 9 ]}นี่คือ UUID ของ NCS แบบ "variant 0" ที่มีตระกูลแอดเดรสเป็น "0" ซึ่งกำหนดไว้ใน NCS ว่า "ไม่ได้ระบุหรือไม่ได้เริ่มต้น" UUID ที่เป็นค่าสูงสุด บางครั้งเรียกว่า Omni UUID ก็เป็นค่าว่างFFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF(นั่นคือ บิตทั้งหมดเป็นค่าที่ตั้งไว้) ซึ่งมีจุดประสงค์เพื่อใช้ในการแสดง "จุดสิ้นสุดของรายการ UUID" ^{[ 9 ]}

ในขั้นต้น Apollo Computer ออกแบบ UUID โดยใช้รูปแบบสายดังต่อไปนี้ โดยอิงจากไทม์สแตมป์และตัวระบุโหนด คล้ายกับเวอร์ชัน 1 และ 6 ^{[ 4 ] [ 22 ]}

RFC 4122 ได้รวม UUID ของ NCS เดิมเข้าไว้เป็น "variant 0" ของรูปแบบใหม่ โดยการซ้อนทับบิต variant ของรูปแบบใหม่กับฟิลด์ NCS Address Family เนื่องจากค่า address family สูงสุดที่กำหนดไว้ใน NCS คือ 13 (เลขฐานสิบหก 00 ถึง 0D) บิตที่มีนัยสำคัญที่สุดในอ็อกเท็ต variant จึงเป็น 0 เสมอสำหรับ UUID ของ NCS ที่มีอยู่ ในขณะที่บิตนี้เป็น 1 ใน variant 3 ตัวใหม่ของ IETF โดยสรุปแล้ว address family ของ NCS 0–127 กลายเป็น "variant 0" ใหม่ ในขณะที่พื้นที่หมายเลขของ address family ของ NCS 128–255 ซึ่งไม่ได้กำหนดไว้ใน NCS ได้ถูกจัดสรรใหม่ให้กับ UUID ของ IETF และ Microsoft variant 1 ถึง 3 ผลลัพธ์ก็คือ UUID ของ NCS เดิมและ UUID variant 1 ถึง 3 ถูกแยกออกจากกันและสามารถอยู่ร่วมกันได้ในฐานข้อมูลเดียวกันและบนช่องทางการสื่อสารเดียวกัน

UUID ของ Apollo NCS รุ่นเก่ามีรูปแบบตามที่อธิบายไว้ในตารางก่อนหน้า ตัวแปร UUID ของ OSF DCE อธิบายไว้ใน RFC 9562 ^{[ 9 ]} UUID ของ Microsoft COM / DCOM มีตัวแปรที่อธิบายไว้ในเอกสารของ Microsoft แต่สำหรับเวอร์ชัน 1 ถึง 5 โดยทั่วไปจะเหมือนกับตัวแปร DCE ยกเว้นบิตตัวแปรเพิ่มเติมและการเรียงลำดับไบต์ (ดูส่วนถัดไป) ตัวแปร 2 ไม่มีเวอร์ชัน 6 ถึง 8

การตีความบล็อกบิตต่างๆ จะแตกต่างกันในตัวแปรที่ 1 และ 2 ตาม "เวอร์ชัน" ในตัวแปรที่ 2 ข้อมูล data_a, data_b และ version|data_c จะถูกสลับไบต์ ในขณะที่ variant|data_d และ data_e จะไม่ถูกสลับไบต์

UUID ของ Variant 1 จะถูกเข้ารหัสตามลำดับในรูปแบบbig-endianตัวอย่างเช่น00112233-4455-6677-8899-aabbccddeeffจะถูกเข้ารหัสเป็นไบต์^{[ 23 ] [ 24 ]}00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff

ในทางตรงกันข้าม UUID แบบที่ 2 ("GUID"): ซึ่งเคยใช้ในไลบรารี Microsoft COM/OLE ในอดีต มี รูปแบบ mixed-endianโดยฟิลด์สามฟิลด์แรก (ที่สอดคล้องกับซับฟิลด์ timestamp เวอร์ชัน 1) เป็นแบบlittle-endianในขณะที่สองฟิลด์สุดท้ายจะถูกส่งออกเป็น อาร์เรย์ไบต์ แบบ big-endianตัวอย่าง UUID ข้างต้น หากเป็น UUID แบบที่ 2 จะถูกเข้ารหัสบนสายเป็น33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff[ ^{25 ] [ 26 ] ทุก}เวอร์ชันภายใต้แบบที่ 2 จะถูกส่งออกด้วยลำดับไบต์นี้ รวมถึงเวอร์ชันที่ไม่มีฟิลด์ตัวเลข เช่น 3, 4 และ 5

ในกรณีส่วนใหญ่ UUID จะถูกแสดงเป็นค่าเลขฐานสิบหกคั่นด้วยเครื่องหมายขีดกลาง รูปแบบที่ใช้กันมากที่สุดคือรูปแบบ 8-4-4-4-12 ซึ่งเป็นสตริงของตัวเลขฐานสิบหก 32 หลักพร้อมเครื่องหมายขีดกลางสี่ตัวxxxxxxxx-xxxx-vxxx-wxxx-xxxxxxxxxxxxเครื่องหมายขีดกลางจะคั่นฟิลด์เวอร์ชัน 1 แต่รูปแบบเดียวกันนี้มักใช้สำหรับทุกเวอร์ชัน ตัวเลขฐานสิบหกแต่ละหลักแทน 4 บิตvแทนส่วนของเวอร์ชัน และบิตลำดับสูงหนึ่งถึงสามของwคือตัวแปร รูปแบบรีจิสทรีของ Windows ก็เหมือนกัน แต่จะใส่ UUID ไว้ใน{}วงเล็บปีกกา ความแตกต่างของการเรียงลำดับไบต์ของตัวแปร 2 นั้นใช้ได้กับการจัดเก็บแบบไบนารีหรือการส่งข้อมูลผ่านสาย และไม่มีผลต่อการแสดงผล UUID ในรูปแบบข้อความ

แม้ว่าจะยังมีการละเว้นเครื่องหมายยัติภังค์อยู่บ้างในบางครั้ง แต่รูปแบบที่มีเครื่องหมายยัติภังค์นั้นถูกนำมาใช้ในระบบเวอร์ชันใหม่กว่า ก่อนหน้านั้น รูปแบบ Apollo แบบเดิมใช้รูปแบบที่แตกต่างออกไปเล็กน้อย34dc23469000.0d.00.00.7c.5f.00.00.00ส่วนแรกคือเวลา (time_high และ time_low รวมกัน) ฟิลด์ที่สงวนไว้จะถูกข้ามไป ฟิลด์ตระกูลจะอยู่หลังจุดแรกโดยตรง ดังนั้นในกรณีนี้0d(13 ในเลขฐานสิบ) สำหรับDDS (Data Distribution Service)ส่วนที่เหลือแต่ละส่วนคั่นด้วยจุด คือไบต์ของโหนด

โดยทั่วไปนิยมใช้ตัวเลขฐานสิบหกตัวพิมพ์เล็ก มาตรฐาน ITU-T Rec. X.667 กำหนดให้ใช้ตัวพิมพ์เล็กในการสร้าง แต่ก็กำหนดให้ยอมรับตัวพิมพ์ใหญ่ในการป้อนข้อมูลด้วย เนื่องจาก UUID เป็นตัวเลข 128 บิต รูปแบบอื่นจึงเป็นไปได้ และพบเห็นได้บ้าง เช่น ตัวเลขฐานสิบหรือเลขฐานสอง

RFC 4122 ^{[ 1 ]}ลงทะเบียนเนมสเปซ "uuid" สำหรับ URN ซึ่งทำให้สามารถสร้าง URN จาก UUID ได้ เช่น โดยurn:uuid:550e8400-e29b-41d4-a716-446655440000ใช้รูปแบบ 8-4-4-4-12 ปกติสำหรับสิ่งนี้

นอกจากนี้ยังสามารถสร้างOIDจาก UUID ได้ ซึ่งในทางกลับกันก็ให้วิธีการสร้าง URN จาก UUID ได้อีกวิธีหนึ่ง OID ในตัวอย่างก่อนหน้านี้คือ2.25.113059749145936325402354257176981405696รูปแบบเลขฐานสิบที่ไม่ระบุเครื่องหมายของ UUID จะมีคำนำหน้าเป็น2.25ซึ่งแสดงถึง{joint-iso-itu-t(2) uuid(25)}"ส่วนโค้ง" ภายในเนมสเปซของ OID อาจมีการเพิ่มคำนำหน้าอีกurn:oid:เพื่อสร้างรูปแบบ URN แบบที่สองสำหรับ UUID โดยทั่วไปแล้วuuidแนะนำให้ใช้ URN แบบ มากกว่าoidURN แบบ

การชนกันเกิดขึ้นเมื่อมีการสร้าง UUID เดียวกันมากกว่าหนึ่งครั้งและถูกกำหนดให้กับตัวอ้างอิงที่แตกต่างกัน ในกรณีของ UUID มาตรฐานเวอร์ชัน 1, 2 หรือ 6 จำนวนมากที่ใช้ที่อยู่ MAC และ/หรือการประทับเวลาที่ไม่ซ้ำกัน การชนกันจะเกิดขึ้นได้เฉพาะจากข้อผิดพลาด เช่น ปัญหาในการผลิต นาฬิกาผิดเพี้ยน หรือข้อบกพร่องของซอฟต์แวร์

UUID ที่ซ้ำกันอาจเกิดขึ้นได้เนื่องจากข้อผิดพลาดในเวอร์ชัน UUID ที่สร้างขึ้นโดยใช้กระบวนการต่างๆ เช่น การสร้างเลขสุ่มหรือการแฮช ตัวอย่างเช่น การมีแหล่งกำเนิดความสุ่มที่มีเอนโทรปีสูงนั้นมีความสำคัญเมื่อสร้าง UUID เวอร์ชัน 4 แต่การชนกันของ UUID ก็อาจเกิดขึ้นได้โดยไม่มีข้อผิดพลาดกับ UUID ดังกล่าว เนื่องจากความบังเอิญ — "โชคไม่ดี"

ความน่าจะเป็นของสิ่งนี้โดยปกติมีขนาดเล็กมากจนสามารถละเลยได้ และสามารถคำนวณได้อย่างแม่นยำโดยอาศัยการวิเคราะห์ปัญหาวันเกิด^{[ 27 ]}ตัวอย่างเช่น จำนวน UUID เวอร์ชัน 4 แบบสุ่มที่ต้องสร้างขึ้นเพื่อให้มีความน่าจะเป็น 50% ของการชนกันอย่างน้อยหนึ่งครั้งคือ 2.71 ควินทิลเลียน ซึ่งคำนวณได้ดังนี้: ^{[ 28 ]}

จำนวนนี้เทียบเท่ากับการสร้าง UUID 1 พันล้านรายการต่อวินาที เป็นเวลาประมาณ 86 ปี ไฟล์ที่มี UUID จำนวนมากขนาดนี้ โดยแต่ละ UUID มีขนาด 16 ไบต์ จะมีขนาดประมาณ 43.4  เอ็กซาไบต์ (37.7  EiB ) ซึ่งไฟล์ที่แสดงเฉพาะตัวระบุจะมีขนาดใหญ่กว่าฐานข้อมูลที่ใหญ่ที่สุดในปัจจุบันหลายเท่าตัว โดยฐานข้อมูลที่ใหญ่ที่สุดในปัจจุบันมีขนาดประมาณ 100 เพตาไบต์ (เช่น ดัชนีเว็บของ Google) หากสร้างตามมาตรฐานแล้ว UUID ที่ซ้ำกันมีแนวโน้มที่จะเกิดจากการเปลี่ยนแปลงบิต (ที่เรียกว่าSingle-event upset ) ที่เกิดจากรังสีคอสมิกที่ผ่านหน่วยความจำหรือที่เก็บข้อมูลบนดิสก์ มากกว่าที่จะเกิดจากความผิดพลาดโดยบังเอิญในขณะสร้าง UUID

จำนวน UUID เวอร์ชัน 4 ที่น้อยที่สุดที่ต้องสร้างขึ้นเพื่อให้ความน่าจะเป็นที่จะพบการชนกันอย่างน้อยหนึ่งครั้งเป็นpนั้น สามารถประมาณได้ด้วยสูตร

ดังนั้น ความน่าจะเป็นที่จะพบข้อมูลซ้ำกันใน UUID เวอร์ชัน 4 ที่สร้างขึ้นอย่างถูกต้องจำนวน 103 ล้านล้านรายการ จึงมีเพียงหนึ่งในพันล้าน

ประเภทของระบบไฟล์หลายประเภท (เช่นext4และBtrfs ) ใช้ UUID เพื่อระบุระบบไฟล์แต่ละระบบให้กับระบบปฏิบัติการอย่างเฉพาะเจาะจง ( NTFSและFAT32ไม่ใช้ UUID แต่ใช้ UID (Unique identifier) ​​ที่สั้นกว่าแทน) ^{[ 29 ]}

เครื่องมือพื้นที่ผู้ใช้ระบบไฟล์^{[ 30 ]}ซึ่งส่วนใหญ่มาจากการใช้งานดั้งเดิมโดยTheodore Ts'o [ ^{14 ] จึง}ใช้ UUID

ไฟล์/etc/fstabอาจกำหนดจุดเชื่อมต่อโดยอิงจาก UUID เหล่านี้ (หรือ UID สำหรับพาร์ติชั่นระบบ FAT32 EFI (ESP)):

# device-uuid mount-point fs-type options dump pass UUID = b18e3b6c-ccb7-4308-b527-35e5e6ee2145 / btrfs defaults 0 0 UUID = 103C-86D6 /efi vfat utf8 0 2 UUID = 64f3cb6a-e70e-45e5-8b90-d86cddbab7bb swap swap defaults 0 0 UUID = eda746c6-1f1b-4cf1-9225-d8b0b46511cc /mnt/Stuff btrfs defaults 0 0

ตารางพาร์ติชัน GUID (GPT) ใช้ UUID (เรียกในที่นี้ว่า "GUID") เพื่อระบุพาร์ติชันและประเภทของพาร์ติชัน รหัสพาร์ติชันที่ไม่ซ้ำกันจะถูกกำหนดโดยระบบปฏิบัติการในแต่ละเครื่อง ส่วนรหัสประเภทพาร์ติชันเป็นตัวเลขที่รู้จักกันดี ซึ่งโดยปกติจะถูกกำหนดโดยระบบปฏิบัติการหรือผู้ผลิตฮาร์ดแวร์

มี GUID หลายประเภทที่ใช้ในComponent Object Model (COM) ของ Microsoft:

• IID – ตัวระบุอินเทอร์เฟซ (ตัวที่ลงทะเบียนในระบบจะถูกเก็บไว้ในรีจิสทรีของ Windowsที่[HKEY_CLASSES_ROOT\Interface]^{[ 31 ]} )
• คลิซไอด์– ตัวระบุคลาส (จัดเก็บไว้ที่[HKEY_CLASSES_ROOT\CLSID]) ในทางปฏิบัติแล้ว มันไม่ได้แยกออกจาก พื้นที่ IID อย่างสิ้นเชิง เพราะการเข้าถึงอินเทอร์เฟซจากระยะไกลอาจต้องใช้พร็อกซี/สตับออบเจ็กต์ซึ่งชุดเครื่องมือบางชุดเคยสร้างขึ้นโดยมีCLSIDเท่ากับIID ของอินเทอร์เฟ ซ
• LIBID – ตัวระบุไลบรารีประเภท; (จัดเก็บไว้ที่[HKEY_CLASSES_ROOT\TypeLib]^{[ 32 ]} )
• CATID – ตัวระบุหมวดหมู่ (การปรากฏของ CATID ในคลาสจะระบุว่าคลาสนั้นเป็นของหมวดหมู่คลาสบางประเภทตามที่ระบุไว้ใน[HKEY_CLASSES_ROOT\Component Categories]^{[ 33 ]} )

UUID มักใช้เป็นคีย์เฉพาะในตารางฐานข้อมูล ฟังก์ชัน NEWIDในMicrosoft SQL Serverเวอร์ชัน 4 Transact-SQLจะส่งคืน UUID เวอร์ชัน 4 แบบสุ่มมาตรฐาน ในขณะที่ ฟังก์ชัน NEWSEQUENTIALIDจะส่งคืนตัวระบุ 128 บิตที่คล้ายกับ UUID ซึ่งจะถูกกำหนดให้เพิ่มขึ้นตามลำดับจนกว่าจะมีการรีบูตระบบครั้งถัดไป^{[ 34 ]} ฟังก์ชัน SYS_GUIDของOracle Databaseไม่ได้ส่งคืน GUID มาตรฐาน แม้จะมีชื่อเช่นนั้นก็ตาม แต่จะส่งคืนค่า RAW 16 ไบต์ 128 บิต โดยอิงจากตัวระบุโฮสต์และตัวระบุโปรเซสหรือเธรด ซึ่งค่อนข้างคล้ายกับ GUID ^{[ 35 ]} PostgreSQLมีชนิดข้อมูลUUID ^{[ 36 ]}และสามารถสร้าง UUID เวอร์ชันส่วนใหญ่ได้โดยใช้ฟังก์ชันจากโมดูล^{[ 37 ] [ 38 ]} MySQLมี ฟังก์ชัน UUIDที่สร้าง UUID เวอร์ชัน 1 มาตรฐาน^{[ 39 ]}

ลักษณะสุ่มของ UUID มาตรฐานเวอร์ชัน 3, 4 และ 5 และลำดับของฟิลด์ภายในเวอร์ชันมาตรฐาน 1 และ 2 อาจสร้างปัญหาเกี่ยวกับตำแหน่งที่ตั้ง ของฐานข้อมูล หรือประสิทธิภาพเมื่อใช้ UUID เป็นคีย์หลักตัวอย่างเช่น ในปี 2545 Jimmy Nilsson รายงานว่าประสิทธิภาพของ Microsoft SQL Server ดีขึ้นอย่างมากเมื่อมีการแก้ไข UUID เวอร์ชัน 4 ที่ใช้เป็นคีย์ให้มีส่วนต่อท้ายที่ไม่สุ่มตามเวลาของระบบ การจัดลำดับใหม่และการเข้ารหัส UUID เวอร์ชัน 1 และ 2 เพื่อให้การประทับเวลามาก่อน สามารถหลีกเลี่ยงการสูญเสียประสิทธิภาพการแทรกได้^{[ 40 ]} นี่คือเหตุผลสำหรับเวอร์ชัน 6 และ 7 ของตัวแปร 1 (DCE) ซึ่ง ได้รับการกำหนดมาตรฐานใน RFC 9562 ^{[ 9 ]}

UEFIและACPIเป็นตัวอย่างที่ใช้ GUID ^{[ 41 ]}

• การโจมตีวันเกิด
• ตัวระบุวัตถุ (OID)
• ตัวระบุทรัพยากรสากล (URI)
• รหัสเกล็ดหิมะ
• ชื่อสากล (WWN)

• ข้อแนะนำ ITU-T X.667 (เข้าถึงได้ฟรี)
• ISO/IEC 9834-8:2014 (เสียค่าใช้จ่าย)
• เอกสารทางเทคนิค TN2166 - ความลับของ GPT - Apple Developer
• เอกสารเกี่ยวกับ UUID - Apache Commons Id
• คีย์ CLSID - เอกสารของ Microsoft
• รหัสระบุตัวตนที่ไม่ซ้ำกันทั่วโลก - ห้องสมุดของ The Open Group
• เครื่องมือถอดรหัส UUID
• ประวัติโดยย่อของ UUID
• ทำความเข้าใจเกี่ยวกับวิธีการสร้าง UUID