पहचानकर्ता बनाएँ
संस्करण 1, 3, 4, 5, 6 और 7 के UUID या ULID बनाएँ, एक-एक करके या हज़ार तक के बैच में, और किसी भी पहचानकर्ता का विश्लेषण करके जानें कि उसका संस्करण और वैरिएंट क्या है और उसमें कौन-सी तारीख है। ये आपके ब्राउज़र में सिस्टम के क्रिप्टोग्राफ़िक जनरेटर से बनते हैं।
122 रैंडम बिट। जब सिर्फ़ एक अद्वितीय पहचानकर्ता चाहिए, तब सबसे ज़्यादा इस्तेमाल होता है।
फ़ॉर्मेट
परिणाम
UUID या ULID का विश्लेषण
हाइफ़न, ब्रेसेस, urn:uuid: प्रीफ़िक्स या 26 अक्षरों का ULID स्वीकार करता है
प्रकार
संस्करण 7: सॉर्ट होने वाली Unix तारीख
वैरिएंट
RFC 9562 (पहले RFC 4122)
बनने की तारीख
22 फ़र॰ 2022, 4:22:22 pm 2022-02-22T19:22:22.000Z · 1645557742000 ms
मानक रूप017f22e2-79b0-7cc3-98c4-dc0c0c07398f
बड़े अक्षर017F22E2-79B0-7CC3-98C4-DC0C0C07398F
ब्रेसेस के साथ GUID{017F22E2-79B0-7CC3-98C4-DC0C0C07398F}
URNurn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f
ULID के रूप में01FWHE4YDGFK1SHH6W1G60EECF
हेक्साडेसिमल017f22e279b07cc398c4dc0c0c07398f
दशमलव पूर्णांक1989357241971137676463954034883508623
Base64AX8i4nmwfMOYxNwMDAc5jw==

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

UUID एक 128-बिट संख्या है जिसे पाँच समूहों (8-4-4-4-12) में 32 हेक्साडेसिमल अंकों के रूप में लिखा जाता है। इससे किसी रिकॉर्ड की पहचान बिना किसी से पूछे हो जाती है कि मान पहले से इस्तेमाल में है या नहीं: दो सर्वर, दो मोबाइल ऐप या दो प्रोसेस बिना तालमेल और बिना टकराव के एक साथ पहचानकर्ता बना सकते हैं। फ़ॉर्मेट RFC 9562 में परिभाषित है, जिसने 2024 में RFC 4122 की जगह ली और संस्करण 6, 7 और 8 जोड़े।

तीसरे समूह की पहली अंक संस्करण बताती है, और हर संस्करण बिट्स को अलग तरह से व्यवस्थित करता है। संस्करण 4 पूरी तरह रैंडम है। संस्करण 7 मिलीसेकंड में तारीख से शुरू होता है, इसलिए पहचानकर्ता बनने के क्रम में लगते हैं। संस्करण 3 और 5 में कुछ भी रैंडम नहीं होता: ये एक नेमस्पेस और एक नाम के हैश से बनते हैं, इसलिए हमेशा एक ही परिणाम देते हैं। संस्करण 1 और 6 में 100 नैनोसेकंड की सटीकता वाली तारीख और एक नोड होता है, जो ऐतिहासिक रूप से कंप्यूटर का MAC पता था।

विश्लेषक उल्टा काम करता है: यह संस्करण और वैरिएंट पढ़ता है, v1, v6 और v7 UUID और ULID से तारीख निकालता है, और उसी मान को GUID, URN, हेक्साडेसिमल, पूर्णांक या Base64 के रूप में दिखाता है। सब कुछ आपके ब्राउज़र में गणना होता है; कोई भी पहचानकर्ता सर्वर पर नहीं जाता।

उदाहरण

v5 · DNS · www.example.com2ed6657d-e927-568b-95e1-2665a8aea6a2यह RFC 9562 का टेस्ट वेक्टर है। संस्करण 5 को सही ढंग से लागू करने वाली हर लाइब्रेरी को DNS नेमस्पेस में इस नाम के लिए ठीक यही मान लौटाना चाहिए।
017F22E2-79B0-7CC3-98C4-DC0C0C07398F2022-02-22T19:22:22.000Zv7 UUID के पहले 12 अंक हेक्साडेसिमल में Unix मिलीसेकंड होते हैं: 0x017F22E279B0 का मान 1645557742000 है।
C232AB00-9414-11EC-B3C8-9F6BDECED8461EC9414C-232A-6B00-B3C8-9F6BDECED846एक ही क्षण संस्करण 1 और संस्करण 6 के रूप में। संस्करण 6 तारीख के बिट्स को सबसे महत्वपूर्ण से सबसे कम महत्वपूर्ण क्रम में रखता है ताकि टेक्स्ट समय के क्रम में सॉर्ट हो; क्लॉक सीक्वेंस और नोड नहीं बदलते।
01ARZ3NDEKTSV4RRFFQ69G5FAV01563e3a-b5d3-d676-4c61-efb99302bd5bULID भी UUID जितने ही 128 बिट लेता है, इसलिए इसे uuid कॉलम में रखा जा सकता है। लेकिन इसमें न संस्करण होता है न वैरिएंट: UUID की तरह पढ़ने पर वे अंक रैंडम हिस्से का भाग होते हैं।

उपयोग के मामले

  • डेटाबेस के ऑटो-इंक्रीमेंट मान देने का इंतज़ार किए बिना, प्राइमरी की को क्लाइंट पर या कई सेवाओं में एक साथ बनाना।
  • आइडेम्पोटेंसी कुंजियाँ बनाना ताकि दोबारा भेजा गया भुगतान या ऑर्डर दो बार प्रोसेस न हो।
  • हर अनुरोध पर एक कोरिलेशन आईडी लगाना ताकि कई माइक्रोसर्विस के लॉग में उसे ट्रैक किया जा सके।
  • v5 से किसी प्राकृतिक कुंजी (ईमेल, URL, SKU) से स्थिर पहचानकर्ता निकालना, ताकि दो सिस्टम बिना कोई टेबल साझा किए एक ही मान तक पहुँचें।
  • जब कोई v7 UUID या ULID लॉग या एरर रिपोर्ट में दिखे, तो उससे जानना कि रिकॉर्ड कब बना था।
  • एक ही बार में सैकड़ों मान्य पहचानकर्ताओं के साथ टेस्ट डेटा लोड करना।

अक्सर पूछे जाने वाले प्रश्न

प्राइमरी की के लिए v4 या v7?

v7, जब तक आपके पास बनने की तारीख छिपाने का कोई कारण न हो। B-ट्री इंडेक्स कुंजियों को क्रम में रखते हैं, और v4 इंडेक्स में कहीं भी पहुँच जाता है: हर इंसर्ट अलग पेज छूता है, पेज बँटते हैं और कैश कम असरदार रहता है। v7 हमेशा अंत में जाता है, ऑटो-इंक्रीमेंट की तरह। SQL Server में सावधान: uniqueidentifier टाइप आख़िरी छह बाइट से शुरू करके सॉर्ट करता है, इसलिए वहाँ v7 भी क्रमिक नहीं रहता।

क्या दो v4 UUID दोहरा सकते हैं?

सैद्धांतिक रूप से हाँ, व्यवहार में नहीं। v4 में 122 रैंडम बिट होते हैं, और कम से कम एक दोहराव की 50 % संभावना तक पहुँचने के लिए लगभग 2.7 × 10¹⁸ बनाने होंगे, यानी 85 साल से ज़्यादा समय तक हर सेकंड एक अरब। शर्त क्रिप्टोग्राफ़िक जनरेटर का उपयोग है: जो असली डुप्लिकेट सामने आते हैं, वे गणित से नहीं बल्कि ठीक से इनिशियलाइज़ न किए गए सीड से आते हैं।

क्या UUID और GUID एक ही हैं?

हाँ, GUID वह नाम है जो Microsoft इस्तेमाल करता है और टेक्स्ट एक जैसा ही होता है; Windows में यह आमतौर पर बड़े अक्षरों में और कर्ली ब्रेसेस में दिखता है। फ़र्क बाइनरी रूप में है: .NET का Guid.ToByteArray पहले तीन समूहों को little-endian में रखता है, इसलिए अगर आप उन कच्चे बाइट्स को किसी दूसरी भाषा से पढ़ें तो शुरुआती अंक उलटे दिखेंगे।

क्या मैं UUID को सीक्रेट टोकन की तरह इस्तेमाल कर सकता हूँ?

ठीक से बने v4 में 122 अप्रत्याशित बिट होते हैं, जो मुश्किल से अंदाज़ा लगने वाले लिंक के लिए काफ़ी हैं, लेकिन RFC 9562 स्पष्ट करता है कि UUID क्रेडेंशियल के लिए नहीं बने: कई लाइब्रेरी क्रिप्टोग्राफ़िक जनरेटर की गारंटी नहीं देतीं, और संस्करण 1, 6 और 7 बनने की तारीख उजागर करते हैं। सेशन या पासवर्ड रीसेट टोकन के लिए अलग से रैंडम बाइट बनाना बेहतर है।

ULID या UUID v7?

दोनों में लगभग एक जैसी जानकारी होती है: 48 बिट मिलीसेकंड और बाकी रैंडम। ULID 26 अक्षरों में बिना हाइफ़न या भ्रामक अक्षरों के लिखा जाता है, जो URL में ज़्यादा सुविधाजनक है। v7 एक मानक UUID है, इसलिए यह बिना रूपांतरण के PostgreSQL के uuid कॉलम और किसी भी वैलिडेटर में फ़िट होता है। अगर आप शुरुआत से बना रहे हैं और आपके डेटाबेस में uuid टाइप है, तो v7 चुनें।

मेरे v1 UUID का नोड मेरा MAC क्यों नहीं है?

क्योंकि नेटवर्क कार्ड का MAC उजागर करने से यह पता लगाया जा सकता है कि किस मशीन ने कौन-सा पहचानकर्ता बनाया, और 1999 में Melissa वायरस के लेखक की पहचान इसी तरह हुई थी। RFC 9562 मल्टीकास्ट बिट चालू वाले रैंडम नोड की सलाह देता है, और यह टूल यही करता है; अगर किसी v1 UUID में असली MAC हो तो विश्लेषक आपको बताता है।

यह भी देखें