المعرف الفريد العالمي

المعرف الفريد العالمي (UUID) هو عبارة عن علامة مكونة من 128 بت تستخدم لتحديد الكائنات بشكل فريد في أنظمة الكمبيوتر. يُستخدم مصطلح المعرف الفريد العالمي (GUID) أيضًا، غالبًا في أنظمة Microsoft.

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

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

يعد استخدام معرفات UUID أمرًا واسع الانتشار، حيث توفر العديد من منصات الحوسبة الدعم لتوليدها وتحليل تمثيلها النصي.

 تاريخ 
في ثمانينيات القرن العشرين، استخدمت شركة Apollo Computer في البداية معرفات UUID في نظام الحوسبة الشبكية (NCS). وفي وقت لاحق، استخدمت مؤسسة البرمجيات المفتوحة (OSF) معرفات UUID لبيئة الحوسبة الموزعة (DCE) الخاصة بها. كان تصميم معرفات UUID الخاصة بـ DCE يعتمد جزئيًا على معرفات UUID الخاصة بـ NCS، والتي استوحى تصميمها بدوره من المعرفات الفريدة (64 بت) المحددة والمستخدمة على نطاق واسع في Domain/OS، وهو نظام تشغيل صممته شركة Apollo Computer. لاحقاً، اعتمدت منصات Microsoft Windows تصميم DCE باعتباره "معرفات فريدة عالميًا" (GUIDs).

سجل RFC 4122 مساحة اسم URN لـ UUIDs وأعاد صياغة المواصفات السابقة، بنفس المحتوى الفني.Leach, P.; Mealling, M.; Salz, R. (2005). A Universally Unique IDentifier (UUID) URN Namespace. Internet Engineering Task Force. doi:10.17487/RFC4122. RFC 4122. Retrieved 17 January 2017. عندما نُشر RFC 4122 في يوليو 2005 كمعيار مقترح لـ IETF، قام الاتحاد الدولي للاتصالات أيضًا بتوحيد معرفات UUID، استنادًا إلى المعايير السابقة والإصدارات المبكرة من RFC 4122. في 7 مايو 2024، نُشر RFC 9562،والذي قدم 3 "إصدارات" جديدة وأوضح بعض الغموض.

 المعايير 
وحدت معرفات UUID بواسطة مؤسسة البرمجيات المفتوحة (OSF) كجزء من بيئة الحوسبة الموزعة (DCE).

وثقت معرفات UUID كجزء من ISO / IEC 11578: 1996 " تكنولوجيا المعلومات - الربط بين الأنظمة المفتوحة - نداء الإجراء عن بعد (RPC)" ومؤخرًا في ITU-T Rec. X.667 | ISO / IEC 9834-8:2014.

نشرت فرقة عمل هندسة الإنترنت (IETF) معيار RFC 9562 من "مجموعة عمل مراجعة تعريفات المعرفات الفريدة عالميًا" كمراجعة لـRFC 4122.  RFC 4122 يعادل من الناحية الفنية ITU-T Rec. X.667 | ISO/IEC 9834-8، ولكنه أصبح الآن قديمًا.

 شكل 
يبلغ حجم UUID 128 بت، حيث يُستخدم 2 إلى 4 بتات للإشارة إلى متغير التنسيق. الإصدار الأكثر شيوعًا قيد الاستخدام، OSF DCE، يحدد أيضًا 4 بتات لإصداره.

يُتحكم في استخدام البتات المتبقية حسب الإصدار/المتغير المحدد.

 المتغيرات 
يشير الحقل المتغير إلى تنسيق UUID (وفي حالة UUID القديم، يشير أيضًا إلى عائلة العنوان المستخدمة لحقل العقدة). عُرفت المتغيرات التالية:

 صُمم متغير Apollo NCS (المشار إليه بالنمط أحادي البت 0xxx 2 ) للتوافق مع تنسيق UUID الخاص بنظام Apollo Network Computing System 1.5 الذي أصبح الآن قديمًا والذي طور حوالي عام 1988. على الرغم من اختلاف التفاصيل، فإن التشابه مع UUIDv1 الحديث واضح. تتوافق البتات المتغيرة في مواصفات UUID الحالية مع البتات العالية من مجموعة العناوين الثمانية في UUIDs الخاصة بـ NCS. على الرغم من أن عائلة العنوان يمكن أن تحتوي على قيم في النطاق 0.. 255، القيم 0 فقط.. 13 عُرفت على الإطلاق. وعليه، فإن نمط البت 0xxx يتجنب التعارضات مع معرفات NCS UUID التاريخية، في حال وجود أي منها في قواعد البيانات. يُعرّف هذا المتغير "العائلات" على أنها نوع فرعي.
 يشار إلى متغير OSF DCE (10xx 2 ) باسم RFC 4122/DCE 1.1 UUIDs، أو "Leach–Salz" UUIDs، نسبة إلى مؤلفي مسودة الإنترنت الأصلية. يُعرّف هذا المتغير "الإصدارات" كنوع فرعي.
 يتميز متغير Microsoft COM/DCOM (110x 2 ) في RFC بأنه "محجوز، متوافق مع الإصدارات السابقة من Microsoft Corporation" وأُستخدم في GUIDs المبكرة على منصة Microsoft Windows .
 لا يُستخدم مساحة المتغير المحجوزة حاليًا بواسطة أي مواصفات.

 إصدارات متغير OSF DCE 
يحدد متغير OSF DCE ثمانية "إصدارات" في المعيار، وقد يكون كل إصدار أكثر ملاءمة من غيره في حالات استخدام محددة. يشار إلى الإصدار من خلال قيمة الجزء الأعلى (4 بتات أعلى، أو رقم سداسي عشري أعلى) من البايت السابع من UUID. في النظام السداسي، هذه هي الشخصية بعد الشرطة الثانية. على سبيل المثال، UUID 9c5b94b1-35ad- 4 9bb-b118-8e8fc24abf80 هو الإصدار 4، وذلك لأن الرقم بعد الشرطة الثانية هو 4 في ... - 4 9bb-... .

 الإصداران 1 و6 (التاريخ والوقت وعنوان MAC) 
يقوم الإصدار 1 بربط عنوان MAC المكون من 48 بت "للعقدة" (أي الكمبيوتر الذي يولد UUID)، مع طابع زمني مكون من 60 بت، وهو عدد الفواصل الزمنية التي تبلغ 100 نانوثانية منذ منتصف ليل 15 أكتوبر 1582 بالتوقيت العالمي المنسق (UTC)، وهو التاريخ الذي اُعتمد فيه التقويم الغريغوري لأول مرة من قبل الجزء الأكبر من أوروبا. تنص RFC 4122 على أن قيمة الوقت تتدحرج حول 3400 ميلادي، اعتمادًا على الخوارزمية المستخدمة، مما يعني أن الطابع الزمني المكون من 60 بت هو كمية موقعة. ومع ذلك، فإن بعض البرامج، مثل مكتبة libuuid، تعامل الطابع الزمني على أنه غير موقّع، مما يضع وقت التبديل في عام 5623 ميلاديًا. وقت التدوير كما هو محدد في توصية ITU-T. X.667 هو 3603 م. 

يمتد تسلسل الساعة "الموحد" المكون من 13 بت أو 14 بت إلى الطابع الزمني من أجل التعامل مع الحالات التي لا تتقدم فيها ساعة المعالج بسرعة كافية، أو حيث توجد معالجات متعددة ومولدات UUID لكل عقدة. عندما تُنشئ معرفات UUID بشكل أسرع من سرعة ساعة النظام، يمكن إنشاء البتات السفلية من حقول الطابع الزمني عن طريق زيادتها في كل مرة تُنشئ فيها معرف UUID، لمحاكاة طابع زمني عالي الدقة. مع كل إصدار 1 من UUID يتوافق مع نقطة واحدة في الفضاء (العقدة) والوقت (الفواصل الزمنية وتسلسل الساعة)، فإن فرصة أن يكون إصداران 1 من UUID تم إنشاؤهما بشكل صحيح متماثلين عن غير قصد هي عمليًا صفر. نظرًا لأن تسلسل الوقت والساعة يبلغ 74 بتًا، فمن الممكن إنشاء 2 74 (1.8  ، أو 18 سكستيليون) من الإصدار 1 من معرفات UUID لكل معرف عقدة، بمعدل متوسط أقصى يبلغ 163 مليار في الثانية لكل معرف عقدة.

على النقيض من إصدارات UUID الأخرى، تعتمد إصدارات 1 و-2 من UUID المستندة إلى عناوين MAC من بطاقات الشبكة على تفردها جزئيًا على معرف صادر عن سلطة تسجيل مركزية، أي جزء معرف المنظمة الفريد (OUI) من عنوان MAC، والذي يُصدر بواسطة IEEE إلى مصنعي معدات الشبكات. تعتمد تفرد إصدارات 1 و2 من معرفات UUID المستندة إلى عناوين MAC الخاصة ببطاقات الشبكة أيضًا على قيام مصنعي بطاقات الشبكة بتعيين عناوين MAC فريدة لبطاقاتهم بشكل صحيح، وهو ما يكون عرضة للخطأ مثل عمليات التصنيع الأخرى. تتلقى الآلات الافتراضية عنوان MAC ضمن نطاق قابل للتكوين في المشرف الافتراضي. بالإضافة إلى ذلك، تسمح بعض أنظمة التشغيل للمستخدم النهائي بتخصيص عنوان MAC، وخاصة OpenWRT.

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

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

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

 الإصدار 2 (التاريخ والوقت وعنوان MAC، إصدار أمان DCE) 
يحتفظ RFC 9562 بالإصدار 2 لمعرفات UUID الخاصة بـ "أمان DCE"؛ ولكنه لا يقدم أي تفاصيل. لهذا السبب، تتجاهل العديد من تطبيقات UUID الإصدار 2. ومع ذلك، تُوفر مواصفات UUIDs للإصدار 2 بواسطة مواصفات خدمات المصادقة والأمان DCE 1.1."DCE 1.1: Authentication and Security Services". The Open Group. 1997.

تتشابه معرفات UUID الخاصة بالإصدار 2 مع الإصدار 1، باستثناء أن أقل 8 بتات أهمية من تسلسل الساعة تُستبدل برقم "المجال المحلي"، وتُستبدل أقل 32 بت أهمية من الطابع الزمني بمعرف عدد صحيح ذي معنى داخل المجال المحلي المحدد. في أنظمة POSIX، تكون أرقام النطاق المحلي 0 و1 مخصصة لمعرفات المستخدم (UIDs) ومعرفات المجموعة (GIDs) على التوالي، ويُحدد أرقام النطاق المحلي الأخرى بواسطة الموقع. في الأنظمة غير POSIX، تُحدد جميع أرقام النطاق المحلية بواسطة الموقع.

إن القدرة على تضمين مجال/معرف مكون من 40 بت في UUID تأتي مع مقايضة. من ناحية أخرى، تسمح 40 بت بحوالي 1 تريليون قيمة للمجال/المعرف لكل معرف عقدة. من ناحية أخرى، مع اقتطاع قيمة الساعة إلى 28 بت الأكثر أهمية، مقارنة بـ 60 بت في الإصدار 1، فإن الساعة في UUID الإصدار 2 سوف "تدق" مرة واحدة فقط كل 429.49 ثواني، أكثر بقليل من 7 دقائق، على عكس كل 100 نانوثانية للإصدار 1. ومع تسلسل الساعة 6 فقط بتات، مقارنة بـ 14 بت في الإصدار 1، لا يمكن إنشاء سوى 64 معرف UUID فريد لكل عقدة/نطاق/معرف لكل 7 دقائق من دقات الساعة، مقارنة بـ 16384 قيمة تسلسل ساعة للإصدار 1.

 الإصداران 3 و5 (يعتمدان على اسم المساحة) 
تُنشئ معرفات UUID للإصدار 3 والإصدار 5 عن طريق تجزئة معرف مساحة الأسماء والاسم. الإصدار 3 يستخدم MD5 كخوارزمية تجزئة، والإصدار 5 يستخدم SHA-1.Davis, K.; Peabody, B.; Leach, P. (2024). Universally Unique IDentifiers (UUIDs). Internet Engineering Task Force. doi:10.17487/RFC9562. RFC 9562. Retrieved 9 May 2024.

معرف مساحة الاسم هو في حد ذاته UUID. توفر المواصفات معرفات UUID لتمثيل مساحات الأسماء لعناوين URL، وأسماء النطاق المؤهلة بالكامل، ومعرفات الكائنات، وأسماء X.500 المميزة؛ ولكن يمكن استخدام أي معرف UUID مرغوب فيه كمُعرّف لمساحة الأسماء.

لتحديد الإصدار 3 من UUID المقابل لمساحة اسم واسم معينين، يحول UUID لمساحة الاسم إلى سلسلة من البايتات، متصلة باسم الإدخال، ثم تُجزء باستخدام MD5، مما ينتج عنه 128 بت. ثم يُستبدل 6 أو 7 بتات بقيم ثابتة، وإصدار 4 بت (على سبيل المثال 0011 2 للإصدار 3)، و"متغير" UUID مكون من 2 أو 3 بتات (على سبيل المثال 10 2 يشير إلى UUID RFC 9562، أو 110 2 يشير إلى Microsoft GUID قديم). نظرًا لأن 6 أو 7 بتات محددة مسبقًا، فإن 121 أو 122 بت فقط تساهم في تفرد UUID.

تعتبر إصدارات UUID-5 مشابهة، ولكن يُستخدم SHA-1 بدلاً من MD5. نظرًا لأن SHA-1 ينشئ ملخصات مكونة من 160 بت، يُقلص الملخص إلى 128 بت قبل استبدال البتات الإصدارية والمتغيرة.

تتمتع إصدارات 3 و5 من UUIDs بخاصية مفادها أن نفس مساحة الاسم والاسم سيعين إلى نفس UUID. ومع ذلك، لا يمكن تحديد مساحة الاسم أو الاسم من UUID، حتى لو حُدد أحدهما، إلا عن طريق البحث بالقوة الغاشمة. يوصي RFC 4122 بالإصدار 5 (SHA-1) بدلاً من الإصدار 3 (MD5)، ويحذر من استخدام معرفات UUID لأي من الإصدارين كبيانات اعتماد أمنية.

 الإصدار 4 (عشوائي) 
يُنشئ UUID الإصدار 4 بشكل عشوائي. كما هو الحال في معرفات UUID الأخرى، يُستخدم 4 بتات للإشارة إلى الإصدار 4، و2 أو 3 بتات للإشارة إلى المتغير (10 2 أو 110 2 للمتغيرين 1 و2 على التوالي). وبالتالي، بالنسبة للمتغير 1 (أي معظم معرفات UUID)، فإن معرف UUID العشوائي للإصدار 4 سيحتوي على 6 بتات متغيرة وإصدار محددة مسبقًا، مما يترك 122 بت للجزء الذي أُنشئ عشوائيًا، بإجمالي 2 122، أو 5.3  (5.3 أونديسيليون) الإصدار المحتمل-4 المتغير-1 UUIDs. هناك نصف عدد ممكن من UUIDs (GUIDs القديمة) للإصدار 4، المتغير 2 لأنه يوجد بت عشوائي متاح أقل، ويُستهلك 3 بتات للمتغير.

وفقًا لـ RFC 9562، تشير البتات الأربعة الأكثر أهمية في المجموعة السابعة إلى الإصدار الذي يلتزم به UUID. وهذا يعني أن الرقم السداسي عشر الأول في المجموعة الثالثة يبدأ دائمًا بالرقم 4 في UUIDv4s. من الناحية المرئية، يبدو هذا مثل xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx، حيث M هو حقل إصدار UUID. إن البتتين أو الثلاثة البتات العلوية من الرقم N تشفر المتغير. القيم هي 8، 9، A أو B للإشارة المكونة من 2 بت، والقيم C أو D للإشارة المكونة من 3 بت. على سبيل المثال، يمكن أن يكون إصدار UUID العشوائي 4، المتغير 1 هو 8D8AC610-566D-4EF0-9C22-186B2A5ED793.

 الإصدار 7 (الطابع الزمني والعشوائي) 
صُممت معرفات UUID الإصدار 7 (UUIDv7) للمفاتيح الموجودة في قواعد البيانات عالية التحميل والأنظمة الموزعة.

يبدأ UUIDv7 بعلامة زمنية Unix Epoch كبيرة الحجم مكونة من 48 بت مع حبيبات تبلغ حوالي مللي ثانية. يمكن تحويل الطابع الزمني بواسطة أي قيمة تحويل زمنية. يأتي بعد الطابع الزمني مباشرة إصدار nibble، والذي يجب أن يكون له قيمة 7. يجب أن تكون البتات المتغيرة 10x . 74 بت المتبقية هي عداد بذور عشوائي (اختياري، على الأقل 12 بت ولكن ليس أكثر من 42 بت) وعشوائية.

يمكن استخدام طريقتين للتعامل مع الانقلاب المضاد معًا:

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

في DBMS، يمكن مشاركة مولد UUIDv7 بين الخيوط (مرتبط بجدول أو بمثيل DBMS) أو يمكن أن يكون محليًا للخيط (مع رتابة ومحلية وأداء أسوأ).

 الإصدار 8 (مخصص) 
الإصدار 8 لديه متطلبين فقط:

 يجب أن تكون البتات المتغيرة 10، لذا يجب أن تكون البتة التي تحتوي على المتغير 8 ( 0b1000 )، أو 9 ( 0b1001 )، أو A ( 0b1010 )، أو B ( 0b1011 ).
 يجب أن تكون قيمة الإصدار nibble 8.

تخبر هذه المتطلبات النظام أن هذا هو الإصدار 8 من UUID. يتعين على البائع تخصيص الـ 122 بت المتبقية. الفرق مع الإصدار 4 هو أن هذه البتات الـ 122 عشوائية، ولكن البتات الـ 122 في إصدار UUID 8 ليست كذلك، لأنها تتبع قواعد محددة للبائع.

 القيم الخاصة 

 لا يوجد UUID 
"المعرف الفريد العالمي (UUID)" الصفري هو 00000000-0000-0000-0000-000000000000 ؛ أي أن جميع البتات مضبوطة على الصفر.

 الحد الأقصى لـ UUID 
"الحد الأقصى" UUID، والذي يُطلق عليه أحيانًا أيضًا اسم "omni" UUID، هو UUID FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF ؛ أي كل البتات مضبوطة على واحد.Davis, K.; Peabody, B.; Leach, P. (2024). Universally Unique IDentifiers (UUIDs). Internet Engineering Task Force. doi:10.17487/RFC9562. RFC 9562. Retrieved 9 May 2024.

 الترميز 

 التمثيل الثنائي 
في البداية، صممت شركة Apollo Computer معرف UUID باستخدام تنسيق السلك التالي:Zahn, Lisa; Dineen, Terence; Leach, Paul; Martin, Elizabeth; Mishkin, Nathaniel; Pato, Joseph; Wyant, Geoffrey (1990). Network Computing Architecture. Prentice Hall. p. 10. ISBN 978-0-13-611674-5."uuid.c".
+تنسيق السلك القديم اسم الإزاحة طول وصف الوقت_عالي  4 ثمانيات / 32 بت أول 6 أوكتيتات هي عدد وحدات الزمن التي تبلغ أربعة ميكروثانية (μs) والتي مرت منذ 1980-01-01 00:00 UTC . الوقت 2 48 × 4 ميكروثانية بعد بداية عام 1980 كان 2015-09-05 05:58:26.84262 UTC. وبالتالي، فإن آخر مرة أمكن فيها إنشاء معرفات UUID بهذا التنسيق الأصلي كانت في عام 2015. But a bug in Domain/OS made only the first half of the timespace usable, so problems occurred on 1997-11-02. الوقت_منخفض  2 ثماني بتات / 16 بت محجوز  2 ثماني بتات / 16 بت تُحجز هذه الثمانيات للاستخدام في المستقبل. عائلة  1 ثماني بتات / 8 بتات هذه الثماني هي عائلة عناوين. العقدة  7 ثمانيات / 56 بت هذه الثماني بتات هي معرف المضيف في النموذج المسموح به من قبل عائلة العنوان المحددة.
في وقت لاحق، وسع UUID من خلال الجمع بين حقل العائلة القديم وحقل المتغير الجديد. نظرًا لأن حقل العائلة كان يستخدم فقط القيم التي تتراوح من 0 إلى 13 في الماضي، فقد تقرر أن UUID مع البت الأكثر أهمية المضبوط على 0 هو UUID قديم. وهذا يعطي الجدول التالي للمجموعة العائلية:
+حقل العائلة/المتغير MSB 0 إم إس بي 1 إم إس بي 2 نطاق قيمة حقل العائلة القديمة في سداسي وصف 0 س س 0–127 (يُستخدم 0–13 فقط) 0x00–0x7f معرف UUID الخاص بـ Apollo NCS القديم 1 0 س 128–191 0x80–0xbf معرف OSF DCE UUID 1 1 0 192–223 0xc0–0xdf معرف Microsoft COM / DCOM UUID 1 1 1 224–255 0xe0–0xff محجوزة للتعريف المستقبلي
يحتوي UUID القديم لـ Apollo NCS على التنسيق الموضح في الجدول السابق. وصف متغير OSF DCE UUID في RFC 9562. يوصف متغير UUID الخاص بـ Microsoft COM / DCOM في وثائق Microsoft.

 إنديانيس 
عند حفظ معرفات UUID إلى تنسيق ثنائي، تُرمز بشكل تسلسلي في big-endian. على سبيل المثال، تُرمز 00112233-4455-6677-8899-aabbccddeeff على هيئة البايتات 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

الاستثناء الوحيد هو متغيرات Microsoft 2 UUID ("GUID"): تستخدم تاريخيًا في مكتبات COM/OLE، وتستخدم تنسيق little-endian، ولكنها تظهر بتنسيق مختلط مع المكونات الثلاثة الأولى من UUID بتنسيق little-endian والمكونين الأخيرين بتنسيق big-endian. يقوم هيكل GUID الخاص بشركة Microsoft بتعريف آخر ثمانية بايتات على هيئة مصفوفة مكونة من 8 بايتات، والتي تُسلسل بترتيب تصاعدي، مما يجعل تمثيل البايت يبدو مختلطًا. على سبيل المثال، تُرمز 00112233-4455-6677-8899-aabbccddeeff على هيئة البايتات 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

 التمثيل النصي 
في معظم الحالات، تُمثل UUIDs كقيم سداسية عشرية. التنسيق الأكثر استخدامًا هو تنسيق 8-4-4-4-12، xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx، حيث يمثل كل x 4 بتات. التنسيقات الأخرى المعروفة هي تنسيق 8-4-4-4-12 مع الأقواس، {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}، كما هو الحال في أنظمة Microsoft، مثل Windows، أو xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx، حيث تُزال جميع الواصلات. في بعض الحالات، من الممكن أيضًا أن يكون لديك xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx مع البادئة "0x" أو اللاحقة "h" للإشارة إلى القيم السداسية عشرية. يُقدم التنسيق باستخدام الواصلات مع نظام المتغيرات الأحدث. قبل ذلك، كان تنسيق Apollo القديم يستخدم تنسيقًا مختلفًا قليلاً: 34dc23469000.0d.00.00.7c.5f.00.00.00. الجزء الأول هو الوقت (الوقت المرتفع والوقت المنخفض مجتمعين). تُخطى الحقل المحجوز. يأتي حقل العائلة مباشرة بعد النقطة الأولى، لذلك في هذه الحالة 0d (13 في النظام العشري) لـ DDS (خدمة توزيع البيانات). أما الأجزاء المتبقية، والتي تُفصل كل منها بنقطة، فهي بايتات العقدة.

الشكل الصغير للقيم السداسية عشرية هو التنسيق المفضل بشكل عام. وبشكل خاص في بعض السياقات مثل تلك المحددة في التوصية ITU-T. X.667، مطلوب الأحرف الصغيرة عند إنشاء النص، ولكن يجب أيضًا قبول الإصدار بالأحرف الكبيرة.

يمكن تمثيل UUID كعدد صحيح مكون من 128 بت. على سبيل المثال، يمكن أيضًا تمثيل UUID 550e8400-e29b-41d4-a716-446655440000 على النحو التالي 113059749145936325402354257176981405696. لاحظ أنه من الممكن الحصول على قيم موقعة وغير موقعة إذا عُين البت الأول من UUID على 1.

يمكن تمثيل UUID كرقم ثنائي مكون من 128 بت. على سبيل المثال، يمكن أيضًا تمثيل UUID 550e8400-e29b-41d4-a716-446655440000 على النحو التالي: 0101010100001110100001000000000111000101010110101000001110101010010101001110001011001010101010101000100000000000000000.

يسجل RFC 9562 مساحة اسم "uuid". يجعل هذا من الممكن إنشاء URNs من UUIDs، مثل urn:uuid:550e8400-e29b-41d4-a716-446655440000 . يُستخدم الشكل العادي 8-4-4-4-12 لهذا الغرض. من الممكن أيضًا إنشاء OID URN من UUIDs، مثل urn:oid:2.25.113059749145936325402354257176981405696 . في هذه الحالة، يُستخدم تنسيق العدد العشري غير الموقّع. يوصى باستخدام "uuid" URN بدلاً من "oid".

 الاصطدامات 
يحدث التصادم عندما يُنشئ نفس UUID أكثر من مرة وتعيينه إلى مراجع مختلفة. في حالة استخدام إصدارات 1 و2 القياسية من UUIDs باستخدام عناوين MAC فريدة من بطاقات الشبكة، من غير المحتمل أن تحدث تصادمات، مع زيادة الاحتمال فقط عندما يختلف التنفيذ عن المعايير، إما عن غير قصد أو عن قصد.

على النقيض من معرفات UUID للإصدار 1 والإصدار 2 التي أُنشئت باستخدام عناوين MAC، مع معرفات UUID للإصدار 1 و-2 التي تستخدم معرفات عقد أُنشئت عشوائيًا، ومعرفات UUID للإصدار 3 والإصدار 5 المستندة إلى التجزئة، ومعرفات UUID العشوائية للإصدار 4، يمكن أن تحدث تصادمات حتى بدون مشاكل في التنفيذ، وإن كان الاحتمال صغيرًا جدًا بحيث يمكن تجاهلها عادةً. يمكن حساب هذا الاحتمال بدقة بناءً على تحليل مشكلة عيد الميلاد.

على سبيل المثال، عدد إصدارات UUID العشوائية من الإصدار 4 التي يجب إنشاؤها للحصول على احتمال 50% لحدوث تصادم واحد على الأقل هو 2.71 كوينتيليون، محسوبًا على النحو التالي:

سيكون هذا الرقم معادلاً لتوليد 1 مليار معرف UUID في الثانية لمدة 86 عامًا تقريبًا سنين. ملف يحتوي على هذا العدد من UUIDs، بمعدل 16 بايت لكل UUID، سيكون حوالي 43.4 إكسابايت (37.7 إي آي بي).

يُقرب أصغر عدد من معرفات UUID للإصدار 4 التي يجب إنشاؤها لاحتمالية العثور على تصادم لتكون p بواسطة الصيغة

وبالتالي، فإن احتمال العثور على نسخة مكررة ضمن 103 تريليون إصدار 4 من UUIDs هو واحد في المليار.

لقد حدثت تصادمات عندما قام المصنعون بتعيين UUID افتراضي لمنتج، مثل اللوحة الأم، ثم فشلوا في الكتابة فوق UUID الافتراضي لاحقًا في عملية التصنيع. على سبيل المثال، يظهر UUID 03000200-0400-0500-0006-000700080009 على العديد من الوحدات المختلفة من اللوحات الأم التي تحمل علامة Gigabyte التجارية.

 الاستخدامات 

 أنظمة الملفات 
تتضمن الاستخدامات المهمة أدوات مساحة مستخدم نظام الملفات ext2 / ext3 / ext4 (يستخدم e2fsprogs معرف libuuid الذي توفره util-linux )، وLVM، وأقسام LUKS المشفرة، GNOME، KDE، macOS، ومعظمها مشتق من التنفيذ الأصلي بواسطة Theodore Ts'o."ext2/e2fsprogs.git - Ext2/3/4 filesystem userspace utilities". Kernel.org. Retrieved 9 January 2017. تُخزن "علامة القسم" و"معرف القسم UUID" في الكتلة الفائقة . كلاهما جزء من نظام الملفات وليس القسم. على سبيل المثال، تحتوي ext2–4 على UUID، بينما لا تحتوي NTFS أو FAT32 على ذلك. الكتلة الفائقة هي جزء من نظام الملفات، وبالتالي فهي متضمنة بالكامل داخل القسم، وبالتالي فإن القيام  يترك كل من sda1 وsdb1 بنفس التسمية وUUID.

 جداول التقسيم 
جدول تقسيم GUID (GUID) هو أحد الأمثلة التي تستخدم GUIDs لتصنيف أنواع التقسيم.

 الاتصال عن بعد 
هناك عدة أنواع من GUIDs المستخدمة في نموذج كائن المكون (COM) الخاص بشركة Microsoft:

  – interface identifier; (The ones that are registered on a system are stored in the Windows Registry at  )
  – class identifier; (Stored at ). In practice it is not entirely separate from the  space, because remoting the interface can require a proxy/stub object which some toolsets used to create with a  equal to the interface's .
  – type library identifier; (Stored at )
  – category identifier; (its presence on a class identifies it as belonging to certain class categories, listed at )

 قواعد البيانات 
تُستخدم معرفات UUID عادةً كمفتاح فريد في جداول قاعدة البيانات. الدالة في Microsoft SQL Server الإصدار 4 تقوم Transact-SQL بإرجاع معرفات UUID العشوائية القياسية للإصدار 4، بينماتعيد دالة معرفات مكونة من 128 بت مشابهة لـ UUIDs والتي يُلتزم بالصعود بالتسلسل حتى إعادة تشغيل النظام التالية. قاعدة بيانات أوراكللا تقوم دالة بإرجاع GUID قياسي، على الرغم من الاسم. بدلاً من ذلك، فإنه يقوم بإرجاع قيمة RAW مكونة من 16 بايت و128 بت استنادًا إلى معرف المضيف ومعرف العملية أو الخيط، وهو مشابه إلى حد ما لـ GUID. يحتوي PostgreSQL علىنوع بيانات ويمكنه إنشاء معظم إصدارات UUIDs من خلال استخدام الوظائف من الوحدات النمطية. يوفر MySQLوظيفة، التي تولد إصدارات UUID القياسية 1.

 الوقت المجمع-GUID 
قد تؤدي الطبيعة العشوائية لمعرفات UUID القياسية للإصدارات 3 و4 و5، وترتيب الحقول داخل الإصدارات القياسية 1 و2، إلى حدوث مشكلات في موقع قاعدة البيانات أو أدائها عند استخدام معرفات UUID كمفاتيح أساسية. على سبيل المثال، في عام 2002 أبلغ جيمي نيلسون عن تحسن كبير في الأداء مع Microsoft SQL Server عندما عُدلت معرفات UUID الخاصة بالإصدار 4 المستخدمة كمفاتيح لتشمل لاحقة غير عشوائية تعتمد على وقت النظام. لقد أدى هذا النهج المسمى "COMB" (معرّفات GUID الزمنية المجمعة) إلى زيادة احتمالية تكرار معرفات UUID بشكل كبير، كما اعترف نيلسون، لكن نيلسون لم يتطلب سوى التفرد داخل التطبيق. من خلال إعادة ترتيب وترميز الإصدارين 1 و2 من معرفات UUID بحيث يأتي الطابع الزمني أولاً، يمكن تجنب فقدان أداء الإدراج.

 انظر أيضا 

 هجوم عيد الميلاد
 معرف الكائن (OID)
 معرف الموارد الموحد (URI)
 معرف ندفة الثلج

 مراجع 

 روابط خارجية 

 التوصية ITU-T X.667 (الوصول المجاني)
 ISO/IEC 9834-8:2014 (مدفوع)
 ملاحظة فنية TN2166 - أسرار GPT - مطور Apple
 توثيق UUID - معرف Apache Commons
 مفتاح CLSID - مستندات Microsoft
 معرف فريد عالمي - مكتبة المجموعة المفتوحة
 أداة فك تشفير UUID
 نبذة تاريخية عن UUID
 فهم كيفية إنشاء معرفات UUID

تصنيف:تأسيسات سنة 1996
تصنيف:إدارة ويندوز
تصنيف:معرفات عالمية
تصنيف:صفحات بترجمات غير مراجعة