डेवलपर टूल · UUID जनरेटर
GUID बनाम UUID: माइक्रोसॉफ्ट के ब्रेसिज़, बाइट ऑर्डर और वेरिएंट की व्याख्या
· पेजभूमि
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
GUID UUID के लिए Microsoft का नाम है, लेकिन ब्रेसिज़, अपरकेस और बाइट क्रम एक ही पहचानकर्ता को सभी प्लेटफ़ॉर्म पर अलग दिखा सकते हैं। यह पोस्ट प्रत्येक अंतर और सुरक्षित रूप से तुलना करने के तरीके के बारे में बताती है।
वही ID जो सभी सिस्टमों से मेल खाने में विफल रहती है - एक .NET सेवा और एक जावा सेवा जो एक रिकॉर्ड पर असहमत है
एक .NET सेवा एक GUID उत्पन्न करती है और इसे जावा सेवा को भेजती है, जो PostgreSQL से UUID के विरुद्ध मान का मिलान करने का प्रयास करती है। स्ट्रिंग तुलना विफल हो जाती है, और सिस्टम रिपोर्ट करता है कि पहचानकर्ता मेल नहीं खाते हैं, भले ही सभी तीन सेवाएँ समान अंतर्निहित 16 bytes के साथ काम करती हैं। अंतर प्रतीत होता है कि कॉस्मेटिक हैं - ब्रेसिज़, केसिंग, बाइट ऑर्डर - लेकिन वे स्ट्रिंग तुलनाओं को विफल कर देते हैं और एकीकरण बिंदुओं को भ्रमित करते हैं जो सीमा पर सामान्य नहीं होते हैं। GUID माइक्रोसॉफ्ट शब्दावली है जिसके लिए RFC 9562 UUID को कॉल करता है: समान बिट लेआउट वाला 128-बिट पहचानकर्ता। दोनों नाम एक ही मौलिक संरचना को दर्शाते हैं, लेकिन प्रतिनिधित्व उन तरीकों से भिन्न है जो डेवलपर्स को आश्चर्यचकित करते हैं। यह समझना कि भ्रम कहां से उत्पन्न होता है, एकीकरण बग को रोकता है।
GUID एक UUID है - साझा 128-बिट प्रारूप और नामकरण में अंतर कहां से आया
GUID का अर्थ वैश्विक रूप से विशिष्ट पहचानकर्ता और वैश्विक रूप से विशिष्ट पहचानकर्ता है और यह वह नाम है जिसका उपयोग Microsoft RFC मानक UUID के लिए करता है। 128-बिट लेआउट और संस्करण/variant सिस्टम समान हैं। RFC 4122 और RFC 9562 UUID प्रारूप और अर्थ निर्दिष्ट करते हैं; Microsoft उन्हें कार्यान्वित करता है और GUID शब्द का उपयोग करता है। नामकरण अंतर ऐतिहासिक है: UUID को IETF द्वारा मानकीकृत किए जाने से पहले Microsoft ने GUID का उपयोग किया था, और Microsoft शब्दावली .NET पारिस्थितिकी तंत्र के भीतर अटक गई है। बिट्स स्तर पर, GUID और UUID पूरी तरह से विनिमेय हैं। फ़ॉर्मेटिंग स्तर पर, वे प्रस्तुति में भिन्न होते हैं: .NET कोड अक्सर GUID को ब्रेसिज़ और अपरकेस अक्षरों के साथ लिखता है, जबकि RFC कैनोनिकल UUID लोअरकेस का उपयोग करते हैं और कोई ब्रेसिज़ नहीं।
ब्रेसिज़ और अपरकेस - रजिस्ट्री-शैली {XXXXXXXX-...} फ़ॉर्म और इसे सामान्य कैसे करें
विहित RFC फॉर्म में UUID को हाइफ़न द्वारा अलग किए गए आठ, चार, चार, चार और बारह लोअरकेस हेक्साडेसिमल वर्णों के रूप में लिखा जाता है: 550e8400-e29b-41d4-a716-446655440000। एक .NET GUID को पारंपरिक रूप से ब्रेसिज़ और अपरकेस के साथ प्रदर्शित किया जाता है: {550E8400-E29B-41D4-A716-446655440000}। ब्रेसिज़ विंडोज़ रजिस्ट्री प्रारूप से आते हैं; अपरकेस एक प्रदर्शन परिपाटी है। दोनों फॉर्म समान 128 bits दर्शाते हैं। .NET के GUID को PostgreSQL के UUID से मिलाने के लिए, ब्रेसिज़ को हटा दें और आवरण को सामान्य करें, फिर स्ट्रिंग्स की तुलना करें। ToolAcre अच्छी तरह से निर्मित चेक विहित रूप को स्वीकार करता है और स्वचालित रूप से ब्रेसिज़ हटा देता है। सामान्यीकरण एक लघु पाठ परिवर्तन है जो सभी अर्थों को सुरक्षित रखता है।
मिश्रित-एंडियन बाइट क्रम - GUID संरचना में पहले तीन फ़ील्ड को लिटिल-एंडियन कैसे संग्रहीत किया जाता है, और क्यों Guid.ToByteArray RFC बाइट क्रम से भिन्न है
GUID और UUID के बीच खतरनाक अंतर बाइट ऑर्डर का है। RFC 9562 के अनुसार पहले तीन फ़ील्ड—8, 4 और 4 हेक्साडेसिमल समूह—big-endian (network) बाइट ऑर्डर में रखे जाते हैं। .NET Guid स्ट्रक्चर पहले तीन फ़ील्ड little-endian में रखता है: स्टोरेज में लिखने से पहले बाइट उलटते हैं। वही 16 bytes, .NET Guid.ToByteArray() से लिखे और RFC-अनुरूप कोड से पढ़े जाने पर, बिल्कुल अलग टेक्स्ट रूप देते हैं। RFC बाइट ऑर्डर वाला UUID 550e8400-e29b-41d4-a716-446655440000 इन बाइट्स में रखा जाता है: 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00।
लीगेसी Microsoft संस्करण - चौथे समूह के पहले अक्षर में a c या d का क्या अर्थ है
बाइट क्रम के अलावा, लीगेसी Microsoft पहचानकर्ता कभी-कभी एक गैर-मानक वैरिएंट फ़ील्ड का उपयोग करते हैं। जहां RFC 9562 निर्दिष्ट करता है कि चौथे समूह का पहला अक्षर 8, 9, a, या b होना चाहिए, लीगेसी Microsoft GUID c, d, e, या f का उपयोग कर सकते हैं। ये अभी भी वैध UUID हैं, लेकिन वे एक विरासत संस्करण के अनुरूप हैं जो RFC मानकीकरण से पहले का है। यदि आपको चौथे समूह के पहले अक्षर में c या d के साथ GUID मिलता है, तो आपके पास एक वैध 128-बिट मान है जो RFC वैरिएंट बिट्स के अनुरूप नहीं है। आधुनिक .NET RFC-संगत GUID उत्पन्न करता है, इसलिए नए पहचानकर्ताओं को यह समस्या प्रदर्शित नहीं करनी चाहिए। लीगेसी वेरिएंट बिट्स दुर्लभ हैं लेकिन पहचानना महत्वपूर्ण है।
कार्यान्वित उदाहरण - समान 16 bytes को RFC क्रम में और GUID-संरचना क्रम में प्रस्तुत किया गया है, जिसमें दिखाया गया है कि कौन से वर्ण स्वैप होते हैं
ले लो UUID 550e8400-e29b-41d4-a716-446655440000 और इसे में परिवर्तित करें।NET GUID लिटिल-एंडियन कन्वेंशन का उपयोग करके बाइट सरणी प्रपत्र। में RFC क्रम में, बाइट्स हैं: पहला फ़ील्ड (550e8400) बराबर है 55 0इ 84 00, दूसरा फ़ील्ड (e29b) e2 9b के बराबर है, तीसरा फ़ील्ड (41d4) बराबर है 41 d4, चौथा और पाँचवाँ बराबर a7 16 44 66 55 44 00 00. में ।NET लिटिल-एंडियन: पहला फ़ील्ड बन जाता है 00 84 0इ 55, दूसरा 9b e2 बन जाता है, तीसरा d4 बन जाता है 41, और बाकी बड़े-एंडियन में रहते हैं। पूर्ण बाइट सरणी है 00 84 0इ 55 9बी ई2 डी4 41 ए7 16 44 66 55 44 00 00. यदि कोई जावा सिस्टम इन बाइट्स को अपेक्षा से पढ़ता है RFC आदेश, यह उन्हें 00840e55-9be2-d441-a716- के रूप में व्याख्या करता है446655440000.
इसमें क्या शामिल नहीं है - SQL सर्वर का NEWSEQUENTIALID और ऑर्डर करना, जो स्वयं का एक भंडारण विषय है
SQL सर्वर NEWSEQUENTIALID फ़ंक्शन व्यवहार और इसके विशिष्ट पहचानकर्ता क्रम गुण भंडारण परत और डेटाबेस-विशिष्ट विषय हैं। यह पोस्ट एप्लिकेशन और क्रमबद्धता स्तर पर प्रारूप और बाइट-ऑर्डर अंतर पर केंद्रित है। डीप डेटाबेस-विशिष्ट UUID हैंडलिंग और बाइट-ऑर्डर मुद्दों को उस डेटाबेस प्लेटफ़ॉर्म के लिए विशिष्ट दस्तावेज़ीकरण में सबसे अच्छा संबोधित किया जाता है। विभिन्न डेटाबेस प्रणालियों में UUID भंडारण, अनुक्रमण, सॉर्टिंग और मूल समर्थन के लिए अलग-अलग दृष्टिकोण और दृष्टिकोण होते हैं। कुछ डेटाबेस स्वचालित रूप से संस्करण और वैरिएंट बिट्स का पता लगाते हैं, जबकि अन्य को सिस्टम और स्टोरेज के बीच की सीमा पर स्पष्ट प्रकार की घोषणाओं और बाइट-ऑर्डर हैंडलिंग की आवश्यकता होती है।
टेकअवे: सीमा पर सामान्यीकरण - ToolAcre चेक विहित रूप को स्वीकार करता है, जो ID का आदान-प्रदान करते समय मानकीकृत करने के लिए आकार है
जब पहचानकर्ता .NET/non-.NET सिस्टम सीमा पार करते हैं तो सीमा पर सामान्यीकरण करें। स्ट्रिप ब्रेसिज़, लगातार केसिंग को सामान्य करें, और यदि बाइट्स .NET Guid.ToByteArray() से आते हैं तो पहले तीन फ़ील्ड को बाइट-स्वैप करें। विहित RFC प्रपत्र संदर्भ मानक है: आठ, चार, चार, चार, और बारह लोअरकेस हेक्साडेसिमल वर्ण हाइफ़न के साथ, कोई ब्रेसिज़ नहीं, बड़े-एंडियन बाइट क्रम। .NET सिस्टम के साथ आदान-प्रदान करते समय, सामान्यीकृत फॉर्म पर सहमत हों और एकीकरण कोड में स्पष्ट रूप से रूपांतरण लागू करें। दस्तावेज़ बाइट-ऑर्डर प्रबंधन और रूपांतरणों का गहनता से परीक्षण करें। GUID और UUID के बीच मुख्य मूलभूत समानताएं इसका मतलब है कि अधिकांश 128 bits समान हैं।