مولد UUID

مولد UUID هو اداة تنشئ معرفات فريدة عالميا، وهي قيم من 128 بت تستخدم لوسم البيانات من دون سجل مركزي. يبنى كل معرف بحيث تكون احتمالات ان تنتج منظومتان القيمة نفسها قريبة جدا من الصفر. ويعتمد المطورون عليه عندما يجب ان يكون المعرف فريدا عبر عدة خوادم او قواعد بيانات او تطبيقات تعمل بشكل مستقل.

وعلى خلاف المعرفات التسلسلية، لا يعتمد UUID على عداد قاعدة بيانات ولا على تنسيق بين الخدمات. وهذا يجعل توليد UUID مثاليا للخدمات المصغرة، والتطبيقات التي تعمل اولا دون اتصال، واي نظام تنشئ فيه عدة عقد سجلات في الوقت نفسه. UUID موحد ضمن RFC 4122، لذلك تنتج الادوات والمكتبات في اللغات المختلفة قيما متوافقة.

لا يحتاج توليد UUID باستخدام هذا المولد عبر الويب سوى بضع نقرات، وكل العملية تتم داخل متصفحك. اختر الاصدار من المحدد: v1 او v3 او v4 او v5 او v7 او Nil او ULID. ادخل العدد الذي تحتاجه، من 1 حتى 1000 في الدفعة. اضغط توليد، وستظهر المعرفات فورا لتكون جاهزة للنسخ.

تنطبق خيارات التنسيق على كل الاصدارات: التبديل بين الاحرف الكبيرة او الصغيرة، والشرطات او بدونها، والاقواس المعقوفة اذا كان نظامك يتوقعها. يمكنك نسخ نتيجة واحدة، او نسخ كامل الدفعة، او تنزيلها كملف `.txt` او `.json` او `.csv`. لا حاجة الى تسجيل او تثبيت او اعداد قبل البدء.

توليد UUID معتمد على namespace (v3 وv5)

يحتاج الاصداران 3 و5 الى namespace واسم بدلا من العشوائية الخالصة، لانهما صمما ليكونا حتميين. اختر namespace قياسيا من RFC 4122 مثل DNS او URL او OID او X.500، او قدم UUID namespace مخصصا. ادخل اسما، وستقوم الاداة بدمج القيمتين باستخدام MD5 للاصدار 3 او SHA-1 للاصدار 5. وسيؤدي الاسم وnamespace نفسيهما دائما الى UUID نفسه، وهذا هو الهدف. يمكن للانظمة المستقلة توليد معرفات متطابقة للمدخل نفسه من دون اي تنسيق مباشر.

فك UUID او ULID موجود

الصق اي UUID او ULID في لوحة الفك ضمن مولد UUID هذا لفحصه من دون توليد قيمة جديدة. تحدد الاداة الاصدار والمتغير فورا. وبالنسبة الى قيم v1 وv7 وULID، تقوم ايضا بفك الطابع الزمني المضمن الى تاريخ ووقت مقروءين.

وهذا مفيد للتحقق من وقت انشاء سجل ما، او لتاكيد ان واجهة API من جهة خارجية اعادت معرفا صالحا. كما يساعد على معرفة الاصدار الحقيقي لUUID غير المألوف.

UUID اختصار لعبارة Universally Unique Identifier، وتحدد المواصفة عدة اصدارات يبنى كل منها بطريقة مختلفة. رقم الاصدار مضمن داخل المعرف نفسه، ولذلك يكشف اي UUID عن طريقة توليده. ويدعم هذا المولد كل الاصدارات الرئيسية، مع جعل v4 الخيار الافتراضي للاستخدام العام.

وعلى خلاف المعرفات التسلسلية، لا يعتمد UUID على عداد قاعدة بيانات ولا على تنسيق بين الخدمات. وهذا يجعل توليد UUID مثاليا للخدمات المصغرة، والتطبيقات التي تعمل اولا دون اتصال، واي نظام تنشئ فيه عدة عقد سجلات في الوقت نفسه. UUID موحد ضمن RFC 4122، لذلك تنتج الادوات والمكتبات في اللغات المختلفة قيما متوافقة.

UUID من الاصدار الاول يجمع بين الطابع الزمني وعنوان MAC للجهاز الذي يولده. ويمكن لهذه الطريقة ان تكشف معلومات عن العتاد، ولذلك اصبحت اقل استخداما اليوم. اما UUID من الاصدار الرابع فيستخدم ارقاما عشوائية او شبه عشوائية، ما يتجنب هذه المساومة تماما. وتولد UUID من الاصدار الخامس قيمة حتمية من namespace واسم باستخدام SHA-1، بطريقة تشبه مخرجات <hashLink>مولد الهاش</hashLink>.

UUID من الاصدار الرابع يحتوي على 122 بت عشوائيا، لان عددا قليلا من البتات يثبت لتحديد الاصدار والمتغير. وهذا يترك عددا هائلا من التركيبات الممكنة، يقارب 5.3 انديسيليون. واحتمال ان يتصادم UUID عشوائيان صغير جدا لدرجة انه يعد عمليا صفرا.

لا توجد جهة مركزية تتعقب UUID التي تم اصدارها من قبل. وهذا غير ضروري لكي تنجح الرياضيات. حتى لو تم توليد مليار UUID كل ثانية لمدة مئة عام فلن يستخدم ذلك الا جزءا ضئيلا جدا من القيم الممكنة. اما الاصدارات الحتمية مثل v3 وv5 فتعمل بشكل مختلف، لان الاسم وnamespace نفسيهما مقصود بهما ان يعيدا النتيجة نفسها.

داخل الدفعة الواحدة، يتم التحقق تلقائيا من القيم v1 وv4 وv7 مقابل بعضها. ويعاد توليد القيم المكررة قبل عرض النتائج، لذلك لن ترى تكرارا غير مقصود. اما دفعات الاصدارين 3 و5 فتتجاوز هذه الخطوة عن قصد، لان الاسم وnamespace نفسيهما يجب ان يتكررا. كما تتكرر دفعات UUID Nil ايضا، لان UUID Nil لا يملك سوى قيمة واحدة: كلها اصفار.

وتستخدم دفعات ULID حماية مختلفة. فكل قيمة تجمع بين طابع زمني بالمللي ثانية ومكوّن عشوائي رتيب. وهذا يبقي التصادمات غير مرجحة حتى داخل الدفعة نفسها.

هذا النوع من الادوات اساسي حيث تحتاج الانظمة المستقلة الى انشاء معرفات من دون الرجوع الى بعضها اولا. مفاتيح قواعد البيانات الرئيسية هي من اكثر حالات الاستخدام شيوعا، خاصة في قواعد البيانات الموزعة او المجزأة. وتناسب الاصدارات القابلة للترتيب مثل v7 وULID قواعد البيانات التي تحتاج ايضا الى ترتيب زمني، لان UUID العشوائي القياسي لا يقدم ذلك.

تعتمد رموز جلسات API ورموز المصادقة كذلك على UUID بسبب صعوبة توقعها، على نحو مشابه للسلاسل العشوائية من <passwordLink>مولد كلمات المرور</passwordLink>.

تستخدم الخدمات المصغرة UUID لوضع علامات على الاحداث والرسائل والمعاملات حتى يمكن تتبعها عبر الخدمات المستقلة. وغالبا ما تستخدم رموز المصادقة مثل JWT قيمة UUID كحقل jti، ويمكن لـ <jwtLink>مفكك ومرمز JWT</jwtLink> فحص هذا الحقل مباشرة. كما تستخدم انظمة الملفات وتخزين الكائنات UUID لتسمية الملفات المرفوعة من دون خطر تصادم الاسماء. وتستخدم مجموعات الاختبار هذه الاداة لانشاء بيانات وهمية واقعية وغير متكررة لبيئات QA.

UUID وGUID يشيران الى الفكرة نفسها: معرف من 128 بت صمم ليكون فريدا من دون تنسيق مركزي. GUID تعني Globally Unique Identifier وهو المصطلح الذي تستخدمه Microsoft في Windows و.NET وSQL Server. اما UUID فهو المصطلح المستخدم في مواصفة RFC 4122 الرسمية وفي معظم المنصات الاخرى.

عمليا يمكن استخدام التنسيقين بالتبادل، وكلاهما يتبع البنية نفسها. فـ GUID الذي يولد على نظام Windows سيتحقق منه كـ UUID في اي مكان اخر. الاختلاف الحقيقي الوحيد هو في التسمية لا في الخوارزمية او بنية البيانات.

يظهر UUID على شكل 32 حرفا سداسيا عشرية موزعة على خمس مجموعات تفصل بينها شرطات. ويتبع النمط بنية 8-4-4-4-12 مثل 550e8400-e29b-41d4-a716-446655440000. ويخصص حرفان من هذه الاحرف لترميز اصدار UUID والمتغير الخاص به.

يوضع رقم الاصدار في بداية المجموعة الثالثة. وUUID الذي يحتوي على الرقم 4 في هذا الموضع يكون من الاصدار الرابع. اما بتات المتغير فتقع في بداية المجموعة الرابعة، وتؤكد ان المعرف يتبع تخطيط RFC 4122. ويبدو ULID مختلفا: فهو 26 حرفا بترميز Crockford Base32، بلا شرطات وبلا رقم اصدار ظاهر.

كل UUID ينتجه هذا المولد يتم انشاؤه مباشرة داخل متصفحك باستخدام مصدر عشوائي امن تشفيريا. لا يتم ابدا ارسال اي UUID او اي بيانات مرتبطة بجلسة الاستخدام الى خادم. وهذا يجعل الاداة مناسبة للمعرفات الداخلية او الحساسة او القريبة من بيئة الانتاج.

ولان التوليد يتم على جانب العميل، فان تحديث الصفحة او اغلاقها لا يترك اي سجل لما تم انشاؤه. لا توجد حسابات او تتبع او تخزين مرتبط بالـ UUID التي تولدها. ويمكنك توليد دفعات اضافية كلما احتجت، من نفس علامة التبويب.

ولمسارات العمل التي تحتاج ايضا الى سلامة الرسائل، يقدم <hmacLink>مولد HMAC</hmacLink> وسيلة مكملة للتحقق من عدم العبث بالبيانات.

توضح الامثلة التالية كيف يتم استخدام المخرجات نفسها من المولد في سيناريوهات واقعية مختلفة. كل مثال يبدأ بـ UUID انتجته هذه الاداة ويبين مكان استخدامه داخل نظام فعلي. مراجعة بعض الحالات الملموسة تسهل فهم سلوك UUID بعد خروجه من المولد.

كل سيناريو في الاعلى يستخدم صيغة المخرجات نفسها تماما، لذلك لا حاجة الى تحويل او اعادة تنسيق بين حالات الاستخدام. سواء انتهى المعرف في عمود قاعدة بيانات او عنوان URL او اسم ملف، فانه يعمل من دون تعديل.

هذا الاتساق هو السبب الذي يدفع الفرق الى توحيد استخدام UUID عبر كامل المنظومة، وغالبا الى جانب ادوات مثل <base64Link>مرمز Base64</base64Link>.