UUID जनरेटर

UUID v4 क्या है?

एक UUID (यूनिवर्सली यूनीक आइडेंटिफ़ायर) एक 128-बिट संख्या है जो पाँच हाइफ़न-अलग समूहों में 32 हेक्साडेसिमल अंकों के रूप में लिखी जाती है, जैसे 550e8400-e29b-41d4-a716-446655440000। वर्शन 4 UUID रैंडम डेटा से बनाए जाते हैं: 128 में से 122 बिट रैंडम हैं, और 6 बिट वर्शन (तीसरे समूह में अंक 4) और वेरिएंट (चौथे समूह की शुरुआत में 8, 9, a, या b) चिह्नित करने के लिए तय हैं।

टकराव की संभावना खगोलीय रूप से कम है। लगभग 5.3 × 10^36 संभावित v4 UUID हैं, इसलिए एक डुप्लिकेट की 50% संभावना तक पहुँचने से पहले आप लगभग 85 वर्षों तक प्रति सेकंड एक अरब बना सकते हैं — यही कारण है कि UUID को बिना किसी केंद्रीय समन्वय के डेटाबेस कुंजी, रिक्वेस्ट ID, और फ़ाइल नामों के रूप में उपयोग किया जाता है।

यह टूल Web Crypto API (crypto.randomUUID, crypto.getRandomValues फ़ॉलबैक के साथ) का उपयोग करता है, इसलिए हर UUID एक क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडम नंबर जनरेटर से आता है और पूरी तरह आपके ब्राउज़र में बनाया जाता है।

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

UUID v4 क्या है?

एक UUID (यूनिवर्सली यूनीक आइडेंटिफ़ायर) एक 128-बिट आइडेंटिफ़ायर है जो पाँच हाइफ़न-अलग समूहों में 32 हेक्साडेसिमल अंकों के रूप में लिखा जाता है, जैसे 550e8400-e29b-41d4-a716-446655440000। वर्शन 4 UUID रैंडम डेटा से बनाए जाते हैं — 128 में से 122 बिट रैंडम हैं, जबकि 6 बिट वर्शन और वेरिएंट चिह्नित करने के लिए तय हैं।

क्या दो बनाए गए UUID कभी टकरा सकते हैं?

सिद्धांत रूप में हाँ, व्यवहार में नहीं। 122 रैंडम बिट के साथ लगभग 5.3 undecillion (5.3 × 10^36) संभावित v4 UUID हैं। एक टकराव की 50% संभावना तक पहुँचने के लिए आपको लगभग 85 वर्षों तक हर सेकंड लगभग एक अरब UUID बनाने पड़ेंगे।

क्या रैंडमनेस क्रिप्टोग्राफ़िक रूप से सुरक्षित है?

हाँ। UUID ब्राउज़र के Web Crypto API (crypto.randomUUID, crypto.getRandomValues पर फ़ॉलबैक के साथ) से बनाए जाते हैं, जो एक क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडम नंबर जनरेटर का उपयोग करता है — अनुमानित Math.random नहीं।

क्या UUID सर्वर पर बनाए जाते हैं?

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

अपरकेस और नो-हाइफ़न विकल्प किसके लिए हैं?

कुछ सिस्टम UUID को अपरकेस में स्टोर या तुलना करते हैं, और कुछ (जैसे कुछ डेटाबेस और API) बिना हाइफ़न के 32-कैरेक्टर रूप की अपेक्षा करते हैं। विकल्प उसी अंतर्निहित मान को फिर से फ़ॉर्मेट करते हैं — RFC 4122 के अनुसार केस और हाइफ़न UUID की पहचान नहीं बदलते, जो उन्हें समकक्ष मानता है।