مولّد UUID

UUID اختصار لـ Universally Unique Identifier— معرّف بطول 128 بِت يُضمن أنه فريد كونياً بحيث يمكن لخوادم منفصلة في أركان مختلفة من العالم توليده دون تنسيق مسبق ودون أن يتطابق مع غيره. تستخدمه قواعد البيانات، أنظمة الملفات، رؤوس HTTP، وكل API يحتاج معرّفاً لا يتطلّب "مكان مركزي" لتوزيع الأرقام.

الصيغة القياسية: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx — 32 رمز hex مُقسَّمة 8-4-4-4-12. الموضع M يحدّد الإصدار، والموضع N يحدّد النوع (variant) وفق RFC 4122 و RFC 9562.

GUID (Globally Unique Identifier) المستخدم في عالم Microsoft هو نفس UUID تماماً، مع اختلاف بسيط في ترتيب البايتات في بعض السياقات القديمة. عملياً يمكنك معاملتهما كمرادفين.

UUID يتكوّن من 128 بِت = 16 بايت = 32 رمز hex. هذه البِتّات موزّعة على حقول حسب الإصدار، لكن الموضعَين الثابتَين في كل إصدارات RFC 4122/9562 هما:

• Version (4 بِت): العدد 1 إلى 8 في الرمز رقم 13.
• Variant (2 بِت): أول بِتَّين في الرمز رقم 17، يساوي 10 ثنائي للنسخات الحديثة.

باقي 122 بِت تختلف وظيفتها حسب الإصدار: ختم زمني، عشوائي، تجزئة لمدخل، أو دمج بين الثلاثة. هذه المرونة هي التي جعلت UUID قابلاً للتطوّر من v1 (1980s) إلى v7 (2024).

المعيار يعرّف ثمانية إصدارات، أبرزها:

• v1: ختم زمني (100ns منذ 1582-10-15) + معرّف عقدة (MAC أو عشوائي).
• v2: "DCE Security" — مهجور تقريباً، لا يستخدمه أحد.
• v3: هاش MD5 لاسم + namespace. حتمي (نفس المدخل يعطي نفس UUID).
• v4: عشوائي كامل (122 بِت). الأكثر استخداماً عالمياً.
• v5: هاش SHA-1 لاسم + namespace. مثل v3 لكن بهاش أقوى.
• v6: v1 معاد ترتيبه ليكون قابلاً للفرز زمنياً.
• v7: ختم زمني Unix بالميلي ثانية + 74 بِت عشوائي. المعيار الموصى به للمشاريع الجديدة في 2026.

في الواقع العملي تختار بين ثلاثة فقط: v1 (تراث)، v4 (افتراضي عشوائي)، أو v7 (مفاتيح أساسية في قواعد البيانات الحديثة).

v1 يجمع ثلاثة عناصر:

1. الوقت (60 بِت): عدد فترات 100 نانوثانية منذ 1582-10-15 (تقويم Gregorian).
2. Clock sequence (14 بِت): عدّاد يتغيّر عند رجوع الساعة للوراء.
3. Node ID (48 بِت): عنوان MAC أصلاً، أو قيمة عشوائية مع تفعيل multicast bit في الأنظمة الحديثة.

المزايا: مرتّب زمنياً (تقريباً) فمفيد للفهارس في قواعد البيانات. العيوب: قد يكشف متى وُلِّد وعلى أي جهاز. لذلك أغلب المكتبات الحديثة تستبدل MAC بقيمة عشوائية حفاظاً على الخصوصية، لكن في هذه الحالة يفقد جزءاً من فائدته.

v4 هو الإصدار الأكثر استخداماً اليوم. 122 بِت عشوائية كاملة (بعد طرح 4 بِت للإصدار و 2 للنوع). يُولَّد بـ crypto.getRandomValues في المتصفّح أو /dev/urandom على الخادم.

المزايا: بسيط، لا يكشف وقت أو هوية، يمكن توليده بدون أيّ حالة (stateless). العيوب: عشوائي بالكامل — لا يمكن فرزه زمنياً، وعند استخدامه مفتاحاً أساسياً في قاعدة بيانات ينتج تشظّياً في الفهرس (B-Tree fragmentation) لأن كل إدراج يقع في موضع عشوائي.

هذا العيب هو الذي دفع إلى ابتكار v7 — ليجمع عشوائية v4 مع ترتيب v1 الزمني.

v7 معتمَد رسمياً مايو 2024. بنيته:

• 48 بِت: ختم زمني Unix بالميلي ثانية (يكفي حتى عام 10889).
• 4 بِت: رقم الإصدار (0111 = 7).
• 12 بِت: عشوائي (يمكن استخدامها sub-millisecond counter).
• 2 بِت: Variant.
• 62 بِت: عشوائي.

النتيجة: UUID يبدأ ببِتّات الزمن (يمكن فرزه نصياً)، لكنه يحتوي 74 بِت عشوائياً ممّا يحفظ خصوصية المُولِّد ويمنع التخمين. هذا التوازن جعله الخيار الأمثل لمفاتيح PostgreSQL و MySQL الحديثة.

للإصدار v4: حساب "مفارقة عيد الميلاد" (Birthday Problem) يقول إنك تحتاج توليد ~2.71 كوينتليون UUID (10^18) قبل أن يصبح احتمال التصادم 50%. لتوضيح المقياس: لو ولّدت مليار UUID في الثانية، ستحتاج ~85 سنة للوصول لاحتمال 50%.

عملياً، التصادم في v4 غير ممكن ضمن أيّ تطبيق واقعي — ما لم يكن مولّد الأرقام العشوائية معطوباً (وهو ما حدث فعلاً في بعض الأخطاء التاريخية، آخرها في Java SE 5 لفترة قصيرة).

v7 أقوى لأن مكوّن الوقت يجعل التصادم مستحيلاً بين UUIDs ولّدت في أجزاء زمنية مختلفة؛ التصادم لا يحدث إلا داخل نفس الميلي ثانية، وحتى هناك تحميك 74 بِت عشوائية.

استخدام UUID مفتاحاً أساسياً (Primary Key) قرار شائع لكن له مفاضلات حقيقية:

• الحجم: 16 بايت بدلاً من 4 (INT) أو 8 (BIGINT). كل جدول وكل فهرس وكل Foreign Key يدفع الثمن.
• الفهارس: v4 يُسبّب تشظّياً في B-Tree (إدراجات في مواقع عشوائية). v7 يحلّ هذا.
• المقروئية: الـ logs و URL وحوارات الدعم الفنّي مع UUID أصعب من "طلب رقم 1042".
• التوزيع: مع UUID يمكن للعميل توليد المعرّف قبل إرساله للخادم (مفيد لـ offline-first apps و sharding).

توصية 2026: استخدم v7 كنوع uuid في PostgreSQL (الإصدار 16+ يدعم uuidv7() أصلاً)، وفي MySQL استخدم BINARY(16) بدلاً من CHAR(36) لتوفير 56% من المساحة.

متى تختار UUID؟

• نظام موزَّع متعدّد الخوادم بدون مُنسِّق مركزي.
• تطبيق Offline-first يحتاج توليد ID قبل المزامنة.
• لا تريد كشف عدد العملاء/الطلبات للمنافسين من خلال "Order #1042".
• دمج بيانات من عدّة مصادر دون قلق التصادم.

متى يظلّ Auto-Increment أفضل؟

• قاعدة بيانات أحادية الخادم بحجم متوسط.
• أداء الإدراج والفهرسة هو الأولوية القصوى.
• المستخدمون يتعاملون مباشرة مع الأرقام (فواتير، طلبات).

الحلّ الوسط الشائع: مفتاح أساسي داخلي BIGINT + عمود uuid منفصل مفهرس للاستخدام الخارجي عبر API.

UUID v4 و v7 ليسا أسراراً. تحتوي على عشوائية كافية بحيث لا يمكن تخمينها، لكن لا تعاملها كـ tokens. لا تستخدم UUID بمفرده كرابط إعادة تعيين كلمة السر أو رمز API. استخدم crypto.randomBytes(32) مع ترميز Base64-URL لذلك.

v1 له خطر خاص: يكشف وقت التوليد (~ميلي ثانية) وقد يكشف عنوان MAC في التطبيقات القديمة. لو كنت مضطراً لـ v1، تأكّد أن المكتبة تستخدم Node ID عشوائي.

أخيراً: لا تنسَ أن "non-secret-but-unguessable" يعتمد على جودة مولّد الأرقام العشوائية. في Node.js و Deno و Browsers الحديثة لا داعي للقلق، لكن في بيئات embedded قد تحتاج تحقّقاً إضافياً.

JavaScript / TypeScript (مدمج في Node 19+ والمتصفّحات):

const id = crypto.randomUUID();
// "9c4f0f8a-1a2b-4c3d-8e5f-7a9b0c1d2e3f"

Python (مكتبة قياسية):

import uuid
u = uuid.uuid4()  # v4
print(str(u))

PostgreSQL 13+:

-- v4
SELECT gen_random_uuid();

-- v7 (PostgreSQL 17+ أو امتداد)
CREATE TABLE orders (
  id  uuid PRIMARY KEY DEFAULT uuidv7(),
  ...
);

MySQL 8:

SELECT UUID();          -- v1
SELECT UUID_TO_BIN(UUID(), 1);  -- v1 بترتيب قابل للفرز، 16 بايت

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

عملياً لا فرق. UUID مصطلح RFC، GUID مصطلح Microsoft لنفس الشيء (128 بِت معرّف فريد). الاختلاف الوحيد القديم: بعض أنظمة Microsoft تخزّن البايتات الأربعة الأولى بترتيب little-endian عند التحويل لـ binary، بينما UUID القياسي big-endian. عند العرض كنصّ hex لا فرق بينهما.

هل يمكن أن يتطابق UUIDs اثنان؟

نظرياً نعم، عملياً لا. لـ v4 تحتاج توليد ~10^18 UUID للوصول لاحتمال تصادم 50% (مفارقة عيد الميلاد). لو ولّدت مليار UUID في الثانية لمدة 85 سنة، احتمال التصادم 50%. أي مشروع واقعي بعيد جداً عن هذه الأرقام.

v4 أم v7 لمفتاح قاعدة البيانات؟

v7 — تقريباً دائماً. v7 يبدأ بختم زمني، فالإدراجات تأتي مرتّبة، وفهرس B-Tree يبقى متّسقاً دون تشظّي. v4 العشوائي الكامل يسبّب "index fragmentation" خاصة مع ملايين الصفوف. v4 يبقى ممتازاً لأيّ معرّف خارج قواعد البيانات (HTTP headers، file names، session tokens).

هل UUID v4 آمن كـ session token أو رابط إعادة تعيين كلمة السر؟

لا. UUID v4 يحتوي 122 بِت عشوائية فقط، وأغلب المكتبات تستخدم PRNG عام وليس CSPRNG مخصّص. للأسرار استخدم crypto.randomBytes(32) ثم ترميز Base64-URL — تحصل على 256 بِت من العشوائية المضمونة من مصدر آمن.

هل أحتاج مكتبة خارجية لـ UUID v7؟

اعتباراً من 2026: PostgreSQL 17 و .NET 9 و Java 21+ تدعم v7 أصلاً. JavaScript المتصفّح يدعم v4 فقط عبر crypto.randomUUID() — للـ v7 استخدم مكتبة صغيرة (مثل uuidv7) أو ضِعها يدوياً (~30 سطر).

هل بياناتي تُرفع للخادم؟

لا. كل الـ UUIDs تُولَّد محلياً في متصفّحك عبر crypto.getRandomValues. لا توجد طلبات شبكة ولا تتبّع — يمكنك حتى قطع الإنترنت وستعمل الأداة.

الأداة في أعلى الصفحة تولّد UUID v1 و v4 و v7 بصيغ متعدّدة وبدفعات حتى 1000 — كل التوليد محلي 100%. للمشاريع الجديدة في 2026: استخدم v7 كمفتاح أساسي في قاعدة البيانات و v4 لكل المعرّفات الأخرى. لا تستخدم v1 إلا للتوافق مع نظام قديم.