UUID जनरेटर

UUID क्या है?

एक UUID (यूनिवर्सली यूनीक आइडेंटिफ़ायर), जिसे GUID भी कहते हैं, एक 128-बिट मान है जिसे 32 हेक्साडेसिमल अंकों में पाँच हाइफ़न-पृथक समूहों के रूप में लिखा जाता है — 8-4-4-4-12, उदाहरण के लिए f47ac10b-58cc-4372-a567-0e02b2c3d479। उद्देश्य ऐसा पहचानकर्ता गढ़ना है जो किसी केंद्रीय प्राधिकरण के बिना अद्वितीय हो, ताकि स्वतंत्र सिस्टम प्रत्येक ऐसी ID बना सकें जो कभी नहीं टकराएँगी। 13वाँ अंक वर्शन एन्कोड करता है और 17वाँ वैरिएंट एन्कोड करता है।

एक नज़र में UUID वर्शन

यह टूल v4, v7, v1 और v5 जनरेट करता है। वर्शन 2 (DCE सुरक्षा), 6 (पुनर्क्रमित v1) और 8 (कस्टम) एप्लिकेशन कोड में विरले ही ज़रूरी होते हैं। हम जानबूझकर MD5-आधारित v3 छोड़ते हैं — MD5 टूटा हुआ है और ब्राउज़र के क्रिप्टो API में अनुपलब्ध — और स्पेसिफ़िकेशन द्वारा प्राथमिकता-प्राप्त SHA-1-आधारित v5 प्रदान करते हैं।

मुझे कौन-सा वर्शन इस्तेमाल करना चाहिए?

• बस एक अद्वितीय ID चाहिए? v4 (रैंडम) इस्तेमाल करें — यह सुरक्षित डिफ़ॉल्ट है।
• डेटाबेस प्राइमरी कुंजी? v7 इस्तेमाल करें — इसका अग्रणी टाइमस्टैम्प इंसर्ट को क्रमबद्ध रखता है, उस इंडेक्स-फ़्रैगमेंटेशन से बचते हुए जो रैंडम v4 कुंजियाँ पैदा करती हैं।
• चाहते हैं कि वही इनपुट हमेशा वही ID दे? एक नेमस्पेस और नाम के साथ v5 इस्तेमाल करें।
• किसी पुराने सिस्टम के साथ अंतरसंचालन? v1 इस्तेमाल करें।

किसी UUID की जाँच करें

किसी भी UUID को पेस्ट करके जाँचें कि वह मान्य है और उसका वर्शन, वैरिएंट और (v1/v7 के लिए) जड़ा हुआ टाइमस्टैम्प पढ़ें।

क्या UUID सचमुच अद्वितीय हैं?

रैंडम v4 के लिए, टकराव की संभावना खगोलीय रूप से कम है: 122 रैंडम बिट के साथ आप लगभग 85 वर्षों तक एक अरब UUID प्रति सेकंड जनरेट कर सकते हैं और फिर भी किसी एक डुप्लिकेट की संभावना केवल लगभग 50% होगी। व्यवहार में आप इन्हें अद्वितीय मान सकते हैं। हालाँकि UUID एक पहचानकर्ता है, कोई रहस्य नहीं — इसे कभी पासवर्ड या सुरक्षा टोकन के रूप में इस्तेमाल न करें।

RFC 4122 से RFC 9562 तक

UUID को पहली बार IETF ने RFC 4122 (जुलाई 2005) में मानकीकृत किया, जिसने वर्शन 1 से 5 परिभाषित किए और urn:uuid: नेमस्पेस पंजीकृत किया। लगभग दो दशकों के वास्तविक उपयोग — विशेषकर वितरित डेटाबेस के विस्फोट — ने एक कमी उजागर की: मूल टाइम-बेस्ड फ़ॉर्मैट निर्माण-क्रम में सॉर्ट होने के लिए नहीं बने थे, जो डेटाबेस को बुरी तरह चाहिए। RFC 9562, मई 2024 में प्रकाशित, RFC 4122 को अप्रचलित करता है और उस माँग का उत्तर देता है। यह पुराने वर्शनों को यथावत रखता है और तीन नए जोड़ता है — v6 (एक पुनर्क्रमित v1), v7 (Unix-मिलीसेकंड समय और रैंडमनेस) और v8 (एक मुक्त-रूप, वेंडर-परिभाषित लेआउट) — साथ ही नया Max UUID प्रहरी (sentinel)। इसने लीगेसी Microsoft COM वैरिएंट को दायरे से बाहर घोषित किया, इसलिए आधुनिक वर्शन केवल मुख्यधारा के "वैरिएंट 1" लेआउट पर लागू होते हैं। संक्षेप में: जो आप पहले से इस्तेमाल करते हैं वह कुछ नहीं टूटा, और समय-सॉर्टेबल ID अंततः असंगत घरेलू योजनाओं के पैचवर्क के बजाय एक मानक बन गए।

UUID की संरचना, बिट-दर-बिट

सभी 128 बिट का उपयोग तय है। 16 ऑक्टेट में, दो छोटे फ़ील्ड आरक्षित होते हैं और बाक़ी पेलोड ले जाते हैं — वर्शन के आधार पर रैंडम बिट, एक टाइमस्टैम्प, या एक हैश। वर्शन सातवें ऑक्टेट के चार उच्च बिट में बैठता है (तीसरे समूह का पहला हेक्स अंक), इसलिए यह हमेशा 1–8 में से एक पढ़ता है। वैरिएंट नौवें ऑक्टेट के उच्च बिट में बैठता है (चौथे समूह का पहला हेक्स अंक), और हर मानक UUID के लिए वे बिट बाइनरी में 10 होते हैं — यही वजह है कि वह अंक हमेशा 8, 9, a या b होता है। दो आरक्षित मान वर्शन योजना के पूरी तरह बाहर आते हैं: Nil UUID, सभी शून्य (00000000-0000-0000-0000-000000000000), जिसका अर्थ "कोई मान नहीं", और Max UUID, सभी एक (ffffffff-ffff-ffff-ffff-ffffffffffff), जिसे RFC 9562 ने किसी परास (range) के अंत को चिह्नित करने के लिए जोड़ा।

नेम-बेस्ड UUID और चार मानक नेमस्पेस

वर्शन 3 और 5 डिटरमिनिस्टिक हैं: वे एक नेमस्पेस UUID को एक नाम स्ट्रिंग के साथ हैश करते हैं, इसलिए वही जोड़ी किसी भी मशीन पर, हमेशा, वही पहचानकर्ता उत्पन्न करती है। यह उन्हें मौजूदा कुंजियों से व्युत्पन्न स्थिर ID के लिए आदर्श बनाता है — एक URL, एक फ़ाइलनाम, एक डोमेन — बिना किसी डेटाबेस लुकअप और बिना किसी समन्वय के। दोनों के बीच एकमात्र अंतर हैश है: v3 MD5 इस्तेमाल करता है, v5 SHA-1, और स्पेसिफ़िकेशन v5 की अनुशंसा करती है। RFC 4122 चार तैयार नेमस्पेस UUID परिभाषित करता है ताकि स्वतंत्र सिस्टम समान इनपुट पर सहमत हों:

उदाहरण के लिए, DNS नेमस्पेस को नाम example.com के साथ v5 के अंतर्गत हैश करने पर हर सही कार्यान्वयन पर हमेशा वही UUID बनता है — यही ठीक-ठीक वजह है कि नेम-बेस्ड UUID बिना किसी साझा स्थिति के सेवाओं में पुनरुत्पादनीय होते हैं।

डेटाबेस प्राइमरी कुंजियों के लिए वर्शन 7 क्यों आगे है

रैंडम v4 UUID ख़राब क्लस्टर्ड प्राइमरी कुंजियाँ बनाते हैं। चूँकि हर मान अप्रत्याशित है, लगातार इंसर्ट पूरे इंडेक्स में बिखर जाते हैं; एक B-ट्री को पूरी संरचना में पेज विभाजित करने पड़ते हैं, वर्किंग सेट कैश में ठीक से नहीं समाता, और तालिका बढ़ने पर राइट थ्रूपुट गिरता है। एक v7 UUID इसे सबसे महत्वपूर्ण बिट में 48-बिट Unix-मिलीसेकंड टाइमस्टैम्प रखकर ठीक करता है, उसके बाद एक ही मिलीसेकंड के भीतर अद्वितीयता के लिए रैंडम बिट। इसलिए मान समय के साथ बढ़ते हैं और निर्माण-क्रम में शब्दकोशीय रूप से सॉर्ट होते हैं, इसलिए नई पंक्तियाँ इंडेक्स के "दाएँ किनारे" पर जुड़ती हैं — वही लोकैलिटी जो एक ऑटो-इंक्रीमेंट पूर्णांक देता है, पर UUID की विकेंद्रित, अननुमेय, मर्ज-अनुकूल प्रकृति बनाए रखते हुए।

यही वजह है कि v7 के अस्तित्व में आने से पहले कई टीमों ने ULID की ओर रुख़ किया। एक ULID एक 128-बिट, समय-सॉर्टेबल पहचानकर्ता है — एक 48-बिट मिलीसेकंड टाइमस्टैम्प और 80 रैंडम बिट — जिसे हेक्साडेसिमल के बजाय 26 Crockford बेस-32 वर्णों में प्रस्तुत किया जाता है। यह वही लोकैलिटी समस्या हल करता है, पर यह कोई IETF मानक नहीं है और इसका पाठ रूप एक मान्य UUID नहीं है। अब जब RFC 9562 ने अनिवार्य रूप से उसी डिज़ाइन के साथ v7 को मानकीकृत किया है, नई परियोजनाएँ पूरी तरह UUID-संगत रहते हुए समय-ऑर्डर्ड ID पा सकती हैं, जो v7 को रैंडम v4 कुंजियों और ULID दोनों से लगातार आगे धकेल रहा है।

"अद्वितीय" के पीछे के आँकड़े, और प्राइवेसी की टिप्पणियाँ

v4 के लिए टकराव की संभावनाएँ ठीक-ठीक आँकड़ों के साथ समझना आसान है। 128 में से छह बिट वर्शन और वैरिएंट के लिए तय हैं, जिससे 122 रैंडम बिट बचते हैं — लगभग 5.3 × 10³⁶ (5.3 अनडेसिलियन) भिन्न मान। बर्थडे समस्या के अनुसार, किसी एक टकराव के होने की संभावना न-होने से अधिक बनने से पहले आपको लगभग 2.71 क्विंटिलियन UUID चाहिए, और उनमें से 103 ट्रिलियन जनरेट करने पर भी किसी डुप्लिकेट की संभावना लगभग एक-अरब-में-एक रहती है — अधिकांश संगठन अपने सभी डेटाबेस मिलाकर जितने पहचानकर्ता कभी बनाएँगे उससे कहीं अधिक। एकमात्र चेतावनी: यह केवल एक अच्छे रैंडम स्रोत के साथ ही टिकता है। किसी कमज़ोर या ग़लत ढंग से सीड किए गए स्यूडो-रैंडम जनरेटर से बना v4 टकरा सकता है और टकराता है।

दो सावधानियाँ दोहराने लायक़ हैं। पहली, UUID एक पहचानकर्ता है, रहस्य नहीं — इसे कभी पासवर्ड, API कुंजी या सेशन टोकन के रूप में इस्तेमाल न करें, जहाँ आपको ऐसा मान चाहिए जो अद्वितीय और किसी समर्पित क्रिप्टोग्राफ़िक स्रोत से अननुमेय हो। दूसरी, टाइम-बेस्ड वर्शन जानकारी लीक कर सकते हैं: एक क्लासिक v1 UUID निर्माण टाइमस्टैम्प और जनरेट करने वाली मशीन का नेटवर्क MAC पता दोनों जड़ता है, जिसने प्रसिद्ध रूप से जाँचकर्ताओं को 1999 के Melissa वायरस के लेखक तक पहुँचने में मदद की। यही ठीक वजह है कि यह जनरेटर v1 को असली MAC के बजाय एक रैंडम नोड से बनाता है, और जब कोई पहचानकर्ता सार्वजनिक रूप से उजागर हो सकता हो तब v4 या v7 सुरक्षित डिफ़ॉल्ट क्यों हैं। अंत में, "GUID" — वह शब्द जो Microsoft इस्तेमाल करता है — बस UUID का दूसरा नाम है; एकमात्र पेच यह है कि कुछ लीगेसी Microsoft GUID मान के हिस्सों को अलग बाइट-क्रम में सीरियलाइज़ करते हैं, इसलिए उन्हें हमेशा कच्चे बाइट के बजाय विहित 8-4-4-4-12 पाठ स्ट्रिंग के रूप में तुलना करें।

व्यवहार में UUID संग्रहण और फ़ॉर्मैटिंग

एक UUID वैचारिक रूप से 16 बाइट है, पर इसे आमतौर पर 36-वर्ण 8-4-4-4-12 स्ट्रिंग के रूप में लिखा जाता है। आप इसे कैसे संग्रहीत करते हैं, यह मायने रखता है। इसे कच्चे 16 बाइट के रूप में रखना — PostgreSQL का मूल uuid प्रकार, या MySQL में BINARY(16) — 36-वर्ण टेक्स्ट कॉलम की आधी से भी कम जगह लेता है और तेज़ इंडेक्स होता है; इसे VARCHAR(36) के रूप में संग्रहीत करना सुविधाजनक है पर बड़े पैमाने पर फ़िज़ूलख़र्च। विहित पाठ रूप लोअर-केस है, हालाँकि स्पेसिफ़िकेशन पार्सरों से अपर-केस भी स्वीकारने की माँग करती है, इसलिए तुलनाओं को केस-असंवेदनशील मानें और आते समय मानों को सामान्यीकृत करें। हाइफ़न केवल सजावटी समूहन हैं — कुछ सिस्टम चार वर्ण बचाने के लिए उन्हें हटा देते हैं — पर विहित, अंतरसंचालनीय रूप उन्हें रखता है।

एक डिज़ाइन सावधानी: चूँकि v1, v6 और v7 एक टाइमस्टैम्प जड़ते हैं, और v4 अननुमेय है, लोग कभी-कभी मान लेते हैं कि किसी URL में कोई भी UUID उजागर करना सुरक्षित है। यह है — अद्वितीयता के लिए — पर UUID फिर भी एक पहचानकर्ता है, कोई प्राधिकरण नहीं। यदि एक्सेस नियंत्रण मान के गुप्त रहने पर निर्भर करता है ("लिंक वाला कोई भी देख सकता है"), तो टाइम-बेस्ड वर्शनों के बजाय v4 या एक समर्पित रैंडम टोकन को प्राथमिकता दें, क्योंकि लीक हुआ v1 या v7 मोटे तौर पर बताता है कि रिकॉर्ड कब बना, और v1 के लिए, संभवतः वह मशीन जिसने इसे बनाया।

कब UUID ग़लत टूल है

UUID मुफ़्त नहीं हैं। 128 बिट पर वे 32-बिट पूर्णांक के चार गुना और 64-बिट के दोगुने आकार के हैं, जो अरबों पंक्तियों और उन्हें संदर्भित करने वाली हर विदेशी कुंजी में जुड़ जाता है। वे इंसानों के लिए भी असुविधाजनक हैं — कोई सपोर्ट टिकट नंबर को "f47ac10b-58cc…" के रूप में ज़ोर से नहीं पढ़ता। यदि आपकी ID एक ही डेटाबेस के भीतर रहती हैं जो पहले से एक विश्वसनीय ऑटो-इंक्रीमेंट अनुक्रम प्रदान करता है, और आपको ऑफ़लाइन, कई नोड पर, या पंक्ति डालने से पहले ID जनरेट करने की ज़रूरत नहीं है, तो एक साधारण अनुक्रमिक पूर्णांक छोटा, तेज़ और अधिक पठनीय है। UUID की ओर ठीक तब जाएँ जब आपको विकेंद्रित जनरेशन चाहिए — क्लाइंट द्वारा, कई सर्वरों द्वारा, या समन्वय के बिना अलग सिस्टमों से मर्ज की गई ID — जहाँ इसकी कोई-केंद्रीय-प्राधिकरण-नहीं गारंटी अपनी क़ीमत वसूलती है। जब आप ऐसा करें, तो v7 को प्राथमिकता दें ताकि आप उस गारंटी को उस इंडेक्स लोकैलिटी का त्याग किए बिना बनाए रखें जिस पर एक डेटाबेस निर्भर करता है।

अक्सर पूछे जाने वाले सवाल

क्या UUID की अद्वितीयता की गारंटी है?

गणितीय रूप से गारंटी नहीं, पर व्यावहारिक उद्देश्यों के लिए हाँ। एक वर्शन-4 UUID में 122 रैंडम बिट होते हैं — किसी टकराव (collision) की थोड़ी-सी भी संभावना बनने से पहले आपको कई वर्षों तक अरबों UUID प्रति सेकंड जनरेट करने पड़ेंगे। वर्शन 5 डिटरमिनिस्टिक है, इसलिए वही नेमस्पेस और नाम डिज़ाइन के अनुसार हमेशा वही UUID उत्पन्न करते हैं।

मुझे कौन-सा UUID वर्शन इस्तेमाल करना चाहिए?

सामान्य अद्वितीय ID के लिए वर्शन 4 (रैंडम) इस्तेमाल करें। यदि आप चाहते हैं कि ID निर्माण-समय के अनुसार सॉर्ट हों तो वर्शन 7 इस्तेमाल करें — यह डेटाबेस प्राइमरी कुंजियों के लिए आदर्श है, क्योंकि यह उस इंडेक्स-फ़्रैगमेंटेशन से बचता है जो रैंडम v4 कुंजियाँ पैदा करती हैं। जब आपको किसी नाम से व्युत्पन्न पुनरुत्पादनीय ID चाहिए तब वर्शन 5 इस्तेमाल करें। वर्शन 1 मुख्यतः लीगेसी संगतता के लिए है।

क्या UUID सुरक्षित या अनुमान लगाने में कठिन होता है?

एक वर्शन-4 UUID इतना अप्रत्याशित होता है कि अनुमान लगाना कठिन हो, पर UUID एक पहचानकर्ता है, कोई गुप्त रहस्य नहीं। इसे पासवर्ड, सेशन टोकन या सुरक्षा कुंजी के रूप में इस्तेमाल न करें — उनके लिए एक समर्पित क्रिप्टोग्राफ़िक रहस्य जनरेट करें।

v4 और v7 में क्या अंतर है?

दोनों अद्वितीय हैं, पर v7 सामने एक मिलीसेकंड टाइमस्टैम्प जड़ता है, इसलिए v7 UUID की सूची निर्माण-क्रम में सॉर्ट होती है। v4 पूरी तरह रैंडम है और इसका कोई क्रम नहीं होता। डेटाबेस कुंजियों के लिए v7 (बेहतर इंडेक्स लोकैलिटी) और जब क्रम मायने न रखे तब v4 इस्तेमाल करें।

यहाँ वर्शन 3 क्यों नहीं है?

वर्शन 3 नेम-बेस्ड है पर MD5 इस्तेमाल करता है, जो क्रिप्टोग्राफ़िक रूप से टूटा हुआ है, और ब्राउज़र का Web Crypto API MD5 उपलब्ध नहीं कराता। हम वर्शन 5 प्रदान करते हैं, वह SHA-1-आधारित समकक्ष जिसकी स्पेसिफ़िकेशन इसके बजाय अनुशंसा करती है।

संबंधित टूल

• SHA हैश जनरेटर
• Unix टाइमस्टैम्प कन्वर्टर
• Base64 एन्कोडर / डिकोडर
• JSON फ़ॉर्मैटर और वैलिडेटर

सभी डेवलपर और डेटा रूपांतरण देखें →