مولد UUID
كل الإصدارات دفعة واحدة مع فاحص

ماذا يفعل مولد UUID هذا

يصنع مولد UUID هذا معرفات فريدة لقواعد البيانات وواجهات البرمجة والملفات والاختبارات. أولًا اختر الإصدار والعدد، ثم تظهر القائمة فورًا. بعد ذلك يمكنك نسخها أو حفظها ملفًا نصيًا.

يغطي كل الإصدارات المستخدمة اليوم. فالإصدار 4 عشوائي تمامًا، والإصدار 7 يترتب حسب الوقت، والإصداران 3 و5 يحولان الاسم إلى المعرف نفسه دائمًا. كما توجد الإصداران القديمان 1 و6، والقيمتان الخاصتان nil وmax.

تعمل الصفحة بالعكس أيضًا. الصق أي UUID ثم يخبرك الفاحص بإصداره ونوعه، وفي المعرفات الزمنية باللحظة الدقيقة لإنشائها.

ما هو UUID؟

UUID أي المعرف الفريد العالمي هو رقم من 128 بت. ويُكتب غالبًا بـ32 خانة ست عشرية في خمس مجموعات، مثل 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. ولأن القيم الممكنة كثيرة جدًا، يستطيع أي شخص إنشاء معرف دون سؤال خادم مركزي، ولن يتطابق مع معرف أحد آخر.

جزءان صغيران يخبرانك بنوع المعرف. فالخانة الأولى من المجموعة الثالثة هي الإصدار، والخانة الأولى من المجموعة الرابعة تحمل النوع. أما الباقي فهو وقت أو عشوائية أو بصمة، حسب الإصدار.

أي إصدار من UUID تستخدم؟

لمعظم المهام استخدم الإصدار 4، لأنه عشوائي وبسيط ومدعوم في كل مكان. لكن إذا صارت المعرفات مفاتيح في جدول بيانات، فاختر الإصدار 7 بدلًا منه. فهو يبدأ بالوقت، لذلك تُخزن الصفوف الجديدة بالترتيب وتبقى الإضافة سريعة.

حين يجب أن يأخذ الشيء نفسه المعرف نفسه دائمًا، استخدم الإصدار 5. فمثلًا يمكن تحويل رابط أو بريد إلكتروني إلى UUID ثابت يعيد أي نظام إنشاءه. أما الإصدارات 1 و3 و6 فهي غالبًا للأنظمة القديمة.

لماذا UUID الإصدار 7 أفضل لقواعد البيانات

تتوزع معرفات الإصدار 4 العشوائية في كل أنحاء الفهرس، لذلك تلمس كل إضافة صفحة مختلفة. ومع الوقت يبطئ ذلك الكتابة ويهدر الذاكرة. أما UUID الإصدار 7 فيبدأ بطابع زمني بالملي ثانية، لذا يقع كل معرف جديد في آخر الفهرس، تمامًا مثل الرقم التسلسلي.

كما يحافظ هذا المولد على ترتيب الدفعة. فحين تتشارك معرفات كثيرة الملي ثانية نفسها، يرتبها عداد في البتات الاثنتي عشرة التالية، كما يوصي معيار RFC 9562 الخاص بالمعرفات.

معرفات مبنية على الاسم: الإصداران 3 و5

تُصنع المعرفات المبنية على الاسم من مدخلين: مساحة أسماء، وهي نفسها UUID، واسم. ثم يُحسب للزوج بصمة، لذلك تعطي المدخلات نفسها النتيجة نفسها دائمًا. وتوجد مساحات قياسية للنطاقات والروابط وOID وأسماء X.500، كما يمكنك استخدام مساحتك الخاصة.

الإصدار 5 يستخدم SHA-1 والإصدار 3 يستخدم MD5. ولا واحد من هذين التلبيدين يحمي شيئًا هنا. كلاهما ينشر البتات بالتساوي فقط. لذلك اختر الإصدار 5 لأي عمل جديد، لأن المعيار يفضله.

اقرأ أي UUID بالفاحص

الصق معرّف UUID في المدقق فينفصل فورًا. ترى الشكل القياسي والنمط ورقم الإصدار. كما تحمل الإصدارات 1 و6 و7 طابعًا زمنيًا. ثم يعرض المدقق تلك اللحظة بتوقيت UTC وبتوقيت منطقتك.

وفي الإصدارين 1 و6 يعرض أيضًا تسلسل الساعة والعقدة. وكانت العقدة قديمًا عنوان بطاقة الشبكة، لذلك يخبرك الفاحص إن كانت تبدو حقيقية أو عشوائية. كما يكفي النقر على أي معرف في القائمة لفحصه.

تحقق من قائمة كاملة باستخدام مدقق UUID

معرّف واحد في كل مرة يكفي، إلى أن يصبح لديك أربعمائة. لذا الصق القائمة كلها في مدقق UUID فيحصل كل سطر على حكمه. وتفصل الصفحة عند المسافات والفواصل والفواصل المنقوطة والشرطات الرأسية وأسطر جديدة. لذا يلتصق عمود جدول وقائمة JSON ونتيجة SQL كما هي. وتقرأ الصفحة حتى 5000 معرّف في مرة واحدة. ثم يظهر كل ما يزيد على ذلك العدد كمتجاوز بدل أن يسقط بصمت.

وبالأخص، هناك ثلاثة أحكام هنا، لا حكمان. يُحسب السطر صحيحًا عندما يصفه المعيار. ويُحسب غير صحيح عندما لا يكون معرّف UUID أصلًا. وبين الحالتين تقع الملاحظة، لسطر شكله صحيح ومع ذلك يستحق نظرة. مثلًا، النمط القديم من مايكروسوفت أو NCS معرّف حقيقي ما زالت أنظمة حقيقية تصدره. وهذان النمطان يأتيان من RFC 4122، معيار UUID الأقدم. ثم يأتي نمط RFC الذي يحمل رقم إصدار لم يخصصه أحد بعد، وهو ينال ملاحظة كذلك. ووصف أي من هذه بغير الصحيح يكون كذبًا، لأن أنظمة عاملة توزعها كل يوم.

كما يذكر كل سطر مرفوض سببه. والسطر في القائمة قد يتعذر قراءته بثلاث طرق فقط. فهو يحمل حرفًا خارج 0-9 و a-f والشرطة. أو فيه عدد خاطئ من الأرقام الست عشرية. أو فيه 32 رقمًا كاملة والشرطات في أماكن خاطئة. والحالتان الأولى والثانية تعنيان عادة نسخة لقطت حرفًا غريبًا، أو قصّت رقمًا في منتصف اللصق. والثالثة معرّف UUID تقع شرطاته في غير موضعها بعد الرقم الثامن والثاني عشر والسادس عشر والعشرين. والسطر يقول ذلك بالضبط. أما الأسطر الفارغة فليست أخطاء، لأن القائمة تستبعدها قبل بدء العد.

يُزال الغلاف قبل الفحص، لأن القوائم الحقيقية تأتي مغلفة. فتنزع الصفحة علامات التنصيص والعلامات الخلفية والأقواس المربعة وأقواس الزوايا والأقواس المستديرة والنقطتين أو النقطة في النهاية. وتنزع كذلك البادئة urn:uuid:. أما الأقواس المعقوفة فتنال عناية أكبر. لذا يُقرأ معرّف GUID من مايكروسوفت بين معقوفتين كاملًا، بينما يذهب قوس شارد من كائن JSON ببساطة. كما تُقرأ سلسلة مجردة من 32 رقمًا ست عشريًا بلا شرطات. وكذلك أي خلط بين الأحرف الكبيرة والصغيرة. والكلمة التي لم تكن معرّفًا أصلًا، مثل مفتاح JSON، تحتفظ بسطرها بدل أن تختفي. وبذلك يبقى العدد صادقًا عن كل ما في اللصق.

ثم يبحث المدقق عن المكرر في القائمة كلها. وتجري المقارنة على الشكل المعياري. لذا تُحسب {X} و urn:uuid:X والمعرّف نفسه بأحرف كبيرة واحدًا. ثم يشير السطر المكرر إلى السطر الذي ظهر فيه أولًا. أما سطران متطابقان من نفايات فلا يُحسبان مكررين أبدًا. فالسطر الذي ليس معرّف UUID لا شكل معياري له للمقارنة. وبعد ذلك يعدّ الملخص القائمة عنك. فترى كم سطرًا مرّ، وكم سطرًا يصفه المعيار. وثلاثة أعداد أخرى تغطي الأسطر التي تستحق نظرة والأسطر التي ليست معرّفات أصلًا والمكرر.

تبقى هذه الأعداد منفصلة عن قصد، والسبب مهم. فالسطر ذو الملاحظة شكله صحيح لا معطوب. وضمّه إلى رقم واحد ناجح أو فاشل يخفي الشيء الوحيد الجدير بالانتباه فيه. لكن إذا أردت المشاكل وحدها، فالمرشّح يترك الأسطر التي ليست معرّفات ظاهرة. لذا تحفظ الأسطر ذات الملاحظة مكانها وسببها. وأخيرًا ينسخ التقرير ما تعرضه الشاشة، فتذهب القائمة مباشرة إلى تذكرة عمل.

UUID أم GUID؟

هما الشيء نفسه. فـGUID أي المعرف الفريد الشامل هو الاسم الذي تستخدمه مايكروسوفت فقط. لذلك تعمل هذه الصفحة مولدًا لـGUID أيضًا: فعّل الأحرف الكبيرة والأقواس المعقوفة لتحصل على نمط {XXXXXXXX-XXXX-...} الذي يعرضه ويندوز و.NET غالبًا.

استخدمت معرفات GUID القديمة جدًا من COM نوعًا مختلفًا. ويكتشفها الفاحص ويشير إليها، وبهذا تعرف متى جاء المعرف من ذلك النظام القديم.

ما مدى تفرد UUID؟

من بين 128 بتًا في معرّف v4، هناك 122 بتًا عشوائيًا. لذا تحتاج إلى نحو 2.7 كوينتيليون معرّف قبل أن تصل فرصة التكرار إلى 50%. وعمليًا، يبقى خطأ في برنامجك أنت أرجح كثيرًا من تكرار.

تستخدم الإصدارات الزمنية بتات عشوائية أقل، لكنها تضيف الوقت. وبالتالي لا يتصادم معرفان إلا إذا نشآ في الملي ثانية نفسها وسحبا أيضًا البتات العشوائية نفسها. ويشرح مقال ويكيبيديا عن UUID هذه الأرقام بالتفصيل.

UUID أم الأرقام التسلسلية؟

الأرقام التسلسلية قصيرة وسريعة، لكن لها حدود. أولًا لا يمنحها إلا قاعدة البيانات، لذلك ينتظر التطبيق الإضافة ليعرف المعرف. ثم إنها تكشف معلومات، لأن الطلب رقم 1043 يخبر أي شخص أن لديك نحو ألف طلب.

تحل معرفات UUID المشكلتين. فأي خادم أو هاتف أو متصفح يستطيع إنشاء معرف دون اتصال، وتندمج معرفات الأنظمة المختلفة دون تصادم. لكنها تشغل مساحة أكبر، لهذا يهم الإصدار 7 والتخزين الثنائي في الجداول الكبيرة.

معرفات UUID في شفرتك

تغطي خيارات الصيغة الاحتياجات الشائعة. احذف الشرطات لتخزين أصغر، أو أضف البادئة urn:uuid: لملفات XML وRDF، أو ضع كل معرف بين علامتي تنصيص مع فواصل، وبهذا يصبح جاهزًا لمصفوفة أو قائمة SQL.

لمعظم قواعد البيانات نوع خاص لمعرفات UUID. ففي PostgreSQL النوع uuid، وفي SQL Server النوع uniqueidentifier، وفي MySQL يُختار غالبًا BINARY(16). كما يحول محول الطوابع الزمنية Unix الطوابع في بياناتك إلى تواريخ والعكس.

هل هذه المعرفات آمنة؟

نعم. تأتي البتات العشوائية من المصدر الآمن في متصفحك، وهو دالة getRandomValues في Web Crypto المصممة للمفاتيح والرموز. كما لا يُرسل شيء إلى خادمنا، لذلك لا يرى أحد غيرك المعرفات التي تنشئها.

تذكر أن UUID معرف وليس سرًا، لأن أي شخص يراه يستطيع نسخه. أما لكلمات المرور ومفاتيح API فاستخدم مولد كلمات المرور بدلًا منه.