मुफ़्त UUID जनरेटर

यादृच्छिक UUID v4 मान तुरंत जनरेट करें।

कोई डेटा आपके डिवाइस से बाहर नहीं जाता

त्वरित जनरेट

-

बल्क जनरेट

UUID के बारे में

UUID (सार्वभौमिक रूप से अद्वितीय पहचानकर्ता) एक 128-bit पहचानकर्ता है जिसे स्थान और समय में अद्वितीय रहने के लिए डिज़ाइन किया गया है। सबसे सामान्य संस्करण, UUID v4, यादृच्छिक या छद्म-यादृच्छिक संख्याओं का उपयोग करके जनरेट होता है। प्रारूप 8-4-4-4-12 हेक्साडेसिमल वर्ण है, उदाहरण के लिए 550e8400-e29b-41d4-a716-446655440000।

एक चार-दशक का इतिहास, Apollo से RFC 9562 तक

UUID अवधारणा 1980 के दशक के मध्य में Apollo Network Computing System (NCS) में उत्पन्न हुई, Apollo Computer में Paul Leach और Rich Salz द्वारा केंद्रीय पंजीकरण के बिना distributed computing का समर्थन करने के लिए डिज़ाइन की गई। Format को 1989 में Open Software Foundation Distributed Computing Environment (OSF DCE) द्वारा अपनाया गया और 1995 में ITU-T X.667 / ISO/IEC 9834-8 के रूप में अंतरराष्ट्रीय स्तर पर मानकीकृत किया गया। IETF ने spec को जुलाई 2005 में RFC 4122 (Leach, Mealling, Salz) में मोड़ा, जो दो दशकों के लिए canonical reference बन गया। RFC 4122 को मई 2024 में RFC 9562 द्वारा update किया गया, जिसने सभी मूल versions (v1 से v5) रखे, तीन नए versions (v6, v7, v8) जोड़े, और विशेष «Nil UUID» (सभी zero) और «Max UUID» (सभी one) constants को औपचारिक रूप से परिभाषित किया। Versioning lineage मायने रखती है क्योंकि प्रत्येक version अलग-अलग गुणों का व्यापार करती है: time-based (sortable, leaky); name-based (inputs से deterministic); random (universal, opaque); custom (आपको जो चाहिए)। नए applications के लिए आधुनिक best practice primary keys के लिए v4 (random) से v7 (timestamp + random) में स्थानांतरित हो गई है, जबकि v4 अपारदर्शी identifiers के लिए सही उत्तर बना हुआ है जहाँ sortability अवांछनीय है।

आठ versions, सादी भाषा में

Database keys के लिए v7 v4 से अधिक क्यों पसंदीदा हो रही है

Random primary keys (v4 UUIDs) के पास उन databases में अच्छी तरह से दस्तावेज़ी performance लागत है जो rows को B-tree या समान index में primary key द्वारा व्यवस्थित करते हैं। प्रत्येक नया insert index में एक यादृच्छिक स्थिति पर उतरता है, जो index pages को विखंडित करता है, disk पर write amplification बढ़ाता है, और page cache को बर्बाद करता है क्योंकि हाल ही में insert की गई rows एक साथ क्लस्टर होने के बजाय कई pages में बिखरी हुई हैं। Sequential keys (auto-incrementing integers, ULIDs, v7 UUIDs) सभी index के दाईं ओर के किनारे पर insert होती हैं, जो working set को छोटा और write amplification को न्यूनतम रखती है। «random key anti-pattern» आलोचना NEWID बनाम NEWSEQUENTIALID के आसपास प्रारंभिक SQL Server documentation पर वापस जाती है, और Postgres community द्वारा v4 बनाम v7 के लिए पुन: स्पष्ट की गई है। Trade-off: v7 हर row का creation time leak करती है, जो कुछ applications में privacy या information-leakage concern हो सकता है (उदा. आप UUID पढ़कर बता सकते हैं कि एक account कब बनाया गया था)। अधिकांश applications के लिए performance जीत timestamp leak से अधिक है; उच्च-privacy applications के लिए, v4 सही उत्तर बना हुआ है।

Collision probability, birthday-paradox गणित

UUID v4 के पास 122 bits randomness है, जो लगभग 5.3 × 1036 संभावित मान देती है। Birthday paradox कहता है कि किसी भी collision की 50% संभावना के लिए आपको लगभग namespace size के वर्गमूल की आवश्यकता है, लगभग 2.71 × 1018 UUIDs। इसे मानवीय शब्दों में रखने के लिए: यदि आप 1 बिलियन UUIDs प्रति सेकंड लगातार उत्पन्न करते हैं, तो आपको एक एकल collision की 50% संभावना के लिए लगभग 86 साल की आवश्यकता होगी। साधारण application-scale generation rates (हजारों या लाखों प्रति दिन) के लिए, व्यावहारिक collision जोखिम शून्य है। वास्तविक systems में «duplicate UUIDs» का सबसे संभावित कारण एक buggy generator है जो CSPRNG के बजाय Math.random() का उपयोग करता है, या startup पर अपर्याप्त entropy वाला generator, या एक process जो गलती से दो generators को समान रूप से seed करती है, अंतर्निहित गणित नहीं। यह generator browser के crypto.randomUUID() (जहाँ उपलब्ध) या crypto.getRandomValues() का उपयोग करता है, दोनों operating system के CSPRNG (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes) से खींचते हैं, TLS session keys के लिए उपयोग की जाने वाली समान entropy source।

Browser implementation: crypto.randomUUID()

Web Crypto API crypto.randomUUID() को एक one-call generator के रूप में expose करता है जो RFC 4122-compliant v4 UUID string लौटाता है। यह Chrome 92 (जुलाई 2021), Firefox 95 (दिसंबर 2021) और Safari 15.4 (मार्च 2022) में shipped हुआ, और लगभग 2022 के बाद से सभी modern browsers में baseline-available है। पुराने browsers के लिए, मानक fallback एक 16-byte Uint8Array allocate करना है, इसे crypto.getRandomValues() से भरना है, version nibble को 4 पर सेट करना है (7वें byte का high nibble = 0x40), variant bits को 10xxxxxx पर सेट करना है (9वें byte के उच्च दो bits = 0x80), और bytes को 8-4-4-4-12 hex string के रूप में format करना है। यह generator जब उपस्थित होता है तो crypto.randomUUID() का उपयोग करता है और अन्यथा manual fallback का, output दोनों तरह से समान है, बस fallback path पर थोड़ा धीमा। दोनों paths पूरी तरह से आपके browser में चलते हैं; कुछ भी network को पार नहीं करता।

उपयोग के मामले, और प्रत्येक को वास्तव में क्या चाहिए

जानने योग्य विकल्प

UUID सार्वभौमिक default है लेकिन एकमात्र विकल्प नहीं, और कई विकल्प विशिष्ट उपयोग मामलों के लिए जानने योग्य हैं। ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 bits UUID की तरह, लेकिन 32 hex digits के बजाय 26 Crockford-Base32 characters के रूप में encoded, अधिक compact और case-insensitively URL-safe। पहले 48 bits Unix millisecond timestamp हैं, इसलिए ULIDs creation time के अनुसार lexicographically sort होती हैं। UUID v7 के वैचारिक रूप से बहुत करीब, इसे वर्षों से predating। Snowflake (Twitter, 2010): 64 bits, UUID की तुलना में बहुत छोटा, SQL BIGINT में fits होता है। 41 bits timestamp + 10 bits machine ID + 12 bits per-millisecond sequence। Twitter/X, Discord, Instagram, और कई बड़े-पैमाने के systems द्वारा उपयोग जहाँ 64-bit primary keys एक कठोर बाधा हैं। KSUID (Segment, 2017): 27 characters, second-precision timestamp + 128 bits random। UUID की तुलना में छोटे string representation के लिए millisecond precision का व्यापार करता है। nanoid (Andrey Sitnik, 2017): एक छोटी library जो configurable लंबाई के random URL-safe identifiers उत्पन्न करती है। Default 21 characters बहुत कम bytes में UUID v4 के समान collision resistance प्रदान करते हैं। एक public-facing URL के लिए जहाँ आप अन्यथा एक UUID embed करते, nanoid छोटा और मित्रवत है। Trade-off: nanoid identifiers में version + variant marker bits नहीं हैं जो उन्हें UUIDs के रूप में अलग करते हैं, इसलिए वे उन systems में फिट नहीं होते जो UUID-shaped मान अपेक्षा करते हैं।

URL सुरक्षा और format विविधताएँ

UUIDs अपने canonical hyphenated रूप में (550e8400-e29b-41d4-a716-446655440000) URL-safe हैं, हर character (lowercase letters, digits, hyphens) RFC 3986 द्वारा परिभाषित unreserved set में है। इसका मतलब है कि आप एक UUID को सीधे URL path या query string में बिना percent-encoding के डाल सकते हैं। कुछ systems compactness के लिए hyphens को strip करते हैं, एक 32-character hex string उत्पन्न करते हैं (550e8400e29b41d4a716446655440000) जो अभी भी URL-safe है; conversion reversible है क्योंकि UUID संरचना तय है। कुछ systems UUIDs को braces में लपेटते हैं ({550e8400-e29b-41d4-a716-446655440000}), Microsoft की GUID convention; braces decorative हैं और कभी URLs में यात्रा नहीं करते। कुछ systems hex characters को uppercase करते हैं; UUIDs spec के अनुसार case-insensitive हैं, लेकिन एक system के भीतर consistency मायने रखती है। यह generator तीनों options (uppercase, braces, बिना dashes के) उस pipeline के साथ compatibility के लिए प्रदान करता है जिसमें आप UUIDs को feed कर रहे हैं।

UUID vs GUID, एक ही चीज़, अलग नाम

UUID IETF, ISO और अधिकांश open-source projects द्वारा उपयोग किया जाने वाला मानक शब्द है। GUID (Globally Unique Identifier) Microsoft term है जो Windows, .NET, COM/OLE, SQL Server, Active Directory और Windows Registry में उपयोग किया जाता है। दोनों एक ही 8-4-4-4-12 hex format में समान 128-bit identifier को संदर्भित करते हैं। कार्यात्मक रूप से विनिमेय, Windows द्वारा उत्पन्न GUID का उपयोग किसी भी जगह किया जा सकता है जहाँ UUID की अपेक्षा की जाती है, और इसके विपरीत। जानने योग्य एकमात्र अंतर: Microsoft की GUID generation ऐतिहासिक रूप से कई APIs में UUID v4 का उपयोग करती थी लेकिन कुछ पुराने COM/OLE संदर्भों में UUID v1 (MAC address के साथ); यह Microsoft की COM specification में दस्तावेज़ है। यदि आप एक Microsoft-origin system से एक GUID प्राप्त करते हैं और जानना चाहते हैं कि यह कौन सी version है, तो version nibble की जाँच करें (13वाँ hex character, v1 के लिए '1', v4 के लिए '4', आदि)।

गोपनीयता: यहाँ भी browser-only क्यों मायने रखता है

एक UUID का कोई अंतर्निहित अर्थ नहीं है, तो यह क्यों मायने रखता है कि generator स्थानीय रूप से चलता है? दो कारण। पहला, जब एक UUID को session token, idempotency key या किसी अन्य secret-जैसे identifier के रूप में उपयोग किया जाता है, तो इसे एक तीसरे-पक्ष के server पर उत्पन्न करने का अर्थ है कि उस server ने आपके उपयोग करने से पहले मान देखा, एक छोटा लेकिन वास्तविक exposure। दूसरा, server-side generators जो «cryptographic randomness» का वादा करते हैं, उपयोगकर्ता द्वारा सत्यापित नहीं किए जा सकते; एक buggy या दुर्भावनापूर्ण server गैर-random मान लौटा सकता है जो random दिखते हैं, और आपके पास bias का पता लगाने का कोई तरीका नहीं होगा। एक browser-only generator वही crypto.randomUUID() call चलाता है जो आपका application server-side चलाएगा; entropy एक ही operating system source से आती है (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); कोई तीसरा पक्ष output नहीं देखता। आप DevTools के Network tab खोलकर Generate पर click करते समय इसे verify कर सकते हैं, कोई outbound requests नहीं हैं। load होने के बाद page को offline (airplane mode) ले जाएँ और generator अभी भी काम करता है।

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

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

वे मूल रूप से एक ही चीज़ हैं। UUID मानक शब्द है (RFC 4122), जबकि GUID (ग्लोबली यूनिक आइडेंटिफ़ायर) माइक्रोसॉफ़्ट की शब्दावली है। दोनों एक ही 8-4-4-4-12 हेक्स प्रारूप में 128-bit पहचानकर्ता को संदर्भित करते हैं।

क्या दो UUID कभी समान हो सकते हैं?

सैद्धांतिक रूप से हाँ, लेकिन संभावना खगोलीय रूप से कम है। UUID v4 में 122 यादृच्छिक बिट्स होते हैं, जो लगभग 5.3 × 10³⁶ संभावित मान देते हैं। एक भी टकराव की 50% संभावना पाने के लिए आपको दशकों तक प्रति सेकंड अरबों UUID जनरेट करने होंगे।

क्या ये UUID क्रिप्टोग्राफ़िक रूप से सुरक्षित हैं?

हाँ। यह जनरेटर Web Crypto API (crypto.getRandomValues) का उपयोग करता है जो क्रिप्टोग्राफ़िक रूप से मज़बूत यादृच्छिक मान प्रदान करता है। आउटपुट सत्र टोकन जैसे सुरक्षा-संवेदनशील उपयोग मामलों के लिए उपयुक्त है।

क्या मुझे अपनी database primary key के लिए UUID v4 या v7 का उपयोग करना चाहिए?

v7 आधुनिक सिफारिश है यदि आपकी database इसे support करती है। v4 (random) B-tree indexes में random positions पर insert करती है, index को fragment करती है, और page cache को बर्बाद करती है। v7 (timestamp + random, RFC 9562 मई 2024) index के दाईं ओर के किनारे पर insert करती है क्योंकि IDs creation time के अनुसार sort होती हैं, auto-increment integers के समान write performance, UUIDs की distribution और uniqueness के साथ। Postgres 18+ में built-in uuidv7() है। Trade-off: v7 हर row का creation time leak करती है, जो कुछ applications में privacy concern हो सकता है। अधिकांश उपयोग मामलों के लिए performance जीत timestamp leak से अधिक है।

ULID, KSUID और nanoid क्या हैं?

वैकल्पिक ID formats। ULID (Alex Knol, ~2016): 128 bits UUID की तरह लेकिन 26 Crockford-Base32 characters के रूप में encoded; timestamp के अनुसार lexicographically sort होती है। KSUID (Segment, 2017): 27 characters, second-precision timestamp + 128 random bits। nanoid (Andrey Sitnik, 2017): एक छोटी library जो configurable लंबाई के URL-safe random IDs उत्पन्न करती है; default 21 characters बहुत कम bytes में UUID v4 के समान collision resistance देते हैं। Snowflake (Twitter, 2010): 64-bit IDs जो SQL BIGINT में फिट होती हैं, Twitter, Discord और Instagram द्वारा उपयोग। UUID का उपयोग करें जब प्राप्त करने वाला system UUID format की अपेक्षा करता है; जब आपके पास specific size, sortability या URL-friendliness आवश्यकताएँ हों तो विकल्पों का उपयोग करें।

क्या UUIDs कहीं भेजे जाते हैं?

नहीं। प्रत्येक UUID Web Crypto API का उपयोग करके आपके browser में स्थानीय रूप से उत्पन्न होती है। Generator कभी network request नहीं करता, Generate पर click करते समय DevTools के Network tab में verify करें, या load होने के बाद page को offline ले जाएँ और पुष्टि करें कि उपकरण अभी भी काम करता है। session tokens, idempotency keys, या अन्य identifiers उत्पन्न करने के लिए सुरक्षित जहाँ आप नहीं चाहते कि किसी तीसरे पक्ष ने आपके उपयोग करने से पहले मान देखा हो।

संबंधित उपकरण

मुफ़्त पासवर्ड जनरेटर ऑनलाइन

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

मुफ़्त हैश जनरेटर

टेक्स्ट या फ़ाइलों से MD5, SHA-1, SHA-256, SHA-384, SHA-512 हैश बनाएं। HMAC हस्ताक्षर समर्थित। ब्राउज़र-आधारित, कोई अपलोड नहीं।

यादृच्छिक संख्या जनरेटर

मुफ़्त ऑनलाइन यादृच्छिक संख्या जनरेटर। किसी भी रेंज में क्रिप्टोग्राफिक रूप से यादृच्छिक संख्याएँ बनाएँ। अद्वितीय मानों, सॉर्टिंग और बैच जनरेशन के विकल्प।