तुम्हाला असा आयडेंटिफायर हवा आहे का जो इतर कुणीही तयार केलेल्या आयडेंटिफायरशी कधीही जुळणार नाही, तोही अशा मशीनवर ज्याबद्दल तुम्ही कधी ऐकलेही नसेल, आणि त्यासाठी कुणाचीही परवानगी घेण्याची गरज नसेल? हेच नेमके UUID चे काम आहे. हा एक 128-बिट नंबर असतो, जो नेहमीच्या 8-4-4-4-12 पॅटर्नमध्ये 36 कॅरेक्टर्सच्या स्वरूपात लिहिला जातो, आणि याची संपूर्ण रचना अशी असते की यापैकी कोणतेही दोन नंबर कधीही सारखे असू शकत नाहीत — मग कुणाला कोणता मिळेल हे कुणीही ठरवत नसले तरीही. हे मोफत जनरेटर तुमच्या ब्राउझरमध्येच ते तयार करते: 'आवृत्ती' मधून आवृत्ती निवडा, 'निवडीची संख्या' मध्ये तुम्हाला किती हवे आहेत ते सांगा आणि 'तयार करा' दाबा. हे पेज उघडल्यावर बहुतांश प्रकल्पांना आवश्यक असलेले v4 चे एक UUID आधीपासूनच तयार असते, त्यामुळे तुम्हाला पहिला आयडेंटिफायर एका क्लिकवर मिळतो.
प्रत्येक आयडेंटिफायर तुमच्या ब्राउझरद्वारे Web Crypto API वापरून तयार केला जातो. जिथे ब्राउझर सपोर्ट करतो तिथे आवृत्ती 4 (v4) crypto.randomUUID() वापरते आणि इतर ठिकाणी crypto.getRandomValues() वापरते — हा Math.random() सारखा JavaScript चा स्यूडो-रँडम फंक्शन नसून खऱ्या अर्थाने क्रायप्टोग्राफिकली सुरक्षित रँडमनेसचा स्रोत आहे. आवृत्ती 7 (v7) च्या सुरुवातीला 48-बिट मिलिसेकंद टाइमस्टॅम्प असतो, त्यानंतर त्याच मिलिसेकंदमध्ये वाढणारा 12-बिट काउंटर असतो, आणि त्यानंतर 62 रँडम बिट्स असतात, ही RFC 9562 मध्ये वर्णन केलेली क्रमवारीची पद्धत आहे; याच काउंटरमुळे हजाराचा एक गट (बॅच) विस्कळीत न होता क्रमाने बाहेर येतो. आवृत्ती 1 (v1) टाइमस्टॅम्पला अशा रँडम नोड आयडेंटिफायरसोबत जोडते ज्यामध्ये मल्टीकास्ट बिट सेट केलेले असते, त्यामुळे 1990 च्या दशकातील सुरुवातीच्या आवृत्त्यांप्रमाणे यात तुमच्या नेटवर्क कार्डचा पत्ता कधीही वापरला जात नाही. आवृत्ती 3 (v3) आणि 5 (v5) अजिबात रँडम नसतात: ते अनुक्रमे MD5 आणि SHA-1 वापरून नेमस्पेस आणि नाव यांना एकत्र हॅश करतात, आणि हे हॅशिंग सुद्धा तुमच्याच डिव्हाइसवर होते. सर्व्हरवर काहीही पाठवले जात नाही, कशाचीही नोंद ठेवली जात नाही, आणि एकदा पेज लोड झाले की इंटरनेट कनेक्शन बंद असले तरीही ते काम करत राहते.
'आवृत्ती' हे असे फील्ड आहे जे बाकी सर्व काही ठरवते. आवृत्ती 4 मध्ये 122 रँडम बिट्स असतात आणि कोणतीही विशिष्ट रचना नसते — हा डीफॉल्ट पर्याय आहे, आणि जेव्हा आयडेंटिफायर फक्त युनिक असणे आवश्यक असते तेव्हा हेच योग्य उत्तर असते. आवृत्ती 7 मध्ये 62 रँडम बिट्स कायम राहतात पण त्याची सुरुवात ते तयार झालेल्या वेळेने होते, त्यामुळे अशा आयडेंटिफायर्सचा संच ते तयार झालेल्या वेळेनुसार क्रमाने लावता येतो; म्हणूनच जेव्हा आयडेंटिफायर डेटाबेसची की (key) बनणार असतो तेव्हा या आवृत्तीची निवड केली जाते. आवृत्ती 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 बनते; हे सुरू असताना 'महिरपी कंस' आणि 'हायफनशिवाय' बंद राहतात, कारण मानक (standard) फक्त एकाच URN रूपाला परवानगी देते आणि ते हायफन असलेले कॅनॉनिकल रूप असते. 'कॉपी फॉरमॅट' हे ठरवते की तुम्ही घेतलेली बॅच कशी जोडली जाईल: प्रत्येक ओळीत एक, स्वल्पविरामाने वेगळे केलेले, किंवा कोडमधील अरे (array) मध्ये थेट पेस्ट करण्यासाठी प्रत्येक मूल्य अवतरण चिन्हात आणि शेवटी स्वल्पविराम असलेले. निकालाच्या खाली एक ओळ असते जी रँडमनेस बिट्समध्ये सांगते — v4 साठी 122, v7 साठी 62 — आणि v7 च्या बाबतीत, बॅचच्या पहिल्या आयडेंटिफायरमध्ये एनकोड केलेला टाइमस्टॅम्प दाखवला जातो, त्यामुळे मूल्याच्या आतील वेळ लपून न राहता स्पष्ट दिसते. 'सर्व कॉपी करा' आणि 'फाइलमध्ये जतन करा' हे दोन्हीही 'कॉपी फॉरमॅट' प्रमाणेच काम करतात. 'इतिहास' तुमच्या ब्राउझरमध्ये शेवटच्या 10 बॅचेस जतन करून ठेवतो: एखादी बॅच परत आणण्यासाठी त्यावर क्लिक करा, एखादी एंट्री कॉपी करा किंवा हटवा, किंवा सर्व साफ करा. 'साफ करा' बटण तुमची सेटिंग्ज तशीच ठेवून केवळ निकाल रिकामा करते, आणि 50 हून अधिक आयडेंटिफायर्स असल्यास यादी पन्नास ओळींऐवजी स्क्रोल करता येण्याजोग्या एका ब्लॉकच्या स्वरूपात दिसते.
या पेजवरील सर्वात महत्त्वपूर्ण गोष्ट म्हणजे प्रायमरी की (primary key) म्हणून v4 आणि v7 मधील फरक, आणि हा केवळ पसंतीचा मुद्दा नाही. डेटाबेस इंडेक्सेस हे क्रमाने (sorted order) ठेवलेले ट्री (trees) असतात, आणि नवीन की त्या क्रमाने कुठे पडते यावर इन्सर्ट (insert) करण्यासाठी किती काम करावे लागेल हे ठरते. v4 ची की रँडम असते, त्यामुळे एकापाठोपाठ येणारे इन्सर्ट्स इंडेक्सच्या कोणत्याही अनपेक्षित कोपऱ्यात पडतात: भरलेली पेजेस दुभंगली जातात, डेटाबेसने मेमरीमध्ये ठेवलेले ट्री चे भाग सहसा पुढच्या इन्सर्टला लागणाऱ्या भागांपेक्षा वेगळे असतात, आणि शेवटी इंडेक्स हा तो ज्या रोज (rows) कडे निर्देश करत असतो त्यापेक्षा खूप मोठा आणि विखंडित (fragmented) बनतो. v7 ची की सध्याच्या मिलिसेकंदने सुरू होते, त्यामुळे एकापाठोपाठ येणारे इन्सर्ट्स ट्री च्या उजव्या टोकाला एकत्र पडतात, जो असा पॅटर्न आहे जो ऑटो-इन्क्रिमेंटिंग इंटिजर (auto-incrementing integer) तयार करतो आणि ज्या पॅटर्नवर इंडेक्स संरचना आधारलेल्या असतात. हीच ती खरी तडजोड आहे: v7 तुम्हाला सिक्वेन्शियल की चे इन्सर्ट बिहेविअर देते आणि त्याचवेळी तुम्हाला UUID निवडायला लावणारे वैशिष्ट्यही जपते, म्हणजेच कुणीही सर्व्हरला न विचारता UUID तयार करू शकतो. याची किंमत अशी आहे की तयार करण्याची वेळ आता आयडेंटिफायरच्या आत वाचता येते, आणि याने काही फरक पडतो की नाही हा तुमच्या डेटाचा प्रश्न आहे, फॉरमॅटचा नाही.
UUID च्या युनिक असण्याची पडताळणी कोणतेही साधन करत नाही; त्याचा आकारच ही खात्री देतो. तिथे कोणतीही रजिस्ट्री नसते, सर्व्हरला राउंड-ट्रिप नसते, लुकअप नसते — एक जनरेटर नंबर तयार करतो आणि तो तुम्हाला देतो, आणि यापैकी दोन नंबर कधीही एकमेकांना धडकत नाहीत (collide होत नाहीत) कारण v4 च्या 2^122 संभाव्य व्हॅल्यूज असतात, जे सुमारे 5.3 × 10^36 (5.3 अनडेसिलियन) आहेत. बर्थ-डे प्रॉब्लेम (birthday problem) हा या आकाराचा अंदाज घेण्याचा प्रामाणिक मार्ग आहे: कोणत्याही दोन आयडेंटिफायर्सची जुळणी होण्याची 50% शक्यता निर्माण होण्यासाठी तुम्हाला अंदाजे 2.7 × 10^18 (2.7 क्विंटिलियन) आयडेंटिफायर्सची आवश्यकता असेल — जे 86 वर्षांपर्यंत दर सेकंदाला एक अब्ज नवीन UUID तयार करण्याइतके आहे. हे काय वचन देते आणि काय देत नाही याबद्दल नेमके असणे महत्त्वाचे आहे. ही एक सांख्यिकीय (statistical) खात्री आहे, अंकगणितीय नाही, आणि ती तेव्हाच खरी ठरते जेव्हा त्यामागील रँडमनेस खरा असतो — जर जनरेटरला चुकीचे सीड (seed) दिलेले असेल, किंवा व्हर्च्युअल मशीन तिच्या एंट्रोपी पूलसह क्लोन केली असेल, तर ते अशा प्रकारे मोडते जे फॉरमॅटला शोधता येत नाही. आवृत्ती 7 हा प्रश्न आणखी संकुचित करते: एकाच मिलिसेकंदच्या आत एक जनरेटर स्वतःची पुनरावृत्ती करूच शकत नाही, कारण काउंटर रँडम नंबर टाकण्याऐवजी वाढवत (increment) जातो, आणि स्वतंत्र जनरेटर्समध्ये 62 रँडम बिट्स हे काम पार पाडतात.
UUID हा एक आयडेंटिफायर आहे, पासवर्ड नाही. आवृत्ती 4 चा अंदाज लावणे अशक्य आहे, आणि यामुळेच लोक याला गुपित (secret) मानण्याची चूक करतात — जसे की पासवर्ड-रीसेट लिंक, न ओळखता येणारी URL, सेशन टोकन, API की. अंदाज न लावता येणे ही खरी गोष्ट आहे, पण गोपनीयता हा व्हॅल्यू कशी हाताळली जाते याचा गुणधर्म आहे, आणि आयडेंटिफायर्स हे डिझाईननुसार निष्काळजीपणे हाताळले जातात: ते URLs मध्ये बसतात, जे ब्राउझरच्या इतिहासात, सर्व्हरच्या लॉग्जमध्ये, रेफरेर हेडर्समध्ये आणि ॲनालिटिक्समध्ये नोंदवले जातात आणि चॅट मेसेजेसमध्ये पेस्ट केले जातात. इतर आवृत्त्या तर यापेक्षाही वाईट पर्याय आहेत. आवृत्ती 1 आणि आवृत्ती 7 दोन्हीही ते केव्हा तयार झाले ही वेळ एनकोड करतात, त्यामुळे ते धारण करणाऱ्या कुणालाही ते अंदाजे केव्हा तयार झाले हे समजते आणि त्यासोबत तयार झालेल्या इतर सर्व गोष्टींची व्याप्ती तो कमी करू शकतो. आवृत्ती 3 आणि 5 मुद्दामहून डिटरमिनिस्टिक बनवलेल्या आहेत: ईमेल पत्त्याचा v5 UUID हा हॅश केलेला सिक्रेट नसून, तो असा व्हॅल्यू आहे जो समान पत्ता असलेला कुणीही एका सेकंदात कॅल्क्युलेट करू शकतो. एखाद्या गोष्टीला नाव देण्यासाठी UUID चा वापर करा. जर व्हॅल्यू कुणालाही समजता कामा नये असे वाटत असेल, तर पासवर्ड जनरेटर किंवा सिक्रेट्ससाठी बनवलेल्या लायब्ररीतील टोकन वापरा.
हे UUID जनरेटर का निवडावे?
- केवळ ब्राउझरमध्ये जनरेशन: आयडेंटिफायर्स तुमच्या डिव्हाइसवर तयार केले जातात आणि ते कुठेही पाठवले जात नाहीत
- Web Crypto API रँडमनेस: क्रायप्टोग्राफिकली सुरक्षित, Math.random() नव्हे
- पाचही आवृत्त्या एकाच ठिकाणी: साधने न बदलता v1, v3, v4, v5 आणि v7
- खऱ्या अर्थाने क्रमाने असणारे v7: RFC 9562 मध्ये वर्णन केल्याप्रमाणे मिलिसेकंदमधील काउंटर
- 4 प्रमाणित नेमस्पेसेस किंवा तुमच्या स्वतःच्या नेमस्पेससह डिटरमिनिस्टिक v3 आणि v5
- एकाच वेळी 1000 पर्यंत तयार करण्याची सोय, 50 च्या पुढे कॉम्पॅक्ट स्क्रोल करण्यायोग्य यादीसह
- प्रत्येक सामान्य आकार: हायफन असलेले, साधे, मोठी अक्षरे, कंसात किंवा urn:uuid: URN
- कोडमध्ये थेट पेस्ट करण्यासाठी ओळी, स्वल्पविराम किंवा अवतरण चिन्हांकित व्हॅल्यूज म्हणून कॉपी करा
- अमर्यादित आणि मोफत: कोणतेही साईन-अप नाही, वापराच्या मर्यादा नाहीत, आमच्या सर्व्हर्सवर काहीही नाही
ज्या वेळी एखाद्या गोष्टीला नाव देण्याची गरज असते आणि ते नाव उपलब्ध असल्याची खात्री कुणीही करू शकत नाही, तेव्हा UUIDs समोर येतात. ॲप्लिकेशन कोड ज्या रोज (rows) तो इन्सर्ट करणार आहे त्यासाठी हे आयडेंटिफायर्स तयार करतो, जेणेकरून तो ऑब्जेक्ट डेटाबेसपर्यंत पोहोचण्याआधीच त्याची स्वतःची ओळख असते आणि राईट (write) ची प्रक्रिया सुरू असतानाच क्लायंट त्याचा संदर्भ घेऊ शकतो. डिस्ट्रीब्युटेड सिस्टिम्स यांच्यावर अधिक अवलंबून असतात: एकाच टेबलमध्ये लिहिणाऱ्या अनेक सेवा, विमानात ऑफलाइन रेकॉर्ड्स तयार करणारा मोबाईल क्लायंट, किंवा अशी रांग (queue) जिने आधीच प्रक्रियेत घेतलेला संदेश ओळखणे आवश्यक असते — यापैकी कुणीही सामायिक काउंटरसाठी (shared counter) आपली वेळ येण्याची वाट पाहू शकत नाही. आवृत्ती 5 वेगळी गरज पूर्ण करते, जी म्हणजे तुमच्याकडे आधीपासून असलेल्या गोष्टीवरून काढलेला स्थिर आयडेंटिफायर: समान डॉक्युमेंट, समान URL किंवा समान खाते नेहमी एकाच UUID शी जोडले जाते, ज्यामुळे कोणतेही डुप्लिकेशन न होता इम्पोर्ट दोनदा चालवता येते. इतर ठिकाणी ते फक्त सिस्टिमला आवश्यक असणारे फॉरमॅट असते — लॉग्ज आणि ट्रेसेस मधून जाणारा कोरिलेशन आयडेंटिफायर, हजारो वापरकर्त्यांनी अपलोड केलेल्या फाईल्स जेव्हा एकाच बकेटमध्ये येतात तेव्हा एकमेकांना न धडकणारे फाईलचे नाव, Windows रजिस्ट्री की, किंवा खऱ्या डेटासारखे दिसणे आवश्यक असणारे टेस्ट फिक्स्चर (test fixture).
काही प्रामाणिक मर्यादा माहीत असणे फायद्याचे आहे. एक बॅच म्हणजे एक आवृत्ती: 'आवृत्ती' मधील मूल्य त्यातील सर्व गोष्टींना लागू होते, त्यामुळे v4 ची रन आणि v7 ची रन या दोन वेगवेगळ्या बॅचेस आहेत. हे एक जनरेटर आहे, इन्स्पेक्टर नाही — एखादा UUID तिथे पेस्ट करून त्याची आवृत्ती किंवा टाइमस्टॅम्प परत वाचणे हे या पेजचे काम नाही. 'फाइलमध्ये जतन करा' हे CSV किंवा JSON ऐवजी साधी मजकूर फाईल (plain text file) लिहिते. आवृत्ती 7 ते कधी तयार झाले हे मिलिसेकंदपर्यंत उघडपणे सांगते, जो दोष नसून खरी तडजोड आहे, आणि आवृत्ती 1 ही त्याच प्रकारे वेळ उघड करते; जर हा तुमच्या डेटासाठी प्रॉब्लेम असेल, तर आवृत्ती 4 ही अशी आवृत्ती आहे जी कुणालाही काहीही सांगत नाही. मानकातील दोन विशेष व्हॅल्यूज या आवृत्त्या नाहीत त्यामुळे 'आवृत्ती' मध्ये पर्याय म्हणून दिसत नाहीत, पण तुम्ही ते इथून कॉपी करू शकता: nil UUID, 00000000-0000-0000-0000-000000000000, आणि max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff. या पेजवरील सर्व गोष्टी RFC 9562 चे पालन करतात, ज्याने 2024 मध्ये RFC 4122 ची जागा घेतली, त्यामुळे येथील आउटपुट UUID हाताळणाऱ्या कोणत्याही लायब्ररी, डेटाबेस किंवा API द्वारे स्वीकारले जाते. या मर्यादांमध्ये दिलेली खात्री खूप भक्कम आहे: प्रत्येक आयडेंटिफायर मानकानुसार, क्रायप्टोग्राफिकली सुरक्षित रँडमनेसपासून, तुमच्या स्वतःच्या मशीनवर तयार केला जातो, आणि इतर कुणीही तो कधीही पाहत नाही.