सार्वभौमिक अद्वितीय पहचानकर्ता

सार्वभौमिक अद्वितीय पहचानकर्ता (यूयूआईडी - UUID) कंप्यूटर प्रणाली में जानकारी के लिए उपयोग की जाने वाली 128 बिट नाममात्र संख्या को उपयोग करता हैं। इस प्रकार विश्व स्तर पर विशिष्ट पहचानकर्ता (GUID) शब्द का उपयोग भी किया जाता है।

मानक विधियों के अनुसार उत्पन्न होने पर, यूयूआईडी व्यावहारिक उद्देश्यों के लिए अद्वितीय होते हैं। अधिकांश अन्य सांख्यकिक योजनाओं के विपरीत, उनकी विशिष्टता केंद्रीय पंजीकरण प्राधिकरण या उन्हें उत्पन्न करने वाली पार्टियों के बीच होने वाले समन्वय पर निर्भर नहीं करती है। जबकि यह संभावना है कि UUID को डुप्लिकेट किया जाएगा पर वह शून्य नहीं है,और यह सामान्यतः नगण्य होने के लिए शून्य के अधिक समीप माना जाता है।

इस प्रकार, कोई भी यूयूआईडी बना सकता है और इसका उपयोग निकट निश्चितता के साथ किसी चीज़ की पहचान करने के लिए किया जा सकता है कि पहचानकर्ता उस चीज़ की नकल नहीं करता है जो पहले से ही किसी और चीज़ की पहचान करने के लिए बनाई जाती है या बनाई जाएगी। स्वतंत्र पार्टियों द्वारा यूयूआईडी के साथ लेबल की गई जानकारी को बाद में एकल डेटाबेस में जोड़ा जाता है और उसी चैनल पर प्रेषित किया जा सकता है, जिसमें दोहराव की नगण्य संभावना होती है।

यूयूआईडी को अपनाना व्यापक है, कई कंप्यूटिंग प्लेटफॉर्म उन्हें उत्पन्न करने और उनके शाब्दिक प्रतिनिधित्व को पार्स करने के लिए समर्थन प्रदान करते हैं।

इतिहास
1980 के दशक में अपोलो कंप्यूटर ने मूल रूप से नेटवर्क कंप्यूटिंग प्रणाली (NCS) में और बाद में ओपन सॉफ्टवेयर फाउंडेशन (OSF) वितरित कंप्यूटिंग पर्यावरण (डीसीई) में यूयूआईडी का उपयोग किया गया हैं। इस प्रकार डीसीई यूयूआईडी का प्रारंभिक डिज़ाइन NCS यूयूआईडी पर आधारित था, जिसका डिजाइन इसके अतिरिक्त (64-बिट कंप्यूटिंग या 64-बिट) अद्वितीय पहचानकर्ताओं से प्रेरित था और अपोलो कंप्यूटर द्वारा डिजाइन किए गए ऑपरेटिंग प्रणाली डोमेन/ओएस में व्यापक रूप से परिभाषित और उपयोग किया गया था। इसके पश्चात, माइक्रोसाॅफ्ट विंडोज प्लेटफ़ॉर्म ने डीसीई डिज़ाइन को विश्व स्तर पर अद्वितीय पहचानकर्ता (GUIDs) के रूप में अपनाया गया था। RFC 4122 ने यूयूआईडी के लिए URN नाम स्थान पंजीकृत किया और इसी तकनीकी सामग्री के साथ, पहले के विनिर्देशों को दोहराया गया था।

जब जुलाई 2005 में RFC 4122 को प्रस्तावित IETF मानक के रूप में प्रकाशित किया गया था, ITU ने भी पिछले मानकों और RFC 4122 के प्रारंभिक संस्करणों के आधार पर यूयूआईडी को मानकीकृत किया गया था।

मानक
वितरित कंप्यूटिंग पर्यावरण (डीसीई) के मुख्य भाग के रूप में यूयूआईडी को ओपन सॉफ्टवेयर फाउंडेशन (ओएसएफ) द्वारा मानकीकृत किया गया है।

UUIDs को मानकीकरण के लिए अंतर्राष्ट्रीय संगठन/अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल कमीशन 11578:1996 सूचना प्रौद्योगिकी - ओपन सिस्टम इंटरकनेक्शन - सुदूर प्रणाली संदेश (RPC) और हाल ही में ITU-T Rec में प्रलेखित किया गया है। X.667 | मानकीकरण के लिए अंतर्राष्ट्रीय संगठन/अंतर्राष्ट्रीय इलेक्ट्रोटेक्निकल कमीशन 9834-8:2005।

इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) ने Standards-Track RFC 4122 प्रकाशित किया,तकनीकी रूप से ITU-T Rec के समकक्ष। X.667 | आईएसओ/आईईसी 9834-8।

प्रारूप
इसके विहित शाब्दिक प्रतिनिधित्व में, एक UUID के 16 ऑक्टेट (कंप्यूटिंग) को 32 हेक्साडेसिमल (बेस-16) अंकों के रूप में दर्शाया जाता है, जो कुल योग के लिए 8-4-4-4-12 के रूप में हाइफ़न द्वारा अलग किए गए पांच समूहों में प्रदर्शित होता है। 36 अक्षरों का (32 हेक्साडेसिमल वर्ण और 4 हाइफ़न)। उदाहरण के लिए:

चार बिट M और 1- से 3-बिट N फ़ील्ड यूयूआईडी के प्रारूप को ही कोड करते हैं।

अंकों के चार बिट  UUID संस्करण हैं, और अंकों के 1 से 3 सबसे महत्वपूर्ण बिट हैं   UUID वैरिएंट को कोड करें। (नीचे सार्वभौमिक अद्वितीय पहचानकर्ता#वेरिएंट|देखें।) उदाहरण में, M है , और एन है   (10xx2), जिसका अर्थ है कि यह संस्करण-1, संस्करण-1 UUID है; यानी, एक समय-आधारित DCE/ RFC 4122 UUID।

विहित 8-4-4-4-12 प्रारूप स्ट्रिंग UUID के 16 बाइट्स के लिए रिकॉर्ड लेआउट पर आधारित है: ये फ़ील्ड संस्करण 1 और 2 UUIDs (अर्थात, समय-आधारित UUIDs) के अनुरूप हैं, लेकिन समान 8-4-4-4-12 प्रतिनिधित्व का उपयोग सभी UUIDs के लिए किया जाता है, यहाँ तक कि अलग-अलग निर्मित UUIDs के लिए भी।

RFC 4122 धारा 3 के लिए आवश्यक है कि इनपुट पर केस-असंवेदनशील होने के साथ-साथ अक्षरों को लोअर केस में उत्पन्न किया जाए।

Microsoft GUIDs को कभी-कभी आस-पास के ब्रेसिज़ के साथ प्रदर्शित किया जाता है:

इस प्रारूप को विंडोज रजिस्ट्री प्रारूप से भ्रमित नहीं होना चाहिए, जो घुंघराले ब्रेसिज़ के भीतर प्रारूप को संदर्भित करता है।

RFC 4122 यूयूआईडी के लिए समान संसाधन का नाम (URN) नेमस्पेस परिभाषित करता है। URN के रूप में प्रस्तुत किया गया UUID इस प्रकार दिखाई देता है: :

एनकोडिंग
यूयूआईडी का बाइनरी एन्कोडिंग प्रणाली के बीच भिन्न होता है। संस्करण 1 यूयूआईडी, आजकल सबसे सरल संस्करण, बड़े एंडियन प्रारूप में एन्कोड किया गया है। उदाहरण के लिए,  बाइट्स के रूप में एन्कोड किया गया है

वैरिएंट 2 यूयूआईडी, ऐतिहासिक रूप से माइक्रोसाॅफ्ट के कंपोनेंट ऑब्जेक्ट मॉडल या COM/OLE लाइब्रेरी में उपयोग किया जाता है, छोटे-एंडियन प्रारूप का उपयोग करता है, किन्तु UUID के पहले तीन घटकों के साथ मिश्रित-एंडियन दिखाई देता है, जो कि छोटे-एंडियन और अंतिम दो बड़े-एंडियन के कारण होता है स्ट्रिंग के रूप में स्वरूपित होने पर विलुप्त बाइट डैश के रूप में होता हैं। उदाहरण के लिए,  को            बाइट्स के रूप में एन्कोड किया गया है।  वैरिएंट 2 में '88' बाइट 'c8' क्यों बन जाती है, इस बारे में विवरण के लिए वैरिएंट पर अनुभाग देखें।

संस्करण
यूयूआईडी का भिन्न क्षेत्र, या N स्थिति उनके प्रारूप और एन्कोडिंग को इंगित करता है। RFC 4122 1 से 3 बिट्स की लंबाई के चार रूपों को परिभाषित करता है:
 * संस्करण 0 (एक-बिट पैटर्न 0xxx द्वारा दर्शाया गया है2, एन = ) 1988 के आसपास विकसित अब अप्रचलित अपोलो नेटवर्क कंप्यूटिंग प्रणाली 1.5 UUID प्रारूप के साथ पश्चगामी संगतता के लिए है। UUID के पहले 6 ऑक्टेट 48-बिट टाइमस्टैम्प हैं (1 जनवरी 1980 UTC के बाद से समय की 4-माइक्रोसेकंड इकाइयों की संख्या), अगले 2 ऑक्टेट आरक्षित हैं, अगला ऑक्टेट पता परिवार है, और अंतिम 7 ऑक्टेट पता परिवार द्वारा निर्दिष्ट फॉर्म में 56-बिट होस्ट आईडी हैं। चूंकि विवरण में भिन्न, आधुनिक संस्करण-1 यूयूआईडी के साथ समानता स्पष्ट है। वर्तमान UUID विनिर्देशन में भिन्न बिट्स NCS यूयूआईडी में पता परिवार ऑक्टेट के उच्च बिट्स के साथ मेल खाते हैं। चूंकि पता परिवार 0..255 की सीमा में मान रख सकता है, केवल मान 0..13 कभी परिभाषित किए गए थे। तदनुसार, संस्करण-0 बिट पैटर्न  ऐतिहासिक NCS यूयूआईडी के साथ विरोध से बचा जाता है, यदि कोई अभी भी डेटाबेस में उपस्तिथ है।
 * संस्करण 1 (10xx2, एन =, 2 बिट्स) को मूल इंटरनेट ड्राफ्ट के लेखकों के नाम पर RFC 4122 /डीसीई 1.1 यूयूआईडी, या Leach-Salz यूयूआईडी के रूप में संदर्भित किया जाता है।
 * वैरिएंट 2 (110x2, N = , 3 बिट्स) को RFC में आरक्षित, माइक्रोसाॅफ्ट Corporation पश्चगामी संगतता के रूप में चित्रित किया गया है और इसका उपयोग माइक्रोसाॅफ्ट विंडोज प्लेटफ़ॉर्म पर प्रारंभिक GUID के लिए किया गया था। यह वैरिएंट 1 से केवल बाइनरी स्टोरेज या ट्रांसमिशन में एंडियननेस से भिन्न होता है: संस्करण -1 यूयूआईडी नेटवर्क (बिग-एंडियन) बाइट ऑर्डर का उपयोग करते हैं, जबकि संस्करण -2 GUIDs UUID के कुछ उपक्षेत्रों के लिए नेटिव (लिटिल-एंडियन) बाइट ऑर्डर का उपयोग करते हैं।
 * आरक्षित को 3-बिट वैरिएंट बिट पैटर्न 111x के रूप में परिभाषित किया गया है2 (एन = ).

संस्करण 1 और 2 वर्तमान यूयूआईडी विनिर्देश द्वारा उपयोग किए जाते हैं। उनके शाब्दिक अभ्यावेदन में, संस्करण बिट्स को छोड़कर संस्करण 1 और 2 समान हैं। बाइनरी प्रतिनिधित्व में, अंतहीनता अंतर है। जब संस्करण 1 के बिग-एंडियन बाइट ऑर्डर और संस्करण 2 के लिटिल-एंडियन बाइट ऑर्डर के बीच कनवर्ट करने के लिए बाइट स्वैपिंग की आवश्यकता होती है, तो ऊपर दिए गए फ़ील्ड स्वैपिंग को परिभाषित करते हैं। पहले तीन क्षेत्र अहस्ताक्षरित 32- और 16-बिट पूर्णांक हैं और अदला-बदली के अधीन हैं, जबकि अंतिम दो क्षेत्रों में बिना व्याख्या के बाइट्स हैं, अदला-बदली के अधीन नहीं हैं। यह बाइट स्वैपिंग संस्करण 3, 4 और 5 के लिए भी लागू होती है, जहां विहित क्षेत्र UUID की सामग्री के अनुरूप नहीं होते हैं।

जबकि कुछ महत्वपूर्ण GUID, जैसे घटक वस्तु मॉडल I अज्ञात इंटरफ़ेस के लिए पहचानकर्ता, नाममात्र रूप से भिन्न-2 UUID हैं, माइक्रोसाॅफ्ट विंडोज सॉफ़्टवेयर में उत्पन्न और उपयोग किए जाने वाले और GUIDs के रूप में संदर्भित कई पहचानकर्ता मानक संस्करण-1 RFC 4122 /डीसीई हैं 1.1 नेटवर्क-बाइट-ऑर्डर यूयूआईडी, न कि लिट्ल-एंडियन वैरिएंट-2 यूयूआईडी। माइक्रोसॉफ्ट का वर्तमान संस्करण  उपकरण मानक संस्करण -1 यूयूआईडी का उत्पादन करता है। कुछ माइक्रोसॉफ्ट दस्तावेज बताते हैं कि GUID यूयूआईडी के लिए समानार्थी है, जैसा RFC 4122 में मानकीकृत है। RFC 4122 स्वयं कहता है कि UUID को GUID के रूप में भी जाना जाता है। यह सब बताता है कि GUID, जबकि मूल रूप से माइक्रोसाॅफ्ट द्वारा उपयोग किए जाने वाले UUID के प्रकार का उल्लेख करते हुए, UUID के लिए केवल वैकल्पिक नाम बन गया है, जिसमें संस्करण-1 और संस्करण-2 दोनों GUID उपस्तिथ हैं।

संस्करण
दोनों प्रकार 1 और 2 के लिए, पांच संस्करण मानकों में परिभाषित किए गए हैं, और विशिष्ट उपयोग स्थितियों में प्रत्येक संस्करण अन्य की तुलना में अधिक उपयुक्त हो सकता है। संस्करण द्वारा इंगित किया गया है  स्ट्रिंग प्रतिनिधित्व में होता हैं।

संस्करण-1 यूयूआईडी समय और नोड आईडी (सामान्यतः मैक पता) से उत्पन्न होते हैं, संस्करण-2 यूयूआईडी पहचानकर्ता (सामान्यतः समूह या उपयोगकर्ता आईडी), समय और नोड आईडी से उत्पन्न होते हैं, संस्करण 3 और 5 नामस्थान पहचानकर्ता और नाम हैशिंग द्वारा उत्पन्न निर्धारक यूयूआईडी उत्पन्न करते हैं, और संस्करण-4 यूयूआईडी अनियमितता या छद्म यादृच्छिकतायास्यूडो-रैंडम नंबर का उपयोग करके उत्पन्न होते हैं।

निल यूयूआईडी
शून्य यूयूआईडी, विशेष मामला, यूयूआईडी है, अर्थात, सभी बिट शून्य पर सेट हैं।

संस्करण 1 (दिनांक-समय और मैक पता)
संस्करण 1 नोड के 48-बिट मैक पते को जोड़ता है (अर्थात, यूयूआईडी उत्पन्न करने वाला कंप्यूटर), 60-बिट टाइमस्टैम्प के साथ, मध्यरात्रि 15 अक्टूबर 1582 समन्वित यूनिवर्सल टाइम (यूटीसी) के बाद से 100-नैनोसेकंड अंतराल की संख्या है। वह इस तिथि पर जिसके द्वारा जॉर्जियाई कैलेंडर को पहली बार कैथोलिक चर्च और पापल राज्यों के बाहर अपनाया गया था। RFC 4122 बताता है कि समय का मान लगभग 3400 ई. का उपयोग किए गए एल्गोरिदम के आधार पर, जिसका अर्थ है कि 60-बिट टाइमस्टैम्प हस्ताक्षरित मात्रा है। चूँकि कुछ सॉफ़्टवेयर, जैसे कि लिब्यूड लाइब्रेरी, टाइमस्टैम्प को अहस्ताक्षरित मानते हैं, 5236 AD में रोलओवर समय डालते हैं। इस प्रकार ITU-T Rec द्वारा परिभाषित रोलओवर का उपयोग X.667 3603 ईस्वी के समय का है।

एक 13-बिट या 14-बिट यूनिकफाइंग क्लॉक सारणी के टाइमस्टैम्प को उन स्थितियों को संभालने के लिए बढ़ाता है जहां प्रोसेसर क्लॉक पर्याप्त तेजी से आगे नहीं बढ़ता है, या जहां कई प्रोसेसर और यूयूआईडी जनरेटर प्रति नोड हैं। जब यूयूआईडी प्रणाली क्लॉक की तुलना में तेज़ी से उत्पन्न होते हैं, तो टाइमस्टैम्प फ़ील्ड के निचले बिट्स को उच्च-रिज़ॉल्यूशन टाइमस्टैम्प का अनुकरण करने के लिए हर बार UUID उत्पन्न होने पर इसे बढ़ाकर उत्पन्न किया जा सकता है। अंतरिक्ष (नोड) और समय (अंतराल और घड़ी अनुक्रम) में बिंदु के अनुरूप प्रत्येक संस्करण 1 यूयूआईडी के साथ, दो उचित रूप से उत्पन्न संस्करण -1 यूयूआईडी के अनायास ही समान होने की संभावना व्यावहारिक रूप से शून्य है। चूंकि समय और घड़ी क्रम कुल 74 बिट्स हैं, 274 (1.8, या 18 सेक्सटिलियन) संस्करण-1 यूयूआईडी प्रति नोड आईडी 163 बिलियन प्रति सेकंड प्रति नोड आईडी की अधिकतम औसत दर पर उत्पन्न किया जा सकता है।

अन्य यूयूआईडी संस्करणों के विपरीत, नेटवर्क कार्ड से मैक पतों पर आधारित संस्करण -1 और -2 यूयूआईडी केंद्रीय पंजीकरण प्राधिकरण द्वारा जारी किए गए पहचानकर्ता पर अपनी विशिष्टता के लिए विश्वास करते हैं, अर्थात् मैक पते का संगठनात्मक रूप से अद्वितीय पहचानकर्ता (ओयूआई) भाग, जो IEEE द्वारा नेटवर्किंग उपकरण के निर्माताओं को जारी किया जाता है। नेटवर्क-कार्ड मैक पतों पर आधारित संस्करण-1 और संस्करण-2 यूयूआईडी की विशिष्टता भी नेटवर्क-कार्ड निर्माताओं पर निर्भर करती है कि वे अपने कार्ड के लिए अद्वितीय मैक पते ठीक से निर्दिष्ट करते हैं, जो कि अन्य निर्माण प्रक्रियाओं की तरह त्रुटि के अधीन है। इसके अतिरिक्त कुछ ऑपरेटिंग प्रणाली अंतिम उपयोगकर्ता को मैक पता, विशेष रूप से ओपेन Wrt को अनुकूलित करने की अनुमति देते हैं।

नोड आईडी के लिए नोड के नेटवर्क कार्ड मैक पते का उपयोग करने का मतलब है कि संस्करण -1 UUID को उस कंप्यूटर पर वापस ट्रैक किया जा सकता है जिसने इसे बनाया था। दस्तावेज़ों को कभी-कभी उन कंप्यूटरों में खोजा जा सकता है जहाँ वे शब्द संसाधन सॉफ़्टवेयर द्वारा एम्बेड किए गए यूयूआईडी के माध्यम से बनाए या संपादित किए गए थे। मेलिसा (कंप्यूटर वायरस) के निर्माता का पता लगाते समय इस गोपनीयता का उपयोग किया गया था।

RFC 4122 संस्करण-1 (या 2) UUID में मैक पते को यादृच्छिक 48-बिट नोड आईडी से परिवर्तित करने की अनुमति देता है, या तो क्योंकि नोड में मैक पता नहीं है, या क्योंकि यह इसका पर्दाफाश करना वांछनीय नहीं है। उस स्थिति में, RFC के लिए आवश्यक है कि नोड आईडी के पहले ऑक्टेट का कम से कम महत्वपूर्ण बिट 1 पर सेट होना चाहिए। यह मैक पतों में बहुस्त्र्पीय बिट से मेल खाता है, और इसे सेट करने से यूयूआईडी को अलग करने में सहायता मिलती है जहां नेटवर्क कार्ड से मैक पते के आधार पर यूयूआईडी से यादृच्छिक रूप से नोड आईडी उत्पन्न होती है, जिसमें सामान्यतः यूनिकास्ट मैक पते होते हैं।

संस्करण 2 (दिनांक-समय और मैक पता, डीसीई सुरक्षा संस्करण)
RFC 4122 संस्करण 2 को डीसीई सुरक्षा यूयूआईडी के लिए सुरक्षित रखता है, किन्तु यह कोई विवरण प्रदान नहीं करता है। इस कारण से, कई यूयूआईडी कार्यान्वयन संस्करण 2 को छोड़ देते हैं। चूंकि, संस्करण-2 यूयूआईडी के विनिर्देश डीसीई 1.1 प्रमाणीकरण और सुरक्षा सेवा विनिर्देश द्वारा प्रदान किए जाते हैं।

संस्करण-2 यूयूआईडी संस्करण 1 के समान हैं, सिवाय इसके कि क्लॉक क्रम के कम से कम महत्वपूर्ण 8 बिट्स को स्थानीय डोमेन नंबर से बदल दिया जाता है, और टाइमस्टैम्प के कम से कम महत्वपूर्ण 32 बिट्स को निर्दिष्ट स्थानीय डोमेन के भीतर पूर्णांक पहचानकर्ता द्वारा प्रतिस्थापित किया जाता है। POSIX प्रणाली पर, स्थानीय-डोमेन नंबर 0 और 1 क्रमशः उपयोगकर्ता आईडी (उपयोगकर्ता पहचानकर्ता) और समूह आईडी (समूह पहचानकर्ता) के लिए होते हैं, और अन्य स्थानीय-डोमेन नंबर साइट-परिभाषित होते हैं। गैर-पॉज़िक्स प्रणाली पर, सभी स्थानीय डोमेन नंबर साइट-परिभाषित होते हैं।

यूयूआईडी में 40-बिट डोमेन/पहचानकर्ता सम्मलित करने की क्षमता ट्रेडऑफ़ के साथ आती है। ओर, 40 बिट प्रति नोड आईडी लगभग 1 ट्रिलियन डोमेन/पहचानकर्ता मान की अनुमति देते हैं। दूसरी ओर, संस्करण 1 में 60 बिट्स की तुलना में क्लॉक मान को 28 सबसे महत्वपूर्ण बिट्स तक छोटा कर दिया गया है, संस्करण 2 UUID में घड़ी प्रत्येक 429.49 सेकंड में केवल बार टिकेगी, 7 मिनट से थोड़ा अधिक, इसके विपरीत संस्करण 1 के लिए प्रत्येक 100 नैनोसेकंड। और संस्करण 1 में 14 बिट्स की तुलना में केवल 6 बिट्स के घड़ी अनुक्रम के साथ, 16,384 घड़ी अनुक्रम की तुलना में प्रति नोड/डोमेन/पहचानकर्ता प्रति 7 मिनट की घड़ी की टिक पर केवल 64 अद्वितीय यूयूआईडी उत्पन्न किए जा सकते हैं। संस्करण 1 के लिए मान। इस प्रकार, संस्करण 2 उन स्थितियों के लिए उपयुक्त नहीं हो सकता है जहां यूयूआईडी आवश्यक हैं, प्रति नोड/डोमेन/पहचानकर्ता, प्रत्येक सात मिनट में लगभग से अधिक की दर से किया जाता हैं।

संस्करण 3 और 5 (नामस्थान नाम-आधारित)
संस्करण-3 और संस्करण-5 यूयूआईडी क्रिप्टोग्राफ़िक हैश फ़ंक्शन द्वारा नामस्थान पहचानकर्ता और नाम से उत्पन्न होते हैं। संस्करण 3 हैशिंग एल्गोरिथम के रूप में एमडी5 का उपयोग करता है, और संस्करण 5 एसएचए-1 का उपयोग करता है।

नेमस्पेस आइडेंटिफ़ायर अपने आप में UUID है। विनिर्देश यूनिफ़ॉर्म रिसोर्स लोकेटर, पूरी तरह से योग्य डोमेन नाम, वस्तु पहचानकर्ता और X.500 LDAPs के लिए नामस्थान का प्रतिनिधित्व करने के लिए यूयूआईडी प्रदान करता है, किन्तु किसी भी वांछित यूयूआईडी का उपयोग नेमस्पेस डिज़ाइनर के रूप में किया जा सकता है।

किसी दिए गए नाम स्थान और नाम के अनुरूप संस्करण-3 UUID निर्धारित करने के लिए, नाम स्थान का UUID बाइट्स की स्ट्रिंग में रूपांतरित होता है, जो इनपुट नाम के साथ जुड़ा होता है, फिर MD5 के साथ हैश किया जाता है, जिससे 128 बिट्स मिलते हैं। फिर 6 या 7 बिट्स को निश्चित मानों से बदल दिया जाता है, 4-बिट संस्करण (जैसे 00112 संस्करण 3 के लिए), और 2- या 3-बिट UUID संस्करण (जैसे 102 RFC 4122 यूयूआईडी, या 1102 को (माइक्रोसाॅफ्ट GUID का संकेत) इंगित करता है। चूंकि 6 या 7 बिट इस प्रकार पूर्व निर्धारित हैं, केवल 121 या 122 बिट यूयूआईडी की विशिष्टता में योगदान करते हैं।

संस्करण-5 UUID समान हैं, किन्तु MD5 केअतिरिक्त SHA-1 का उपयोग किया जाता है। चूंकि SHA-1 160-बिट डाइजेस्ट उत्पन्न करता है, डाइजेस्ट संस्करण से पहले 128 बिट्स तक छोटा हो जाता है और संस्करण बिट्स को बदल दिया जाता है।

संस्करण-3 और संस्करण-5 यूयूआईडी में वह गुण है जो ही नामस्थान और नाम ही यूयूआईडी में मैप करेगा। चूंकि, न तो नामस्थान और न ही यूयूआईडी से नाम निर्धारित किया जा सकता है, यदि उनमें से निर्दिष्ट हो, ब्रूट-बल खोज को छोड़कर उपयोग करता हैं। RFC 4122 संस्करण 3 (MD5) की तुलना में संस्करण 5 (SHA-1) की अनुशंसा करता है, और सुरक्षा क्रेडेंशियल के रूप में किसी भी संस्करण के UUID के उपयोग के विरुद्ध चेतावनी देता है।

संस्करण 4 (यादृच्छिक)
एक संस्करण 4 UUID बेतरतीब ढंग से उत्पन्न होता है। अन्य यूयूआईडी की तरह, संस्करण 4 को इंगित करने के लिए 4 बिट का उपयोग किया जाता है, और संस्करण (10)2 को इंगित करने के लिए 2 या 3 बिट (1102 संस्करण 1 और 2 के लिए क्रमशः) का उपयोग किया जाता है। इस प्रकार, संस्करण 1 (अर्थात, अधिकांश यूयूआईडी) के लिए यादृच्छिक संस्करण -4 यूयूआईडी में 6 पूर्वनिर्धारित संस्करण और संस्करण बिट्स होंगे, कुल 2 के लिए यादृच्छिक रूप से उत्पन्न भाग के लिए 122122 बिट्स छोड़कर, या 5.3 (5.3 बड़ी संख्याओं के नाम) संभावित संस्करण-4 संस्करण-1 यूयूआईडी का उपयोग करता हैं। आधे से अधिक संभावित संस्करण-4 संस्करण-2 यूयूआईडी (विरासत GUIDs) हैं क्योंकि कम यादृच्छिक बिट उपलब्ध है, संस्करण के लिए 3 बिट्स का उपभोग किया जा रहा है।

टक्कर
हैश टकराव तब होता है जब ही यूयूआईडी से अधिक बार उत्पन्न होता है और अलग-अलग संदर्भों को सौंपा जाता है। मानक संस्करण-1 और संस्करण-2 यूयूआईडी के स्थितियों में नेटवर्क कार्ड से अद्वितीय मैक पते का उपयोग करते हुए, टक्कर होने की संभावना नहीं है, केवल बढ़ी हुई संभावना के साथ, जब कार्यान्वयन मानकों से भिन्न होता है, या तो अनजाने में या जानबूझकर।

संस्करण-1 और संस्करण-2 यूयूआईडी के विपरीत मैक एड्रेस का उपयोग करके उत्पन्न किया गया, संस्करण-1 और -2 यूयूआईडी के साथ जो विभिन्न विधियों से उत्पन्न नोड आईडी, हैश-आधारित संस्करण-3 और संस्करण-5 यूयूआईडी और रैंडम संस्करण-4 यूयूआईडी का उपयोग करते हैं। कार्यान्वयन समस्याओं के बिना भी टक्कर हो सकती है, यद्यपि संभावना इतनी कम है कि इसे सामान्य रूप से अनदेखा किया जा सकता है। जन्मदिन की समस्या के विश्लेषण के आधार पर इस संभावना की ठीक-ठीक गणना की जा सकती है।

उदाहरण के लिए, कम से कम टकराव की 50% संभावना रखने के लिए जनरेट किए जाने वाले रैंडम वर्शन-4 UUID की संख्या 2.71 क्विंटिलियन है, जिसकी गणना इस प्रकार की गई है:
 * $$n \approx \frac{1}{2} + \sqrt{\frac{1}{4} + 2 \times \ln(2) \times 2^{122}} \approx 2.71 \times 10^{18}.$$

यह संख्या लगभग 85 वर्षों के लिए प्रति सेकंड 1 बिलियन यूयूआईडी उत्पन्न करने के बराबर है। इतने सारे UUID वाली फ़ाइल, प्रति UUID 16 बाइट्स पर, लगभग 45 एक्साबाइट होगी।

संस्करण -4 यूयूआईडी की सबसे छोटी संख्या जो p होने के लिए विवादित सूत्र को खोजने की संभावना के लिए उत्पन्न होनी चाहिए, उक्त सूत्र को इस प्रकार अनुमानित किया जाता है:


 * $$\sqrt{2 \times 2^{122} \times \ln\frac{1}{1 - p}}.$$

इस प्रकार, 103 ट्रिलियन संस्करण-4 यूयूआईडी के भीतर डुप्लिकेट खोजने की संभावना अरब में है।

फाइल प्रणाली
महत्वपूर्ण उपयोगों में सम्मलित हैं ext2/ext3/ext4 फाइल प्रणाली उपयोक्ता स्थान उपकरण (e2fsprogs उपयोग-लाइनेक्स द्वारा प्रदान किए गए libuuid का उपयोग करता है), लॉजिकल वॉल्यूम मैनेजर (लिनक्स)Linux), LUKS एन्क्रिप्टेड विभाजन, GNOME, KDE, और macOS, जिनमें से अधिकांश थिओडोर त्सो द्वारा मूल कार्यान्वयन से प्राप्त किए गए हैं।

सोलारिस (ऑपरेटिंग प्रणाली) (ओपन सॉफ्टवेयर फाउंडेशन कार्यान्वयन का उपयोग करके) में यूयूआईडी के उपयोगों में से कर्नेल पैनिक के स्थितियों में क्रैश डंप डेटा को फॉल्ट मैनेजमेंट इवेंट के साथ जोड़ने के उद्देश्य से चल रहे ऑपरेटिंग प्रणाली उदाहरण की पहचान करता है।

विभाजन लेबल और विभाजन UUID दोनों सुपरब्लॉक (फाइल प्रणाली) में संग्रहीत हैं। वे दोनों विभाजन केअतिरिक्त फाइल प्रणाली का भाग हैं। उदाहरण के लिए, ext2–4 में UUID होता है, जबकि NTFS या FAT32 में नहीं होता है।

सुपरब्लॉक फ़ाइल प्रणाली का हिस्सा है, इस प्रकार पूरी तरह से विभाजन के भीतर समाहित है, इसलिए कर रहा है dd if=/dev/sda1 of=/dev/sdb1 sda1 और sdb1 दोनों को ही लेबल और UUID के साथ छोड़ देता है।

कॉम में
माइक्रोसाॅफ्ट के कंपोनेंट ऑब्जेक्ट मॉडल (COM) में उपयोग किए जाने वाले GUID के कई प्रकार हैं:
 * IID - इंटरफ़ेस पहचानकर्ता, (जो प्रणाली पर पंजीकृत हैं, वे विंडोज रजिस्ट्री में संग्रहीत हैं [HKEY_CLASSES_ROOT\Interface] )
 * CLSID - वर्ग पहचानकर्ता, (पर संग्रहीत [HKEY_CLASSES_ROOT\CLSID])
 * LIBID - लाइब्रेरी पहचानकर्ता टाइप करें, (पर संग्रहीत [HKEY_CLASSES_ROOT\TypeLib] )
 * CATID - श्रेणी पहचानकर्ता, (एक वर्ग पर इसकी उपस्थिति इसे कुछ वर्ग श्रेणियों से संबंधित के रूप में पहचानती है, जो सूचीबद्ध है [HKEY_CLASSES_ROOT\Component Categories] )

डेटाबेस कुंजियों के रूप में
यूयूआईडी सामान्यतः डेटाबेस टेबल में अनूठी कुंजी के रूप में उपयोग की जाती हैं। इस प्रकार NEWID }} माइक्रोसाॅफ्ट SQL सर्वर संस्करण 4 ट्रांसैक्ट-SQL में फ़ंक्शन मानक यादृच्छिक संस्करण -4 यूयूआईडी देता है, जबकि NEWSEQUENTIALID फ़ंक्शन यूयूआईडी के समान 128-बिट पहचानकर्ता लौटाता है जो अगले प्रणाली रीबूट तक अनुक्रम में बढ़ने के लिए प्रतिबद्ध हैं। ओरेकल डाटाबेस SYS_GUID नाम के अतिरिक्त फ़ंक्शन मानक GUID नहीं लौटाता है। इसकेअतिरिक्त, यह मेजबान पहचानकर्ता और प्रक्रिया या थ्रेड पहचानकर्ता के आधार पर 16-बाइट 128-बिट रॉ मान देता है, जो कुछ तक GUID के समान है। पोस्टग्रे SQL में सम्मलित है UUID को डेटा के द्वारा इसके प्रकार और प्रारुप के कारण उक्त कार्यों के उपयोग के माध्यम से यूयूआईडी के अधिकांश संस्करण उत्पन्न कर सकते हैं।  MySQL प्रदान करता है UUID फ़ंक्शन, जो मानक संस्करण-1 UUID उत्पन्न करता है।

संस्करण 3, 4, और 5 के मानक यूयूआईडी की यादृच्छिक प्रकृति, और मानक संस्करण 1 और 2 के भीतर फ़ील्ड का क्रम यूयूआईडी को प्राथमिक कुंजी के रूप में उपयोग किए जाने पर संदर्भ या प्रदर्शन के डेटाबेस इलाके के साथ समस्याएं उत्पन्न कर सकता है। उदाहरण के लिए, 2002 में जिमी निल्सन ने माइक्रोसाॅफ्ट SQL सर्वर के साथ प्रदर्शन में महत्वपूर्ण सुधार की सूचना दी जब कुंजी के रूप में उपयोग किए जा रहे संस्करण -4 यूयूआईडी को प्रणाली समय के आधार पर गैर-यादृच्छिक प्रत्यय सम्मलित करने के लिए संशोधित किया गया था। इस तथाकथित काॅम्ब (संयुक्त समय-GUID) दृष्टिकोण ने यूयूआईडी को गैर-मानक बना दिया और डुप्लिकेट होने की अधिक संभावना है, जैसा कि निल्सन ने स्वीकार किया, किन्तु निल्सन को केवल आवेदन के भीतर विशिष्टता की आवश्यकता थी। संस्करण 1 और 2 यूयूआईडी को फिर से क्रमित और एन्कोडिंग करके, जिससे कि टाइमस्टैम्प पहले आए, सम्मिलन प्रदर्शन हानि को टाला जा सकता है। कुछ वेब फ्रेमवर्क, जैसे लारावेल, टाइमस्टैम्प पहले यूयूआईडी के लिए समर्थन करते हैं जो अनुक्रमित डेटाबेस कॉलम में कुशलतापूर्वक संग्रहीत किए जा सकते हैं। यह संस्करण 4 प्रारूप का उपयोग करके काॅम्ब UUID बनाता है, किन्तु जहां पहले 48-बिट्स UUIDv1 की तरह टाइमस्टैम्प बनाते हैं। काॅम्ब UUID विचार के आधार पर अधिक निर्दिष्ट स्वरूपों में सम्मलित हैं:
 * ULID, जो संस्करण 4 को इंगित करने के लिए उपयोग किए गए 4 बिट्स को हटा देता है, और डिफ़ॉल्ट रूप से बेस32 एन्कोडिंग का उपयोग करता है।
 * UUID संस्करण 6 से 8, तीन काॅम्ब UUID स्वरूपों का औपचारिक प्रस्ताव।

यह भी देखें

 * नैनो आईडी
 * जन्मदिन अटैक
 * वस्तु पहचानकर्ता (ओआईडी)
 * यूनिफॉर्म रिसोर्स पहचानकर्ता (यूआरआई)
 * स्नोफ्लेक आईडी

बाहरी संबंध
Standards
 * Recommendation ITU-T X.667 (Free access)
 * ISO/IEC 9834-8:2014 (Paid)

ITU-T UUID Generator
 * Universally Unique Identifiers (यूयूआईडी)

Technical Articles
 * Technical Note TN2166 - Secrets of the GPT - Apple Developer
 * UUID Documentation - Apache Commons Id
 * CLSID Key - माइक्रोसाॅफ्ट Docs
 * Universal Unique Identifier - The Open Group Library

Miscellaneous
 * UUID Decoder tool
 * A Brief History of the UUID
 * Understanding How यूयूआईडी Are Generated

Implementation in various languages
 * Golang - google/uuid
 * PHP - ramsey/uuid
 * C++ - Boost UUID
 * Linux or C - libuuid
 * Python - uuid.py
 * Java - java.util.UUID
 * C# - System.Guid
 * Javascript - Crypto.randomUUID