UUID जनरेटर
UUID v4/v7, ULID और Nano ID बनाइए — एक-एक या थोक में
इस टूल के बारे में
चार रूपों में सार्वभौमिक रूप से अद्वितीय पहचानकर्ता बनाइए: UUID v4 (पूरी तरह यादृच्छिक, रोज़ का डिफ़ॉल्ट), UUID v7 (समय के क्रम में, डेटाबेस कुंजियों के लिए आधुनिक विकल्प), ULID (समय के क्रम में, संक्षिप्त Crockford Base32 वर्तनी के साथ) और Nano ID (छोटा, URL-मैत्रीपूर्ण)। एक बार में एक या हज़ार तक बनाइए — प्रति पंक्ति एक, किसी seed स्क्रिप्ट में चिपकाने के लिए तैयार।
यादृच्छिकता Web Crypto API (crypto.getRandomValues) से आती है — क्रिप्टोग्राफ़िक रूप से सुरक्षित स्रोत, Math.random नहीं। निर्माण स्थानीय है, यानी ये आईडी किसी और को ज्ञात नहीं हैं, कहीं दर्ज नहीं होतीं, और ऑफ़लाइन भी उपलब्ध हैं।
यदि आप किसी नई प्रणाली के लिए आईडी प्रारूप चुन रहे हैं: v7 और ULID निर्माण-समय के क्रम में लगते हैं, जिससे B-ट्री इंडेक्स प्रसन्न रहते हैं और लॉग में आईडी लगभग कालक्रम में दिखती हैं; v4 यह कुछ नहीं बताता कि वह कब बनी — और कभी-कभी ठीक यही चाहिए होता है।
अक्सर पूछे जाने वाले प्रश्न
- UUID v4 और v7 में क्या अंतर है?
- v4 में 122 यादृच्छिक बिट होते हैं। v7 (RFC 9562) की शुरुआत 48-बिट यूनिक्स-मिलीसेकंड टाइमस्टैम्प से होती है, उसके बाद यादृच्छिक बिट, इसलिए बाद में बनी आईडी बाद में ही क्रम पाती हैं। डेटाबेस की प्राथमिक कुंजियों के लिए v7 आमतौर पर insert लोकैलिटी और इंडेक्स आकार सुधारता है; जहाँ क्रम अप्रासंगिक हो या समय लीक नहीं होना चाहिए, वहाँ v4 ठीक रहता है।
- क्या दो बनी हुई UUID टकरा सकती हैं?
- 122 यादृच्छिक बिट के साथ यह संभावना इतनी कम है कि उसके लिए डिज़ाइन में कुछ करना बेकार है: दूर की भी संभावना पाने के लिए दशकों तक प्रति सेकंड अरबों आईडी बनानी पड़ेंगी। व्यवहार में टकराव बग से आते हैं (seed दोबारा इस्तेमाल करना, पंक्तियाँ कॉपी करना), यादृच्छिकता से नहीं।
- UUID v7 के बजाय ULID क्यों चुनें?
- दोनों एक ही समस्या हल करते हैं। ULID 26 वर्णों का, केस-असंवेदनशील Crockford Base32 है — URL और लॉग में छोटा और साफ़ — जबकि v7 मानक 36-वर्ण वाला UUID रूप बनाए रखता है जिसे हर डेटाबेस और लाइब्रेरी पहले से स्वीकारती है। जो आपके परितंत्र में अधिक स्वाभाविक रूप से चले, वही चुनिए।
- क्या इन आईडी को गुप्त कुंजी या टोकन की तरह इस्तेमाल किया जा सकता है?
- यादृच्छिकता क्रिप्टोग्राफ़िक रूप से सुरक्षित है, पर आईडी आमतौर पर दिखाई, लॉग और इंडेक्स की जाती हैं — उन्हें सार्वजनिक माना जाता है। सत्र टोकन या API कुंजी के लिए कम से कम 128 यादृच्छिक बिट वाला अलग गुप्त मान बनाइए और उसे पासवर्ड की तरह सँभालिए।