العربية

أدوات المطور · مولد UUID

RFC 4122 مقابل RFC 9562: ما الذي تغير في 2024 UUID القياسي

· خلفية

uuid التشفير متصفح API

يعرض المخطط الزمني RFC 4122 (2005) وRFC 9562 (2024) مع تمييز ثلاثة إصدارات جديدة
الرسم التوضيحي المتجه الأصلي ToolAcre

تم الاستشهاد باثنين من RFCs لـ UUIDs ولا يقولان نفس الشيء تمامًا. تتناول هذه المشاركة ما RFC 9562 الذي تمت إضافته وتوضيحه وإهماله بالنسبة إلى RFC 4122.

ما RFC الذي أستشهد به؟ - الارتباك عندما تشير الوثائق والمكتبات إلى معايير مختلفة

يتم الاستشهاد بشكل روتيني بطلبي RFC في وثائق UUID، ولا يذكران أشياء متطابقة. RFC 4122، المنشور في 2005، حدد UUIDs وإصداراتها الخمسة (من الإصدار 1 إلى الإصدار 5). RFC 9562، تم نشره في 2024، عفا عليها الزمن RFC 4122 بالكامل، يوضح نقاط الغموض التي تعامل معها الممارسون، ويضيف ثلاثة إصدارات جديدة (الإصدار 6، الإصدار 7، الإصدار 8)، ويحدث الإرشادات حول تنفيذ العشوائية. عندما تستشهد مكتبة بـ RFC 4122، فهذا ليس خطأ - ربما تم إصدار هذه المكتبة قبل نشر RFC 9562 أو قد لا يكون لدى المشرفين وثائق محدثة. يؤدي التحقق من RFC من الاستشهادات إلى إخبارك بموعد آخر تحديث ملحوظ للمكتبة. عند كتابة مواصفات جديدة أو تقييم عمليات التنفيذ، RFC 9562 هو المرجع المعياري.

التقادم، وليس استبدال التنسيق — كل شيء صالح ضمن RFC 4122 يظل صالحًا؛ لم يتغير التصميم والبتات المتغيرة

RFC 9562 عفا عليه الزمن رسميًا RFC 4122 باعتباره المستند المرجعي الحالي مع الاحتفاظ بتمثيل 128 المألوف والمجموعات السداسية العشرية وموضع الإصدار وتخطيط المتغير الأساسي. لا يلزم إعادة إصدار سلاسل UUID المخزنة الموجودة لمجرد وجود RFC أحدث. يتم الترحيل العملي في الوثائق والمولدات وسياسة التحقق من الصحة: ​​استشهد بالمعيار الحالي، وافهم الإصدارات المضافة، وتحقق مما إذا كانت التعليمات البرمجية القديمة تعتمد على الغموض الذي أوضحته المراجعة. لا يزال يتعين اختبار التوافق عند حدود النظام، خاصة عندما تقوم المكتبة بإجراء تسلسل لهياكل Microsoft GUID أو تفرض مجموعة أضيق من الإصدارات عما يصفه المعيار.

ثلاثة إصدارات جديدة - v6 (مُعاد ترتيب الوقت)، v7 (مُرتّب حسب وقت Unix) وv8 (محدد بالتنفيذ)

RFC 9562 يضيف ثلاثة إصدارات جديدة إلى المعيار. يقوم الإصدار 6 بإعادة ترتيب بتات الطابع الزمني v1 لإنتاج معرفات قابلة للفرز معجميًا لتحسين أداء قاعدة البيانات. يستخدم الإصدار 7 طابعًا زمنيًا يبلغ 48 بت Unix بالمللي ثانية متبوعًا ببتات عشوائية، مما يوفر إنشاءًا مرتبًا بالوقت دون مخاوف خصوصية الإصدار 1. الإصدار 8 عبارة عن فتحة هروب للتخطيطات المحددة بالتنفيذ. لا يغير أي من هذه الإصدارات كيفية عمل الإصدارين v1-v5 أو ما تعنيه. يمكن أن يتواجد الإصدار 1 UUID من 2005 والإصدار 7 UUID من 2024 معًا في نفس قاعدة البيانات، حيث تحدد كل منها بتات الإصدار الخاصة بها طريقة إنشائها. تتناول الإصدارات الثلاثة الجديدة الأنماط الشائعة التي ظهرت في الممارسة العملية.

الحد الأقصى UUID ينضم إلى Nil — قيمة F الكاملة المحددة بجانب القيمة صفر بالكامل

RFC 4122 قام بتوثيق Nil UUID (جميع البتات الصفرية) كقيمة مرجعية خاصة في الأمثلة والوثائق. RFC 9562 يتضمن نفس تعريف Nil ولكنه يحدد رسميًا الحد الأقصى UUID (جميع البتات مضبوطة على واحد) لحدود النطاق. لا يعد Nil ولا Max إصدارًا 4 عشوائيًا UUID لأنهما لا يحتويان على الإصدار الصحيح والبتات المتغيرة. يعد الحد الأقصى UUID مفيدًا كحدود نطاق أعلى في استعلامات قاعدة البيانات: WHERE uuid_column <= MAX_UUID يطابق جميع UUIDs الممكنة. يعتبر Nil مفيدًا كحارس للأعمدة غير المعينة في أعمدة UUID الخالية. RFC 9562 يوثق كلاهما دون تفويض باستخدامهما في بيانات التطبيق.

إرشادات واضحة — نصيحة صريحة لاستخدام CSPRNG للحقول العشوائية، وللعدادات الرتيبة خلال ميلي ثانية واحدة، ولتفضيل الإصدارات المرتبة زمنيًا لموقع قاعدة البيانات

RFC 9562تميز إرشادات أفضل الممارسات الخاصة بـ مقاومة الاصطدام عن عدم القدرة على التخمين. يجب أن تستخدم الحقول العشوائية مصدرًا مناسبًا لنموذج التهديد الخاص بالتطبيق، كما تستدعي العتامة الحساسة للأمان CSPRNG. تواجه المولدات المستندة إلى الوقت مشكلة رتابة منفصلة عندما تشترك عدة معرفات في علامة زمنية واحدة؛ يصف المعيار العدادات ودقة الطابع الزمني الإضافية كطرق ممكنة، ولكل منها قواعد الحالة والتمرير. تظل الإصدارات المستندة إلى الاسم بمثابة معرفات حتمية، وليست أدلة على الأصالة. هذه التوضيحات مهمة لأن واحدا UUID يمكن للمحلل قبول كافة التخطيطات على الرغم من اختلاف متطلبات إنشائها وخصائص الكشف عن المعلومات.

حيث تظهر أفكار ULID — كيف أثر تنسيق المجتمع على تصميم الإصدار السابع

RFC 9562 يقول مؤلفوها إنهم قاموا بتحليل العديد من أنظمة المعرفات القابلة للفرز الموجودة، بما في ذلك ULID، وSnowflake وKSUID، أثناء تطوير التخطيطات الجديدة. وهذا يدعم استنتاجًا متواضعًا: الطلب التشغيلي على المعرفات الموزعة والمرتبة زمنيًا هو ما أدى إلى المراجعة. لا يثبت أن أحد تنسيقات المجتمع قد تبرع بتخطيط حقل دقيق للإصدار 7. التشابه العملي كافٍ لأعمال الهندسة المعمارية: تضع هذه العائلات معلومات الوقت بالقرب من المقدمة حتى يتمكن الترتيب العادي من الحفاظ على ترتيب الإنشاء الواسع، ثم يختلف في التشفير والتنسيق والسلوك داخل العلامة. اختر من بينها حسب توافق النظام البيئي والضمانات الموثقة بدلاً من المطالبة بالنسب المباشر.

ما لا يغطيه هذا هو الفرق بين سطر وآخر؛ يتبع هذا المنشور العواقب العملية للمنفذين

يتبع هذا المنشور الشامل العواقب العملية وتنفيذ RFC 9562 للمنفذين والمستخدمين، وليس الاختلافات سطرًا تلو الآخر مقابل RFC 4122. المواصفات الكاملة متاحة من هيئات المعايير وتستحق القراءة لتنفيذ معالجة UUID باللغات أو الأنظمة الأساسية - يوفر النص تفاصيل موثوقة تتجاوز ما يمكن أن تغطيه النظرة العامة. لا يصف هذا المنشور آليات مستوى البت لكيفية إعادة ترتيب v6 بايتات v1 أو كيفية تشفير v7 للميلي ثانية لنظام Unix. تظل كل من المعايير وأدلة التنفيذ هي المرجع الرسمي الأساسي لأي سؤال يتعلق بالتنفيذ فيما يتعلق بتخطيط البت أو التشفير أو التحقق من الامتثال.

الخلاصة: قم بتحديث اقتباساتك وافتراضياتك — يتبع المولد ToolAcre إرشادات CSPRNG التي يشترك فيها كلا طلبي RFC

بالنسبة لأي عمل جديد، قم بتحديث الوثائق والمواصفات للاستشهاد بـ RFC 9562. تظل كل UUID من RFC 4122 سارية بموجب RFC 9562 - تعتبر الهجرة ذات طبيعة تطلعية وإدارية بحتة. تعزز الإرشادات الموضحة بشأن عشوائية التشفير أن المعرفات يجب أن تأتي من مصادر آمنة للتشفير في أنظمة الإنتاج. يتبع ToolAcre إرشادات عشوائية التشفير من كلا RFCs، وذلك باستخدام Web Crypto الخاص بالمتصفح API حصريًا. عندما تواجه UUID من السجلات أو عمليات تصدير قاعدة البيانات أو API من الاستجابات، فإن فحص ToolAcre الجيد يُبلغ عن إصداره ومتغيره مقابل RFC 9562. RFC 9562 هو توضيح وتحديث لمعيار مستقر بالفعل.