डेवलपर टूल · UUID जनरेटर
128 Bits से 36 वर्ण तक: UUID टेक्स्ट एनकोडिंग कैसे काम करती है
· यह काम किस प्रकार करता है
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
UUID 16 bytes है, फिर भी इसका परिचित रूप 36 वर्ण है। यह पोस्ट हेक्स दोहरीकरण, हाइफ़न, केस नियम और मानक फॉर्म बहुत लंबा होने पर लोगों द्वारा उपयोग की जाने वाली छोटी एन्कोडिंग के बारे में बताती है।
कॉलम मान से अधिक चौड़ा क्यों है - 16-बाइट मान जिसकी लागत पाठ में 36 वर्ण है और URL और संग्रहण के लिए इसका क्या अर्थ है
जब आप UUID प्रारूप चुनते हैं तो स्टोरेज कॉलम की चौड़ाई फट जाती है। एक 128-बिट मान 16 bytes है, लेकिन इसका पाठ प्रतिनिधित्व एन्कोडिंग पर निर्भर करता है: हेक्साडेसिमल (36 वर्ण हाइफ़न के साथ, 32 बिना), Base64url (22 वर्ण), Base58 (22–23 अक्षर), क्रॉकफ़ोर्ड Base32 (26 अक्षर)। यदि आपका स्कीमा UUID को VARCHAR(36) के रूप में संग्रहीत करता है, तो आप प्रत्येक पंक्ति में 36 वर्ण खर्च कर रहे हैं। 1 अरब पंक्तियों और बिना किसी अन्य कॉलम वाली तालिका में, 16 गीगाबाइट बाइनरी की तुलना में 36 गीगाबाइट टेक्स्ट ओवरहेड है। चुनाव सिर्फ दिखावटी नहीं है; यह क्वेरी आकार, नेटवर्क राउंड-ट्रिप और कैश दबाव को प्रभावित करता है। विहित प्रारूप 36 वर्ण है: आठ हेक्स अंक, हाइफ़न, चार हेक्स अंक, हाइफ़न, चार हेक्स अंक, हाइफ़न, चार हेक्स अंक, हाइफ़न, बारह हेक्स अंक।
हेक्स सब कुछ दोगुना कर देता है - प्रत्येक बाइट दो अक्षर बन जाता है, और चार हाइफ़न 36 को पूरा करते हैं
प्रत्येक बाइट ठीक दो हेक्साडेसिमल वर्ण (0–9, a–f) बन जाता है। जब UUID पहली बार निर्दिष्ट किए गए थे तब से पठनीयता और विरासत कारणों से हाइफ़न मौजूद हैं। हेक्साडेसिमल एन्कोडिंग बाइट गिनती को दोगुना कर देती है: 16 bytes 32 हेक्स अंक और 4 हाइफ़न बन जाते हैं। यह सबसे धीमी एन्कोडिंग और सबसे लंबी है, लेकिन मानव-पठनीय है और हर जगह समर्थित है। केस नियम: RFC 9562 कैनोनिकल आउटपुट के लिए लोअरकेस अनिवार्य है, लेकिन इनपुट केस-असंवेदनशील है। अपरकेस को संग्रहीत करने से सामान्यीकरण का अवसर बर्बाद हो जाता है, इसलिए लोअरकेस को संग्रहीत करें और इनपुट पर केस-असंवेदनशील रूप से तुलना करें। Base64url एन्कोडिंग 64-वर्ण वर्णमाला (A–Z, a–z, 0–9, माइनस, अंडरस्कोर) का उपयोग करके तीन बाइट्स को चार वर्णों के रूप में दर्शाता है। सोलह बाइट्स 21 वर्ण और एक पैडिंग वर्ण, कुल मिलाकर 22 वर्ण बन जाते हैं। Base64url URL में आरक्षित पैडिंग और मानक वर्ण (प्लस और स्लैश) को हटा देता है।
केस नियम - आउटपुट पर लोअरकेस, इनपुट पर केस-असंवेदनशील, और मिश्रित-केस तुलनाएँ मौन बेमेल का कारण क्यों बनती हैं
Base64url प्रारूप में UUID हेक्स की तुलना में 14 वर्ण बचाता है और प्रतिशत-एन्कोडिंग के बिना URL में मान्य है। ट्रेड-ऑफ़: यह कम पठनीय है (छोटे अक्षर अंकों की तरह दिखते हैं; b, 8, B, और 8 को भ्रमित करना आसान है)। Base58 का उपयोग बिटकॉइन और अन्य ब्लॉकचेन द्वारा किया जाता है और अस्पष्ट वर्णों (0, O, I, l) को हटा देता है, जिससे परिणाम पढ़ने योग्य रहते हुए 22–23 वर्ण बन जाता है। क्रॉकफ़ोर्ड Base32 (चेकसुम्ड ISBN जैसे प्रारूपों के लिए डिज़ाइन किया गया) 26 वर्णों का उपयोग करता है और संक्षिप्तता पर शुद्धता को प्राथमिकता देता है। Microsoft GUID बाइट-ऑर्डर ट्रैप कुछ डेटाबेस में UUID स्टोरेज पर लागू होता है। RFC 9562 सभी बाइट्स के लिए नेटवर्क बाइट ऑर्डर (बिग-एंडियन) निर्दिष्ट करता है। कुछ Microsoft SQL सर्वर कॉन्फ़िगरेशन पहले तीन फ़ील्ड में छोटे-एंडियन बाइट क्रम के साथ GUID संग्रहीत करते हैं।
छोटे एन्कोडिंग - 22 वर्णों पर Base64url, Base58 और क्रॉकफोर्ड Base32, पठनीयता और कॉपी-पेस्ट सुरक्षा में उनके ट्रेड-ऑफ के साथ
बड़े-एंडियन और छोटे-एंडियन में संग्रहीत समान 128-बिट मान अलग-अलग हेक्स स्ट्रिंग उत्पन्न करता है। Microsoft GUID के रूप में संग्रहीत UUID 550e8400-e29b-41d4-a716-446655440000 को 00840e55-9be2-d441-a716-446655440000 के रूप में पुनर्प्राप्त किया जा सकता है (बाइट्स 0–3 और 4–5 और 6–7 उलट गए)। यदि आपका सिस्टम RFC-अनुपालक और Microsoft सिस्टम के बीच पुल बनाता है, तो आपको इसके बारे में पता होना चाहिए और या तो सीमा या दस्तावेज़ पर सामान्यीकृत करना चाहिए कि आप प्रत्येक कॉलम में किस प्रारूप का उपयोग कर रहे हैं। कार्यान्वित उदाहरण: हेक्साडेसिमल में v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 36 वर्ण रखता है। 16 bytes के रूप में यह 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60 है। Base64url में: तीन-बाइट खंडों में विभाजित करें, Base64 में कन्वर्ट करें, स्ट्रिप पैडिंग: my5PGk8-TBqKfRssPTRPX2A। बिना हाइफ़न वाले हेक्साडेसिमल में: 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 वर्ण)।
माइक्रोसॉफ्ट बाइट-ऑर्डर ट्रैप - कैसे GUID के पहले तीन फ़ील्ड को थोड़ा-सा संग्रहीत किया जाता है, ताकि समान बाइट्स दो अलग-अलग स्ट्रिंग के रूप में प्रिंट हो सकें
Base64url 14 वर्ण सहेजता है; Base58 लगभग इतनी ही बचत करेगा; हेक्साडेसिमल मानक है. अपने उपयोग के मामले के आधार पर चुनें: यदि पहचानकर्ता URL में दिखाई देता है और प्रत्येक वर्ण मायने रखता है, तो Base64url का उपयोग करें; यदि यह लॉग और UI में दिखाई देता है जहां मनुष्य इसे पढ़ते हैं, तो हेक्साडेसिमल कैनोनिकल फॉर्म का उपयोग करें; यदि आप एक ब्लॉकचेन प्रणाली या वितरित प्रणाली का निर्माण कर रहे हैं जहां चेकसमिंग मायने रखती है, तो Base58 या क्रॉकफोर्ड Base32 का उपयोग करें। कॉलम प्रकार चुनते समय, वह मान संग्रहीत करें जो आपके वास्तविक एक्सेस पैटर्न के लिए अनुकूलित हो। यदि आप UUID को बार-बार क्वेरी करते हैं और केस-असंवेदनशील मिलान की आवश्यकता है, तो बाइनरी (16) स्टोर करें और डेटाबेस को प्रतिनिधित्व को संभालने दें। यदि आप सबस्ट्रिंग द्वारा क्वेरी करते हैं (उपसर्ग से शुरू होने वाले UUID की खोज करते हैं), तो डिबग आउटपुट में हेक्साडेसिमल अधिक पठनीय है।
कार्यान्वित उदाहरण - बाइट्स, कैनोनिकल हेक्स और एक संक्षिप्त रूप में लिखा गया एक पहचानकर्ता, प्रत्येक रूपांतरण चरण को दर्शाता है
यदि आप CSV को निर्यात करते हैं और गैर-तकनीकी उपयोगकर्ताओं को ईमेल करते हैं, तो हेक्साडेसिमल अधिक पहचानने योग्य है। यदि आपके पास जगह की कमी है (स्थानीय कैश वाला मोबाइल ऐप), तो Base64url या Base58 बैंडविड्थ बचाता है। ToolAcre जनरेटर विहित 36-वर्ण हेक्साडेसिमल प्रारूप आउटपुट करता है; यदि आपको एक अलग एन्कोडिंग की आवश्यकता है, तो अच्छी तरह से बनाई गई जांच अभी भी काम करती है क्योंकि यह प्रारूप की जांच करने से पहले किसी भी वैध प्रतिनिधित्व को सामान्य कर देती है। लाखों UUID को एन्कोडिंग या डिकोड करते समय प्रदर्शन संबंधी विचार मायने रखते हैं। हेक्साडेसिमल एन्कोडिंग सरल है: प्रत्येक बाइट को प्रति बाइट O(1) समय में दो वर्णों में बदलें। डिकोडिंग भी उतना ही सरल है। Base64 एन्कोडिंग और डिकोडिंग लुकअप टेबल का उपयोग करते हैं और थोड़े धीमे होते हैं (हार्डवेयर और कार्यान्वयन के आधार पर हेक्स प्रति बाइट की तुलना में लगभग 2-3x धीमा)। Base58 काफी धीमा है क्योंकि यह अनिवार्य रूप से आधार रूपांतरण है और इसके लिए मॉड्यूलर अंकगणित की आवश्यकता होती है।
इसमें क्या शामिल नहीं है - डेटाबेस कॉलम विकल्प जैसे कि मूल UUID प्रकार बनाम बाइनरी (16), अलग से कवर किया गया
यदि आपका सिस्टम UUID को हॉट लूप (उच्च-आवृत्ति पहचानकर्ता पीढ़ी, थोक निर्यात) में एनकोड या डीकोड करता है, तो हेक्साडेसिमल तेज़ है। यदि एन्कोडिंग कभी-कभी होती है और 14-वर्ण बचत का मामला है, तो Base64url एक उचित व्यापार-बंद है। ToolAcre जनरेटर हेक्स आउटपुट देता है, इसलिए आपको अनुकूलता से समझौता किए बिना प्रदर्शन लाभ मिल रहा है। स्ट्रिंग तुलना शब्दार्थ एन्कोडिंग के अनुसार भिन्न होते हैं। हेक्साडेसिमल UUID की तुलना स्ट्रिंग्स के रूप में की जा सकती है: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (लेक्सिकोग्राफ़िक तुलना कार्य)। बाइनरी UUID की तुलना बाइट्स के रूप में की जा सकती है: बाइट-दर-बाइट तुलना संख्यात्मक तुलना के समान है। Base64url और Base58 एन्कोडेड UUID, हालांकि, लेक्सिकोग्राफ़िक स्ट्रिंग तुलना में संख्यात्मक क्रम को संरक्षित नहीं करते हैं। यदि आपका सिस्टम UUID की लेक्सिकोग्राफ़िक सॉर्टिंग (इंडेक्स या डेटाबेस कुंजियों के निर्माण के लिए आश्चर्यजनक रूप से सामान्य पैटर्न) पर निर्भर करता है, तो आपको या तो हेक्साडेसिमल, बाइनरी, या सॉर्ट करने योग्य UUID वेरिएंट (v6 या v7) का उपयोग करना होगा।
टेकअवे: कैनोनिकल फॉर्म को सीमाओं पर रखें - ToolAcre जनरेटर मानक 36-वर्ण UUIDs आउटपुट करता है और इसका चेक उस फॉर्म में स्ट्रिंग स्वीकार करता है
ToolAcre जनरेटर वर्तमान में v4 UUIDs का उत्पादन करता है, जो एन्कोडिंग क्रम के अनुसार क्रमबद्ध नहीं होते हैं। इंटरऑपरेबिलिटी के लिए एकल एन्कोडिंग पर मानकीकरण की आवश्यकता होती है। एक प्रणाली जो हेक्स, Base64 और Base58 में UUID को एक साथ स्वीकार करती है, उसे प्रसंस्करण से पहले सभी इनपुट को एक विहित रूप में सामान्य करना होगा। यह संभव है लेकिन जटिलता जोड़ता है। बाहरी APआई या डेटाबेस को एक विशिष्ट एन्कोडिंग की आवश्यकता हो सकती है: कुछ APआई urn:uuid: उपसर्ग हेक्स की अपेक्षा करते हैं, अन्य हाइफ़न रहित हेक्स की अपेक्षा करते हैं, फिर भी अन्य Base64url की अपेक्षा करते हैं। अपने सिस्टम की UUID एन्कोडिंग अपेक्षा को API अनुबंधों में स्पष्ट रूप से दर्ज करें। ToolAcre जनरेटर हमेशा कैनोनिकल हेक्स आउटपुट करता है; यदि आपको अन्य एन्कोडिंग की आवश्यकता है, तो रूपांतरण स्पष्ट रूप से करें और टीम को ट्रेड-ऑफ़ (स्थान, प्रदर्शन, पठनीयता, क्रमबद्धता) का दस्तावेजीकरण करें।