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

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

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

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

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

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

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

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 UUIDs के लिए समान संसाधन का नाम (URN) नेमस्पेस परिभाषित करता है। URN के रूप में प्रस्तुत किया गया UUID इस प्रकार दिखाई देता है: :

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

वेरिएंट
UUIDs का भिन्न क्षेत्र, या 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 UUIDs में पता परिवार ऑक्टेट के उच्च बिट्स के साथ मेल खाते हैं। चूंकि पता परिवार 0..255 की सीमा में मान रख सकता है, केवल मान 0..13 कभी परिभाषित किए गए थे। तदनुसार, वेरिएंट-0 बिट पैटर्न  ऐतिहासिक NCS UUIDs के साथ विरोध से बचा जाता है, यदि कोई अभी भी डेटाबेस में उपस्तिथ है।
 * वेरिएंट 1 (10xx2, एन =, 2 बिट्स) को मूल इंटरनेट ड्राफ्ट के लेखकों के नाम पर RFC 4122/DCE 1.1 UUIDs , या Leach-Salz UUIDs के रूप में संदर्भित किया जाता है।
 * वैरिएंट 2 (110x2, N = , 3 बिट्स) को RFC में आरक्षित, Microsoft Corporation पश्चगामी संगतता के रूप में चित्रित किया गया है और इसका उपयोग Microsoft Windows प्लेटफ़ॉर्म पर प्रारंभिक GUID के लिए किया गया था। यह वैरिएंट 1 से केवल बाइनरी स्टोरेज या ट्रांसमिशन में एंडियननेस से भिन्न होता है: वेरिएंट -1 UUIDs नेटवर्क (बिग-एंडियन) बाइट ऑर्डर का उपयोग करते हैं, जबकि वेरिएंट -2 GUIDs UUID के कुछ उपक्षेत्रों के लिए नेटिव (लिटिल-एंडियन) बाइट ऑर्डर का उपयोग करते हैं।
 * आरक्षित को 3-बिट वैरिएंट बिट पैटर्न 111x के रूप में परिभाषित किया गया है2 (एन = ).

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

जबकि कुछ महत्वपूर्ण GUID, जैसे घटक वस्तु मॉडल I अज्ञात इंटरफ़ेस के लिए पहचानकर्ता, नाममात्र रूप से भिन्न-2 UUID हैं, Microsoft Windows सॉफ़्टवेयर में उत्पन्न और उपयोग किए जाने वाले और GUIDs के रूप में संदर्भित कई पहचानकर्ता मानक संस्करण-1 RFC 4122/DCE हैं 1.1 नेटवर्क-बाइट-ऑर्डर UUIDs, न कि लिट्ल-एंडियन वैरिएंट-2 UUIDs। माइक्रोसॉफ्ट का वर्तमान संस्करण  उपकरण मानक संस्करण -1 UUIDs का उत्पादन करता है। कुछ माइक्रोसॉफ्ट दस्तावेज बताते हैं कि GUID यूयूआईडी के लिए समानार्थी है, जैसा RFC 4122 में मानकीकृत है। RFC 4122 स्वयं कहता है कि UUID को GUID के रूप में भी जाना जाता है। यह सब बताता है कि GUID, जबकि मूल रूप से Microsoft द्वारा उपयोग किए जाने वाले 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-बिट यूनिकफाइंग क्लॉक सीक्वेंस टाइमस्टैम्प को उन स्थितियों को संभालने के लिए बढ़ाता है जहां प्रोसेसर क्लॉक पर्याप्त तेजी से आगे नहीं बढ़ता है, या जहां कई प्रोसेसर और यूयूआईडी जनरेटर प्रति नोड हैं। जब UUIDs सिस्टम क्लॉक की तुलना में तेज़ी से उत्पन्न होते हैं, तो टाइमस्टैम्प फ़ील्ड के निचले बिट्स को एक उच्च-रिज़ॉल्यूशन टाइमस्टैम्प का अनुकरण करने के लिए हर बार UUID उत्पन्न होने पर इसे बढ़ाकर उत्पन्न किया जा सकता है। अंतरिक्ष (नोड) और समय (अंतराल और घड़ी अनुक्रम) में एक बिंदु के अनुरूप प्रत्येक संस्करण 1 यूयूआईडी के साथ, दो उचित रूप से उत्पन्न संस्करण -1 यूयूआईडी के अनायास ही समान होने की संभावना व्यावहारिक रूप से शून्य है। चूंकि समय और घड़ी क्रम कुल 74 बिट्स हैं, 274 (1.8, या 18 सेक्सटिलियन) संस्करण-1 यूयूआईडी प्रति नोड आईडी 163 बिलियन प्रति सेकंड प्रति नोड आईडी की अधिकतम औसत दर पर उत्पन्न किया जा सकता है।

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

संस्करण 2 (दिनांक-समय और मैक पता, डीसीई सुरक्षा संस्करण)
RFC 4122 संस्करण 2 को DCE सुरक्षा UUIDs के लिए सुरक्षित रखता है; किन्तु यह कोई विवरण प्रदान नहीं करता है। इस कारण से, कई यूयूआईडी कार्यान्वयन संस्करण 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 के लिए नामस्थान का प्रतिनिधित्व करने के लिए UUIDs प्रदान करता है; किन्तु किसी भी वांछित यूयूआईडी का उपयोग नेमस्पेस डिज़ाइनर के रूप में किया जा सकता है।

किसी दिए गए नाम स्थान और नाम के अनुरूप संस्करण-3 UUID निर्धारित करने के लिए, नाम स्थान का UUID बाइट्स की एक स्ट्रिंग में रूपांतरित होता है, जो इनपुट नाम के साथ जुड़ा होता है, फिर MD5 के साथ हैश किया जाता है, जिससे 128 बिट्स मिलते हैं। फिर 6 या 7 बिट्स को निश्चित मानों से बदल दिया जाता है, 4-बिट संस्करण (जैसे 00112 संस्करण 3 के लिए), और 2- या 3-बिट UUID संस्करण (जैसे 102 RFC 4122 UUIDs, या 110 को इंगित करता है2 विरासत Microsoft 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 बेतरतीब ढंग से उत्पन्न होता है। अन्य UUIDs की तरह, संस्करण 4 को इंगित करने के लिए 4 बिट का उपयोग किया जाता है, और संस्करण (10) को इंगित करने के लिए 2 या 3 बिट का उपयोग किया जाता है2 या 1102 वेरिएंट 1 और 2 के लिए क्रमशः)। इस प्रकार, संस्करण 1 (अर्थात, अधिकांश यूयूआईडी) के लिए एक यादृच्छिक संस्करण -4 यूयूआईडी में 6 पूर्वनिर्धारित संस्करण और संस्करण बिट्स होंगे, कुल 2 के लिए यादृच्छिक रूप से उत्पन्न भाग के लिए 122 बिट्स छोड़कर122, या 5.3 (5.3 बड़ी संख्याओं के नाम) संभावित संस्करण-4 संस्करण-1 UUIDs। आधे से अधिक संभावित संस्करण-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 UUIDs की सबसे छोटी संख्या जो p होने के लिए टक्कर खोजने की संभावना के लिए उत्पन्न होनी चाहिए, सूत्र द्वारा अनुमानित है


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

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

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

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

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

डेटाबेस कुंजियों के रूप में
यूयूआईडी सामान्यतः डेटाबेस टेबल में एक अनूठी कुंजी के रूप में उपयोग की जाती हैं। NEWID }} Microsoft SQL सर्वर संस्करण 4 Transact-SQL में फ़ंक्शन मानक यादृच्छिक संस्करण -4 UUIDs देता है, जबकि NEWSEQUENTIALID फ़ंक्शन यूयूआईडी के समान 128-बिट पहचानकर्ता लौटाता है जो अगले सिस्टम रीबूट तक अनुक्रम में बढ़ने के लिए प्रतिबद्ध हैं। ओरेकल डाटाबेस SYS_GUID नाम के बावजूद फ़ंक्शन मानक GUID नहीं लौटाता है। इसकेअतिरिक्त, यह एक मेजबान पहचानकर्ता और एक प्रक्रिया या थ्रेड पहचानकर्ता के आधार पर एक 16-बाइट 128-बिट रॉ मान देता है, जो कुछ हद तक एक GUID के समान है। PostgreSQL में एक सम्मलित है UUID डेटा प्रकार और मॉड्यूल से कार्यों के उपयोग के माध्यम से यूयूआईडी के अधिकांश संस्करण उत्पन्न कर सकते हैं। MySQL प्रदान करता है UUID फ़ंक्शन, जो मानक संस्करण-1 UUID उत्पन्न करता है। संस्करण 3, 4, और 5 के मानक यूयूआईडी की यादृच्छिक प्रकृति, और मानक संस्करण 1 और 2 के भीतर फ़ील्ड का क्रम यूयूआईडी को प्राथमिक कुंजी के रूप में उपयोग किए जाने पर संदर्भ या प्रदर्शन के डेटाबेस इलाके के साथ समस्याएं उत्पन्न कर सकता है। उदाहरण के लिए, 2002 में जिमी निल्सन ने Microsoft SQL सर्वर के साथ प्रदर्शन में एक महत्वपूर्ण सुधार की सूचना दी जब कुंजी के रूप में उपयोग किए जा रहे संस्करण -4 UUIDs को सिस्टम समय के आधार पर एक गैर-यादृच्छिक प्रत्यय सम्मलित करने के लिए संशोधित किया गया था। इस तथाकथित COMB (संयुक्त समय-GUID) दृष्टिकोण ने UUIDs को गैर-मानक बना दिया और डुप्लिकेट होने की अधिक संभावना है, जैसा कि निल्सन ने स्वीकार किया, किन्तु निल्सन को केवल आवेदन के भीतर विशिष्टता की आवश्यकता थी। संस्करण 1 और 2 UUIDs को फिर से क्रमित और एन्कोडिंग करके, जिससे कि टाइमस्टैम्प पहले आए, सम्मिलन प्रदर्शन हानि को टाला जा सकता है। कुछ वेब फ्रेमवर्क, जैसे laravel, टाइमस्टैम्प पहले यूयूआईडी के लिए समर्थन करते हैं जो एक अनुक्रमित डेटाबेस कॉलम में कुशलतापूर्वक संग्रहीत किए जा सकते हैं। यह संस्करण 4 प्रारूप का उपयोग करके एक COMB UUID बनाता है, किन्तु जहां पहले 48-बिट्स UUIDv1 की तरह एक टाइमस्टैम्प बनाते हैं। COMB UUID विचार के आधार पर अधिक निर्दिष्ट स्वरूपों में सम्मलित हैं:
 * ULID, जो संस्करण 4 को इंगित करने के लिए उपयोग किए गए 4 बिट्स को हटा देता है, और डिफ़ॉल्ट रूप से बेस32 एन्कोडिंग का उपयोग करता है।
 * UUID संस्करण 6 से 8, तीन COMB UUID स्वरूपों का एक औपचारिक प्रस्ताव।

यह भी देखें

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

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

ITU-T UUID Generator
 * Universally Unique Identifiers (UUIDs)

Technical Articles
 * Technical Note TN2166 - Secrets of the GPT - Apple Developer
 * UUID Documentation - Apache Commons Id
 * CLSID Key - Microsoft Docs
 * Universal Unique Identifier - The Open Group Library

Miscellaneous
 * UUID Decoder tool
 * A Brief History of the UUID
 * Understanding How UUIDs 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