क्या आपको एक ऐसे आइडेंटिफ़ायर की ज़रूरत है जो किसी और द्वारा बनाए गए आइडेंटिफ़ायर से न टकराए, वह भी किसी ऐसी मशीन पर जिसके बारे में आपने कभी सुना तक न हो, और किसी से अनुमति लिए बिना? यही काम एक UUID करता है। यह एक 128-बिट संख्या है, जिसे परिचित 8-4-4-4-12 पैटर्न में 36 वर्णों के रूप में लिखा जाता है, और इसका पूरा डिज़ाइन इस तरह से है कि उनमें से कोई भी दो समान नहीं होंगे, भले ही कोई भी यह समन्वय न कर रहा हो कि किसे कौन सा मिलेगा। यह मुफ़्त जनरेटर उन्हें सीधे आपके ब्राउज़र में बनाता है: 'संस्करण' में एक संस्करण चुनें, 'चयन की संख्या' में बताएं कि आपको कितने चाहिए, और 'जनरेट करें' पर क्लिक करें। यह पृष्ठ एक v4 के साथ खुलता है, वह संस्करण जो अधिकांश प्रोजेक्ट चाहते हैं, ताकि पहला आइडेंटिफ़ायर केवल एक क्लिक दूर हो।
प्रत्येक आइडेंटिफ़ायर आपके ब्राउज़र द्वारा Web Crypto API के माध्यम से बनाया जाता है। संस्करण 4 वहां crypto.randomUUID() का उपयोग करता है जहां ब्राउज़र इसे प्रदान करता है, और अन्यथा crypto.getRandomValues() का — जो Math.random() जैसे JavaScript स्यूडो-रैंडम फ़ंक्शन के बजाय रैंडमनेस का एक क्रिप्टोग्राफ़िक रूप से मज़बूत स्रोत है। संस्करण 7 शुरुआत में एक 48-बिट मिलीसेकंड टाइमस्टैम्प रखता है, फिर एक 12-बिट काउंटर जो उसी मिलीसेकंड के भीतर बढ़ता है, और फिर 62 रैंडम बिट्स, जो RFC 9562 में वर्णित क्रमबद्ध विधि है; उस काउंटर के कारण ही एक हज़ार का बैच बेतरतीब होने के बजाय क्रम में आता है। संस्करण 1 एक टाइमस्टैम्प को एक रैंडम नोड आइडेंटिफ़ायर के साथ जोड़ता है जिसमें मल्टीकास्ट बिट सेट होता है, इसलिए यह 1990 के दशक के मूल कार्यान्वयनों की तरह कभी भी आपके नेटवर्क कार्ड का पता नहीं ले जाता है। संस्करण 3 और 5 बिल्कुल भी रैंडम नहीं हैं: वे MD5 और SHA-1 का क्रमशः उपयोग करके एक नेमस्पेस और एक नाम को एक साथ हैश करते हैं, और वह हैशिंग भी आपके डिवाइस पर ही होती है। सर्वर पर कुछ भी नहीं भेजा जाता है, कुछ भी लॉग नहीं किया जाता है, और एक बार पृष्ठ लोड होने के बाद यह कनेक्शन बंद होने पर भी काम करता रहता है।
'संस्करण' वह फ़ील्ड है जो बाकी सब कुछ तय करता है। संस्करण 4, 122 रैंडम बिट्स है और इसमें कोई संरचना नहीं है — यह डिफ़ॉल्ट है, और तब सही उत्तर है जब एक आइडेंटिफ़ायर का केवल अद्वितीय होना आवश्यक हो। संस्करण 7 में 62 रैंडम बिट्स होते हैं लेकिन यह अपने निर्माण के समय के साथ शुरू होता है, इसलिए उनका एक सेट उस क्रम में सॉर्ट हो जाता है जिस क्रम में उन्हें बनाया गया था; यही बात इसे तब चुनने लायक संस्करण बनाती है जब आइडेंटिफ़ायर एक डेटाबेस की बनने वाला हो। संस्करण 1 मूल समय-आधारित योजना है, जिसे यहां उन सिस्टम्स के लिए रखा गया है जो अभी भी इसकी मांग करते हैं। संस्करण 3 और 5 की जोड़ी अलग है: वे नियतात्मक हैं, जिसका अर्थ है कि समान इनपुट हमेशा समान आइडेंटिफ़ायर उत्पन्न करते हैं, और वे दो अतिरिक्त फ़ील्ड लेते हैं — 'नेमस्पेस', जो कि मानक स्पेस DNS, URL, OID और X.500 में से एक है या आपका अपना कोई 'कस्टम' स्पेस है, और 'नाम', जो पहचानी जा रही स्ट्रिंग है। v5 को URL नेमस्पेस और https://example.com/a दें और आपको आज, कल और किसी और की मशीन पर भी वही UUID मिलेगा। इसी कारण से, v3 या v5 चुने जाने पर 'चयन की संख्या' गायब हो जाती है: एक नियतात्मक मान की एक हज़ार प्रतियां केवल एक नियतात्मक मान की एक हज़ार प्रतियां ही होंगी। हर दूसरे संस्करण के लिए 'चयन की संख्या' 1 से 1000 तक चलती है।
चार स्विच अंतर्निहित 128 बिट्स को बदले बिना आउटपुट का आकार बदलते हैं। 'अपरकेस' हेक्साडेसिमल अंकों को बड़े अक्षरों के रूप में प्रिंट करता है, 'बिना हाइफ़न के' वह कॉम्पैक्ट 32-कैरेक्टर रूप देता है जिसे कुछ कॉलम और फ़ाइल नाम पसंद करते हैं, और 'कर्ली ब्रैकेट' मान को { } के अंदर लपेटता है — वह आकार जिसे Windows और .NET की दुनिया GUID कहती है। 'उन्नत विकल्प' के तहत, urn:uuid: वह उपसर्ग जोड़ता है जो इसे एक औपचारिक URN बनाता है; इसके चालू होने पर यह 'कर्ली ब्रैकेट' और 'बिना हाइफ़न के' को बंद कर देता है, क्योंकि मानक केवल एक URN रूप की अनुमति देता है और वह हाइफ़न वाला कैनोनिकल रूप है। 'कॉपी फ़ॉर्मैट' यह तय करता है कि जब आप कोई बैच लेते हैं तो उसे कैसे जोड़ा जाता है: प्रति पंक्ति एक, अल्पविराम द्वारा अलग किया गया, या उद्धरण में प्रत्येक मान एक पीछे वाले अल्पविराम के साथ, जिसे सीधे कोड में एक ऐरे में पेस्ट किया जा सकता है। परिणाम के नीचे एक पंक्ति बैठती है जो बिट्स में रैंडमनेस की रिपोर्ट करती है — v4 के लिए 122, v7 के लिए 62 — और, v7 के लिए, बैच के पहले आइडेंटिफ़ायर में एन्कोडेड टाइमस्टैम्प, ताकि मान के अंदर का समय निहित होने के बजाय दिखाई दे। 'सभी कॉपी करें' और 'फ़ाइल में सहेजें' दोनों 'कॉपी फ़ॉर्मैट' का सम्मान करते हैं। 'इतिहास' आपके अंतिम 10 बैचों को आपके ब्राउज़र में ही रखता है: इसे वापस लाने के लिए किसी एक पर क्लिक करें, एक प्रविष्टि को कॉपी या हटा दें, या सब कुछ साफ़ करें। 'साफ़ करें' परिणाम को खाली कर देता है और आपकी सेटिंग्स को वैसा ही छोड़ देता है, और 50 आइडेंटिफ़ायर के बाद सूची पचास पंक्तियों के बजाय एक स्क्रॉल करने योग्य ब्लॉक बन जाती है।
इस पृष्ठ पर सबसे महत्वपूर्ण बात एक प्राइमरी की के रूप में v4 और v7 के बीच का अंतर है, और यह पसंद का मामला नहीं है। डेटाबेस इंडेक्स वे पेड़ होते हैं जिन्हें सॉर्ट किए गए क्रम में रखा जाता है, और एक नई की उस क्रम में कहां पहुंचती है, यह तय करता है कि इंसर्ट करने में कितना काम लगेगा। एक v4 की रैंडम होती है, इसलिए लगातार इंसर्ट इंडेक्स के असंबंधित कोनों में पहुंचते हैं: जो पेज भरे हुए थे वे स्प्लिट हो जाते हैं, डेटाबेस मेमोरी में पेड़ के जिन हिस्सों को पकड़े हुए है वे शायद ही कभी वे हिस्से होते हैं जिनकी अगली इंसर्ट को आवश्यकता होती है, और इंडेक्स उन पंक्तियों की तुलना में बड़ा और अधिक खंडित हो जाता है जिनकी ओर वह इशारा करता है। एक v7 की वर्तमान मिलीसेकंड के साथ शुरू होती है, इसलिए लगातार इंसर्ट पेड़ के दाहिने किनारे पर एक-दूसरे के बगल में पहुंचते हैं, जो वह पैटर्न है जो एक ऑटो-इंक्रीमेंटिंग इंटीजर पैदा करता है और वह पैटर्न जिसके इर्द-गिर्द इंडेक्स संरचनाएं बनाई गई थीं। यही पूरा ट्रेडऑफ़ है: v7 आपको एक अनुक्रमिक की का इंसर्ट व्यवहार देता है और साथ ही उस गुण को भी बनाए रखता है जिसके कारण आपने पहली बार UUID को चुना था, जो यह है कि कोई भी सर्वर से पूछे बिना इसे बना सकता है। इसकी कीमत यह है कि अब निर्माण का समय आइडेंटिफ़ायर के अंदर पढ़ा जा सकता है, और यह मायने रखता है या नहीं, यह आपके डेटा के बारे में एक सवाल है, न कि फ़ॉर्मैट के बारे में।
कोई भी चीज़ कभी किसी UUID की विशिष्टता की जांच नहीं करती है; इसका आकार ही इसकी गारंटी है। कोई रजिस्ट्री नहीं है, कोई सर्वर राउंड-ट्रिप नहीं है, कोई लुकअप नहीं है — एक जनरेटर एक संख्या पैदा करता है और उसे सौंप देता है, और उनमें से दो के आपस में न टकराने का कारण केवल यह है कि 2^122 संभावित v4 मान हैं, यानी लगभग 5.3 × 10^36। बर्थडे प्रॉब्लम इसे मापने का ईमानदार तरीका है: किसी भी दो के मेल खाने की 50% संभावना होने से पहले आपको लगभग 2.7 × 10^18 आइडेंटिफ़ायर की आवश्यकता होगी, जो 86 वर्षों तक हर सेकंड एक बिलियन नए UUID हैं। यह क्या वादा करता है और क्या नहीं करता है, इसके बारे में सटीक होना उचित है। यह एक सांख्यिकीय गारंटी है, अंकगणितीय नहीं, और यह केवल तब तक लागू रहती है जब तक कि अंतर्निहित रैंडमनेस वास्तविक हो — एक जनरेटर जिसे खराब तरीके से सीड किया गया हो, या एक वर्चुअल मशीन जिसे उसके एंट्रॉपी पूल के साथ क्लोन किया गया हो, इसे इस तरह से तोड़ता है जिसका फ़ॉर्मैट पता नहीं लगा सकता। संस्करण 7 इस प्रश्न को और भी सीमित कर देता है: एक ही मिलीसेकंड के अंदर कोई जनरेटर खुद को बिल्कुल भी दोहरा नहीं सकता, क्योंकि काउंटर पासा फेंकने के बजाय बढ़ता है, और स्वतंत्र जनरेटरों के बीच 62 रैंडम बिट्स काम करते हैं।
एक UUID एक आइडेंटिफ़ायर है, पासवर्ड नहीं। संस्करण 4 अप्रत्याशित है, और यह लोगों को इसे एक रहस्य के रूप में मानने के लिए ललचाता है — पासवर्ड-रीसेट लिंक, एक URL जिसका अनुमान न लगाया जा सके, एक सेशन टोकन, एक API की। अप्रत्याशितता वास्तविक है, लेकिन गोपनीयता इस बात की संपत्ति है कि किसी मान को कैसे संभाला जाता है, और आइडेंटिफ़ायर्स को जानबूझकर लापरवाही से संभाला जाता है: वे URL में बैठते हैं, जो ब्राउज़र के इतिहास, सर्वर लॉग्स, रेफ़रर हेडर्स और एनालिटिक्स में पहुंचते हैं, और चैट संदेशों में पेस्ट किए जाते हैं। अन्य संस्करण और भी खराब विकल्प हैं। संस्करण 1 और संस्करण 7 दोनों निर्माण के क्षण को एन्कोड करते हैं, इसलिए जिस किसी के पास भी यह है, उसे मोटे तौर पर पता होता है कि इसे कब बनाया गया था और वह उसके साथ बनाई गई हर चीज़ के आस-पड़ोस को सीमित कर सकता है। संस्करण 3 और 5 जानबूझकर नियतात्मक हैं: ईमेल पते का v5 UUID कोई हैश किया हुआ रहस्य नहीं है, यह एक ऐसा मान है जिसकी गणना समान पते वाला कोई भी व्यक्ति एक सेकंड में कर सकता है। किसी चीज़ का नाम रखने के लिए UUID का उपयोग करें। जब मान का अज्ञात रहना आवश्यक हो, तो पासवर्ड जनरेटर का या रहस्यों के लिए बनाई गई लाइब्रेरी से किसी टोकन का उपयोग करें।
इस UUID जनरेटर को क्यों चुनें?
- केवल-ब्राउज़र जनरेशन: आइडेंटिफ़ायर्स आपके डिवाइस पर बनते हैं और कभी भी कहीं नहीं भेजे जाते
- Web Crypto API की रैंडमनेस: क्रिप्टोग्राफ़िक रूप से सुरक्षित, Math.random() नहीं
- एक ही स्थान पर पांच संस्करण: v1, v3, v4, v5 और v7, टूल बदले बिना
- वास्तव में क्रमबद्ध v7: मिलीसेकंड के भीतर एक काउंटर, जैसा कि RFC 9562 वर्णित करता है
- चार मानक नेमस्पेस या आपके अपने के साथ नियतात्मक v3 और v5
- एक बार में 1000 तक, पचास के बाद एक कॉम्पैक्ट स्क्रॉल करने योग्य सूची के साथ
- हर सामान्य आकार: हाइफ़न वाला, बिना हाइफ़न का, अपरकेस, ब्रैकेट वाला या urn:uuid: URN
- लाइन्स, कॉमा या उद्धृत मानों के रूप में कॉपी करें जो सीधे कोड में पेस्ट होते हैं
- असीमित और मुफ़्त: कोई साइन-अप नहीं, उपयोग की कोई सीमा नहीं, हमारे सर्वर पर कुछ भी नहीं
UUIDs वहां दिखाई देते हैं जहां किसी चीज़ का नाम इससे पहले रखा जाना होता है कि कोई यह पुष्टि कर सके कि वह नाम मुफ़्त है। एप्लिकेशन कोड उन्हें उन पंक्तियों के लिए बनाता है जिन्हें वह डालने वाला होता है, ताकि ऑब्जेक्ट के डेटाबेस तक पहुंचने से पहले ही उसकी एक पहचान हो और एक क्लाइंट उस समय उसका संदर्भ ले सके जब राइट अभी भी जारी हो। वितरित सिस्टम उन पर अधिक निर्भर करते हैं: एक ही टेबल में लिखने वाली कई सेवाएं, हवाई जहाज में ऑफ़लाइन रिकॉर्ड बनाने वाला एक मोबाइल क्लाइंट, एक कतार जिसे उस संदेश को पहचानना होता है जिसे वह पहले ही प्रोसेस कर चुकी है — इनमें से कोई भी साझा काउंटर के लिए अपनी बारी का इंतज़ार नहीं कर सकता। संस्करण 5 एक अलग ज़रूरत को पूरा करता है, जो आपके पास पहले से मौजूद किसी चीज़ से प्राप्त एक स्थिर आइडेंटिफ़ायर है: एक ही दस्तावेज़, एक ही URL या एक ही खाता हमेशा एक ही UUID पर मैप होता है, ताकि बिना किसी डुप्लीकेशन के एक इम्पोर्ट दो बार चल सके। दूसरी जगहों पर, वे बस एक ऐसा फ़ॉर्मैट होते हैं जिसकी कोई सिस्टम मांग करता है — लॉग्स और ट्रेसेज़ में पिरोया गया एक कोरिलेशन आइडेंटिफ़ायर, एक फ़ाइल नाम जो तब नहीं टकराएगा जब एक हज़ार यूज़र्स का अपलोड एक बकेट में आएगा, एक Windows रजिस्ट्री की, एक टेस्ट डेटा जिसे वास्तविक डेटा जैसा दिखना चाहिए।
कुछ ईमानदार सीमाओं को जानना उचित है। एक बैच एक संस्करण है: 'संस्करण' में जो मान चुना गया है वह उसमें मौजूद हर चीज़ पर लागू होता है, इसलिए v4 का एक रन और v7 का एक रन दो अलग-अलग बैच हैं। यह एक जनरेटर है, कोई इंस्पेक्टर नहीं — UUID को पेस्ट करके उसका संस्करण या टाइमस्टैम्प वापस पढ़ना कोई ऐसा काम नहीं है जो यह पृष्ठ करता है। 'फ़ाइल में सहेजें' CSV या JSON के बजाय एक सादा टेक्स्ट फ़ाइल लिखता है। संस्करण 7 खुले तौर पर यह बताता है कि इसे कब बनाया गया था, मिलीसेकंड तक, जो एक कमी के बजाय एक वास्तविक ट्रेडऑफ़ है, और संस्करण 1 उसी तरह समय को लीक करता है; यदि वह आपके डेटा के लिए कोई समस्या है, तो संस्करण 4 वह संस्करण है जो किसी को कुछ नहीं बताता। मानक के दो विशेष मान संस्करण नहीं हैं और इसलिए 'संस्करण' में विकल्प नहीं हैं, लेकिन आप उन्हें यहां से कॉपी कर सकते हैं: निल UUID, 00000000-0000-0000-0000-000000000000, और अधिकतम UUID, ffffffff-ffff-ffff-ffff-ffffffffffff। इस पृष्ठ पर मौजूद हर चीज़ RFC 9562 का पालन करती है, वह स्पेसिफिकेशन जिसने 2024 में RFC 4122 की जगह ली, इसलिए आउटपुट किसी भी लाइब्रेरी, डेटाबेस या API द्वारा स्वीकार किया जाता है जो UUIDs को संभालता है। इन सीमाओं के भीतर गारंटी एक मज़बूत गारंटी है: प्रत्येक आइडेंटिफ़ायर आपके अपने मशीन पर, क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडमनेस से, मानक के अनुसार बनाया गया है, और इसे कभी कोई और नहीं देखता है।