डेवलपर टूल · UUID जनरेटर
RFC 4122 बनाम RFC 9562: 2024 UUID मानक में क्या परिवर्तन हुआ
· पेजभूमि
uuid क्रिप्टोग्राफी ब्राउज़र-एपिस
UUID के लिए दो आरएफसी का हवाला दिया गया है और वे बिल्कुल एक जैसी बात नहीं कहते हैं। यह पोस्ट RFC 9562 द्वारा RFC 4122 के संबंध में क्या जोड़ा गया, स्पष्ट किया गया और अस्वीकृत किया गया, इसके बारे में बताती है।
मैं किस RFC का हवाला दूं? - भ्रम तब होता है जब दस्तावेज़ीकरण और पुस्तकालय विभिन्न मानकों का संदर्भ देते हैं
UUID दस्तावेज़ में दो RFC को नियमित रूप से उद्धृत किया जाता है, और वे समान बातें नहीं कहते हैं। RFC 4122, 2005 में प्रकाशित, परिभाषित UUIDs और उनके पांच संस्करण (v1 से v5 तक)। RFC 9562, 2024 में प्रकाशित, RFC 4122 को पूरी तरह से अप्रचलित कर देता है, उन अस्पष्टताओं को स्पष्ट करता है जिन पर चिकित्सकों ने काम किया है, तीन नए संस्करण (v6, v7, v8) जोड़ता है, और यादृच्छिकता को लागू करने पर मार्गदर्शन अद्यतन करता है। जब कोई लाइब्रेरी RFC 4122 का हवाला देती है, तो यह गलत नहीं है - हो सकता है कि लाइब्रेरी RFC 9562 प्रकाशित होने से पहले जारी की गई हो या अनुरक्षकों के पास अद्यतन दस्तावेज़ न हों। RFC उद्धरणों की जाँच करने से आपको पता चलता है कि लाइब्रेरी को आखिरी बार महत्वपूर्ण रूप से कब अद्यतन किया गया था। नए विनिर्देश लिखते समय या कार्यान्वयन का मूल्यांकन करते समय, RFC 9562 मानक संदर्भ होता है।
अप्रचलित हो रहा है, प्रारूप को प्रतिस्थापित नहीं किया जा रहा है - RFC 4122 के अंतर्गत मान्य सभी चीजें वैध रहती हैं; लेआउट और वैरिएंट बिट्स अपरिवर्तित हैं
RFC 9562 परिचित 128-बिट प्रतिनिधित्व, हेक्साडेसिमल समूह, संस्करण स्थिति और प्रमुख संस्करण लेआउट को बरकरार रखते हुए वर्तमान संदर्भ दस्तावेज़ के रूप में RFC 4122 को औपचारिक रूप से अप्रचलित कर देता है। मौजूदा संग्रहीत UUID स्ट्रिंग्स को केवल इसलिए पुनः जारी करने की आवश्यकता नहीं है क्योंकि एक नया RFC मौजूद है। व्यावहारिक माइग्रेशन दस्तावेज़ीकरण, जनरेटर और सत्यापन नीति में है: वर्तमान मानक का हवाला दें, जोड़े गए संस्करणों को समझें, और जांचें कि क्या पुराना कोड संशोधन द्वारा स्पष्ट की गई अस्पष्टता पर निर्भर था। संगतता का अभी भी सिस्टम सीमाओं पर परीक्षण किया जाना चाहिए, विशेष रूप से जहां लाइब्रेरी Microsoft GUID संरचनाओं को क्रमबद्ध करती है या मानक वर्णन की तुलना में संस्करणों के एक संकीर्ण सेट को लागू करती है।
तीन नए संस्करण - v6 (पुन: व्यवस्थित समय), v7 (Unix-युग समय-क्रमबद्ध) और v8 (कार्यान्वयन-परिभाषित)
RFC 9562 मानक में तीन नए संस्करण जोड़ता है। संस्करण 6 बेहतर डेटाबेस प्रदर्शन के लिए लेक्सिकोग्राफ़िक रूप से क्रमबद्ध पहचानकर्ताओं का उत्पादन करने के लिए v1 टाइमस्टैम्प बिट्स को पुन: व्यवस्थित करता है। संस्करण 7 एक 48-बिट Unix मिलीसेकंड टाइमस्टैम्प का उपयोग करता है जिसके बाद यादृच्छिक बिट्स होते हैं, जो v1 की गोपनीयता चिंताओं के बिना समय-क्रमबद्ध पीढ़ी प्रदान करता है। संस्करण 8 कार्यान्वयन-परिभाषित लेआउट के लिए एक एस्केप हैच है। इनमें से कोई भी संस्करण यह नहीं बदलता कि v1-v5 कैसे काम करता है या उनका क्या मतलब है। 2005 से एक v1 UUID और 2024 से एक v7 UUID एक ही डेटाबेस में सह-अस्तित्व में रह सकते हैं, प्रत्येक अपने संस्करण बिट्स के साथ अपनी पीढ़ी विधि की पहचान कर सकता है। तीन नए संस्करण व्यवहार में उभरे सामान्य पैटर्न को संबोधित करते हैं।
अधिकतम UUID शून्य से जुड़ता है - ऑल-जीरो के साथ परिभाषित ऑल-एफ मान
RFC 4122 ने उदाहरणों और दस्तावेज़ीकरण में एक विशेष संदर्भ मान के रूप में शून्य UUID (सभी शून्य बिट्स) का दस्तावेजीकरण किया। RFC 9562 में समान शून्य परिभाषा शामिल है लेकिन औपचारिक रूप से सीमा सीमाओं के लिए अधिकतम UUID (सभी बिट्स एक पर सेट) को परिभाषित करता है। न तो Nil और न ही Max कोई संस्करण 4 यादृच्छिक UUID है क्योंकि उनके पास सही संस्करण और वैरिएंट बिट्स नहीं हैं। अधिकतम UUID डेटाबेस प्रश्नों में ऊपरी सीमा सीमा के रूप में उपयोगी है: WHERE uuid_column <= MAX_UUID सभी संभावित UUID से मेल खाता है। शून्य अशक्त UUID कॉलमों में शून्य के लिए एक प्रहरी के रूप में उपयोगी है। RFC 9562 दोनों दस्तावेज़ एप्लिकेशन डेटा में उनके उपयोग को अनिवार्य किए बिना।
स्पष्ट मार्गदर्शन - यादृच्छिक फ़ील्ड के लिए CSPRNG का उपयोग करने की स्पष्ट सलाह, एक मिलीसेकंड के भीतर मोनोटोनिक काउंटरों पर, और डेटाबेस इलाके के लिए समय-आदेशित संस्करणों को प्राथमिकता देने पर
RFC 9562 का सर्वोत्तम अभ्यास मार्गदर्शन टकराव प्रतिरोध को अकल्पनीयता से अलग करता है। रैंडम फ़ील्ड को एप्लिकेशन के ख़तरे मॉडल के लिए उपयुक्त स्रोत का उपयोग करना चाहिए, और सुरक्षा-संवेदनशील अपारदर्शिता के लिए CSPRNG का उपयोग करना चाहिए। जब कई पहचानकर्ता एक टाइमस्टैम्प टिक साझा करते हैं तो समय-आधारित जनरेटर में एक अलग एकरसता की समस्या होती है; मानक संभावित तरीकों के रूप में काउंटरों और अतिरिक्त टाइमस्टैम्प परिशुद्धता का वर्णन करता है, प्रत्येक राज्य और रोलओवर नियमों के साथ। नाम-आधारित संस्करण नियतिवादी पहचानकर्ता बने रहते हैं, प्रामाणिकता के प्रमाण नहीं। ये स्पष्टीकरण मायने रखते हैं क्योंकि एक UUID पार्सर सभी लेआउट को स्वीकार कर सकता है, भले ही उनकी पीढ़ी की आवश्यकताएं और सूचना-प्रकटीकरण गुण भिन्न हों।
जहां ULID के विचार दिखाई देते हैं - समुदाय प्रारूप ने v7 के डिज़ाइन को कैसे प्रभावित किया
RFC 9562 का कहना है कि इसके लेखकों ने नए लेआउट विकसित करते समय ULID, स्नोफ्लेक और KSUID सहित कई मौजूदा क्रमबद्ध पहचानकर्ता योजनाओं का विश्लेषण किया। यह एक मामूली निष्कर्ष का समर्थन करता है: समय-आदेशित, वितरित पहचानकर्ताओं के लिए परिचालन मांग ने संशोधन की जानकारी दी। यह साबित नहीं होता है कि एक समुदाय प्रारूप ने संस्करण 7 को एक सटीक फ़ील्ड लेआउट दान किया है। वास्तुकला कार्य के लिए व्यावहारिक समानता पर्याप्त है: ये परिवार समय की जानकारी को सामने रखते हैं ताकि सामान्य क्रम व्यापक निर्माण क्रम को संरक्षित कर सके, फिर एन्कोडिंग, समन्वय और भीतर-टिक व्यवहार में भिन्न होता है। प्रत्यक्ष वंशावली के दावे के बजाय पारिस्थितिकी तंत्र अनुकूलता और दस्तावेजी गारंटी के आधार पर उनमें से चुनें।
इसमें क्या शामिल नहीं है - पंक्ति-दर-पंक्ति अंतर; यह पोस्ट कार्यान्वयनकर्ताओं के लिए व्यावहारिक परिणामों का अनुसरण करती है
यह व्यापक पोस्ट कार्यान्वयनकर्ताओं और उपयोगकर्ताओं के लिए RFC 9562 के व्यावहारिक परिणामों और कार्यान्वयन का अनुसरण करता है, न कि पंक्ति-दर-पंक्ति RFC 4122 से भिन्न है। पूर्ण विनिर्देश मानक निकायों से उपलब्ध हैं और भाषाओं या प्लेटफार्मों में UUID हैंडलिंग को लागू करने के लिए पढ़ने लायक हैं - पाठ एक सिंहावलोकन से परे आधिकारिक विवरण प्रदान करता है। यह पोस्ट बिट-स्तरीय यांत्रिकी का वर्णन नहीं करती है कि कैसे v6, v1 बाइट्स को पुन: व्यवस्थित करता है या कैसे v7 Unix मिलीसेकंड को एनकोड करता है। बिट लेआउट, एन्कोडिंग, या अनुपालन सत्यापन के संबंध में किसी भी कार्यान्वयन प्रश्न के लिए मानक और कार्यान्वयन गाइड दोनों प्राथमिक आधिकारिक संदर्भ बने हुए हैं।
टेकअवे: अपने उद्धरण और अपने डिफ़ॉल्ट अपडेट करें - ToolAcre जनरेटर CSPRNG मार्गदर्शन का पालन करता है जो दोनों आरएफसी साझा करते हैं
किसी भी नए कार्य के लिए, RFC 9562 का हवाला देते हुए दस्तावेज़ और विशिष्टताओं को अद्यतन करें। RFC 4122 से प्रत्येक UUID RFC 9562 के अंतर्गत वैध रहता है—प्रवास पूरी तरह से दूरदर्शी और प्रशासनिक प्रकृति का है। क्रिप्टोग्राफ़िक यादृच्छिकता पर स्पष्ट मार्गदर्शन इस बात को पुष्ट करता है कि पहचानकर्ताओं को उत्पादन प्रणालियों में क्रिप्टोग्राफ़िक रूप से सुरक्षित स्रोतों से आना चाहिए। ToolAcre विशेष रूप से ब्राउज़र के Web Crypto API का उपयोग करते हुए, दोनों RFC से क्रिप्टोग्राफ़िक यादृच्छिकता मार्गदर्शन का पालन करता है। जब आप लॉग, डेटाबेस निर्यात, या API प्रतिक्रियाओं से UUID का सामना करते हैं, तो ToolAcre अच्छी तरह से गठित चेक RFC 9562 के विरुद्ध इसके संस्करण और संस्करण की रिपोर्ट करता है। RFC 9562 पहले से ही स्थिर मानक का स्पष्टीकरण और आधुनिकीकरण है।