UUID v4 Generator

क्रिप्टोग्राफिक रूप से सुरक्षित यादृच्छिक UUID v4 जनरेट करें

…

फ़ॉर्मेट करें

संख्या:

यह भी आज़माएं:UUID v1 Generator UUID v7 Generator UUID v3 Generator UUID v2 Generator ULID Generator NanoID Generator CUID Generator CUID2 Generator UUID Decoder

UUID v4 आधुनिक सॉफ्टवेयर में सबसे व्यापक रूप से उपयोग किया जाने वाला UUID संस्करण है। अन्य संस्करणों के विपरीत जो timestamp या namespace hash से bits व्युत्पन्न करते हैं, UUID v4 पूरी तरह यादृच्छिक डेटा से बना है — जो इसे सबसे सरल और सबसे व्यापक विकल्प बनाता है जब भी ऐसा unique identifier चाहिए जो अपने उद्गम के बारे में कोई metadata न रखे।

यह जनरेटर crypto.randomUUID() उपयोग करता है, जो मूल ब्राउज़र और Node.js API है और operating system के cryptographically secure random number generator से entropy प्राप्त करता है — वही स्रोत जो TLS key material के लिए उपयोग होता है।

UUID v4 क्या है?

एक Universally Unique Identifier (UUID) एक 128-bit लेबल है जिसे RFC 4122 में मानकीकृत किया गया है। इसे आमतौर पर 32 hexadecimal अंकों के रूप में हाइफ़न द्वारा 8-4-4-4-12 प्रारूप में समूहीकृत करके दर्शाया जाता है:

550e8400-e29b-41d4-a716-446655440000

UUID v4 में, 128 bits में से 122 bits यादृच्छिक होते हैं। शेष 6 bits विशिष्टता द्वारा अनिवार्य निश्चित फ़ील्ड हैं: 4 bits संस्करण अंकित करते हैं (0100 = 4) और 2 bits RFC 4122 variant अंकित करते हैं (10)। इन्हीं निश्चित bits के कारण तीसरा समूह हमेशा 4 से शुरू होता है और चौथा समूह हमेशा 8, 9, a, या b से शुरू होता है।

UUID v4 की संरचना

550e8400-e29b-41d4-a716-446655440000 को समझना:

खंड	Bits	अर्थ
550e8400	32 यादृच्छिक	time_low (नाम ऐतिहासिक है — v4 में पूरी तरह यादृच्छिक)
e29b	16 यादृच्छिक	time_mid (ऐतिहासिक नाम — v4 में पूरी तरह यादृच्छिक)
41d4	4 निश्चित + 12 यादृच्छिक	Version nibble `4` (binary `0100`) + 12 यादृच्छिक bits
a716	2 निश्चित + 14 यादृच्छिक	Variant bits `10` (पहले byte के MSBs) + 14 यादृच्छिक bits
446655440000	48 यादृच्छिक	node (v4 में पूरी तरह यादृच्छिक)

Note:चौथे समूह की शुरुआत में variant nibble हमेशा 8, 9, a, या b में से एक होती है — क्योंकि उस byte के ऊपरी दो bits 10 पर निश्चित हैं (RFC 4122 variant marker), जिससे शेष दो bits बदल सकते हैं।

UUID v4 बनाम अन्य संस्करण

RFC 4122 पाँच UUID संस्करण परिभाषित करता है। प्रत्येक एक अलग समस्या का समाधान करता है:

UUID v1Timestamp + MAC

60-bit timestamp (Oct 1582 से 100-nanosecond अंतराल) को host MAC address के साथ संयुक्त करता है। एक ही machine पर एकदिशीय रूप से वृद्धिशील।

Use when: जब time-ordered IDs चाहिए और server की पहचान तथा उत्पादन समय उजागर होने पर कोई आपत्ति न हो।

UUID v3MD5 hash

निर्धारक: एक ही namespace + name हमेशा एक ही UUID उत्पन्न करता है। MD5 hashing उपयोग करता है।

Use when: जब किसी ज्ञात namespace से पुनरुत्पादनीय IDs चाहिए (जैसे DNS names)। v3 की बजाय v5 को प्राथमिकता दें।

UUID v4यादृच्छिक

122 bits की cryptographically secure यादृच्छिकता। कोई timestamp, MAC, या namespace नहीं। सबसे सामान्य सामान्य-प्रयोजन विकल्प।

Use when: जब बिना किसी संरचनात्मक अर्थ और अधिकतम गोपनीयता के साथ unique IDs चाहिए।

UUID v5SHA-1 hash

v3 जैसा लेकिन SHA-1 उपयोग करता है। Namespace + name से निर्धारक।

Use when: जब पुनरुत्पादनीय, content-addressed identifiers चाहिए (जैसे URL द्वारा पहचाने गए संसाधनों के लिए स्थिर IDs)।

UUID v7समय-क्रमित यादृच्छिक

नया संस्करण (RFC 9562, 2024)। उच्च bits में Unix millisecond timestamp अंकित करता है, फिर यादृच्छिक bits। क्रमबद्ध और डेटाबेस-अनुकूल।

Use when: जब प्राकृतिक समय-क्रम के साथ डेटाबेस-index-अनुकूल IDs चाहिए (नए projects के लिए v1 की बजाय इसे प्राथमिकता दें)।

UUID v4 कब उपयोग करें

UUID v4 अधिकांश स्थितियों में सही विकल्प है जहाँ बस एक unique ID चाहिए बिना अतिरिक्त बाधाओं के:

User और account IDs

ऐसे अपारदर्शी user IDs जो account निर्माण समय या server की पहचान के बारे में कुछ भी उजागर नहीं करते। इन्हें सूचीबद्ध या अनुमान नहीं किया जा सकता।

Database primary keys

किसी भी database engine के साथ काम करता है। UUID v4 को बिना किसी समन्वय के client-side उत्पन्न और distributed sources से विलय किया जा सकता है — कोई sequence table या central ID service की ज़रूरत नहीं।

Session और token IDs

122 bits की यादृच्छिकता brute-force अनुमान को व्यावहारिक रूप से असंभव बना देती है — जो 122-bit यादृच्छिक token की शक्ति के बराबर है।

File और object names

Uploads, S3 object keys, या cache entries के लिए दोहराव-सुरक्षित filenames। दो clients के एक ही key पर लिखने का कोई जोखिम नहीं।

Idempotency keys

Request जमा करने से पहले client पर UUID उत्पन्न करें। Server बिना किसी साझा counter के पुनः प्रयास किए गए अनुरोधों का दोहराव सुरक्षित रूप से हटा सकता है।

Correlation और trace IDs

हर log line और distributed trace span पर UUID जोड़ें। Services या machines के बीच कोई समन्वय की आवश्यकता नहीं।

Note:यदि आपके उपयोग के मामले को क्रमबद्ध IDs की ज़रूरत है (जैसे आप चाहते हैं कि database rows insertion time के अनुसार एकत्रित हों), तो UUID v7 पर विचार करें। UUID v4 जानबूझकर यादृच्छिक है और high insert rates पर B-tree indexes में विखंडन उत्पन्न कर सकता है।

टकराव की संभावना

122 यादृच्छिक bits के साथ, UUID v4 space में 2¹²² ≈ 5.3 × 10³⁶ संभावित मान हैं। टकराव की प्रायिकता जन्मदिन समस्या के अनुसार चलती है:

उत्पन्न UUIDsटकराव की संभावना

1 billion (10⁹) ~1 in 5.3 × 10¹⁸

1 trillion (10¹²) ~1 in 5.3 × 10¹²

10¹⁸ (1 exabyte worth)~1 in 5,300

50% टकराव संभावना के लिए लगभग 2.71 × 10¹⁸ UUIDs उत्पन्न करने होंगे। 1 billion UUIDs प्रति second की दर पर, इसमें लगभग 85 वर्ष का निरंतर उत्पादन लगेगा। किसी भी वास्तविक अनुप्रयोग के लिए टकराव व्यावहारिक चिंता का विषय नहीं हैं।

Code उदाहरण

JavaScript — Browser और Node.js 14.17+

crypto.randomUUID() method सभी आधुनिक browsers (Chrome 92+, Firefox 95+, Safari 15.4+) और Node.js 14.17+ में मूल रूप से उपलब्ध है। कोई package स्थापना की आवश्यकता नहीं।

// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"

// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())

Node.js — पुराने संस्करण (uuid package)

const { v4: uuidv4 } = require('uuid')

const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"

Python

python

import uuid

# Generate a UUID v4
id = str(uuid.uuid4())
# → '110e8400-e29b-41d4-a716-446655440000'

# The uuid module uses os.urandom() — cryptographically secure
print(uuid.uuid4().hex)  # without hyphens
# → '110e8400e29b41d4a716446655440000'

Go

import "github.com/google/uuid"

id := uuid.New().String()
// → "110e8400-e29b-41d4-a716-446655440000"

// Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic)
// Always prefer github.com/google/uuid for production use

Rust

toml

# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }

rust

use uuid::Uuid;

let id = Uuid::new_v4().to_string();
// → "110e8400-e29b-41d4-a716-446655440000"

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

क्या UUID v4 cryptographically secure है?

UUID v4 स्वयं एक security primitive नहीं है — यह एक identifier format है। हालाँकि, जब crypto.randomUUID() (browser या Node.js) या समकक्ष OS-level APIs के माध्यम से उत्पन्न किया जाता है, तो आधारभूत entropy cryptographically secure होती है। इसका अर्थ है कि UUID v4 मानों को session tokens या idempotency keys के रूप में उपयोग करना उचित है, जहाँ अप्रत्याशितता मायने रखती है। Security-sensitive संदर्भों के लिए Math.random()-based UUID generators का उपयोग न करें — केवल ऐसे APIs उपयोग करें जो OS CSPRNG से entropy लेते हैं।

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

सैद्धांतिक रूप से हाँ, व्यावहारिक रूप से नहीं। किसी भी यथार्थवादी डेटासेट (अरबों IDs) में दोहराव उत्पन्न करने की संभावना अत्यंत नगण्य है — hardware fault से data corruption होने से भी कहीं कम। UUID v4 टकराव को production system design में असंभव माना जाता है। यदि वास्तव में शून्य-टकराव की गारंटी चाहिए, तो केंद्रीकृत counter या database sequence उपयोग करें।

UUID v4 बनाम nanoid — कौन सा उपयोग करूँ?

दोनों CSPRNG-आधारित यादृच्छिक ID जनरेटर हैं। मुख्य अंतर:

UUID v4 RFC 4122 मानक का अनुसरण करता है, हर database और framework द्वारा मान्यता प्राप्त है, और शून्य निर्भरताएं आवश्यक हैं (मूल crypto.randomUUID())।
nanoid URL-safe alphabet उपयोग करता है और डिफ़ॉल्ट रूप से छोटा है (21 अक्षर बनाम 36)। जब URL लंबाई या पठनीयता मायने रखे तब उपयोगी। npm package की आवश्यकता होती है।

UUID v4 को प्राथमिकता दें जब बाहरी सिस्टम के साथ अंतरसक्रियता मायने रखे (APIs, databases, logging infrastructure)। nanoid को प्राथमिकता दें जब छोटे IDs चाहिए और आप पूरे stack पर नियंत्रण रखते हों।

क्या databases में UUIDs strings या binary के रूप में संग्रहीत करने चाहिए?

अधिकांश databases के लिए, UUID या BINARY(16) column (16 bytes) के रूप में संग्रहीत करना VARCHAR(36) string (36 bytes) से अधिक कुशल है। PostgreSQL में मूल uuid type है। MySQL और MariaDB BINARY(16) और UUID_TO_BIN() / BIN_TO_UUID() helpers के साथ अच्छी तरह काम करते हैं। SQLite उपयोगकर्ता आमतौर पर TEXT के रूप में संग्रहीत करते हैं। भंडारण विकल्प का uniqueness या correctness पर कोई प्रभाव नहीं पड़ता।

UUID v4 में hyphens क्यों हैं — और क्या उन्हें छोड़ा जा सकता है?

Hyphens RFC 4122 द्वारा परिभाषित canonical UUID प्रतिनिधित्व का हिस्सा हैं। ये पूरी तरह सौंदर्यात्मक हैं — ये कोई जानकारी नहीं रखते और 128-bit मान को प्रभावित नहीं करते। इन्हें छोड़ने पर कार्यात्मक रूप से समतुल्य संक्षिप्त 32-अक्षर hex string मिलती है। अधिकांश UUID parsers दोनों रूप स्वीकार करते हैं। संदेह होने पर, third-party tools और databases के साथ अधिकतम संगतता के लिए canonical hyphenated रूप उपयोग करें।

const id = crypto.randomUUID()              // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '')     // "550e8400e29b41d4a716446655440000"

भाषा गाइड

Python में UUID v4 जेनरेट करें — uuid.uuid4()