برنامج حساب الوقت

• UUID v1 يجمع بين طابع زمني وعنوان MAC الخاص بالجهاز — وهو مضمون التفرُد ولكنه يكشف عن وقت الإنشاء وهوية الأجهزة، مما يُثير مخاوف تتعلق بالخصوصية.
• UUID v3 و v5 هما دالتا تجزئة حتميتان: يستخدم v3 خوارزمية MD5، بينما يستخدم v5 خوارزمية SHA-1. مع توفر نفس المساحة والاسم، فهما ينتجان دائماً نفس معرف UUID — وهو أمر مفيد لتوليد معرفات متسقة من مفاتيح طبيعية (مثل تحويل عناوين البريد الإلكتروني إلى معرفات مستخدمين).
• UUID v4 يستخدم 122 بت من البيانات العشوائية، مما يوفر أقوى ضمان للتفرُد دون تسريب أي معلومات.
• UUID v7 (وفقاً لـ RFC 9562، لعام 2024) يدمج طابعاً زمنياً لنظام يونكس في أول 48 بت مع الاحتفاظ بـ 74 بت عشوائي — وهو قابل للفرز حسب وقت الإنشاء، مما يجعله مثملاً للمفاتيح الأساسية لقواعد البيانات حيث يكون أداء الفهرسة مهمًا.

بالنسبة لمعظم التطبيقات، يُعد v4 الخيار الافتراضي؛ وانتقل إلى v7 للمفاتيح الأساسية لقواعد البيانات عندما يكون ترتيب الإدخال مهمًا.

يستخدم UUID v4 عدد 128 بت عشوائياً، مما ينتج عنه 5.3 × 10^36 قيمة محتملة. تحدد مشكلة عيد الميلاد احتمالية حدوث التصادم: فبعد توليد 2.7 × 10^18 (2.7 كوينتيليون) معرف UUID، تصبح هناك فرصة بنسبة 50% لحدوث تصادم واحد.

من الناحية العملية، فإن توليد مليار معرف UUID في الثانية لمدة 85 عامًا يصل إلى هذا الحد. وبمستويات أكثر واقعية — لنظام يولد مليون معرف UUID يوميًا — فإن احتمالية حدوث أي تصادم خلال 100 عام تقارب 1 من كل 10^24.

يفترض هذا وجود مولد أرقام عشوائية مناسب (CSPRNG)؛ فإن استخدام دالة Math.random() في جافاسكريبت (والتي لا تتمتع بالحماية التشفيرية) يقلل من الإنتروبيا ويزيد من مخاطر التصادم. احرص دائماً على استخدام crypto.randomUUID() أو مكتبات uuid v4 أو دمج وظائف UUID الأصلية لقواعد البيانات في الأنظمة الإنتاجية.

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

مع ذلك، تؤثر قيم UUID v4 العشوائية سلبًا على أداء فهرس شجرة B — فعمليات الإدخال العشوائية تتسبب في انقسام الصفحات وتجزئتها، مما يزيد من تضخيم الكتابة بمقدار يتراوح بين 2 إلى 5 أضعاف مقارنة بالمفاتيح الرقمية المتسلسلة. ويحل UUID v7 هذه المشكلة عبر العشوائية المسبوقة بطابع زمني، مما يوفر التفرُد والترتيب التسلسلي معاً.

كما أن تكلفة التخزين أعلى أيضاً: 16 بايت مقابل 4-8 بايت للأرقام الصحيحة، وهو أمر مهم للغاية في الجداول التي تحتوي على مليارات الصفوف والفهارس متعددة.

هناك نمط شائع يجمع بين معرفات UUID كمحددات عامة مع مفاتيح رقمية متزايدة تلقائياً داخلياً، وربط الجداول عبر المفتاح الرقمي الفعال بينما يتم عرض معرف UUID الآمن فقط لوافجهات برمجة التطبيقات وعناوين URL.

UUID (المعرف الفريد عالمياً) هو قيمة مكونة من 128 بت مصممة لتكون فريدة عبر المكان والزمان دون الحاجة إلى سلطة تسجيل مركزية، كما هو محدد بواسطة معيار IETF RFC 9562 (والذي يلغي معيار RFC 4122 الأقدم).

تُكتب بتات الـ 128 كـ 32 رمزاً سداسياً عشرياً مجمعة بنمط 8-4-4-4-12، مثل 550e8400-e29b-41d4-a716-446655440000. يتم حجز بتات معينة: حيث يشفر الرمز السادس عشر الإصدار، وتشفر البتات العليا من الرمز السابع عشر المتغير.

بينما تحمل البتات المتبقية بيانات عشوائية، أو طابعاً زمنياً، أو اسماً مجزأً بناءً على الإصدار. ونظراً لأن المساحة القابلة للعنونة هي 2^122، فيمكن للمولدات المستقلة صك المعرفات بأمان دون أي تنسيق مسبق.

أبسط طريقة لإنشاء معرف UUID هي استخدام دالة مدمجة في اللغة تستدعي مصدراً عشوائياً آمناً تشفيرياً.

• في JavaScript، تُرجع الدالة crypto.randomUUID() معرف UUID بالإصدار v4 وموثقة في مستندات MDN Web Docs كجزء من واجهة Web Crypto API، وهي متوفرة في المتصفحات الحديثة وبيئة Node.js 14.17+.
• في Python، توفر وحدة uuid في المكتبة القياسية الدالة uuid.uuid4() للقيم العشوائية والدالة uuid.uuid1() للقيم القائمة على الطابع الزمني.
• في PostgreSQL، تُنتج الدالة gen_random_uuid() معرف UUID بالإصدار v4، بينما يوفر MySQL 8 الدالة UUID() للحصول على قيمة بأسلوب الإصدار v1.

تُصدر جميع هذه الطرق سلاسل نصية متوافقة مع معيار RFC 9562، بحيث تتكامل المعرفات التي تُنشأ في لغة ما بسلاسة مع لغة أخرى.

نعم، كل من GUID و UUID هما نفس المعرف ذي الـ 128 بتاً؛ فمصطلح GUID (المعرف الفريد عالمياً) هو ببساطة تسمية مايكروسوفت لمعيار UUID القياسي المحدَّد في وثيقة IETF RFC 9562. إنهما متوافقان ثنائياً، لذا فإن أي قيمة يتم إنشاؤها بواسطة نظام التشغيل Windows أو بيئة .NET يمكن استخدامها بواسطة أي نظام متوافق مع معيار RFC والعكس صحيح.

الفرق الروتيني الوحيد هو طريقة العرض: غالباً ما تغلف أدوات مايكروسوفت القيمة بأقواس متعرجة، على سبيل المثال {550e8400-e29b-41d4-a716-446655440000}، كما أن بعض واجهات برمجة تطبيقات COM كانت تستخدم الأحرف الكبيرة للقيم السداسية عشرية تاريخياً.

هناك ملاحظة دقيقة تتمثل في ترتيب البايتات — حيث تخزن قيمة GUID الثنائية الخاصة بمايكروسوفت الحقول الثلاثة الأولى بترتيب البايت الأصغر أولاً (little-endian)، وهو أمر يهم فقط عند تحليل البايتات الخام وليس عند استخدام الصيغة النصية القياسية المفصولة بشرطات.

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

يستمد الإصدار الرابع (v4) 122 بتاً من مولد أرقام عشوائية آمن تشفيرياً (CSPRNG)، لذا يصعب التنبؤ به عملياً، ولكن الإصدار الأول (v1) والإصدار السابع (v7) يدمجان طوابع زمنية تسرب وقت الإنشاء، بينما يُعد الإصدار الثالث (v5) والإصدار الثالث (v3) تجزئات حتمية لنساّبة واسم معروفين.

بالنسبة لرموز الجلسات، أو إعادة تعيين كلمات المرور، أو مفاتيح واجهة برمجة التطبيقات (API)، أنشئ أسراراً مخصصة عالية الانتروبيا بدلاً من الاعتماد على هيكل UUID للحماية.

حقول الإصدار والمتغير (version and variant) هي أنماط بتات ثابتة مدمجة في كل معرف UUID متوافق مع معيار RFC 9562 والتي تخبر المحللات كيف تم إنشاء القيمة.

يشغل الإصدار البتات الأربعة الأكثر أهمية من البايت السابع (الرقم السداسي عشر الثالث عشر)، لذلك يظهر في معرف UUID من الإصدار v4 الرقم 4 دائماً، بينما يظهر الرقم 7 في الإصدار v7. أما المتغير فيقع في البتات الثلاثة أو الاثنين الأكثر أهمية من البايت التاسع (الرقم السداسي عشر السابع عشر)، والذي يجعل هذا الرقم بالنسبة لمتغير IETF القياسي واحداً من الآتي: 8، 9، a، أو b.

لهذا السبب يتطابق معرف UUID الصالح من الإصدار v4 مع النمط xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. يُعد التحقق من هذه المواضع الثابتة بالطريقة الصحيحة للتحقق من صحة أو تصنيف معرف UUID بدلاً من إجراء فحص فضفاض للطول.

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

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

عند تهيئة جداول بحجم إنتاجي، يُنصح بالنظر في الإصدار السابع لكي تقع الصفوف المدرجة بالجملة بترتيب فهرس تسلسلي تقريباً، مما يحافظ على صفحات شجرة البحث الثنائية (B-tree) مدمجة ويقلل من تضخيم الكتابة أثناء الاستيراد.

قم بتخزين معرفات UUID في نوع بيانات ثنائي أصلي بحجم 16 بايت متى ما كانت قاعدة بياناتك تدعم ذلك، لأن الاحتفاظ بها كنصوص من 36 حرفاً يهدر أكثر من ضعف المساحة ويبطئ مقارنات الفهارس. توفر PostgreSQL نوع عمود uuid مخصص، بينما تستخدم MySQL وSQL Server عادةً النوع BINARY(16) مع دوّال تحويل من وإلى السلسلة النصية المفصولة بشرطات.

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

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

الخطأ الأكثر شيوعاً في UUID هو استخدام مصدر عشوائي غير آمن تشفيرياً مثل دالة Math.random() في JavaScript، وهي ليست مولداً رقمياً عشوائياً آمناً تشفيرياً (CSPRNG) ويمكنها إنتاج قيم متحيزة أو قابلة للتنبؤ؛ ولهذا يوصي موقع MDN باستخدام الدالة crypto.randomUUID() أو واجهة Web Crypto API بدلاً من ذلك.

تشمل الأخطاء المتكررة الأخرى ما يلي:

• معاملة معرف UUID الفارغ (الذي كله أصفار) كمعرف حقيقي
• افتراض أن معرفات UUID سرية بما يكفي لتخويل الوصول
• تخزينها كنصوص بينما يكون عمود البيانات الثنائية بحجم 16 بايت أكثر كفاءة بكثير

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