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

الموسوعة الحرة

المعرّف الفريد عالميًا ( UUID ) هو رقم مكون من 128 بت يُستخدم لتعريف المعلومات في أنظمة الحاسوب. ويُستخدم أيضًا مصطلح المعرّف الفريد عالميًا ( GUID )، عادةً في البرامج التي تُنتجها شركة مايكروسوفت . [ 1 ]

عند إنشائها وفقًا للمعايير، تكون معرّفات UUID فريدة من نوعها عمليًا. ولا تعتمد فرادتها على جهة تسجيل مركزية أو تنسيق بين الجهات التي تُنشئها، على عكس معظم أنظمة الترقيم الأخرى.

مع أن احتمال تكرار مُعرّف فريد عالمي (UUID) ليس معدومًا، إلا أنه قريب جدًا من الصفر لدرجة تجعله ضئيلاً للغاية. [ 2 ] وبالتالي، يُمكن لأي شخص إنشاء أعداد كبيرة من مُعرّفات UUID واستخدامها كمعرّفات مع يقين شبه تام بأنها لا تُكرر مُعرّفات UUID التي أنشأها أو سينشئها آخرون، حيث أن التنسيق الوحيد المطلوب لتحقيق التفرد هو الالتزام بمعايير UUID. لذا، يُمكن للمعلومات المُصنّفة بمُعرّفات UUID من قِبل جهات مستقلة أن تتعايش في قواعد البيانات أو القنوات نفسها، مع احتمال ضئيل للغاية للتكرار.

إن اعتماد معرّفات UUID واسع الانتشار، حيث توفر العديد من منصات الحوسبة الدعم لإنشائها ولتحليل تمثيلها النصي.

تاريخ

استخدم حاسوب أبولو معرّفات فريدة عالمية (UUIDs) في نظام الحوسبة الشبكية (NCS)، الذي أُطلق عام 1987، بتصميم مستوحى من المعرّفات الفريدة ذات 64 بت لنظام التشغيل Domain/OS ، وهو نظام تشغيل سابق لأبولو . [ 3 ] اعتمدت منصات مايكروسوفت ويندوز تصميم NCS (ولاحقًا تصميم DCE) كمعرّفات فريدة عالمية (GUIDs) في أوائل التسعينيات.

في وقت لاحق، استخدمت مؤسسة البرمجيات المفتوحة (OSF) معرّفات UUID في بيئة الحوسبة الموزعة (DCE)، بتصميم يعتمد جزئيًا على معرّفات NCS UUID. وقد وُثِّق ذلك في مواصفات DCE 1.1 RPC عام 1996، وفي مواصفات DCE 1.1 لخدمات المصادقة والأمان، المنشورة عام 1997. [ 4 ] [ 5 ] [ 6 ] كما وثّقت المنظمة الدولية للمعايير/اللجنة الكهروتقنية الدولية (ISO/IEC) تصميم DCE عام 1996، في معيار ISO / IEC 11578:1996 " تكنولوجيا المعلومات - الربط البيني للأنظمة المفتوحة - استدعاء الإجراءات عن بُعد ". [ 7 ]

في يوليو 2005، نشرت فرقة عمل هندسة الإنترنت (IETF) معيار RFC 4122 [ 1 ] ، الذي سجّل أيضًا مساحة اسم URN لمعرّفات UUID. وفي الوقت نفسه، قام الاتحاد الدولي للاتصالات (ITU) بتوحيد معرّفات UUID، استنادًا إلى المعايير السابقة والإصدارات المبكرة من RFC 4122، في توصية ITU-T X.667 ISO/IEC 9834-8. وكان هذا مكافئًا تقنيًا لـ RFC 4122 [ 8 ].

المواصفات الحالية لـ IETF هي RFC 9562 [ 9 ] ، وهي معيار مقترح نُشر في مايو 2024. وقد حددت هذه المواصفات ثلاثة إصدارات جديدة من UUID (6-8) من صيغة DCE. وتُستخدم حاليًا معرّفات UUID من تصميم DCE/IETF، مع توفير إمكانية التوافق مع الإصدارات السابقة من معرّفات UUID القديمة الخاصة بـ Apollo NCS ومعرّفات GUID الخاصة بـ Microsoft.

كان مؤلفو RFC 4122 هم بول ليتش، ومايكل ميلينغ ، وريتش سالز ، وكان مؤلفا المسودة الأولية للإنترنت عام 1997 [ 10 ] هما ليتش وسالز. شغل ليتش منصب مهندس نظام التشغيل Domain/OS، واستمر في العمل لدى أبولو كمصمم لنظام NCS، ثم ساهم، بصفته مهندسًا معماريًا متميزًا لدى مايكروسوفت، في تصميم OLE/COM/DCOM، حيث أدخل مفهوم UUIDs إلى ذلك المشروع. [ 11 ] وكان ليتش أيضًا أحد مؤلفي RFC 9562. أما سالز فكان عضوًا في فريق DCE التابع لمؤسسة البرمجيات المفتوحة. [ 12 ] اندمجت أبولو عام 1989 مع هيوليت-باكارد ، العضو المؤسس لمؤسسة البرمجيات المفتوحة. وقد ساهم أعضاء فريق NCS السابقون، بعد انضمامهم إلى هيوليت-باكارد، في إدخال مفهوم UUIDs إلى DCE التابع لمؤسسة البرمجيات المفتوحة. كان ميلينغ عضواً بارزاً في فريق هندسة الإنترنت (IETF)، حيث شغل مقعداً في المجموعة التوجيهية لهندسة الإنترنت، وشارك بشكل كبير في عمل فريق هندسة الإنترنت على معرّفات الموارد الموحدة (URNs). [ 13 ] وقد جمعت RFC 4122 كل هذه الجوانب معاً.

شكل

المعرّف الفريد العالمي (UUID) هو رقم مكون من 128 بت. ويُحدد معنى هذه البتات من خلال نوع المعرّف ، والذي تم تعريف ثلاثة أنواع منه. النوع الأكثر شيوعًا هو النوع الأول، بينما تُستخدم الأنواع الأخرى للتوافق مع الإصدارات السابقة أو للتعريفات المستقبلية. للنوعين الأول والثاني "إصدارات" تُحدد بدورها تفسير المعرّف الفريد العالمي.

المتغيرات

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

  • يُستخدم المتغير 0 (المُشار إليه بنمط البت الواحد 0 xxx 2 ، 0 16 إلى 7 16 ) للتوافق مع الإصدارات السابقة من تنسيق UUID الخاص بنظام الحوسبة الشبكية أبولو 1.5، الذي طُوّر حوالي عام 1987. يتداخل حقل المتغير في مُعرّفات UUID الحالية مع خانة عنوان عائلة UUID في نظام الحوسبة الشبكية، بحيث تحتوي أي مُعرّفات UUID لا تزال قيد الاستخدام على القيمة 0 في البت الأول من حقل المتغير. كما يشمل نطاق ترقيم المتغير 0 مُعرّف UUID الفارغ (Nil UUID).
  • يُشار إلى مُعرّفات UUID من النوع الأول (10 xx 2 ، والتي تظهر على شكل 8 16 ، 9 16 ، a 16 أو b 16 ) باسم مُعرّفات RFC 4122/DCE 1.1 UUID ، أو مُعرّفات "Leach–Salz" UUID، نسبةً إلى مُؤلفي مسودة الإنترنت الأصلية . وهذه هي مُعرّفات UUID المُستخدمة حاليًا.
  • يُستخدم المتغير الثاني (110 × 2 ، c 16 أو d 16 ) للتوافق مع الإصدارات السابقة من معرّفات GUID المستخدمة في Microsoft COM/DCOM. وقد استُخدم هذا التنسيق في معرّفات GUID المبكرة على منصة Microsoft Windows . تُنشئ أدوات Microsoft الحالية معرّفات UUID من المتغير الأول، وليس هذا المتغير. والفرق الرئيسي بين هذا المتغير والمتغير الأول، بالإضافة إلى بت المتغير الإضافي، هو ترتيب البايتات داخل معرّف UUID. وقد أعلن RFC 9562 أن هذا المتغير خارج نطاق هذا المعيار، لذا فإن الإصدارات الثلاثة الجديدة المُعرّفة للمتغير الأول لا تنطبق على المتغير الثاني.
  • يتضمن المتغير 3 (111 x 2 ، e 16 أو f 16 ) الحد الأقصى لـ UUID، ولكنه غير محدد بخلاف ذلك ومحجوز للاستخدام المستقبلي.

الإصدارات

يحتوي كل من متغيري OSF DCE وMicrosoft COM/DCOM (1 و2 على التوالي) على إصدارات ، يُشار إليها بقيمة البتات الأربعة العليا من البايت السابع من UUID. في التمثيلات النصية لـ UUID، يُمثل هذا الرقم الست عشري الذي يلي الواصلة الثانية. لا تحتوي متغيرات Apollo NCS UUID من النوع 0 على إصدارات، حيث يتم تصنيفها فرعيًا عبر "عائلات العناوين" بدلاً من الإصدارات. نصت RFC 9562 [ 9 ] ، التي حددت الإصدارات 6 و7 و8، على أن المتغيرات الأخرى غير متغير OSF DCE 1 "خارج نطاق" RFC، تاركةً لمايكروسوفت تحديد إصدارات جديدة للمتغير 2. مع ذلك، فإن الإصدارات من 1 إلى 5، الموحدة في RFC 4122 [ 1 ] ، هي نفسها في متغير مايكروسوفت، باستثناء ترتيب البايتات.

مقارنة إصدارات UUID
إصداريكتبمصدر الوقتمصدر الإنتروبيا/الهويةأفضل حالة استخدام
1قائم على الوقتغريغوري (100  نانوثانية) وتسلسل الساعةعنوان MACالأنظمة القديمة؛ التفرد الموزع
2أمن DCEتسلسل غريغوري (منخفض الدقة) وساعةالمعرف المحلي (UID/GID) والعقدةبيئات الأمان القائمة على DCE [الأنظمة القديمة]
3قائم على الاسم (MD5)لا شيء (حتمي)مساحة الاسم والاسممعرّفات حتمية؛ تجزئة الأسماء القديمة
4عشوائيلا أحدالتشفير العشوائيللأغراض العامة؛ أقصى قدر من الخصوصية
5قائم على الاسم (SHA-1)لا شيء (حتمي)مساحة الاسم والاسمالمعرفات القطعية؛ مفضلة على الإصدار 3
6مرتبة زمنياًغريغوري (100  نانوثانية) وتسلسل الساعةعنوان MAC أو عنوان عشوائيمفاتيح قاعدة البيانات؛ نسخة مُعاد ترتيبها 1
7مرتبة زمنياًحقبة يونكس (مللي ثانية)التشفير العشوائيمفاتيح قواعد البيانات الحديثة؛ توطين عالي
8مخصصعاملالتنفيذ محددتصميمات تجريبية أو خاصة بالتطبيقات

الإصداران 1 و 6 (التاريخ والوقت وعنوان MAC)

يُدمج الإصدار الأول عنوان MAC ذي 48 بت الخاص بـ "العقدة" (أي الحاسوب الذي يُنشئ UUID) مع طابع زمني ذي 60 بت. في الأنظمة التي تستخدم عناوين MAC ذات 64 بت من نوع EUI-64، تُستخدم أقل 48 بت أهمية. كما يُمكن استخدام رقم عشوائي ذي 48 بت.

الطابع الزمني هو عدد الفترات الزمنية التي تبلغ 100 نانوثانية منذ منتصف ليل 15 أكتوبر 1582 بالتوقيت العالمي المنسق (UTC)، وهو التاريخ الذي اعتُمد فيه التقويم الغريغوري لأول مرة. تنص RFC 4122 على أن قيمة الوقت تتكرر في عام 3409 ميلادي، [ 1 ] اعتمادًا على الخوارزمية المستخدمة، مما يعني أن الطابع الزمني ذو 60 بت هو قيمة مُوقّعة. مع ذلك، تتعامل بعض البرامج، مثل مكتبة libuuid، مع الطابع الزمني على أنه قيمة غير مُوقّعة، مما يجعل وقت التكرار في عام 5236 ميلادي. [ 14 ]

تُستخدم سلسلة ساعة "تفريد" مكونة من 13 أو 14 بت لتمديد الطابع الزمني ومعالجة الحالات التي لا يتقدم فيها تردد ساعة المعالج بالسرعة الكافية، أو عند وجود معالجات متعددة ومولدات UUID لكل عقدة. عندما يتم توليد معرّفات UUID بسرعة تفوق سرعة تقدم ساعة النظام، يمكن زيادة البتات الدنيا من الطابع الزمني وسلسلة الساعة لمحاكاة دقة أعلى وضمان التفرد. مع كل معرّف UUID من الإصدار 1 يُقابل نقطة واحدة في الفضاء (العقدة) والوقت (الفترات وسلسلة الساعة)، فإن احتمال تطابق معرّفين UUID من الإصدار 1 تم توليدهما بشكل صحيح يكاد يكون معدومًا. بما أن مجموع الوقت وسلسلة الساعة يبلغ 74 بت، فإن 2^ 74 (1.8 × 10^ 12 )يمكن إنشاء 22 أو 18 سيكستليون من معرّفات UUID الإصدار 1 لكل معرّف عقدة، بمعدل متوسط ​​أقصى يبلغ 163 مليار في الثانية لكل معرّف عقدة. [ 1 ]

يكون تخطيط UUID الإصدار 1 كما يلي:

 تخطيط سجل UUID الإصدار 1
اسمالحجم (بايت)الطول (بأرقام سداسية عشرية)محتويات
الوقت_منخفض48عدد صحيح يمثل أقل 32 بت من الوقت
منتصف الوقت24عدد صحيح يمثل الأجزاء الستة عشر الوسطى من الوقت
time_hi_and_version24نسخة من أربعة بتات في البتات الأكثر أهمية، متبوعة بالبتات الـ 12 العليا من الوقت
clock_seq_hi_and_res clock_seq_low24متغير من اثنين إلى ثلاثة بتات في البتات الأكثر أهمية، متبوعًا بتسلسل الساعة المكون من 13 أو 14 بت
العقدة612معرف العقدة ذو 48 بت

الإصدار 6 مطابق للإصدار 1 باستثناء ترتيب بتات الطابع الزمني. في الإصدار 6، تُرتّب بتات الطابع الزمني من الأكثر أهمية إلى الأقل أهمية. يُمكّن هذا الأنظمة من فرز مُعرّفات UUID من الإصدار 6 حسب ترتيب إنشائها ببساطة عن طريق فرزها معجميًا. من خلال إعادة ترتيب بايتات الطابع الزمني الأصلي (أعلى-أدنى) في نظام NCS لتمكين الفرز، يُصبح الإصدار 6 أقرب إلى مُعرّفات UUID من الإصدار 0 القديم في نظام NCS من الإصدار 1.

تخطيط سجل UUID الإصدار 6
مجالالعرض (بت)وصف
ذروة الوقت32أهم 32 بت من الطابع الزمني ذي الـ 60 بت
منتصف الوقت16البتات الستة عشر الوسطى من الطابع الزمني ذي الـ 60 بت
إصدار4رقم الإصدار ذو 4 بت (0110)
الوقت_منخفض12أقل 12 بت أهمية من الطابع الزمني ذي 60 بت
متغير2النسخة ذات البتتين (10)
clock_seq14تسلسل الساعة ذو 14 بت
العقدة48معرف العقدة ذو 48 بت (عادةً ما يكون عنوان MAC)

الإصدار 2 (التاريخ والوقت وعنوان MAC، إصدار أمان DCE)

يخصص كل من RFC 4122 و9562 [ 9 ] الإصدار 2 لمعرفات UUID الخاصة بـ "أمان DCE"، لكنهما لا يقدمان أي تفاصيل. ويعلن RFC 9562 أنها "خارج نطاق" هذا التعريف. وتتجاهل العديد من تطبيقات ومكتبات UUID الإصدار 2. ومع ذلك، فإن مواصفات الإصدار 2 من معرفات UUID مقدمة من مواصفات خدمات المصادقة والأمان DCE 1.1. [ 6 ]

تخطيط سجل UUID الإصدار 2
مجالالعرض (بت)وصف
المعرف المحلي32معرف محلي 32 بت (عادةً ما يكون معرف مستخدم أو معرف مجموعة POSIX)
منتصف الوقت16البتات الستة عشر الوسطى من الطابع الزمني ذي الـ 60 بت
إصدار4رقم الإصدار المكون من أربعة بتات (0010)
time_hi12أعلى 12 بت من الطابع الزمني
متغير2النسخة ذات البتتين (10)
clock_seq_low6البتات الستة المنخفضة من تسلسل الساعة
local_id_domain8نطاق المعرف (على سبيل المثال، 0 لمعرف المستخدم، 1 لمعرف المجموعة)
العقدة48معرف العقدة ذو 48 بت (عادةً ما يكون عنوان MAC)

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

وبالتالي، تُعدّ مُعرّفات UUID من الإصدار الثاني وسيلةً لدمج مُعرّف محليّ ذي 32 بت، خاصّ بالعقدة، من نوع مُحدّد ذي 8 بت ("النطاق")، مع مُعرّف العقدة وطابع زمنيّ ذي أصل ميلاديّ، ما يُحوّل المُعرّف الخاصّ بالعقدة إلى مُعرّف فريد عالميًا. لكنّ المقابل هو أنّ الطابع الزمنيّ ذو دقة منخفضة مُقارنةً بالطوابع الزمنية في الإصدار الأول، إذ يتكرر مرة واحدة فقط كل 429.49  ثانية، أي ما يزيد قليلًا عن 7  دقائق، وهو ما يختلف تمامًا عن التكرارات التي تبلغ 100 نانوثانية في الإصدار الأول. [ 15 ]

الإصداران 3 و 5 (القائمة على اسم النطاق)

يتم توليد معرّفات UUID من الإصدارين 3 و5 عن طريق تجزئة معرّف مساحة الاسم والاسم. يستخدم الإصدار 3 خوارزمية MD5 للتجزئة، بينما يستخدم الإصدار 5 خوارزمية SHA-1 . [ 9 ] يُعدّ هذا مفيدًا عندما تحتاج الأنظمة إلى توليد معرّف UUID نفسه بشكل حتمي بناءً على مجموعة من الأسماء أو المعرّفات الأخرى، دون الحاجة إلى التنسيق.

معرّف مساحة الاسم هو نفسه معرّف فريد عالمي (UUID). يوفر معيار RFC معرّفات فريدة عالمية ثابتة لتمثيل مساحات الأسماء لعناوين URL ، وأسماء النطاقات المؤهلة بالكامل ، ومعرّفات الكائنات ، والأسماء المميزة X.500 ؛ ولكن يمكن استخدام أي معرّف فريد عالمي مرغوب فيه كمعرّف لمساحة الاسم. يوجد سجل IANA لمعرّفات مساحات الأسماء الإضافية.

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

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

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

الإصدار 4 (عشوائي)

يتم إنشاء مُعرّف فريد عالمي (UUID) من الإصدار 4 عشوائيًا. وكما هو الحال في مُعرّفات UUID الأخرى، تُستخدم أربعة بتات للإشارة إلى الإصدار 4، وبتّان أو ثلاثة بتات للإشارة إلى النوع (10^ 2 أو 110^ 2 للنوعين 1 و2 على التوالي). وبالتالي، بالنسبة للنوع 1 (أي معظم مُعرّفات UUID)، سيحتوي مُعرّف UUID عشوائي من الإصدار 4 على ستة بتات مُحددة مُسبقًا للنوع والإصدار، تاركًا 122 بتًا للجزء المُنشأ عشوائيًا، ليصبح المجموع 2^ 122 ، أو 5.3 × 10 ^22 بت.يوجد 36 (5.3 أنديسيليون ) من معرّفات UUID المحتملة من الإصدار 4، المتغير 1. يوجد نصف هذا العدد من معرّفات UUID المحتملة من الإصدار 4، المتغير 2 (معرّفات GUID القديمة) نظرًا لوجود بت عشوائي أقل، حيث يتم استهلاك ثلاثة بتات للمتغير. 

الإصدار 7 (طابع زمني وعشوائي)

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

يتم بناؤها على النحو التالي:

تخطيط سجل UUID الإصدار 7
مجالالعرض (بت)وصف
unix_ts_ms48طابع زمني يونكس ذو 48 بت بالمللي ثانية
إصدار4رقم الإصدار المكون من أربعة بتات (0111)
rand_a12دقة طابع زمني تصل إلى 12 بتًا في أجزاء من الألف من الثانية، أو عداد رتابة، أو بيانات شبه عشوائية
متغير2النسخة ذات البتتين (10)
rand_b6262 بت من عداد الرتابة، أو بيانات شبه عشوائية

بالإضافة إلى الطابع الزمني، يُخصص ما مجموعه 74 بتًا للبنى الاختيارية الثلاث (دقة إضافية للطابع الزمني، عداد مُهيأ، بيانات عشوائية). وبغض النظر عن ترتيب هذه البنى واشتراط استخدام 12 بتًا كحد أقصى للدقة الإضافية للطابع الزمني، فإن عدد البتات المخصصة لكل بنية (بما في ذلك إمكانية استخدام 0) وتفاصيلها متروكة للمُنفذ. يمكن تعديل الطوابع الزمنية ذات 48 بتًا أو تشويشها أو إضفاء طابع ضبابي عليها لضمان الرتابة والخصوصية، ويُذكر صراحةً أنه لا يوجد شرط بشأن مدى قرب الطابع الزمني من وقت يونكس الفعلي. ولكن من الواضح أن الهدف هو أن تكون الطوابع الزمنية رتيبة وتقريبية لوقت يونكس، وينص معيار RFC على استخدام الإصدار 8 من UUID المخصص للتصاميم القائمة على الطوابع الزمنية والتي لا تعتمد على وقت يونكس. بخلاف بعض إصدارات UUID الأخرى، فإن إصدارات UUID 7 لا تتضمن عناوين MAC، ويمكنها تجنب مشكلات الخصوصية المرتبطة بها.

الإصدار 8 (مخصص)

في مُعرّف UUID المُخصّص، يكون الإصدار هو 8، ويجب أن تكون بتات المتغير 10، ليصبح المجموع 6 بتات. أما البتات الـ 122 المتبقية فلم يتم تحديدها.

وفقًا لمواصفات RFC، فإنّ معرّفات UUID من الإصدار 8 مخصصة للاستخدامات التجريبية والخاصة بمورّدين محددين. تشير مواصفات RFC، على سبيل المثال، إلى إمكانية استخدام هذا الإصدار لمعرّف قائم على الاسم/التجزئة، يتم إنشاؤه باستخدام دالة تجزئة أحدث من تلك المحددة لإصداري UUID 3 (MD5) و5 (SHA-1). كما تشير مواصفات RFC إلى إمكانية استخدام الإصدار 8 لتصميمات UUID القائمة على الطابع الزمني والتي لا تتناسب مع الإصدارين 6 أو 7، مثل تلك التي تستخدم حقبة زمنية مختلفة.

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

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

استخدام عناوين MAC

على عكس إصدارات UUID الأخرى، تعتمد الإصدارات 1 و2 و6 على عناوين MAC الخاصة ببطاقات الشبكة ، وتعتمد في تفردها جزئيًا على مُعرِّف صادر عن جهة تسجيل مركزية، وهو جزء المُعرِّف الفريد للمنظمة (OUI) من عنوان MAC، والذي يصدره معهد مهندسي الكهرباء والإلكترونيات (IEEE) بشكل أساسي لمصنعي معدات الشبكات. [ 16 ] كما يعتمد تفرد مُعرِّفات UUID المستندة إلى عناوين MAC الخاصة ببطاقات الشبكة على قيام مصنعي بطاقات الشبكة بتخصيص عناوين MAC فريدة لبطاقاتهم بشكل صحيح، وهو أمر، كغيره من عمليات التصنيع، عُرضة للخطأ. وقد تأتي عناوين MAC أيضًا من مصادر أخرى غير بطاقات الشبكة. على سبيل المثال، تتلقى الأجهزة الافتراضية عنوان MAC من نطاق قابل للتكوين في برنامج إدارة الأجهزة الافتراضية (Hypervisor) ، [ 17 ] وتسمح بعض أنظمة التشغيل للمستخدم النهائي بتخصيص عنوان MAC، ولا سيما OpenWrt . [ 18 ] عندما يكون للجهاز عنوان MAC ذو 64 بت من نوع EUI-64، فإن استخدام أقل 48 بت أهمية منه، كما هو موصى به في RFC، قد يؤدي إلى تكرار جزء مُعرّف العقدة من UUID. وبالتالي، قد لا تكون مُعرّفات العقد المستندة إلى عناوين MAC فريدة عالميًا.

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

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

استخدام الطوابع الزمنية

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

فيما يتعلق بترتيب وتصنيف معرّفات UUID، يبدأ الإصداران 1 و2 من "المنتصف" باستخدام البتات الـ 32 الأقل أهمية من الطابع الزمني. هذان الإصداران، بالإضافة إلى الإصدارات من 3 إلى 5 و8، لا يُرتبان ترتيبًا زمنيًا. لم يكن دور الطابع الزمني في هذه الإصدارات من معرّفات UUID هو تسهيل ترتيبها زمنيًا، بل تحقيق التفرد العالمي من خلال تثبيت عملية التوليد مكانيًا وزمنيًا.

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

تسمح هذه المواصفة بتعديل أو "تشويه" الطابع الزمني لنظام يونكس ذي 48 بت للحفاظ على التناسق (ضمان زيادة المعرفات التي يتم إنشاؤها بتتابع سريع) أو لتعزيز الخصوصية. ولأنّ RFC لا يحدد حدًا أقصى صارمًا للانحراف عن وقت يونكس الفعلي، فقد تختلف التطبيقات المختلفة في كيفية موازنتها بين الدقة الزمنية وهذه المتطلبات الأخرى. [ 20 ]

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

لا يشترط معيار RFC 9562 حدًا أدنى لعدد البتات العشوائية في الإصدار 7؛ إذ يسمح لحقول دقة أجزاء من الألف من الثانية وعداد الرتابة بشغل المساحة المتبقية من بنية 128 بت. وبالتالي، تعتمد مقاومة التصادم وقابلية التخمين كليًا على تخصيص هذه البتات في التنفيذ المحدد. [ 21 ]

القيم الخاصة

معرّف UUID الفارغ 00000000-0000-0000-0000-000000000000(أي جميع بتاته فارغة)، والذي يُستخدم للتعبير عن مفهوم "عدم وجود قيمة". [ 9 ] هذا معرّف UUID من نوع "المتغير 0" في NCS، وعائلة عناوينه "0"، ويُعرّف في NCS بأنه "غير مُحدد أو غير مُهيأ". معرّف UUID الأقصى، والذي يُسمى أحيانًا معرّف UUID الشامل، هو FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF(أي جميع بتاته مُفعّلة). يُستخدم هذا للتعبير عن "نهاية قائمة معرّفات UUID". [ 9 ]

التشفير

التمثيل الثنائي

في البداية، صممت شركة Apollo Computer نظام UUID بتنسيق الأسلاك التالي، استنادًا إلى الطابع الزمني ومعرف العقدة، على غرار الإصدارين 1 و 6 [ 4 ] [ 22 ]

تخطيط سجل Apollo NCS UUID
مجالالعرض (بت)وصف
ذروة الوقت32أعلى 32 بت من الطابع الزمني ذي 64 بت بمدة 4 ميكروثانية، الأصل = 1 يناير 1980
الوقت_منخفض16أقل 16 بت من الطابع الزمني ذي 64 بت بمدة 4 ميكروثانية
محجوز16حقل محجوز (غالباً 0)
عائلة8عائلة العناوين (على سبيل المثال، 0x00 لغير المحدد، 0x02 لـ IP، 0x0D لـ DDS)
يستضيف56معرّف المضيف ذو 56 بت (عنوان الشبكة)

أدرجت RFC 4122 معرّفات NCS UUID القديمة كـ"متغير 0" من التنسيق الجديد، وذلك بتداخل بتات المتغير في التنسيق الجديد مع حقل عائلة عناوين NCS. وبما أن أعلى قيمة لعائلة العناوين المُعرّفة في NCS هي 13 (من 00 إلى 0D بالنظام الست عشري)، فإن البت الأكثر أهمية في ثماني بتات المتغير يكون دائمًا 0 لمعرّفات NCS UUID الحالية، بينما يكون هذا البت 1 في متغيرات IETF الثلاثة الأحدث. ونتيجةً لذلك، أصبحت عائلات عناوين NCS من 0 إلى 127 هي "المتغير 0" الجديد، بينما أُعيد تخصيص نطاق ترقيم عائلات عناوين NCS من 128 إلى 255، الذي كان غير مُعرّف في NCS، لمعرّفات IETF ومايكروسوفت UUID من المتغيرات 1 إلى 3. وكانت النتيجة فصل معرّفات NCS UUID القديمة ومعرّفات المتغيرات 1 إلى 3، ما سمح لها بالتعايش في قواعد البيانات نفسها وعلى قنوات الاتصال نفسها.

حقل العائلة / المتغير
MSB 0MSB 1MSB 2عائلة (ثمانية)متغيروصف
0xxx00-0x7F0محجوز. التوافق مع الإصدارات السابقة من Apollo NCS، بالإضافة إلى Nil. يتم تصنيفها فرعياً حسب عائلة العناوين.
10xx80-xBF1معرف OSF DCE الفريد. تم تصنيفه حسب الإصدارات (1-8).
110xC0-xDF2محجوز. التوافق مع الإصدارات السابقة من مايكروسوفت. مصنف حسب الإصدارات (1-5).
111xE0-xFF3محجوز (مستقبلي، بالإضافة إلى الحد الأقصى).

يستخدم مُعرّف UUID القديم لنظام Apollo NCS التنسيق الموضح في الجدول السابق. أما مُعرّف UUID الخاص بـ OSF DCE، فقد وُصف في RFC 9562 [ 9 ] . ويُمكن الاطلاع على مُعرّف UUID الخاص بـ Microsoft COM / DCOM في وثائق Microsoft، ولكن بالنسبة للإصدارات من 1 إلى 5، فهو مُطابق عمومًا لمُعرّف DCE، باستثناء بتّات المُعرّف الإضافية وترتيب البايتات. (انظر القسم التالي). ولا يتوفر الإصدار من 6 إلى 8 من المُعرّف 2.

مجالالعرض (بت)وصف
RFCs 4122 / 9562 تخطيط المتغيرات 1-3
البيانات_أ32أول 32 بت من الطابع الزمني أو البيانات
بيانات_ب16ثاني 16 بت من الطابع الزمني أو البيانات
إصدار4رقم الإصدار (البتات من 48 إلى 51)
بيانات_ج12الجزء الثالث المكون من 12 بت من الطابع الزمني أو البيانات (البتات من 52 إلى 63)
متغير2-3بتات RFC 9562 المتغيرة (10x، 110، 111، البتات 64-66)
بيانات_د13-14تسلسل الساعة أو البيانات الأخرى (البتات من 66 أو 67 إلى 79)
بيانات_هـ48معرف العقدة ذو 48 بت أو بيانات أخرى (البتات من 80 إلى 127)

يختلف تفسير كتل البتات المختلفة في المتغيرين 1 و2 وفقًا لـ "الإصدار". في المتغير 2، يتم تبديل بايتات data_a وdata_b وversion|data_c، بينما لا يتم تبديل بايتات variant|data_d وdata_e.

ترتيب البايتات

يتم ترميز معرّفات UUID من النوع الأول بشكل تسلسلي باستخدام نظام big-endian . على سبيل المثال، 00112233-4455-6677-8899-aabbccddeeffيتم ترميزها على شكل بايتات 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff. [ 23 ] [ 24 ]

على النقيض من ذلك، فإن معرّفات UUID من النوع الثاني (GUIDs)، المستخدمة تاريخيًا في مكتبات Microsoft COM/OLE ، تأتي بتنسيق مختلط النهاية ، حيث تكون الحقول الثلاثة الأولى (المقابلة للحقول الفرعية للطابع الزمني في الإصدار 1) بتنسيق النهاية الصغرى ، بينما يُرسل الحقلان الأخيران كمصفوفات بايت بتنسيق النهاية الكبرى . مثال UUID المذكور أعلاه، لو كان من النوع الثاني، لكان مُشفّرًا على الشبكة على النحو التالي 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff: [ 25 ] [ 26 ]. تُرسل جميع الإصدارات ضمن النوع الثاني بهذا الترتيب للبايتات، بما في ذلك الإصدارات التي لا تحتوي على حقول رقمية، مثل 3 و4 و5.

التمثيل النصي

في معظم الحالات، تُمثَّل مُعرِّفات UUID بقيم سداسية عشرية مفصولة بشرطات. يُعدّ تنسيق 8-4-4-4-12 الأكثر استخدامًا، وهو عبارة عن سلسلة من 32 رقمًا سداسيًا عشريًا مع أربع شرطات . تفصل الشرطات xxxxxxxx-xxxx-vxxx-wxxx-xxxxxxxxxxxxحقول الإصدار 1، ولكن يُستخدم التنسيق نفسه عادةً لجميع الإصدارات. يُمثِّل كل رقم سداسي عشري 4 بتات؛ يُمثِّل v...w{}

على الرغم من أنه لا يزال يتم حذفها أحيانًا، فقد تم تقديم التنسيق الذي يحتوي على شرطات مع نظام المتغيرات الأحدث. قبل ذلك، كان تنسيق أبولو القديم يستخدم تنسيقًا مختلفًا قليلاً 34dc23469000.0d.00.00.7c.5f.00.00.00. الجزء الأول هو الوقت (مجموع الوقت الأعلى والوقت الأدنى). يتم تخطي الحقل المحجوز. يأتي حقل العائلة مباشرة بعد النقطة الأولى، لذا في هذه الحالة 0d(13 بالنظام العشري) لخدمة توزيع البيانات (DDS) . الأجزاء المتبقية، كل منها مفصول بنقطة، هي بايتات العقدة.

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

يُسجّل RFC 4122 [ 1 ] مساحة اسم "uuid" لمعرّفات الموارد الموحدة (URNs). وهذا يُتيح إمكانية تكوين معرّفات الموارد الموحدة من معرّفات UUID، مثل urn:uuid:550e8400-e29b-41d4-a716-446655440000. ويُستخدم التنسيق القياسي 8-4-4-4-12 لهذا الغرض.

من الممكن أيضًا إنشاء مُعرّف كائن (OID) من مُعرّف فريد عالمي (UUID)، مما يُتيح بدوره طريقة أخرى لإنشاء مُعرّف موارد موحد (URN) منه. مُعرّف الكائن (OID) في المثال السابق هو 2.25.113059749145936325402354257176981405696. يُسبق الشكل العشري غير المُوقّع لمُعرّف UUID بالبادئة 2.25، والتي تُمثّل {joint-iso-itu-t(2) uuid(25)}"القوس" ضمن نطاق اسم مُعرّف الكائن (OID). يُمكن إضافة بادئة أخرى urn:oid:لإنشاء شكل ثانٍ من مُعرّف الموارد الموحد (URN) لمُعرّفات UUID. بشكل عام، uuidيُفضّل استخدام مُعرّف الموارد الموحد (URN) على مُعرّف oidالكائن (UUID).

التصادمات

يحدث التصادم عندما يتم إنشاء نفس المعرّف الفريد العالمي (UUID) أكثر من مرة ويتم تخصيصه لمراجع مختلفة. في حالة العديد من معرّفات UUID القياسية من الإصدار 1 أو 2 أو 6 التي تستخدم عناوين MAC فريدة و/أو طوابع زمنية، لا يمكن أن تحدث التصادمات إلا نتيجة خطأ، مثل مشاكل التصنيع أو اختلال التوقيت أو أخطاء البرامج.

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

عادةً ما يكون احتمال حدوث ذلك ضئيلاً للغاية لدرجة أنه يمكن تجاهله، ويمكن حسابه بدقة بناءً على تحليل مسألة عيد الميلاد . [ 27 ] على سبيل المثال، يبلغ عدد معرّفات UUID العشوائية من الإصدار 4 التي يجب إنشاؤها للحصول على احتمال 50% لحدوث تصادم واحد على الأقل 2.71  كوينتيليون، ويتم حسابه على النحو التالي: [ 28 ]

ن≈12+14+ln⁡(2)×2123≈2.71×1018.{\displaystyle n\approx {\frac {1}{2}}+{\sqrt {{\frac {1}{4}}+\ln(2)\times 2^{123}}}\approx 2.71\times 10^{18}.}

هذا العدد يعادل توليد  مليار مُعرّف فريد عالمي (UUID) في الثانية الواحدة لمدة 86  عامًا تقريبًا. ملف يحتوي على هذا العدد من المُعرّفات، بحجم 16 بايت لكل مُعرّف، سيبلغ حجمه حوالي 43.4 إكسابايت (37.7 إكسابايت ) - وهو ملف يحتوي على قائمة بالمُعرّفات فقط، أكبر بكثير من أكبر قواعد البيانات الموجودة حاليًا، والتي يبلغ حجمها حوالي 100 بيتابايت (مثل فهارس جوجل للويب). إذا تم توليد المُعرّفات وفقًا للمعايير، فمن المرجح أن تكون المُعرّفات المُكررة ناتجة عن انعكاسات بتية (ما يُسمى باضطراب الحدث الفردي ) بسبب مرور الأشعة الكونية عبر الذاكرة أو وحدة التخزين، أكثر من كونها ناتجة عن خطأ في عملية توليد المُعرّفات.  

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

2123×ln⁡11-ص.{\displaystyle {\sqrt {2^{123}\times \ln {\frac {1}{1-p}}}}.}

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

الاستخدامات

أنظمة الملفات

تستخدم العديد من أنواع أنظمة الملفات (على سبيل المثال، ext4 و Btrfs ) معرّفًا فريدًا عالميًا (UUID) لتمييز كل نظام ملفات بشكل فريد لنظام التشغيل. ( لا يستخدم NTFS و FAT32 هذا المعرّف، بل يستخدمان معرّفًا فريدًا عالميًا أقصر (UID) بدلاً من ذلك.) [ 29 ]

أدوات مساحة المستخدم لنظام الملفات، [ 30 ] معظمها مشتق من التنفيذ الأصلي بواسطة ثيودور تسو ، [ 14 ] وبالتالي تستخدم UUIDs.

قد يقوم ملف /etc/fstabبتعيين نقاط التحميل بناءً على هذه المعرفات الفريدة العالمية (أو معرف فريد عالمي لقسم نظام FAT32 EFI (ESP)):

# device-uuid mount-point fs-type options dump pass UUID = b18e3b6c-ccb7-4308-b527-35e5e6ee2145 / btrfs defaults 0 0 UUID = 103C-86D6 /efi vfat utf8 0 2 UUID = 64f3cb6a-e70e-45e5-8b90-d86cddbab7bb swap swap defaults 0 0 UUID = eda746c6-1f1b-4cf1-9225-d8b0b46511cc /mnt/Stuff btrfs defaults 0 0

جداول التقسيم

يستخدم جدول تقسيم GUID ( GPT) معرّفات UUID (تُسمى هنا "GUID") لتحديد الأقسام وأنواعها. يتم تعيين معرّفات الأقسام الفريدة محليًا بواسطة نظام التشغيل. أما معرّفات أنواع الأقسام فهي أرقام معروفة، وعادةً ما يتم تعيينها من قِبل مُصنّعي أنظمة التشغيل أو الأجهزة.

مايكروسوفت كوم

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

  • IID – مُعرّف الواجهة؛ (يتم تخزين المُعرّفات المُسجلة على النظام في سجل ويندوز في [HKEY_CLASSES_ROOT\Interface][ 31 ] )
  • CLSID– مُعرِّف الفئة؛ (مُخزَّن في [HKEY_CLASSES_ROOT\CLSID]). عمليًا، لا ينفصل تمامًا عن مساحة IID ، لأن الوصول عن بُعد إلى الواجهة قد يتطلب كائنًا وسيطًا/بديلًا ، والذي كانت بعض مجموعات الأدوات تستخدمه لإنشائه بمعرّف فئة (CLSID) يساوي معرّف واجهة المستخدم (IID ).
  • LIBID – مُعرِّف مكتبة الأنواع؛ (مخزَّن في [HKEY_CLASSES_ROOT\TypeLib][ 32 ] )
  • CATID – مُعرّف الفئة؛ (وجوده على فئة ما يُحدد انتمائها إلى فئات معينة، مُدرجة في [HKEY_CLASSES_ROOT\Component Categories][ 33 ] )

قواعد البيانات

تُستخدم مُعرّفات UUID عادةً كمفاتيح فريدة في جداول قواعد البيانات . تُعيد دالة NEWID في Microsoft SQL Server الإصدار 4 Transact-SQL مُعرّفات UUID عشوائية قياسية من الإصدار 4، بينما تُعيد دالة NEWSEQUENTIALID مُعرّفات 128 بت تُشبه مُعرّفات UUID، والتي يتم تثبيتها بالتسلسل حتى إعادة تشغيل النظام التالية. [ 34 ] لا تُعيد دالة SYS_GUID في قاعدة بيانات Oracle مُعرّف GUID قياسيًا، على الرغم من اسمها. بدلاً من ذلك، تُعيد قيمة RAW بحجم 128 بت و16 بايت، بناءً على مُعرّف المضيف ومُعرّف العملية أو مؤشر الترابط، وهو ما يُشبه إلى حدٍ ما مُعرّف GUID. [ 35 ] يحتوي PostgreSQL على نوع بيانات UUID [ 36 ] ويمكنه إنشاء مُعظم إصدارات مُعرّفات UUID باستخدام دوال من الوحدات النمطية. [ 37 ] [ 38 ] يُوفر MySQL دالة UUID تُنشئ مُعرّفات UUID قياسية من الإصدار 1. [ 39 ]

قد تُسبب الطبيعة العشوائية لمعرّفات UUID القياسية في الإصدارات 3 و4 و5، وترتيب الحقول في الإصدارين 1 و2، مشاكل في موضع البيانات أو الأداء عند استخدام معرّفات UUID كمفاتيح أساسية . على سبيل المثال، في عام 2002، أبلغ جيمي نيلسون عن تحسن ملحوظ في أداء Microsoft SQL Server عند تعديل معرّفات UUID في الإصدار 4 المستخدمة كمفاتيح لتضمين لاحقة غير عشوائية تعتمد على وقت النظام. ومن خلال إعادة ترتيب معرّفات UUID في الإصدارين 1 و2 وتشفيرها بحيث يأتي الطابع الزمني أولًا، يمكن تجنب فقدان أداء الإدخال. [ 40 ] هذا هو الأساس المنطقي للإصدارين 6 و7 من المتغير 1 (DCE)، المُوحّد في RFC 9562 [ 9 ] .

أمثلة أخرى

يُعد كل من UEFI و ACPI مثالين على استخدام GUID. [ 41 ]

انظر أيضاً

مراجع

  1. 1 2 3 4 5 6 7 8 9 ليتش، ب.؛ ميلينغ، م.؛ سالز، ر. (2005). مساحة اسم URN لمعرف فريد عالمي (UUID) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC4122 . RFC 4122. تم الاسترجاع في 17 يناير 2017 .
  2. ↑ "المعرفات الفريدة عالميًا (UUID)" . H2 . تم الاطلاع عليه بتاريخ 21 مارس 2021 .
  3. ↑ ليتش، بي جيه؛ ليفين، بي إتش؛ هاميلتون، جيه إيه؛ ستامبف، بي إل (18-20 أغسطس 1982). "معرفات المستخدم كأسماء داخلية في نظام ملفات موزع". وقائع الندوة الأولى لجمعية ACM SIGACT-SIGOPS حول مبادئ الحوسبة الموزعة - PODC '82 . الصفحات 34-41 . doi : 10.1145/800220.806679 . ISBN  0-89791-081-8.
  4. 1 2 زان، ليزا؛ دينين، تيرينس؛ ليتش، بول؛ مارتن، إليزابيث؛ ميشكين، ناثانيال؛ باتو، جوزيف؛ واينت، جيفري (1990). هندسة الحوسبة الشبكية . برنتيس هول . ص 10. ISBN  978-0-13-611674-5.
  5. ↑ "DCE 1.1: استدعاء الإجراء عن بعد" . مجموعة Open Group. 1997.
  6. 1 2 3 "DCE 1.1: خدمات المصادقة والأمان" . مجموعة Open Group. 1997.
  7. ↑ ISO/IEC 11578:1996 تكنولوجيا المعلومات - الربط البيني للأنظمة المفتوحة - استدعاء الإجراءات عن بُعد (RPC) (تقرير فني). المنظمة الدولية للتوحيد القياسي . 1996.
  8. ↑ "تكنولوجيا المعلومات - إجراءات تشغيل هيئات تسجيل مُعرّفات الكائنات: توليد مُعرّفات فريدة عالميًا واستخدامها في مُعرّفات الكائنات" . الاتحاد الدولي للاتصالات . أكتوبر 2014. تم الاطلاع عليه بتاريخ 8 مايو 2026 .
  9. 1 2 3 4 5 6 7 8 9 10 ديفيس، ك.؛ بيبودي، ب.؛ ليتش، ب. (2024). المعرفات الفريدة عالميًا (UUIDs) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC9562 . RFC 9562. تم الاطلاع عليه في 9 مايو 2024 .
  10. ↑ ب. ليتش؛ ر. سالز (فبراير 1998). المعرفات الفريدة العالمية (UUIDs) والمعرفات الفريدة العامة (GUIDs) . فريق هندسة الإنترنت (IETF ). المعرف: draft-leach-uuids-guids-01.
  11. ↑ "بول ليتش - متتبع بيانات IETF" . datatracker.ietf.org . تم الاطلاع عليه بتاريخ 8 مايو 2026 .
  12. ↑ "سيرة ريتش سالز" . XML.com . تاريخ الاطلاع: 8 مايو 2026. شارك في العديد من مشاريع المعايير الخاصة بمؤسسة البرمجيات المفتوحة (OSF)، وفريق هندسة الإنترنت (IETF)، واتحاد شبكة الويب العالمية (W3C)، ومنظمة خدمات البنية التحتية لأمريكا الشمالية (OASIS) ...
  13. ↑ "مايكل ميلينغ - متتبع بيانات IETF" . datatracker.ietf.org . تم الاطلاع عليه بتاريخ 8 مايو 2026 .
  14. 1 2 "ext2/e2fsprogs.git - أدوات مساحة المستخدم لنظام الملفات Ext2/3/4" . Kernel.org . تم الاطلاع عليه بتاريخ 9 يناير 2017 .
  15. ↑ كوتشلينج، أ.م. "ما الجديد في بايثون 2.5" . Python.org . تم الاطلاع عليه بتاريخ 23 يناير 2016 .
  16. ↑ "جهة التسجيل" . جمعية معايير IEEE . مؤرشف من الأصل في 4 أبريل 2011.
  17. ↑ "عناوين MAC للأجهزة الافتراضية" . Super User .
  18. ↑ "إعداد عنوان MAC" . OpenWrt. 15 سبتمبر 2021.
  19. ↑ رايتر، لوك (2 أبريل 1999). "تتبع شخصيات ميليسا البديلة" . زد نت . تم الاطلاع عليه في 16 يناير 2017 .
  20. ↑ ديفيس، ك.؛ بيبودي، ب.؛ ليتش، ب. (مايو 2024). "RFC 9562: المعرفات الفريدة عالميًا (UUIDs)، القسم 6.2: الرتابة والعدادات" . IETF . تم الاطلاع عليه في 8 مايو 2026 .
  21. ↑ ديفيس، ك.؛ بيبودي، ب.؛ ليتش، ب. (مايو 2024). "RFC 9562: المعرفات الفريدة عالميًا (UUIDs)، القسم 8: اعتبارات الأمان" . IETF . تم الاطلاع عليه في 8 مايو 2026 .
  22. ↑ "uuid.c" . opensource.apple.com . مؤرشف من الأصل بتاريخ 24 فبراير 2021. تم الاطلاع عليه بتاريخ 8 يونيو 2017 .
  23. ↑ ستيل، نيك. "تحليل المعرفات الفريدة العالمية" .
  24. ↑ "شرح إصدارات UUID | UUIDTools.com" . www.uuidtools.com .
  25. ↑ ليتش، بول. "UUIDs و GUIDs" .
  26. ↑ "Guid.ToByteArray Method (System)" . learn.microsoft.com .
  27. ^ يسوع، باولو. باكيرو، كارلوس؛ ألميدا، باولو. “إنشاء المعرفات في البيئات المتنقلة” (PDF) . Repositorium.Sdum.Uminho.pt .
  28. ↑ ماثيس، فرانك هـ. (يونيو 1991). "مسألة عيد الميلاد المعممة". مجلة SIAM Review . 33 ( 2 ): 265-270 . CiteSeerX 10.1.1.5.5851 . doi : 10.1137/1033051 . ISSN 0036-1445 . JSTOR 2031144. OCLC 37699182 .    
  29. ↑ إيدج، جيك (18 مايو 2022). "اللقطات، وعقد البيانات، ومعرفات نظام الملفات" . LWN.net . تم الاطلاع عليه في 31 يناير 2026 .
  30. ↑ "gen_uuid.c" . opensource.apple.com . مؤرشف من الأصل بتاريخ 6 يوليو 2017. تم الاطلاع عليه بتاريخ 17 سبتمبر 2017 .
  31. ↑ "مؤشرات الواجهات والواجهات" . مركز مطوري ويندوز - تقنيات تطبيقات سطح المكتب . مايكروسوفت . تم الاطلاع عليه بتاريخ 15 ديسمبر 2015. يمكنك الإشارة إلى واجهة أثناء التشغيل باستخدام مُعرّف واجهة فريد عالميًا ( IID ) . يسمح هذا المُعرّف ، وهو نسخة محددة من مُعرّف فريد عالميًا ( GUID ) تدعمه COM، للعميل بالاستعلام بدقة من كائن ما عما إذا كان يدعم دلالات الواجهة، دون أي تكلفة إضافية غير ضرورية ودون الارتباك الذي قد ينشأ في النظام من وجود إصدارات متعددة من نفس الواجهة بنفس الاسم.
  32. ↑ "تسجيل مكتبة أنواع" . شبكة مطوري مايكروسوفت . مايكروسوفت . تم الاطلاع عليه بتاريخ 15 ديسمبر 2015 .
  33. ↑ "التصنيف حسب إمكانيات المكونات" . مركز مطوري ويندوز - تقنيات تطبيقات سطح المكتب . مايكروسوفت . تم الاطلاع عليه بتاريخ 15 ديسمبر 2015. يتم تخزين قائمة بمعرفات CATID والأسماء المقروءة في موقع معروف في سجل النظام.
  34. ↑ "NEWSEQUENTIALID (Transact-SQL)" . شبكة مطوري مايكروسوفت . مايكروسوفت . 8 أغسطس 2015. تم الاطلاع عليه بتاريخ 14 يناير 2017 .
  35. ↑ "مرجع SQL لقاعدة بيانات أوراكل" . أوراكل .
  36. ↑ "القسم 8.12 نوع UUID" . وثائق PostgreSQL 9.4.10 . مجموعة تطوير PostgreSQL العالمية. 13 فبراير 2020.
  37. ↑ "uuid-ossp" . PostgreSQL: الوثائق: 9.6 . مجموعة تطوير PostgreSQL العالمية. 12 أغسطس 2021.
  38. ↑ "pgcrypto" . PostgreSQL: الوثائق: 9.6 . مجموعة تطوير PostgreSQL العالمية. 12 أغسطس 2021.
  39. ↑ "القسم 13.20 وظائف متنوعة" . دليل مرجعي لـ MySQL 5.7 . شركة أوراكل .
  40. ↑ "تخزين قيم UUID في MySQL" . بيركونا. 19 ديسمبر 2014. مؤرشف من الأصل في 29 نوفمبر 2020. تم الاطلاع عليه في 10 فبراير 2021 .
  41. ↑ "جداول بيانات ACPI" . UEFI .