UUID बनाएँ

कहाँ चलता है
कुछ भी अपलोड नहीं होता, क्योंकि कोई फ़ाइल है ही नहीं — गणना इसी पन्ने में होती है।
न कतार, न खाता
यह उतनी ही तेज़ी से जवाब देता है जितनी आपकी मशीन देती है, और कभी नहीं पूछता कि आप कौन हैं।
जितनी बार चाहें
न कुछ गिना जाता है, न कोई सीमा है — दोबारा जवाब देने में हमारा कुछ ख़र्च नहीं होता।

काम कैसे करता है

बताइए कितनी चाहिए।
बटन दबाइए।
सूची कॉपी कर लीजिए। वह आपके ही डिवाइस पर बनी है।

बिट कहाँ से आते हैं

यहाँ `crypto.getRandomValues` इस्तेमाल होता है, ब्राउज़र का क्रिप्टोग्राफ़िक जनरेटर, जो अपनी entropy ऑपरेटिंग सिस्टम से लेता है। यह `Math.random()` नहीं है, जिसका नतीजा उसकी भीतरी अवस्था से दोबारा बनाया जा सकता है और जिसे कभी ऐसी पहचान नहीं बनानी चाहिए जिसका अनुमान किसी को न लग सके।

फ़र्क़ नतीजे में नहीं दिखता: दोनों सही शक्ल की स्ट्रिंग बनाते हैं और दोनों किसी भी रूप-जाँच को पार कर जातीं। यह उसी दिन दिखता है जब कोई अगली पहचान का अनुमान लगा लेता है, और तब तक वह उत्पादन में जा चुकी होती है। अगर ब्राउज़र क्रिप्टोग्राफ़िक जनरेटर नहीं देता तो यहाँ काम रुक जाता है, कमज़ोर विकल्प पर लौटने के बजाय।

एक सौ बाईस बिट, एक सौ अट्ठाईस नहीं

UUID 128 बिट की होती है, पर version 4 में चार बिट version की संख्या से तय हैं और दो variant से। बचे 122 यादृच्छिक, जो इतने हैं कि अरबों बनाने पर भी टकराव की संभावना अप्रासंगिक रहती है।

यही गुंजाइश उन्हें बिना किसी समन्वय के बिखरे हुए ढंग से बनाने देती है: दो सेवाएँ जो आपस में कभी बात नहीं करतीं, एक ही समय पहचानें बना सकती हैं और कुछ तय किए बिना। यही वह गुण है जिसके लिए UUID मौजूद हैं, और यही वजह है कि जैसे ही एक से ज़्यादा मशीनें लिख रही हों, अपने-आप बढ़ने वाला काउंटर काम का नहीं रहता।

Version और variant कहाँ पढ़े जाते हैं

Version तीसरे समूह का पहला अक्षर है, यानी तेरहवाँ hexadecimal अंक: यहाँ हमेशा `4`। Variant चौथे समूह का पहला अक्षर है और उसे `8`, `9`, `a` या `b` होना चाहिए, क्योंकि इन्हीं चार अंकों के शुरुआती बिट `10` हैं, जिन पर RFC 4122 अपना दावा करता है।

यह नंगी आँख से जाँचा जा सकता है, और घर के बने जनरेटर को पकड़ने का सबसे तेज़ तरीक़ा यही है। जो 32 यादृच्छिक hexadecimal अंक जोड़कर छोड़ देता है और इन दो जगहों को तय नहीं करता, वह ऐसी पहचानें बनाता है जो UUID जैसी दिखती हैं, औपचारिक रूप से UUID नहीं हैं, और सालों चलती रहती हैं — उस दिन तक जब कोई उन्हें गंभीरता से जाँच लेता है।

Version 4 ही क्यों, version 1 क्यों नहीं

Version 1 वाली UUID में बनने का क्षण 100 नैनोसेकंड की परिशुद्धता के साथ होता है और, परंपरागत रूप से, नेटवर्क कार्ड का MAC पता। दोनों चीज़ें उस व्यक्ति द्वारा दोबारा निकाली जा सकती हैं जिसके पास पहचान है, इसलिए बाहर से दिखने वाली कोई डेटाबेस-कुंजी उस मशीन और उस क्षण का सुराग़ बन जाती है।

यह किताबी चिंता नहीं है: 1999 में Melissa वायरस के लेखक की पहचान इसी रास्ते हुई थी, क्योंकि Word दस्तावेज़ों की पहचानों में MAC लिख देता था। जहाँ पहचान बाहर से दिखती हो, वहाँ सही चुनाव version 4 है।

Version 7 और डेटाबेस का index

Version 7 आगे मिलीसेकंड में एक timestamp लगाती है और बाक़ी यादृच्छिकता से भरती है, जिससे पहचानें अपने ही मान से समय के हिसाब से क्रम में आ जाती हैं। इससे वह समस्या हल हो जाती है जिसके चलते बहुत सी टीमें UUID को प्राथमिक कुंजी बनाने से बचती रही हैं।

वजह index है। यादृच्छिक कुंजियाँ B-वृक्ष के भीतर लगातार बदलती जगहों पर लिखती हैं, जिससे पन्ने टूटते हैं और कैश बेकार जाता है; बड़ी तालिकाओं में इससे लिखने की गति में मापी जा सकने वाली गिरावट आती है। बढ़ती हुई कुंजी हमेशा आख़िर में लिखती है। बदले में बनने का क्षण फिर से पढ़ा जा सकने लायक़ हो जाता है।

एक बार में सौ तक, और सौ ही क्यों

यहाँ एक बार में सौ तक बनती हैं, हर पंक्ति पर एक। यह सीमा किसी गणना-लागत की वजह से नहीं है — एक लाख बनाने में भी ब्राउज़र को पलक झपकने जितना समय लगता — बल्कि इसलिए कि उससे बड़ी सूची पन्ने पर पढ़ने और कॉपी करने लायक़ नहीं रहती।

अगर आपको सचमुच हज़ारों चाहिए तो सही जगह वह स्क्रिप्ट है जहाँ वे इस्तेमाल होनी हैं: हर आधुनिक भाषा में `uuid4` एक पंक्ति का काम है, और उन्हें बनाकर फिर कहीं और चिपकाना उस काम में एक अतिरिक्त क़दम जोड़ता है जिसमें कोई क़दम चाहिए ही नहीं। यह पन्ना उस हालत के लिए है जहाँ आपको अभी, हाथ से, कुछ पहचानें चाहिए।

बड़े अक्षर, कोष्ठक और URN वाला उपसर्ग

यहाँ वे छोटे अक्षरों में और बिना किसी सजावट के बनती हैं, जो बनाते समय विनिर्देश की माँग है। पढ़ते समय बड़े अक्षर भी क़बूल करने होते हैं, और असल में .NET तथा Windows के बहुत से औज़ार परंपरागत रूप से ऐसे ही लिखते हैं।

दो लपेटन भी चलन में हैं: घुँघराले कोष्ठक, जो Windows की registry की लिखावट से आते हैं, और आगे लगा `urn:uuid:`, जो URN के नामस्थान से आता है। इनमें से कोई भी पहचान का हिस्सा नहीं है। जो अपने आप तुलना कर रहा है उसे छोटे अक्षरों में सामान्य कर लेना चाहिए और लपेटन हटा देनी चाहिए, वरना दो एक जैसी पहचानें सिर्फ़ लिखावट के कारण तुलना में विफल हो जाएँगी।

UUID कोई रहस्य नहीं है

Version 4 वाली पहचान का व्यवहार में अनुमान लगाना असंभव है, और वहाँ से उसे पहुँच का token बना देने तक का क़दम कहीं ज़्यादा बार उठाया जाता है: कोई «निजी» लिंक जिसकी एकमात्र सुरक्षा यह है कि URL में एक UUID है।

समस्या entropy नहीं है बल्कि यह है कि URL कहाँ-कहाँ पहुँचती है: इतिहास में, अगले क्लिक के referrer हेडर में, किसी proxy के लॉग में, उस संदेश में जहाँ कोई उसे आगे भेज देता है। Token को समाप्त होना चाहिए और वापस लिया जा सकना चाहिए, और UUID इनमें से कुछ नहीं करती।

ये यहीं बनती हैं, किसी से माँगी नहीं जातीं

ऐसी सेवाएँ हैं जो API से UUID लौटाती हैं, और उनका इस्तेमाल करने का मतलब है कि किसी और ने ठीक वे पहचानें देख ली हैं जो आप अपने डेटाबेस में डालने वाले हैं। यह प्रलय नहीं है और ज़रूरी भी नहीं है: बनाना एक स्थानीय क्रिया है, दो पंक्तियों की।

यहाँ यह आपके ही टैब में, ब्राउज़र की क्रिप्टोग्राफ़ी से होता है। कोई रिक्वेस्ट शामिल नहीं है, इसलिए पन्ना एक बार खुल जाने के बाद यह बिना इंटरनेट के भी उसी तरह चलता है — ट्रेन में, किसी कॉर्पोरेट proxy के पीछे, या किसी अलग-थलग मशीन पर।

ULID और दूसरे छोटे विकल्प

UUID अकेला विकल्प नहीं है। ULID वही 128 बिट रखता है पर उन्हें 26 अक्षरों के base32 में लिखता है और आगे एक timestamp रखता है, इसलिए वह छोटा भी है और समय के हिसाब से क्रम में भी। NanoID लंबाई ख़ुद चुनने देता है और किसी मानक का पालन नहीं करता।

चुनने की कसौटी यह है कि पहचान को किससे बात करनी है। UUID वह रूप है जिसे हर डेटाबेस, हर भाषा और हर API पहले से जानती है, और यही उसकी असली क़ीमत है। ULID या NanoID तब समझदारी हैं जब पहचान सिर्फ़ आपके अपने तंत्र के भीतर रहनी हो और उसकी लंबाई या क्रम मायने रखता हो — बाहर जाते ही वह फ़ायदा किसी और के लिए एक और अपरिचित रूप बन जाता है।

DPDP Act के लिहाज़ से इसका क्या मतलब है

अभी-अभी बनी UUID में कोई निजी डेटा नहीं होता — वे यादृच्छिक बिट हैं। वह छद्मनाम तब बनती है जब आपके तंत्र में वह किसी व्यक्ति से जुड़ जाती है, और उसके बाद उस पर वही बाध्यताएँ लागू होती हैं जो किसी भी दूसरी उपयोक्ता-पहचान पर।

यह पन्ना उससे पहले वाले हिस्से की गारंटी देता है: पहचानें आपके ही डिवाइस पर जन्म लेती हैं और किसी बीच की सेवा से होकर नहीं गुज़रतीं। यह छोटा और असली फ़र्क़ है, ख़ासकर तब जब वे असली डेटा के किसी स्थानांतरण के लिए थोक में बनाई जा रही हों।

UUID बनाएँ: आम सवाल

क्या ये सचमुच यादृच्छिक हैं?

ये crypto.getRandomValues से बनती हैं, ब्राउज़र के क्रिप्टोग्राफ़िक जनरेटर से, जो entropy ऑपरेटिंग सिस्टम से लेता है। यह Math.random() नहीं है, जिसका नतीजा उसकी भीतरी अवस्था से दोबारा बनाया जा सकता है।

क्या दो एक जैसी बन सकती हैं?

Version 4 में 122 यादृच्छिक बिट हैं, इसलिए अरबों बनाने पर भी संभावना अप्रासंगिक है। यही वह गुण है जो उन्हें बिना समन्वय के बिखरे हुए ढंग से बनाने देता है।

Version 4 ही क्यों, version 1 क्यों नहीं?

क्योंकि version 1 के भीतर बनने का क्षण होता है और, परंपरागत रूप से, मशीन का MAC पता। अगर पहचान बाहर से दिखती है तो यह ऐसी जानकारी है जिसे बाहर नहीं जाना चाहिए।

क्या मैं UUID को पहुँच के token की तरह इस्तेमाल कर सकता हूँ?

बेहतर है न करें। Entropy काफ़ी है, पर URL इतिहास में, referrer हेडर में और proxy के लॉग में पहुँच जाती है — और UUID न समाप्त होती है न वापस ली जा सकती है, जो token को करना ही चाहिए।

क्या ये किसी सर्वर पर बनती हैं?

नहीं। ये आपके ही टैब में, ब्राउज़र की क्रिप्टोग्राफ़ी से बनती हैं, बिना किसी रिक्वेस्ट के। पन्ना एक बार खुल जाने के बाद यह बिना इंटरनेट के भी चलता है।