UUID बनाएं
निजी — आपकी फ़ाइल कभी स्टोर नहीं होती
कौन सा वर्शन?
आपका UUID यहां दिखेगा।
यह कैसे काम करता है
वर्शन चुनें
जिसका अंदाज़ा न लगाया जा सके, उसके लिए v4। डेटाबेस की के लिए v7। फ़र्क़ मान नहीं लिया जाता, पेज पर समझाया जाता है।
चुनें कि कितने
एक, या एक साथ दस हज़ार तक, वैकल्पिक फ़ॉर्मैटिंग के साथ — UPPERCASE, ब्रेसेस, बिना हाइफ़न, या कोड के लिए तैयार कोट की हुई सूची।
कॉपी करें
सब कॉपी करें, या टेक्स्ट फ़ाइल के रूप में डाउनलोड करें।
वर्शन 4 या वर्शन 7, और डेटाबेस में यह क्यों मायने रखता है
UUID 128 बिट का होता है, जिसे जाने-पहचाने 8-4-4-4-12 समूहों में 32 hex अंकों के रूप में लिखा जाता है। इनमें से छह बिट यह बताने में ख़र्च होते हैं कि यह कौन-सा वर्शन और वैरिएंट है, जिससे वर्शन 4 में 122 रैंडम बिट बचते हैं — इतने कि आप सौ साल तक हर सेकंड एक अरब बनाएं, तब भी एक ही UUID दोबारा मिलने की संभावना बेहद कम रहेगी। यही इसकी पूरी ख़ूबी है: दो सिस्टम जिन्होंने कभी आपस में बात नहीं की, दोनों आइडेंटिफ़ायर बना सकते हैं और बेफ़िक्र मान सकते हैं कि वे कभी टकराएंगे नहीं।
यह तभी सच है जब रैंडमनेस असली हो, और यहां वह सामान्य रैंडम नंबर जनरेटर से नहीं, क्रिप्टोग्राफ़िक रैंडम स्रोत से आती है। यह फ़र्क़ तब मायने रखता है जब आइडेंटिफ़ायर को एक्सेस टोकन की तरह इस्तेमाल किया जाए — पासवर्ड रीसेट लिंक, कोई ऐसा शेयर URL जिसका अंदाज़ा न लगे — क्योंकि अनुमान लगाने लायक जनरेटर से कोई पिछली वैल्यू देखकर अगली निकाल सकता है। क्रिप्टोग्राफ़िक स्रोत के साथ अनुमान लगाने को कुछ नहीं होता।
वर्शन 7 इसलिए है क्योंकि डेटाबेस प्राइमरी की के रूप में वर्शन 4 बुरा बर्ताव करता है। यह शुरुआत में 48-बिट मिलीसेकंड टाइमस्टैम्प रखता है और बाक़ी रैंडमनेस से भरता है, इसलिए क्रम से बने UUID उसी क्रम में सॉर्ट होते हैं जिसमें वे बने थे। यह दिखावटी बात लगती है, पर है नहीं: रैंडम की हर insert को पूरे इंडेक्स में बिखेर देती है, इसलिए हर write अलग पेज को छूता है और कैश मदद करना बंद कर देता है, जबकि समय के क्रम वाली की एक सिरे पर जुड़ती जाती है। बड़ी टेबल पर insert की रफ़्तार में फ़र्क़ काफ़ी बड़ा होता है, और v7 के स्टैंडर्ड बनने की वजह यही है।
यह सौदा असली है और तौलने लायक है। वर्शन 7 UUID देखने वाले किसी को भी बता देता है कि वह लगभग कब बना, मिलीसेकंड तक, और ऐसे कई UUID दिखा देते हैं कि आप कितनी तेज़ी से रिकॉर्ड बनाते हैं। इंटरनल की के लिए यह ठीक है। URL में दिखने वाले आइडेंटिफ़ायर के लिए — ऑर्डर नंबर, डॉक्यूमेंट लिंक, यूज़र id — यह जानकारी का छोटा-सा रिसाव है जो वर्शन 4 में नहीं होता। अगर दोनों बातें मायने रखती हैं, तो प्राइमरी की के लिए v7 और पब्लिक चीज़ों के लिए v4 इस्तेमाल करें।
जब आपको कुछ और चाहिए
उन्हें वहीं बनाएं जहां वे इस्तेमाल होते हैं। हर डेटाबेस और भाषा में यह पहले से मौजूद है — PostgreSQL में gen_random_uuid(), MySQL में UUID(), JavaScript में crypto.randomUUID(), Python में uuid.uuid4() — और ब्राउज़र में एक बैच बनाकर कोड में पेस्ट करना fixture या टेस्ट के लिए ठीक है, पर चलने वाली किसी भी चीज़ के लिए ग़लत।
अगर v7 की वजह सॉर्ट होने वाली की है, तो कुछ विकल्प जानने लायक हैं। ULID यही विचार 26 कैरेक्टर में रखता है, जो छोटे हैं और केस-इनसेंसिटिव हैं; Snowflake आइडेंटिफ़ायर 64 बिट में आ जाते हैं, जो UUID के 128 बिट के मुक़ाबले इंडेक्स का साइज़ आधा कर देता है। और कई डेटाबेस में सामान्य auto-increment integer आज भी इन सबसे तेज़ और छोटा है — UUID अपनी क़ीमत के लायक तब हैं जब आइडेंटिफ़ायर एक साथ कई जगहों पर बनाने हों, वरना नहीं।
अक्सर पूछे जाने वाले सवाल
v4 या v7 — मुझे कौन-सा चाहिए?
अगर यह डेटाबेस प्राइमरी की है, तो v7। अगर इसका अंदाज़ा लगाना नामुमकिन होना चाहिए — पासवर्ड रीसेट लिंक, इनवाइट कोड, सेशन आइडेंटिफ़ायर — तो v4। बस यही पूरा फ़ैसला है, और ज़्यादातर लोगों को कभी पता ही नहीं चलता कि कोई फ़ैसला करना था, क्योंकि लगभग हर जनरेटर सिर्फ़ v4 देता है।
डेटाबेस की के रूप में v4 बुरा क्यों है?
क्योंकि यह पूरी तरह रैंडम है, और डेटाबेस इंडेक्स सॉर्टेड होता है। नई रैंडम की इंडेक्स में रैंडम जगहों पर आती हैं, इसलिए हर insert अलग पेज को छूता है, कैश मदद करना बंद कर देता है, और इंडेक्स बिखरता और बढ़ता जाता है। बड़ी, व्यस्त टेबल पर यह मापी जा सकने वाली सुस्ती है जो समय के साथ बढ़ती जाती है। यह कोई सैद्धांतिक चिंता नहीं है — इसी वजह से Postgres और MySQL दोनों के डॉक्यूमेंटेशन में अब इसकी चर्चा है।
UUID v7 क्या है?
ऐसा UUID जिसके पहले 48 बिट मिलीसेकंड टाइमस्टैम्प हैं, और उसके बाद रैंडमनेस। यह अब भी दुनिया भर में यूनीक है और अब भी 128 बिट का है, लेकिन चूंकि समय पहले आता है, v7 UUID उसी क्रम में सॉर्ट होते हैं जिसमें वे बने थे। नई की इंडेक्स में बिखरने के बजाय आख़िर में जुड़ती हैं, ठीक वैसे ही जैसे auto-increment integer करता है — पर UUID की यूनीकनेस के साथ। इसे 2024 में RFC 9562 में स्टैंडर्ड बनाया गया और नई टेबल के लिए यही मौजूदा सिफ़ारिश है।
क्या यहां के v7 UUID सच में सॉर्ट होते हैं?
हां, एक ही मिलीसेकंड के अंदर भी, और ज़्यादातर इम्प्लीमेंटेशन यहीं ग़लती करते हैं। टाइमस्टैम्प का रिज़ॉल्यूशन सिर्फ़ मिलीसेकंड का है, इसलिए लूप में हज़ार ID बनाना एक ही मिलीसेकंड में पूरा हो जाता है — और अगर निचले बिट पूरी तरह रैंडम हों, तो वे हज़ार ID उस क्रम में सॉर्ट नहीं होते जिसमें बने थे। यह जनरेटर RFC 9562 में बताया गया monotonic काउंटर इस्तेमाल करता है, इसलिए हर बार पूरा बैच सख़्ती से बढ़ते क्रम में होता है। हज़ार बनाएं और सॉर्ट करें; वे उसी क्रम में लौटेंगे जिसमें बने थे।
क्या v7 UUID को पब्लिक दिखाना सुरक्षित है?
एक बात ध्यान में रखकर: डिज़ाइन से ही यह बता देता है कि वह कब बना, मिलीसेकंड तक। डेटाबेस की के लिए यह आमतौर पर हानिरहित या काम का भी होता है। लेकिन अगर बनने का समय ख़ुद संवेदनशील है, या आपको ऐसा आइडेंटिफ़ायर चाहिए जिसका अंदाज़ा न लगे, तो v4 इस्तेमाल करें — v7 में अब भी 74 रैंडम बिट हैं, जो बहुत हैं, लेकिन ID रखने वाला कोई भी इसका टाइमस्टैम्प साफ़ पढ़ सकता है।
क्या ये सुरक्षित होने लायक रैंडम हैं?
हां। रैंडमनेस `crypto.getRandomValues` से आती है, जो ब्राउज़र का क्रिप्टोग्राफ़िक रूप से सुरक्षित जनरेटर है, कभी `Math.random` से नहीं। इस फ़र्क़ की वजह से असली कमज़ोरियां सामने आई हैं: `Math.random` तेज़ है पर अनुमान लगाने लायक, और इस पर बने सेशन टोकन का असल में अंदाज़ा लगाया जा चुका है। v4 UUID में 122 रैंडम बिट होते हैं, जो इतने हैं कि टकराव कोई व्यावहारिक चिंता नहीं।
क्या ये मेरे डिवाइस पर बनते हैं?
हां, पूरी तरह, और आइडेंटिफ़ायर के लिए यह मायने रखता है। किसी और के सर्वर से मंगाया गया UUID ऐसा UUID है जिसे कोई और देख चुका है — अगर आप कोई सीक्रेट बना रहे हैं, तो इससे मक़सद ही ख़त्म हो जाता है। ये कभी आपके ब्राउज़र से बाहर नहीं जाते। पेज लोड होने के बाद अपना Wi-Fi बंद करें, यह बिल्कुल वैसे ही काम करेगा। हमारी बात मानने के बजाय प्राइवेसी के दावे को ख़ुद जांचने का यही सबसे आसान तरीक़ा है।
nil UUID क्या है?
सब शून्य: 00000000-0000-0000-0000-000000000000। यह एक मान्य, आरक्षित UUID है, जिसका इस्तेमाल वहां “कुछ नहीं” या “सेट नहीं” बताने के लिए होता है जहां null मुमकिन नहीं। इसका उल्टा, सब f वाला max UUID, कभी-कभी सॉर्टिंग में सीमा-चिह्न (sentinel) के रूप में इस्तेमाल होता है। दोनों यहां दिए गए हैं क्योंकि कभी-कभार इनकी ज़रूरत पड़ती है और इन्हें सही-सही टाइप करना झंझट है।
ध्यान दें: वर्शन 4 UUID ब्राउज़र के क्रिप्टोग्राफ़िक रैंडम स्रोत से आते हैं, Math.random से नहीं, इसलिए इन्हें आइडेंटिफ़ायर के रूप में इस्तेमाल करना सुरक्षित है। वर्शन 7 में मिलीसेकंड का टाइमस्टैम्प होता है, जिससे वह अच्छी तरह सॉर्ट होता है — और इसका यह भी मतलब है कि उससे पता चलता है कि वह लगभग कब बना। जहां यह मायने रखता हो, वहां v7 इस्तेमाल न करें।
यह टूल अपनी वेबसाइट पर लगाएं
किसी भी ब्लॉग, क्लास पेज या हेल्प आर्टिकल के लिए मुफ़्त। एक स्निपेट पेस्ट करें और आपके विज़िटर इसे सीधे आपके पेज पर इस्तेमाल कर सकेंगे।