डेवलपर टूल · UUID जनरेटर
क्या चीज़ UUID स्ट्रिंग को अच्छी तरह से बनाती है, और एक चेकर क्या नहीं जान सकता
· यह काम किस प्रकार करता है
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
अपरकेस, ब्रेसिज़, कलश: उपसर्ग और लुप्त हाइफ़न सभी वास्तविक इनपुट में दिखाई देते हैं। यह पोस्ट विहित रूप को परिभाषित करता है, दिखाता है कि एक उदार सत्यापनकर्ता को क्या स्वीकार करना चाहिए, और सुगठितता को अस्तित्व से अलग करता है।
400 जिसे 404 होना चाहिए था - कितना ख़राब UUID सत्यापन भ्रामक API त्रुटियाँ उत्पन्न करता है
एक API समापन बिंदु को क्लाइंट से एक पहचानकर्ता प्राप्त होता है: {12345678-90AB-CDEF-1234-567890ABCDEF}। सत्यापन कोड जाँचता है कि क्या यह /[0-9a-f]{32}/ से मेल खाता है और इसे अमान्य मानकर अस्वीकार कर देता है। क्लाइंट को एक 400 ख़राब अनुरोध मिलता है जहाँ 404 Not founder का मतलब था। पहचानकर्ता अच्छी तरह से बना हुआ है—यह ब्रेस्ड प्रारूप में एक वैध UUID है—लेकिन सत्यापनकर्ता बहुत सख्त है। इसके विपरीत, एक समापन बिंदु जो किसी भी 32-वर्ण हेक्स स्ट्रिंग (डैश के बिना) को स्वीकार करता है, 123456789012345678901234567890123456 को स्वीकार करेगा, इसे वैध के रूप में पार्स करेगा, और टाइपो को छोड़ देगा। RFC 9562 विहित पाठ्य प्रतिनिधित्व को परिभाषित करता है, लेकिन वास्तविक दुनिया का इनपुट पांच अलग-अलग प्रारूपों में आता है, और एक सत्यापनकर्ता जो केवल विहित रूप को स्वीकार करता है, वह 1 से 5 प्रतिशत सुविचारित इनपुट को अस्वीकार कर देगा।
विहित पाठ्य प्रपत्र - 32 लोअरकेस हेक्स अंक 8-4-4-4-12, बिल्कुल 36 वर्ण, जैसा कि मानक आउटपुट के लिए निर्दिष्ट करता है
विहित पाठ्य प्रपत्र 32 हाइफ़न द्वारा अलग किए गए पांच समूहों में लोअरकेस हेक्साडेसिमल अंक है: 8-4-4-4-12। 550e8400-e29b-41d4-a716-446655440000 के रूप में दर्शाया गया। मानक आउटपुट के लिए लोअरकेस अनिवार्य करता है; इनपुट पर, केस-असंवेदनशील मिलान की अनुशंसा की जाती है। यह फॉर्म स्पष्ट है, प्रत्येक प्लेटफ़ॉर्म पर समान तरीके से बाइट्स में पार्स करता है, और प्रत्येक UUID लाइब्रेरी डिफ़ॉल्ट रूप से यही आउटपुट करती है। यदि आप CSPRNG से एक नया UUID उत्पन्न कर रहे हैं, तो विहित रूप वह है जो आपको उत्पादित करना चाहिए और जो ToolAcre उत्पन्न करता है। वास्तविक दुनिया का इनपुट पूर्वानुमानित तरीकों से भटकता है। अपरकेस पहचानकर्ता (550E8400-E29B-41D4-A716-446655440000) उन सिस्टमों में सामान्य हैं जो अपरकेस में डिफ़ॉल्ट होते हैं; वे समान बाइट्स का प्रतिनिधित्व करते हैं और सामान्यीकरण के बाद लोअरकेस में स्वीकार किए जाने चाहिए।
ऐसे वेरिएंट जो आपको जंगली रूप में मिलेंगे - अपरकेस हेक्स, {braces}, urn:uuid: उपसर्ग और 32-वर्ण हाइफ़न रहित रूप, और जिन्हें मानक स्वीकार करने के लिए कहता है
ब्रेस्ड फॉर्म ({550e8400-e29b-41d4-a716-446655440000}) पायथन के UUID मॉड्यूल और माइक्रोसॉफ्ट के सिस्टम से मानक आउटपुट है; ब्रेसिज़ को अलग करने से वैध विहित रूप मिलता है। URN उपसर्ग (urn:uuid:550e8400-e29b-41d4-a716-446655440000) को समान संसाधन नामों के लिए RFC 8141 द्वारा परिभाषित किया गया है; स्कीम और स्ट्रिपिंग-आइडेंटिफ़ायर उपसर्ग को हटाने से विहित रूप निकल जाता है। हाइफ़न रहित रूप (550e8400e29b41d4a716446655440000) संरचना के बिना 32 हेक्स अंक है; यह वैध बाइट्स है लेकिन 8-4-4-4-12 समूह खो देता है जो संस्करणों और वेरिएंट को पढ़ने योग्य बनाता है। ये सभी वैरिएंट समान 128-बिट मान पर मैप होते हैं। RFC 9562 अनुभाग 3 बताता है कि इनपुट पर, अपरकेस वेरिएंट SHOULD स्वीकार किए जाएंगे। यह अन्य प्रकारों को प्रतिबंधित नहीं करता है; यह कहता है कि आउटपुट पर, कैनोनिकल लोअरकेस फॉर्म MUST का उपयोग किया जाएगा।
संस्करण और भिन्न विवेक - क्या उस UUID को अस्वीकार किया जाए जिसका तीसरा समूह 0 से शुरू होता है या जिसका चौथा समूह f से शुरू होता है
एक अच्छी तरह से गठित सत्यापनकर्ता को: विहित 8-4-4-4-12 फॉर्म को लोअरकेस या अपरकेस में स्वीकार करना चाहिए; ब्रेस्ड और कलश को स्वीकार करें: वेरिएंट को अलग करके और मूल रूप को मान्य करके; हाइफ़न रहित 32-अंकीय हेक्स स्ट्रिंग स्वीकार करें और तुलना के लिए उन्हें विहित के रूप में प्रारूपित करें; हेक्स अंकों या गैर-हेक्साडेसिमल वर्णों की गलत संख्या वाली स्ट्रिंग को अस्वीकार करें। सबसे आम गलती अपरकेस या ब्रेस्ड इनपुट को अस्वीकार करना है क्योंकि सत्यापनकर्ता केवल कैनोनिकल फॉर्म से मेल खाने के लिए हाथ से लिखा गया था। संस्करण और संस्करण पर विवेक जांच से टाइप संबंधी त्रुटियां पकड़ी जा सकती हैं। यदि तीसरा समूह 0 या 9 से शुरू होता है, तो UUID अमान्य या आरक्षित है; यदि चौथा समूह ई या एफ से शुरू होता है, तो वैरिएंट RFC 9562 नहीं है।
व्यावहारिक उदाहरण - छह उम्मीदवार स्ट्रिंग एक सख्त जांच और एक उदार जांच के माध्यम से चलते हैं, प्रत्येक पास या असफल होने के कारणों के साथ
एक उदार सत्यापनकर्ता इन मूल्यों को स्वीकार करता है; एक सख्त सत्यापनकर्ता उन्हें अस्वीकार कर सकता है। ToolAcre अच्छी तरह से गठित चेक सख्त सत्यापन करता है: यह सही स्थानों पर डैश के साथ विहित 36-वर्ण प्रपत्र की पुष्टि करता है, हर स्थिति में हेक्स अंकों को सत्यापित करता है, और जांचता है कि संस्करण और वैरिएंट बिट्स सीमा में हैं। यह जाँच नहीं करता है कि UUID आपके डेटाबेस में मौजूद है या यह क्रिप्टोग्राफ़िक रूप से सुरक्षित स्रोत से उत्पन्न हुआ है; वे आपके एप्लिकेशन लॉजिक द्वारा की गई अलग-अलग जाँचें हैं। सुगठित वास्तविक के समान नहीं है। एक UUID स्ट्रिंग जो अपने आकार के अनुसार सही ढंग से पार्स करती है, हो सकता है कि आपके डेटाबेस में किसी भी पंक्ति की पहचान न करे।
अच्छी तरह से गठित होना वास्तविक नहीं है - आपके डेटा में वाक्यात्मक रूप से परिपूर्ण UUID क्यों मौजूद नहीं हो सकता है, और चेकर कभी भी आपकी प्राधिकरण परत क्यों नहीं होनी चाहिए
ए UUID जो पूरी तरह से बना हुआ है उसका अनुमान लगाया गया होगा या गलत तरीके से कॉपी-पेस्ट किया गया होगा। प्रारूप सत्यापन पहला द्वार है; अस्तित्व जांच और प्राधिकरण जांच दूसरे और तीसरे हैं। प्रत्येक प्रारूप-अमान्य इनपुट के लिए डेटाबेस के विरुद्ध लुकअप चलाना बेकार है; डेटाबेस क्वेरी से पहले प्रारूप-अमान्य इनपुट को अस्वीकार करने से समय की बचत होती है। ToolAcre जनरेटर आउटपुट मानक 36-अक्षर UUID; यदि आप अपना स्वयं का सत्यापनकर्ता बना रहे हैं, तो वास्तविक दुनिया के इनपुट से मेल खाने के लिए ब्रेस्ड और यूआरएन: वेरिएंट स्वीकार करें, और अपने डेटाबेस से पूछने से पहले उन स्ट्रिंग्स को अस्वीकार कर दें जो मूल आकार के नियमों में विफल हैं। एक सख्त सत्यापनकर्ता को लागू करने के लिए नियमित अभिव्यक्ति और एज-केस हैंडलिंग की आवश्यकता होती है। विहित रूप सीधा है: /^[0-9ए-एफ]{8}-[0-9ए-एफ]{4}-[0-9ए-एफ]{4}-[0-9ए-एफ]{4}-[0-9ए-एफ]{12}$/i (केस-असंवेदनशील)। ब्रेस्ड फॉर्म घुंघराले ब्रेसिज़ जोड़ता है: /^\{[0-9ए-एफ]{8}-[0-9ए-एफ]{4}-[0-9ए-एफ]{4}-[0-9ए-एफ]{4}-[0-9ए-एफ]{12}\}$/i. कलश: संस्करण एक योजना जोड़ता है: /^urn:uuid:[0-9ए-एफ]{8}-[0-9ए-एफ]{4}-[0-9ए-एफ]{4}-[0-9ए-एफ]{4}-[0-9ए-एफ]{12}$/i.
इसमें क्या शामिल नहीं है - भंडारण के लिए ID को सामान्य बनाना और कॉलम प्रकार चुनना, जो अलग-अलग निर्णय हैं
एक एकल रेगेक्स जो सभी प्रकारों को संभालता है वह कम पठनीय है लेकिन संभव है। अधिकांश सत्यापनकर्ता पहले सामान्यीकृत करते हैं: स्ट्रिप ब्रेसिज़ और कलश: उपसर्ग, लोअरकेस में कन्वर्ट करें, फिर कैनोनिकल पैटर्न से मेल करें। जैसा कि 403 आलेख में वर्णित है, स्थिति 14 और स्थिति 19 की जांच करके पैटर्न मिलान के बाद संस्करण और वैरिएंट बिट्स की जांच की जा सकती है। अमान्य इनपुट को शालीनता से संभालना सत्यापन डिज़ाइन का हिस्सा है। जब कोई क्लाइंट विकृत UUID सबमिट करता है, तो त्रुटि संदेश में रेगेक्स पैटर्न या आंतरिक सत्यापन नियमों को उजागर न करें। एक स्पष्ट त्रुटि लौटाएँ: "अमान्य UUID प्रारूप। अपेक्षित 8-4-4-4-12 प्रारूप, जैसे 550e8400-e29b-41d4-a716-446655440000 " इनपुट को सही करने का प्रयास न करें; ग्राहक को पुनः सबमिट करने के लिए कहें.
टेकअवे: आकार को जल्दी मान्य करें, अस्तित्व को अलग से देखें - ToolAcre चेक किसी डेटाबेस को छूने से पहले ब्राउज़र में आकार की पुष्टि करता है
कुछ सिस्टम सुरक्षा ऑडिटिंग के लिए अमान्य इनपुट लॉग करते हैं (इंजेक्शन के प्रयास या प्रारूप भ्रम के हमलों का पता लगाना)। ToolAcre सत्यापनकर्ता स्पष्ट त्रुटि संदेश के साथ गैर-विहित प्रपत्रों को अस्वीकार कर देता है और स्वतः-सही करने का प्रयास नहीं करता है। इंटरऑपरेबिलिटी के लिए कैनोनिकल फॉर्म क्यों मायने रखता है: यदि एक सिस्टम UUID को हाइफ़नलेस हेक्स के रूप में संग्रहीत करता है और दूसरा उन्हें कैनोनिकल 8-4-4-4-12 के रूप में संग्रहीत करता है, तो समानता के लिए उनकी तुलना करने के लिए सामान्यीकरण की आवश्यकता होती है। अपरकेस बनाम लोअरकेस के लिए केस-असंवेदनशील तुलना की आवश्यकता होती है। ब्रेस्ड बनाम बेअर के लिए स्ट्रिपिंग की आवश्यकता होती है। ये विविधताएँ थोक संचालन (आयात, प्रवासन, तुलना) को कठिन बनाती हैं। मानक टूल जो विहित रूप में आउटपुट करते हैं, घर्षण को कम करते हैं। ToolAcre जेनरेटर हमेशा 36-कैरेक्टर लोअरकेस कैनोनिकल फॉर्म आउटपुट करता है; जब आप अन्य प्रणालियों से UUID आयात करते हैं, तो स्थिरता सुनिश्चित करने के लिए उन्हें अपनी ETL प्रक्रिया में इस फॉर्म में सामान्यीकृत करें।