مولّد UUID

معرفات UUID من النوع v4 تتكوّن من 122 بتاً من العشوائية القوية تشفيرياً — الخيار الافتراضي المنتشر لمفاتيح الإيديمبوتينسي ومعرّفات الجلسات وأي معرّف معتم وغير مرتَّب. أما UUID v7 فيضمّن في البايتات الأولى ختمًا زمنيًا بمقدار 48 بتاً بالميلّي ثانية لنظام يونكس، فتترتّب القيم المولّدة في أوقات متقاربة لغويًا بشكل متقارب. لذلك يناسب v7 المفاتيح الأساسية في قواعد البيانات، حيث تُجزّئ الإدخالات العشوائية فهرس B-tree.

مثال

ثلاثة UUID v4 (عشوائية، بلا ترتيب):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

ثلاثة UUID v7 مولَّدة في الميلّي ثانية نفسها (لاحظ البادئة المشتركة):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

الأخطاء الشائعة والملاحظات

هذه هي المزالق الحقيقية التي يقع فيها المطورون عند دمج UUID في تطبيق:

• استخدام v4 حيث يهمّ ترتيب الإدخال. فهرسة 10 ملايين من v4 العشوائية تسبّب انقساماً كثيفاً للصفحات في B-tree. إن بقيت على v4 فتقبّل تضخم الكتابة، أو حوّل المفتاح الأساسي إلى v7.
• إزالة الشرطات وفقدان نصف بايت الإصدار. تبقى f47ac10b58cc4372a5670e02b2c3d479 سلسلة UUID سداسية عشرية صالحة من 32 حرفاً، لكن الحرف الثالث عشر (4) هو علامة الإصدار — لا نصف بايت عشوائي. لا تفترض أن الأحرف الـ 32 كلها عشوائية.
• الاعتماد على Math.random(). المكتبات القديمة المبنية على Math.random() ليست قوية تشفيريًا وقد تكون قابلة للتنبؤ. استخدم crypto.randomUUID() (المتصفحات وNode 19+) أو مكتبة v7 تقرأ من crypto.
• التعامل مع v7 على أنه ختم زمني. أول 48 بتاً تحمل الزمن، لكن الباقي عشوائي؛ لذا اثنان من v7 في الميلّي ثانية نفسها لا يترتّبان بشكل حتمي. لا تعتمد على فكّ التعادل.
• التخزين بوصف VARCHAR(36). يعمل، لكنه يضاعف التخزين مقارنة بعمود UUID الأصلي (16 بايت) أو BINARY(16) ويبطّئ عمليات الجوين. استخدم النوع الأصلي لقاعدة البيانات (uuid في Postgres، UNIQUEIDENTIFIER في SQL Server).
• تعبير نمطي يشترط إصداراً بعينه. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i يطابق v4 فقط. إذا أصدرتَ لاحقاً v7 فسيرفض هذا التعبير بصمت معرّفات صالحة.

ما الفرق بين UUID v4 وv7؟

v4 يضم 122 بتاً من العشوائية زائد علامات الإصدار والمتغير، دون أي مكوّن زمني. أما v7 فيسبق ختماً زمنياً بمقدار 48 بتاً بالميلّي ثانية لنظام يونكس ويملأ الباقي ببتات عشوائية، فتترتّب قيم v7 المولّدة في أوقات متقاربة لغويًا بشكل متقارب. استخدم v7 مفتاحاً أساسياً في قاعدة البيانات لإبقاء إدخالات B-tree محلية؛ واستخدم v4 إن أردت إزالة أي إشارة ترتيب.

هل قد أحصل يوماً على UUID مكرّر؟

عملياً لا. يملك UUID v4 122 بتاً عشوائياً، لذا احتمال تصادم اثنين منها في دفعة من مليار نحو 10^-18. ستحتاج لتوليد ما يقارب 2.7 × 10^18 معرف v4 لبلوغ 50 % من احتمال تصادم واحد. اعتبر الوحدانية أمراً مفروغاً منه ولا تضف فحص وحدانية.

هل v4 عشوائي تشفيرياً؟

تستخدم هذه الأداة crypto.randomUUID() التي تُلزم المواصفة بسحب قيمها من PRNG قوي تشفيريًا. يكفي ذلك لمعرّفات الجلسات ومفاتيح الإيديمبوتينسي ومعظم رموز الأمان. لكنه ليس بديلاً لرمز موقَّع أو سر API طويل، ولا ينبغي اشتقاق مفاتيح تشفير من UUID.

هل UUID v7 معياري؟

نعم. عُرِّف UUID v7 في RFC 9562 (مايو 2024) الذي حلّ محلّ RFC 4122 وأضفى الطابع الرسمي على v6 وv7 وv8 إلى جانب الإصدارات الأصلية. في معظم اللغات الحديثة تنفيذات لـ v7 — وتقبل Postgres وMySQL وSQL Server قيم v7 في عمود UUID دون أي تغيير.

كيف يبدو الشكل الثنائي وهل تهمّ الترتيبية (endianness)؟

UUID هو 16 بايت. يجمعها الشكل النصي القياسي في 8-4-4-4-12 حرفاً سداسياً عشرياً. تُكتب البايتات بترتيب الشبكة (big-endian) وفق RFC 9562، لذا تبدأ 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 بالبايت 0x01. خزّنت معرّفات Microsoft GUID تاريخياً المجموعات الثلاث الأولى بترتيب little-endian في الذاكرة — انتبه عند التعامل مع تفريغات .NET الثنائية.

هل تحفظون معرّفات UUID التي تولّدها هذه الأداة؟

لا. لا نحفظ معرّفات UUID التي تولّدها هنا. كل قيمة تظهر في منطقة الإخراج وتختفي حالما تحدّث الصفحة أو تغلق التبويب — لا شيء يُخزَّن، ولا قياسات تُجمع على القيم. تحقّق بنفسك في أدوات مطوّري المتصفح.