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

يُدمج الإصدار الأول عنوان 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^ ⁷⁴ (1.8 × 10^ 12 )^{يمكن إنشاء 22} أو 18 سيكستليون من معرّفات UUID الإصدار 1 لكل معرّف عقدة، بمعدل متوسط ​​أقصى يبلغ 163 مليار في الثانية لكل معرّف عقدة. ^{[ 1 ]}

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

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

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

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

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

Version-3 and version-5 UUIDs are generated by hashing a namespace identifier and name. Version 3 uses MD5 as the hashing algorithm, and version 5 uses SHA-1.^[9] This is useful when systems need deterministically to generate the same UUID based on a set of other names or identifiers, without coordination.

The namespace identifier is itself a UUID. The RFC provides constant UUIDs to represent the namespaces for URLs, fully qualified domain names, object identifiers, and X.500 distinguished names; but any desired UUID may be used as a namespace designator. There is an IANA registry for additional namespace ids.

To determine the version-3 UUID corresponding to a given namespace and name, the UUID of the namespace is transformed to a string of bytes, concatenated with the input name, then hashed with MD5, yielding 128 bits. Then six or seven bits are replaced by fixed values, the four-bit version (e.g. 0011₂ for version 3), and the two- or three-bit UUID "variant" (e.g. 10₂ indicating an RFC 9562^[9] UUIDs, or 110₂ indicating a legacy Microsoft GUID). Since 6 or 7 bits are thus predetermined, only 121 or 122 bits contribute to the uniqueness of the UUID.

Version-5 UUIDs are similar, but SHA-1 is used instead of MD5. Since SHA-1 generates 160-bit digests, the digest is truncated to 128 bits before the version and variant bits are replaced.

Version-3 and version-5 UUIDs have the property that, given the version, the same namespace and name will map to the same UUID. However, neither the namespace nor name can be determined from the UUID, even if one of them is specified, except by brute-force search. RFC 4122 recommends version 5 (SHA-1) over version 3 (MD5). This is because it is believed that MD5 is more prone to collisions than SHA-1, though MD5 is somewhat faster. The RFC warns against use of UUIDs of any version as security capabilities.^[1]:16

A version-4 UUID is randomly generated. As in other UUIDs, four bits are used to indicate version 4, and two or three bits to indicate the variant (10₂ or 110₂ for variants 1 and 2 respectively). Thus, for variant 1 (that is, most UUIDs) a random version-4 UUID will have six predetermined variant and version bits, leaving 122 bits for the randomly generated part, for a total of 2¹²², or 5.3×10^{يوجد 36} (5.3 أنديسيليون ) من معرّفات UUID المحتملة من الإصدار 4، المتغير 1. يوجد نصف هذا العدد من معرّفات UUID المحتملة من الإصدار 4، المتغير 2 (معرّفات GUID القديمة) نظرًا لوجود بت عشوائي أقل، حيث يتم استهلاك ثلاثة بتات للمتغير. 

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

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

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

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

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

But version 8 is not restricted to such scenarios. In essence, version-8 UUIDs are 122 opaque bits, combined with six version and variant bits, allowing them to be separated from other UUID forms.

Unlike other versions, the RFC does not mandate a specific bit layout or generation algorithm, and they are not to be assumed to be unique. Unlike version-4 UUIDs, which should be 122 bits from a high-entropy source of randomness and where uniqueness and collision-resistance are subject to mathematical analysis, the uniqueness, unguessability, collision-resistance, privacy, etc of version-8 UUIDs, in general, can be relied upon based only on trust in the source (if known), out-of-band coordination, or external documentation beyond the standard. In addition, as with other UUID versions, there is no concept of version subtypes. What this means for version 8 is that in a situation where version-8 UUIDs from multiple sources and generation methods have been pooled into a single stream or database and some prove problematic, there is no way to separate the UUIDs by source, other than, perhaps, by resolving them, if that is possible.

In contrast to the other UUID versions, versions 1, 2, and 6 are based on MAC addresses from network cards, relying for their uniqueness in part on an identifier issued by a central registration authority, namely the Organizationally Unique Identifier (OUI) part of the MAC address, which is issued by the IEEE mainly to manufacturers of networking equipment.^[16] The uniqueness of the UUIDs based on network-card MAC addresses also depends on network-card manufacturers properly assigning unique MAC addresses to their cards which, like other manufacturing processes, is subject to error. MAC addresses also may come from sources other than network cards. For example, virtual machines receive a MAC address from a range that is configurable in the hypervisor,^[17] and some operating systems permit the end user to customise the MAC address, notably OpenWrt.^[18] When a device has an EUI-64 64-bit "MAC address", using the least significant 48 bits of it, as recommended by the RFC, may result in the node ID part of the UUID being duplicated. Thus, node IDs based on MAC addresses may not be globally unique.

غالبًا ما يعني استخدام عنوان 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، حيث يُحدد إطارًا عامًا بدلًا من تخطيط بتات صارم لدقة الطابع الزمني الاختيارية التي تصل إلى أجزاء من الألف من الثانية، والعدادات، والعشوائية.

The specification allows the 48-bit Unix timestamp to be adjusted or "fuzzed" to maintain monotonicity (ensuring IDs created in rapid succession always increase) or to enhance privacy. Because the RFC does not define a strict maximum deviation from actual Unix time, different implementations may vary in how they balance chronological accuracy against these other requirements.^[20]

Consequently, the lexical sortability of versions 6 and 7 UUIDs is most consistent when generated by the same library or system. Mixing UUIDs from different sources, or interleaving different versions and variants in a single database, can degrade the time-ordering and index locality that these versions were designed to provide.

RFC 9562 does not mandate a minimum number of random bits for version 7; it allows the sub-millisecond precision and monotonicity counter fields to occupy the remainder of the 128-bit structure. Consequently, collision resistance and guessability depend entirely on the specific implementation's allocation of these bits.^[21]

Variant 1 UUIDs are sequentially encoded in big-endian. For example, 00112233-4455-6677-8899-aabbccddeeff is encoded as the bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.^[23][24]

In contrast, variant 2 UUIDs ("GUIDs"): historically used in Microsoft COM/OLE libraries, have a mixed-endian format, with the first three fields (corresponding to version-1 timestamp subfields) being little-endian, while the final two fields are emitted as big-endian arrays of bytes. The example UUID above, if it were a variant 2 UUID, would be encoded on the wire as 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.^[25][26] All versions under variant 2 are emitted with this byte ordering, including versions not containing numeric fields, such as 3,4, and 5.