fixmint
HI

UUID v4 या v7: कौन-सा चुनें और क्यों मायने रखता है

द्वारा · · 8 नवंबर 2026 को अपडेट किया गया · 5 मिनट पढ़ाई

रैंडम पहचानकर्ता चाहिए और कुछ और नहीं, तो UUID v4 इस्तेमाल करें। जब पहचानकर्ता डेटाबेस की कुंजी हो, या जब आप चाहते हों कि ID बनने के समय के हिसाब से क्रम में लगें, तो UUID v7 इस्तेमाल करें। दोनों 128 बिट के होते हैं और एक ही 36 अक्षरों के रूप में लिखे जाते हैं, इसलिए फ़र्क़ इसमें है कि बिट कैसे सजे हैं। नीचे दिया गया UUID जनरेटर आपके ब्राउज़र में किसी भी वर्शन के एक बार में एक से 500 तक UUID बना देता है।

UUID जनरेटरकोड के लिए यूनिक ID चाहिएमुफ़्त में करें

UUID कैसा दिखता है

UUID, यानी यूनिवर्सली यूनीक आइडेंटिफ़ायर, 128 बिट की एक संख्या है जो 32 हेक्साडेसिमल अंकों में पाँच हिस्सों में लिखी जाती है: 8, 4, 4, 4 और 12 अंक, जिन्हें हाइफ़न से अलग किया जाता है। एक उदाहरण है 3f2b8c1e-6d4a-4f7b-9c2e-8a1d5e0b7f63।

संख्या के दो हिस्से तय होते हैं। चार बिट वर्शन बताते हैं, इसलिए तीसरा हिस्सा v4 के लिए 4 से और v7 के लिए 7 से शुरू होता है। दो बिट वैरिएंट बताते हैं, इसलिए चौथा हिस्सा 8, 9, a या b से शुरू होता है। बाक़ी बिट असली पहचानकर्ता को रखते हैं। वर्शन और वैरिएंट के बिट इसी वजह से हैं कि v4 UUID में 128 की जगह 122 रैंडम बिट होते हैं।

UUID v4: रैंडम

v4 UUID उन तय बिट को छोड़कर पूरी तरह रैंडम होता है। उसके 122 रैंडम बिट की वजह से एक ही मान दोबारा आना बेहद असंभव है। मान लीजिए आप एक अरब v4 UUID बनाते हैं। किन्हीं दो के मिलने की संभावना लगभग n का वर्ग, दो गुना संभावित मानों की संख्या से भाग देने पर, आती है, और यह लगभग 10 की घात माइनस 19 है। यानी टकराव के लिए आपको कोई अलग इंतज़ाम करने की ज़रूरत नहीं।

यह अनुमान इस मान्यता पर टिका है कि जनरेटर अपने बिट क्रिप्टोग्राफ़िक रैंडम स्रोत से लेता है। अगर जनरेटर के नतीजे अनुमान लगाए जा सकने लायक हों, तो यह भरोसा टूट जाता है। यह टूल ब्राउज़र का क्रिप्टोग्राफ़िक रैंडम स्रोत इस्तेमाल करता है, जो crypto.randomUUID या crypto.getRandomValues के ज़रिए मिलता है।

UUID v7: पहले समय

v7 को RFC 9562 में परिभाषित किया गया है। इसके पहले 48 बिट यूनिक्स समय को मिलीसेकंड में रखते हैं, इसलिए बाद में बना ID पहले बने ID से बड़े पहले हिस्से वाला होता है। उसके बाद वर्शन के बिट आते हैं, फिर रैंडम बिट, वैरिएंट के बिट और और रैंडम बिट। रैंडम हिस्से के कुछ भाग में काउंटर रखा जा सकता है, जो एक ही मिलीसेकंड में कई ID बनने पर भी उन्हें क्रम में रखता है।

चूँकि समय पहले आता है, v7 ID को एक ही तरह के अक्षरों में टेक्स्ट के रूप में छाँटने पर वे बनने के समय के हिसाब से, मिलीसेकंड तक सटीक, क्रम में लग जाते हैं। ऐसा इसलिए होता है क्योंकि हेक्साडेसिमल अंकों की चौड़ाई तय होती है और समय शुरुआती अक्षरों में होता है।

समय दिखता भी है। जो कोई v7 UUID पढ़ेगा, वह लगभग अंदाज़ा लगा सकता है कि वह कब बना था। आप UUID जनरेटर के Inspect फ़ील्ड में ख़ुद यह जाँच सकते हैं, जो पहले 48 बिट को वापस तारीख और समय में बदल देता है।

v7 डेटाबेस इंडेक्स के लिए क्यों ठीक है

डेटाबेस इंडेक्स आम तौर पर B-tree होता है, यानी ऐसी संरचना जो कुंजी के हिसाब से क्रम में रखी जाती है। जब कुंजी रैंडम होती है, जैसे v4 में, तो हर नई पंक्ति इंडेक्स में किसी रैंडम जगह पर बैठती है। तब डेटाबेस को इंडेक्स के कई अलग-अलग हिस्सों में लिखना पड़ता है, जिससे पेज का ज़्यादा बँटना और कैश में ज़्यादा मिस होना होता है। बड़ी टेबल पर यह काम जुड़कर भारी पड़ता है।

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

v4 और v7 के बीच चुनाव

  • डेटाबेस की प्राइमरी कुंजी, या कोई भी टेबल जो समय के साथ बढ़ती है: v7। इंडेक्स व्यवस्थित रहता है।
  • लॉग, इवेंट या संदेश जिन्हें आप अक्सर समय के हिसाब से छाँटते हैं: v7, क्योंकि क्रम ID में ही होता है।
  • सार्वजनिक ID जिनमें बनने का समय निजी रहना चाहिए: v4। v7 ID बता देता है कि वह कब बना था।
  • कई डिवाइस जिनकी घड़ियाँ भरोसेमंद नहीं: v4 या v7, दोनों यूनीक रहते हैं, क्योंकि यह काम रैंडम बिट करते हैं। सिर्फ़ v7 का छँटाई वाला क्रम घड़ियों के सही होने पर निर्भर करता है।

दोनों वर्शन मानक हैं, लेकिन पुरानी लाइब्रेरी शायद सिर्फ़ v4 जानती हों। RFC 4122 कई साल तक वर्शन 1 से 5 का वर्णन करता रहा। RFC 9562 मई 2024 में प्रकाशित हुआ, RFC 4122 की जगह लेता है, और वर्शन 6, 7 और 8 परिभाषित करता है। किसी भी चीज़ पर भरोसा करने से पहले जाँच लें कि आपकी लाइब्रेरी का वर्शन v7 को सपोर्ट करता है या नहीं।

UUID स्टोर करना

टेक्स्ट के रूप में लिखा UUID 36 अक्षर लेता है। उसके 16 बाइट बाइनरी रूप में रखे जा सकते हैं, जो कहीं कम जगह लेता है। इसके लिए कई डेटाबेस में नेटिव UUID प्रकार होता है, या 16 बाइट का बाइनरी कॉलम होता है, और यह टेक्स्ट से तुलना में तेज़ भी होता है।

एक फ़ॉर्मेट चुनें और उसी पर टिके रहें। बड़े अक्षर, छोटे अक्षर, हाइफ़न और ब्रेसेस, इन सबको इंसान एक ही UUID मानता है, लेकिन डेटाबेस या स्ट्रिंग की तुलना उन्हें अलग मान सकती है। जेनरेटर में बड़े अक्षर, बिना हाइफ़न और ब्रेसेस के विकल्प उन सिस्टम के लिए हैं जिन्हें ये रूप चाहिए।

UUID को कभी गुप्त कुंजी न बनाएँ

UUID एक पहचानकर्ता है, पासवर्ड, सेशन टोकन या एक्सेस की नहीं। यह यूनीक होने के लिए बनाया गया है, अनुमान न लगाए जा सकने के लिए नहीं। v7 UUID अपने साथ बनने का समय भी रखता है। और पहचानकर्ता लिंक, लॉग, ईमेल और स्क्रीनशॉट में चिपकाए जाते हैं, जहाँ उन्हें देखने वाला कोई भी उन्हें दोबारा इस्तेमाल कर सकता है।

एक्सेस कंट्रोल सर्वर पर होना चाहिए। जिस व्यक्ति को कोई ID पता है, उसे उस रिकॉर्ड को देखने या बदलने की अपने-आप अनुमति नहीं मिलनी चाहिए। पासवर्ड, पासफ़्रेज़ या टोकन के लिए ऐसा जेनरेटर इस्तेमाल करें जो गुप्त चीज़ों के लिए बना हो। पासवर्ड जनरेटर आपके डिवाइस पर सुरक्षित रैंडमनेस से रैंडम पासवर्ड या शब्द-आधारित पासफ़्रेज़ बनाता है, और उनकी मज़बूती का अनुमान भी देता है। लंबाई और रैंडमनेस क्यों मायने रखते हैं, इसकी पृष्ठभूमि के लिए मज़बूत पासवर्ड और एंट्रॉपी पढ़ें।

टूल का इस्तेमाल

  1. रैंडम ID के लिए वर्शन 4 चुनें, या समय के हिसाब से क्रम में लगने वाले ID के लिए वर्शन 7।
  2. संख्या तय करें, एक बार में 1 से 500 तक।
  3. अगर आपके कोड को कोई ख़ास रूप चाहिए, तो बड़े अक्षर, बिना हाइफ़न या ब्रेसेस वाला विकल्प चुनें।
  4. सभी को कॉपी करें, या सूची को .txt फ़ाइल के रूप में डाउनलोड करें।
  5. Inspect फ़ील्ड में कोई भी UUID चिपकाकर उसका वर्शन, वैरिएंट और, v7 के मामले में, उसमें मौजूद समय पढ़ें।

त्वरित जवाब

क्या v4 UUID यूनीक होता है? व्यवहार में, हाँ। उसके 122 रैंडम बिट इतना कम मौक़ा देते हैं कि आपको दोहराव की जाँच करने की ज़रूरत नहीं पड़ती।

क्या मुझे हर जगह v7 इस्तेमाल करना चाहिए? हमेशा नहीं। डेटाबेस कुंजियों और समय के हिसाब से छाँटी जाने वाली हर चीज़ के लिए v7 इस्तेमाल करें। जब बनने का समय छिपा रहना चाहिए, तब v4 इस्तेमाल करें।

क्या मैं UUID को पासवर्ड की तरह इस्तेमाल कर सकता हूँ? नहीं। यह एक पहचानकर्ता है। जो भी गुप्त रहना चाहिए, उसके लिए पासवर्ड जेनरेटर इस्तेमाल करें।

क्या यह टूल ID कहीं भेजता है? नहीं। ID आपके ब्राउज़र में बनते हैं और दिखाए जाते हैं, और उन्हें किसी सर्वर पर नहीं भेजा जाता।

अंग्रेज़ी मूल से AI की मदद से अनुवादित।

टिप्पणियाँ

    अभी कोई टिप्पणी नहीं। पहली टिप्पणी आप करें।

    आपकी रेटिंग (वैकल्पिक)

    आपका ईमेल कभी दिखाया या सहेजा नहीं जाता।

    Open Data for AGI - Why Public, Free, and Open Datasets Matter का कवरOpen Data for AGI - Why Public, Free, and Open Datasets Matter

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

    $4.99Gumroad पर पाएँअंग्रेज़ी में