UUID जाँचें

UUID 128 बिट की होती है, जो आम तौर पर 32 hexadecimal अंकों के रूप में, पाँच समूहों में और बीच में हाइफ़न के साथ लिखी जाती है। ऐसी स्ट्रिंग से तीन चीज़ें जाँची जा सकती हैं: रूप सही है या नहीं, तेरहवाँ अक्षर कौन-सा version बताता है, और चौथे समूह के शुरुआती बिट कौन-सा variant बताते हैं।

जो नहीं जाँचा जा सकता वह यह है कि यह पहचान कभी किसी को दी भी गई थी या नहीं। न कोई रजिस्टर है न कोई जाँच-अंक — UUID अपने भीतर यह जानकारी नहीं रखती कि वह असली है। जिसे यह जानना है कि कोई रिकॉर्ड मौजूद है या नहीं उसे अपने डेटाबेस से पूछना होगा; यह पन्ना उससे पहले वाले सवाल का जवाब देता है, यानी यह कि पूछना बनता भी है या नहीं।

Version की संख्या तीसरे समूह का पहला अक्षर है, यानी तेरहवाँ hexadecimal अंक। वहाँ `4` का मतलब यादृच्छिक है, `1` का समय-आधारित, `7` का नए RFC 9562 के हिसाब से समय में क्रमबद्ध, और `3` तथा `5` MD5 और SHA-1 पर आधारित नाम वाले रूप हैं।

जगह पता होते ही यह नंगी आँख से पढ़ा जाता है, और किसी संदेह की पुष्टि का सबसे तेज़ तरीक़ा यही है। जिसे उस जगह कोई जानी-पहचानी संख्या न दिखे उसके सामने या तो version से पहले की कोई UUID है, या कोई ऐसी चीज़ है जो सिर्फ़ UUID जैसी दिखती है।

चौथे समूह का पहला अक्षर `8`, `9`, `a` या `b` होना चाहिए। इन चार अंकों के शुरुआती बिट `10` हैं, जो वह variant है जिस पर RFC 4122 अपना दावा करता है; कोई और मान पुरानी या आरक्षित योजनाओं का है।

व्यवहार में: सही version वाली पर उस जगह `c` या `f` वाली पहचान किसी मानक-अनुरूप लाइब्रेरी से नहीं बनी। आम कारण घर के बने वे जनरेटर हैं जो 32 यादृच्छिक अंक जोड़ देते हैं और दोनों तय जगहों को अनदेखा कर देते हैं — ऐसी ख़राबी जो सालों बिना किसी की नज़र में आए ज़िंदा रह सकती है।

विनिर्देश बनाते समय छोटे अक्षरों की माँग करता है और पढ़ते समय बड़े अक्षरों के प्रति सहिष्णुता की। व्यवहार में दोनों मिलते हैं: .NET और Windows के बहुत से औज़ार परंपरागत रूप से बड़े अक्षरों में लिखते हैं, बाक़ी अधिकतर छोटे में।

इसके ऊपर दो आम लपेटन हैं: घुँघराले कोष्ठक, Windows की registry की लिखावट से, और आगे लगा `urn:uuid:`, URN के नामस्थान से। दोनों यहाँ पहचान लिए जाते हैं और अनदेखे कर दिए जाते हैं। जो अपने आप तुलना कर रहा है उसे पहले सामान्य करना होगा, वरना दो बिलकुल एक जैसी पहचानें अपनी लिखावट के कारण तुलना में विफल हो जाएँगी।

Version 1 वाली UUID में बनने का क्षण 100 नैनोसेकंड की परिशुद्धता के साथ होता है और, आख़िरी समूह में, परंपरागत रूप से नेटवर्क कार्ड का MAC पता। दोनों चीज़ें उस व्यक्ति द्वारा दोबारा निकाली जा सकती हैं जिसके पास पहचान है।

यह किताबी नहीं है: 1999 में Melissa वायरस के लेखक की पहचान इसी रास्ते हुई थी, क्योंकि Word दस्तावेज़ों की पहचानों में MAC लिख देता था। जहाँ पहचान बाहर से दिखती हो वहाँ सही चुनाव version 4 है; आजकल की लाइब्रेरियाँ इसके अलावा असली पते के बजाय यादृच्छिक node डालती हैं।

Version 7 आगे मिलीसेकंड में एक timestamp लगाती है और बाक़ी यादृच्छिकता से भरती है, जिससे पहचानें अपने ही मान से समय के हिसाब से क्रम में आ जाती हैं — और इससे वह समस्या हल हो जाती है जिसके चलते बहुत सी टीमें UUID को प्राथमिक कुंजी बनाने से बचती थीं।

कारण डेटाबेस का index है। यादृच्छिक कुंजियाँ B-वृक्ष की लगातार बदलती जगहों पर लिखती हैं, जिससे पन्ने टूटते हैं और कैश बेकार जाता है; बड़ी तालिकाओं में लिखने की गति मापी जा सकने वाली हद तक गिरती है। बढ़ती हुई कुंजी आख़िर में लिखती है। बदले में बनने का क्षण फिर से पढ़ा जा सकने लायक़ हो जाता है।

सिर्फ़ शून्य वाली पहचान nil UUID है, जिसका ज़िक्र विनिर्देश में साफ़-साफ़ है और जो औपचारिक रूप से वैध है, भले उसमें न version हो न variant। उसका मतलब «कोई नहीं» है और वह वहाँ मिलती है जहाँ कोई फ़ील्ड ख़ाली नहीं हो सकता पर ख़ाली रहना चाहिए।

RFC 9562 से उसका उलटा भी मौजूद है, max UUID, जिसमें सिर्फ़ `f` होते हैं। दोनों यहाँ की जाँच पार करते हैं और अपनी असल पहचान के साथ बताए जाते हैं। जिसे उत्पादन के डेटा में nil UUID मिले उसे शक करना चाहिए: वह लगभग कभी जान-बूझकर रखा गया निशान नहीं होता, बल्कि चुपचाप विफल हो चुका कोई जनरेटर होता है।

सबसे आम ख़राबियाँ मामूली हैं: 32 के बजाय 31 अंक क्योंकि कॉपी करते समय एक छूट गया, किसी spreadsheet की कोशिका से आया आख़िर का एक स्पेस, या बिना हाइफ़न वाली 32 अंकों की स्ट्रिंग। आख़िरी एक आम भंडारण-रूप है और किसी कॉलम में पूरी तरह सामान्य है, बस वह पाठ्य रूप नहीं है।

ऐसी हालतों में यहाँ बताया जाता है कि क्या बिगड़ा है, बजाय सिर्फ़ «अवैध» कह देने के। असली क़ीमत यही है: जिसे किसी त्रुटि-संदेश के भीतर कोई पहचान मिली है वह जानना चाहता है कि एक अक्षर खो गया है या दूसरे पक्ष ने ऐसा कुछ भेजा है जो कभी UUID था ही नहीं।

बहुत से तंत्र UUID को पाठ के बजाय 16 बाइट के रूप में रखते हैं, क्योंकि पाठ्य रूप 36 अक्षर लेता है और बाइट वाला रूप 16 — किसी बड़ी तालिका में यह जगह और index दोनों पर दिखता है। तब निर्यात में वह hexadecimal की 32 अंकों वाली एक अटूट स्ट्रिंग बनकर निकलती है।

यहाँ ऐसी स्ट्रिंग यह बताकर पहचानी जाती है कि हाइफ़न नहीं हैं। और एक जाल भी है जो जानने लायक़ है: कुछ पुराने Microsoft तंत्र पहले तीन समूहों की बाइट उलटे क्रम में रखते हैं, इसलिए उनके निर्यात से आई पहचान वही होकर भी दूसरी लिखी दिखती है — दो तंत्रों के बीच पहचानें न मिलने की यह वजह ढूँढ़ने में सबसे ज़्यादा समय लेती है।

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

व्यावहारिक फ़ायदा उलटी दिशा में है, और वह असली है: चूँकि वैध UUID में सिर्फ़ hexadecimal अंक और हाइफ़न होते हैं, रूप की यह जाँच अपने आप हर उस अक्षर को छाँट देती है जिससे कोई query या कोई path तोड़ा जा सकता है। इसीलिए किसी पहचान को किसी क्वेरी में डालने से पहले उसका रूप जाँच लेना सस्ता और सार्थक है — बशर्ते उसे मान लेने की जगह न समझा जाए कि रिकॉर्ड मौजूद है और वह इस उपयोक्ता का है।

UUID अपने आप में निजी डेटा नहीं है, पर वह आम तौर पर वह चाबी होती है जो निजी डेटा तक ले जाती है: कोई उपयोक्ता-पहचान, कोई session कुंजी, किसी सपोर्ट तंत्र का कोई मामला-नंबर। चूँकि जाँच पन्ने पर ही होती है, उनमें से कुछ भी हम तक नहीं पहुँचता।

Version 1 वाली पहचानों के साथ यह और जुड़ जाता है कि उनके भीतर जानकारी होती है: बनने का क्षण और, संभवतः, बनाने वाली मशीन का MAC। ठीक ऐसे मानों को किसी और के फ़ॉर्म से भेजना सबसे बुरा विचार होता — और यही वजह है कि यहाँ विश्लेषण वहीं होता है जहाँ पहचान पहले से है।