देख रहे हैं: हिन्दी अंग्रेज़ी में देखें

UUID जनरेटर

अपने ब्राउज़र में v4 (रैंडम) या v7 (समय-क्रमित) UUID बनाएँ। रैंडमनेस के लिए Web Crypto API का उपयोग।

  1. रैंडम UUID के लिए v4, और समय-क्रमित के लिए v7 चुनें।
  2. संख्या सेट करें (अधिकतम 1000) और "जनरेट करें" दबाएँ।
  3. पूरी सूची के लिए "सब कॉपी करें" का उपयोग करें, या एक पंक्ति मैन्युअली चुनें।
यह क्या करता है?

v4 UUID 122 बिट की क्रिप्टोग्राफ़िक रूप से सशक्त रैंडमनेस हैं — आइडेम्पोटेंसी कुंजियों, सेशन IDs, और जहाँ भी आपको ओपेक, अक्रमिक पहचान चाहिए, वहाँ सर्वव्यापी डिफ़ॉल्ट। v7 UUID शुरुआती बाइट्स में 48-बिट Unix-मिलीसेकंड टाइमस्टैम्प रखते हैं, इसलिए समय में पास बने मान शब्दकोशीय क्रम में भी पास रहते हैं। इससे v7 डेटाबेस प्राथमिक कुंजी के लिए बेहतर बैठता है, जहाँ रैंडम इंसर्ट B-tree इंडेक्स को बिखेर सकते हैं।

उदाहरण

तीन v4 UUIDs (रैंडम, बिना क्रम):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

एक ही मिलीसेकंड में बने तीन v7 UUIDs (साझा उपसर्ग देखें):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

सामान्य त्रुटियाँ और सावधानियाँ

एप्लिकेशन में UUID जोड़ते समय डेवलपर्स जिन वास्तविक समस्याओं से टकराते हैं:

  • जहाँ इंसर्शन क्रम मायने रखता है, वहाँ v4 का उपयोग। 1 करोड़ रैंडम v4 को इंडेक्स करने से B-tree में भारी पेज स्प्लिट होते हैं। v4 ही रखना है तो राइट एम्प्लिफ़िकेशन सहें, अन्यथा प्राथमिक कुंजी को v7 पर स्विच करें।
  • हाइफ़न हटाने पर संस्करण निबल (nibble) खोना। f47ac10b58cc4372a5670e02b2c3d479 अभी भी एक मान्य 32-अक्षर हेक्स UUID है, पर 13वाँ अक्षर (4) संस्करण चिह्न है — रैंडम निबल नहीं। पूरे 32 अक्षरों को रैंडम न मानें।
  • Math.random() पर निर्भरता। Math.random() पर बनी पुरानी लाइब्रेरियाँ क्रिप्टोग्राफ़िक रूप से सशक्त नहीं हैं और पूर्वानुमेय हो सकती हैं। crypto.randomUUID() (ब्राउज़र और Node 19+) या crypto से पढ़ने वाली v7 लाइब्रेरी का उपयोग करें।
  • v7 को टाइमस्टैम्प की तरह मानना। शुरुआती 48 बिट समय हैं पर बाक़ी रैंडम, इसलिए एक ही मिलीसेकंड के दो v7 निर्धारिक रूप से क्रमित नहीं होते। टाई-ब्रेकिंग पर निर्भर न हों।
  • VARCHAR(36) के रूप में संग्रहण। काम करता है पर नेटिव 16-बाइट UUID / BINARY(16) कॉलम की तुलना में स्टोरेज दुगुना हो जाता है और जॉइन धीमे पड़ते हैं। डेटाबेस के नेटिव प्रकार का उपयोग करें (Postgres में uuid, SQL Server में UNIQUEIDENTIFIER)।
  • विशिष्ट संस्करण माँगने वाला रेगेक्स। /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i केवल v4 से मेल खाता है। बाद में v7 जारी करेंगे तो वह रेगेक्स मान्य IDs को चुपचाप अस्वीकार कर देगा।
अक्सर पूछे जाने वाले प्रश्न

UUID v4 और v7 में क्या अंतर है?

v4 में 122 बिट रैंडमनेस और संस्करण/वेरिएंट चिह्न होते हैं, बिना किसी समय घटक के। v7 में 48-बिट Unix-मिलीसेकंड टाइमस्टैम्प उपसर्ग रूप में होता है और बाक़ी रैंडम, इसलिए समय में पास बने v7 शब्दकोशीय क्रम में भी पास रहते हैं। डेटाबेस प्राथमिक कुंजी के लिए v7 चुनें ताकि B-tree इंसर्ट स्थानीय रहें; बिलकुल कोई क्रम-संकेत नहीं चाहिए तो v4।

क्या कभी डुप्लिकेट UUID मिलेगा?

व्यावहारिक रूप से नहीं। v4 UUID में 122 रैंडम बिट होते हैं, इसलिए एक अरब के बैच में दो का टकराव लगभग 10^-18 की प्रायिकता है। 50% टकराव संभावना पाने के लिए लगभग 2.7 क्विंटिलियन v4 चाहिए। विशिष्टता को मान लें और अलग से यूनिकनेस जाँच न जोड़ें।

क्या v4 क्रिप्टोग्राफ़िक रूप से रैंडम है?

यह टूल crypto.randomUUID() का उपयोग करता है, जिसे स्पेसिफिकेशन के अनुसार क्रिप्टोग्राफ़िक रूप से सशक्त PRNG से लेना ज़रूरी है। सेशन IDs, आइडेम्पोटेंसी कुंजियों और अधिकांश सुरक्षा टोकनों के लिए यह काफ़ी है। यह हस्ताक्षरित टोकन या लंबे API सीक्रेट का विकल्प नहीं है, और UUID से एन्क्रिप्शन कुंजियाँ न निकालें।

क्या UUID v7 मानकीकृत है?

हाँ। UUID v7 RFC 9562 (मई 2024) में परिभाषित है, जिसने RFC 4122 को प्रतिस्थापित किया और मूल संस्करणों के साथ v6, v7 तथा v8 को औपचारिक किया। अधिकांश आधुनिक भाषाओं में v7 क्रियान्वयन हैं — Postgres, MySQL और SQL Server बिना बदलाव के v7 को UUID कॉलम में स्वीकार करते हैं।

बाइनरी रूप कैसा दिखता है और क्या एंडियननेस मायने रखती है?

UUID 16 बाइट का होता है। मानक टेक्स्ट रूप इन्हें 8-4-4-4-12 हेक्स अक्षरों में समूहित करता है। RFC 9562 के अनुसार बाइट्स नेटवर्क (बिग-एंडियन) क्रम में लिखे जाते हैं, इसलिए 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 बाइट 0x01 से शुरू होता है। Microsoft GUID ऐतिहासिक रूप से पहली तीन समूहों को मेमोरी में लिटल-एंडियन रखते हैं — .NET बाइनरी डंप के साथ इंटरऑप करते समय सावधान रहें।

क्या आप इस टूल से बने UUID को सहेजते हैं?

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