UUID जेनरेटर
अपने ब्राउज़र में रैंडम RFC-4122 वर्शन 4 UUID (जिन्हें GUID भी कहा जाता है) जेनरेट करें। आपको कितने चाहिए वह चुनें, अपरकेस या हाइफ़न टॉगल करें, और परिणाम तुरंत कॉपी करें — कुछ भी अपलोड नहीं होता।
विकल्प
मात्रा
अपरकेस
हाइफ़न
UUID जेनरेटर का उपयोग कैसे करें
- 1
मात्रा सेट करें
मात्रा फ़ील्ड या प्लस व माइनस बटन का इस्तेमाल करके चुनें कि आपको कितने UUID चाहिए, 1 से 100 तक।
- 2
फ़ॉर्मैट चुनें
बड़े हेक्साडेसिमल अक्षरों के लिए Uppercase टॉगल करें और हर ID से चार dash रखने या हटाने के लिए Hyphens टॉगल करें।
- 3
ID जनरेट करें
क्रिप्टोग्राफ़िक रूप से बेतरतीब version-4 UUID बनाने के लिए Generate पर क्लिक करें, हर एक अपनी अलग लाइन पर सूचीबद्ध।
- 4
नतीजे कॉपी करें
पूरी सूची एक साथ कॉपी करने के लिए Copy बटन का इस्तेमाल करें, जो कोड, डेटाबेस, या स्प्रेडशीट में पेस्ट करने के लिए तैयार है।
UUID विस्तार से: वर्शन, टकराव, और इन्हें कब इस्तेमाल करें
UUID क्या होता है
UUID — Universally Unique Identifier, जिसे Microsoft की दुनिया में GUID कहा जाता है — एक 128-bit मान है जिसे इस तरह डिज़ाइन किया गया है कि वह बिना किसी केंद्रीय प्राधिकरण के नंबर बाँटे ही अद्वितीय रहे। इसका canonical टेक्स्ट रूप 36 कैरेक्टर का होता है: 32 हेक्साडेसिमल अंक जो चार हाइफ़न से 8-4-4-4-12 पैटर्न में पाँच समूहों में बँटे होते हैं। वे 128 bit ही पूरी पहचान हैं; हाइफ़न और अक्षरों का केस तो बस प्रस्तुति है।
इसका वादा विकेंद्रीकरण का है। कोई भी मशीन, कहीं भी, एक पहचानकर्ता गढ़ सकती है जिसके कहीं और गढ़े गए किसी पहचानकर्ता से टकराने की व्यावहारिक रूप से कोई संभावना नहीं होती, यही वजह है कि जब स्वतंत्र सिस्टम को ऐसी ID बनानी हों जो बाद में बिना तालमेल के आपस में मिल जाएँ, तो UUID डिफ़ॉल्ट key होते हैं।
वर्शन 4: डिज़ाइन से ही रैंडम
यह जनरेटर version-4 UUID बनाता है, जो सबसे ज़्यादा इस्तेमाल होने वाला प्रकार है। v4 UUID लगभग पूरी तरह रैंडम होता है: 128 bit में से मुट्ठी भर bit वर्शन और वैरिएंट दर्शाने के लिए तय होते हैं, जिससे 122 bit शुद्ध रैंडमपन के बचते हैं। आप किसी v4 मान को पहचान सकते हैं क्योंकि तीसरे समूह की शुरुआत करने वाला अंक हमेशा 4 होता है, और चौथे समूह की शुरुआत करने वाला अंक 8, 9, a, या b में से एक होता है।
चूँकि इसमें कोई अंतर्निहित टाइमस्टैम्प या मशीन पहचानकर्ता नहीं होता, v4 UUID इस बारे में कुछ नहीं उजागर करता कि वह कब या कहाँ बना। यह निजता उन योजनाओं के मुकाबले एक असली फ़ायदा है जो किसी MAC एड्रेस या किसी क्रम को एन्कोड करती हैं, और यही एक वजह है कि v4 keys, टोकन, और रिकॉर्ड पहचानकर्ताओं के लिए रोज़मर्रा का डिफ़ॉल्ट बन गया।
रैंडमपन कहाँ से आता है
किसी रैंडम UUID के लिए रैंडम स्रोत की गुणवत्ता ही सब कुछ है। यह टूल किसी तेज़ पर अनुमान-योग्य pseudo-random फ़ंक्शन के बजाय आपके ब्राउज़र के अंतर्निहित क्रिप्टोग्राफ़िक रूप से सुरक्षित जनरेटर का इस्तेमाल करता है — वही primitive जो सुरक्षा-संवेदनशील मानों के लिए काम आता है। यह इसलिए मायने रखता है क्योंकि किसी कमज़ोर जनरेटर से बनी ID का अनुमान लगाया या उन्हें क्रम से गिना जा सकता है, जिससे एक ऐसा पहचानकर्ता जो अननुमेय होना चाहिए था, एक सुरक्षा छेद बन जाता है।
एक उचित क्रिप्टोग्राफ़िक स्रोत के साथ, वे 122 रैंडम bit सचमुच अप्रत्याशित होते हैं, इसलिए आउटपुट प्रोडक्शन डेटाबेस keys, idempotency keys, और ऐसे ही दूसरे कामों के लिए उपयुक्त है। फिर भी सीमा पर ज़ोर देना ज़रूरी है: UUID एक पहचानकर्ता है, कोई रहस्य नहीं। इसे इतना अननुमेय मानें कि क्रम से गिनना मुश्किल हो, पर अकेले इसी पर एक authorization टोकन की तरह भरोसा न करें।
टकराव व्यावहारिक चिंता क्यों नहीं हैं
v4 UUID का दायरा खगोलीय रूप से विशाल है — 2 की 122वीं घात, यानी लगभग 5.3 गुणा 10 की 36वीं घात जितने भिन्न मान। इसे परिप्रेक्ष्य में रखें तो, एक अकेले टकराव की संभावना किसी मापने लायक स्तर तक पहुँचने से पहले आपको कई दशकों तक हर सेकंड अरबों UUID बनाने पड़ेंगे। हर वास्तविक एप्लिकेशन के लिए दो रैंडम तरीके से बने v4 UUID के मिलने की संभावना इतनी छोटी है कि उसे शून्य ही माना जाता है।
यही वजह है कि आप हज़ारों क्लाइंट और सर्वर पर स्वतंत्र रूप से ID बना सकते हैं और बस यह मान सकते हैं कि वे टकराएँगी नहीं, बिना किसी केंद्रीय सेवा तक अद्वितीयता जाँचने की राउंड ट्रिप किए। यह असंभाव्यता ही ख़ूबी है: यह आपको तालमेल-मुक्त जनरेशन उस कीमत पर देती है जो आप व्यवहार में कभी देखेंगे ही नहीं।
वर्शन 1, वर्शन 7, और क्रमबद्धता
सभी UUID रैंडम नहीं होते। Version 1 अपना मान मौजूदा समय और जनरेट करने वाली मशीन के नेटवर्क एड्रेस से निकालता है, जो अद्वितीयता की गारंटी तो देता है पर एक टाइमस्टैम्प और एक हार्डवेयर पहचानकर्ता को ID में पका देता है — यह निजता और सूचना-रिसाव की एक चिंता है जिसने कई टीमों को v4 की ओर धकेला। Version 7 एक अलग समस्या का आधुनिक जवाब है: यह ऊँचे bit में एक मिलीसेकंड टाइमस्टैम्प रखता है जिसके बाद रैंडम bit आते हैं।
वह बनावट v7 मानों को सादे स्ट्रिंग के रूप में लगभग बनने के क्रम में सॉर्ट कराती है, जो डेटाबेस इंडेक्स के लिए एक असली फ़ायदा है। शुद्ध रूप से रैंडम v4 keys किसी इंडेक्स में बिखर जाती हैं और कुछ इंजनों पर insert के प्रदर्शन को नुकसान पहुँचा सकती हैं, जबकि समय-क्रम वाली keys हाल के insert को एक साथ समूहित रखती हैं। अगर आपको UUID की वैश्विक-अद्वितीयता वाली बात चाहिए पर साथ ही कालक्रम के अनुसार क्रम भी, तो v7 ही पकड़ने लायक है; अगर आप खास तौर पर चाहते हैं कि कोई समय अंतर्निहित न हो, तो v4 सही विकल्प बना रहता है।
UUID बनाम auto-increment ID
क्लासिक विकल्प एक डेटाबेस auto-increment पूर्णांक है। क्रमिक पूर्णांक compact, स्वाभाविक रूप से क्रमबद्ध, और प्राइमरी key के रूप में बेहद कुशल होते हैं, पर इन्हें अगला नंबर बाँटने के लिए सत्य का एक अकेला स्रोत चाहिए और ये सूचना उजागर करते हैं: एक क्रमिक ID मोटे तौर पर बता देती है कि कितने रिकॉर्ड मौजूद हैं और किसी हमलावर को एक जोड़कर पड़ोसी ID का अनुमान लगाने देती है। UUID दोनों समस्याएँ हल करते हैं — न कोई केंद्रीय काउंटर, और न ही क्रम से गिनी जा सकने वाली कोई शृंखला।
अदला-बदली दूसरी दिशा में भी चलती है। एक UUID 16 byte का होता है जबकि एक पूर्णांक 4 या 8 byte का, इसका टेक्स्ट रूप URL और लॉग में भारी-भरकम लगता है, और रैंडम वाला सॉर्ट नहीं किया जा सकता। एक उचित अंगूठे का नियम: UUID तब इस्तेमाल करें जब ID को क्लाइंट या वितरित सेवाओं द्वारा बनाया जाना हो, सिस्टमों के बीच मर्ज होना हो, या अनुमान-योग्य नहीं होनी चाहिए; एक अकेले आत्म-निहित डेटाबेस के लिए auto-increment पूर्णांकों पर टिके रहें, जहाँ compactness और क्रम सबसे ज़्यादा मायने रखते हैं।
फ़ॉर्मैटिंग और थोक जनरेशन
canonical रूप हाइफ़न के साथ लोअरकेस hex होता है, और ज़्यादातर सिस्टम इसे स्वीकार करते हैं, पर परंपराएँ अलग-अलग होती हैं। यह टूल आपको अपरकेस अक्षरों पर जाने देता है, जिन्हें कुछ प्लेटफ़ॉर्म और पुराने Microsoft टूलिंग पसंद करते हैं, और हाइफ़न हटाकर एक compact 32-कैरेक्टर रूप पाने देता है जो URL, फ़ाइलनाम, या ऐसी किसी जगह काम आता है जहाँ dash शोर भर हों। अंतर्निहित 128-bit मान केस या हाइफ़न के बावजूद एक जैसा ही रहता है, इसलिए ये पूरी तरह प्रदर्शन के विकल्प हैं।
जब आपको एक साथ कई ID चाहिए — किसी टेबल को सीड करना, टेस्ट fixtures बनाना, keys को पहले से आवंटित करना — तो आप एक ही क्लिक में एक बैच बना सकते हैं और पूरी सूची एक साथ कॉपी कर सकते हैं, हर एक अपनी अलग लाइन पर। सब कुछ आपके ब्राउज़र में स्थानीय रूप से बनता है और कुछ भी प्रेषित या संग्रहीत नहीं होता, इसलिए संवेदनशील रिकॉर्ड से जुड़े पहचानकर्ता भी कभी आपके डिवाइस से बाहर नहीं जाते।
अक्सर पूछे जाने वाले प्रश्न
यह किस तरह के UUID जनरेट करता है?
बेतरतीब मान कैसे बनाए जाते हैं?
मैं एक बार में कितने UUID बना सकता हूँ?
क्या जनरेट किए UUID सचमुच अद्वितीय हैं?
क्या कुछ भी किसी सर्वर पर भेजा जाता है?
संबंधित टूल्स
इन उपयोगी टूल्स के साथ आगे बढ़ें