إنشاء معرّفات UUID
خاص — لا يُخزَّن ملفك أبدًا
أي إصدار؟
يظهر 0 معرّف UUID هنا.
كيف تعمل الأداة
اختر الإصدار
v4 لأي شيء يجب ألا يُخمَّن. وv7 لمفاتيح قواعد البيانات. والفرق مشروح في الصفحة لا مفترض.
اختر العدد
واحد، أو حتى عشرة آلاف دفعة واحدة، مع تنسيق اختياري — أحرف كبيرة، أو بين أقواس معقوفة، أو دون شرطات، أو كقائمة بين علامات تنصيص جاهزة للكود.
انسخها
انسخ الكل، أو نزّلها كملف نصي.
الإصدار 4 أم الإصدار 7، ولماذا يهم ذلك في قاعدة البيانات
UUID هو 128 بت تُكتب في 32 خانة ست عشرية بالتقسيم المألوف 8-4-4-4-12. تُخصَّص ست من هذه البتات لبيان الإصدار والمتغير، فيتبقى 122 بتًا عشوائيًا في الإصدار 4 — وهذا يكفي لأن تنشئ مليار معرّف في الثانية طوال قرن ويظل احتمال أن ترى المعرّف نفسه مرتين ضئيلًا للغاية. وهذه هي الجاذبية كلها: نظامان لم يتواصلا قط يستطيع كلٌّ منهما إنشاء معرّفات وافتراض أنها لن تتصادم أبدًا بأمان.
ولكي يصح ذلك يجب أن تكون العشوائية حقيقية، وهي هنا تأتي من مصدر العشوائية التشفيري لا من مولّد أرقام عشوائية عادي. ويهم هذا الفرق حين تُستخدم المعرّفات كرموز صلاحية — رابط إعادة تعيين كلمة المرور، أو رابط مشاركة لا يمكن تخمينه — لأن المولّد القابل للتنبؤ يتيح لشخص ما استنتاج القيمة التالية من القيم السابقة. أما مع مصدر تشفيري فلا يوجد ما يُتنبأ به.
الإصدار 7 موجود لأن الإصدار 4 يتصرف بشكل سيئ كمفتاح أساسي في قاعدة البيانات. فهو يضع طابعًا زمنيًا من 48 بت بدقة جزء من الألف من الثانية في البداية ويملأ الباقي بالعشوائية، لذا تُفرز معرّفات UUID المُنشأة بالتتابع بترتيب إنشائها. يبدو هذا شكليًا وليس كذلك: فالمفتاح العشوائي يبعثر كل عملية إدراج عبر الفهرس كله، فتلمس كل عملية كتابة صفحة مختلفة ويتوقف التخزين المؤقت عن المساعدة، بينما يُضاف المفتاح المرتّب زمنيًا إلى طرف واحد. وفي جدول كبير يكون الفرق في سرعة الإدراج كبيرًا، وهو سبب اعتماد v7 كمعيار.
المقايضة حقيقية وتستحق الموازنة. يخبر UUID من الإصدار 7 كل من يراه بوقت إنشائه تقريبًا، بدقة جزء من الألف من الثانية، وسلسلة منها تكشف مدى سرعتك في إنشاء السجلات. بالنسبة لمفتاح داخلي فلا بأس بذلك. أما لمعرّف ظاهر في رابط URL — رقم طلب، أو رابط مستند، أو معرّف مستخدم — فهو تسريب صغير للمعلومات لا يعاني منه الإصدار 4. استخدم v7 للمفتاح الأساسي وv4 لأي شيء عام إن كان الأمران يهمانك.
عندما تحتاج إلى شيء آخر
أنشئها حيث تُستخدم. كل قاعدة بيانات وكل لغة برمجة لديها هذا مدمجًا — gen_random_uuid() في PostgreSQL، وUUID() في MySQL، وcrypto.randomUUID() في JavaScript، وuuid.uuid4() في Python — وإنشاء دفعة في المتصفح ولصقها في الكود لا بأس به لبيانات اختبار ثابتة (fixture) أو اختبار، وخطأ لأي شيء يعمل فعليًا.
إذا كان سبب اختيار v7 هو المفاتيح القابلة للفرز، فهناك بدائل تستحق المعرفة. ULID يرمّز الفكرة نفسها في 26 حرفًا أقصر ولا تتأثر بحالة الأحرف؛ ومعرّفات Snowflake تتسع في 64 بت، ما يقلص حجم الفهرس إلى النصف مقارنةً بـ 128 بت في UUID. وفي كثير من قواعد البيانات لا يزال العدد الصحيح العادي ذو الزيادة التلقائية أسرع وأصغر من أيٍّ منها — فمعرّفات UUID تستحق تكلفتها حين يجب إنشاء المعرّفات في عدة أماكن في الوقت نفسه، ولا تستحقها في غير ذلك.
الأسئلة الشائعة
v4 أم v7 — أيهما أريد؟
إذا كان مفتاحًا أساسيًا في قاعدة بيانات، فـ v7. وإذا كان يجب أن يستحيل تخمينه — رابط إعادة تعيين كلمة المرور، أو رمز دعوة، أو معرّف جلسة — فـ v4. هذا هو القرار كله، ومعظم الناس لا يعرفون أصلًا أن هناك قرارًا، لأن كل المولّدات تقريبًا لا توفّر إلا v4.
لماذا يُعد v4 سيئًا كمفتاح لقاعدة البيانات؟
لأنه عشوائي تمامًا، وفهرس قاعدة البيانات مرتّب. تقع المفاتيح العشوائية الجديدة في أماكن عشوائية من الفهرس، فتلمس كل عملية إدراج صفحة مختلفة، ويتوقف التخزين المؤقت عن المساعدة، ويتجزأ الفهرس ويتضخم. وفي جدول كبير ومزدحم يكون هذا تباطؤًا ملموسًا يزداد سوءًا مع الوقت. وهو ليس مصدر قلق نظري — بل هو سبب تناول وثائق Postgres وMySQL كلتيهما له الآن.
ما UUID v7؟
UUID أول 48 بتًا فيه طابع زمني بدقة جزء من الألف من الثانية، تليه العشوائية. لا يزال فريدًا عالميًا ولا يزال 128 بت، لكن لأن الوقت يأتي أولًا، تُفرز معرّفات v7 بترتيب إنشائها. تُضاف المفاتيح الجديدة إلى نهاية الفهرس بدلًا من أن تتبعثر فيه، وهذا بالضبط سلوك العدد الصحيح ذي الزيادة التلقائية — مع تفرّد UUID. اعتُمد كمعيار في RFC 9562 عام 2024، وهو التوصية الحالية للجداول الجديدة.
هل تُفرز معرّفات v7 هنا فعلًا؟
نعم، حتى داخل الجزء الواحد من الألف من الثانية، وهو الجزء الذي تخطئ فيه معظم التطبيقات. فدقة الطابع الزمني لا تتجاوز جزءًا من الألف من الثانية، لذا فإن إنشاء ألف معرّف في حلقة ينتهي داخل جزء واحد — ومع بتات دنيا عشوائية بالكامل، لا تُفرز هذه الألف بترتيب إنشائها. يستخدم هذا المولّد العدّاد الرتيب الموصوف في RFC 9562، لذا تكون الدفعة تصاعدية بدقة، في كل مرة. أنشئ ألفًا وافرزها؛ وستعود بترتيب إنشائها.
هل من الآمن كشف UUID من الإصدار v7 للعامة؟
مع مراعاة أمر واحد: إنه يكشف وقت إنشائه، بدقة جزء من الألف من الثانية، بحكم تصميمه. بالنسبة لمفتاح قاعدة بيانات يكون هذا عادةً غير ضار بل مفيدًا. لكن إذا كان وقت الإنشاء نفسه حساسًا، أو كنت تحتاج إلى معرّف لا يمكن تخمينه، فاستخدم v4 — فلا يزال في v7 عدد 74 بتًا عشوائيًا، وهو كثير جدًا، لكن طابعه الزمني مقروء بوضوح لكل من لديه المعرّف.
هل هي عشوائية بما يكفي لتكون آمنة؟
نعم. تأتي العشوائية من `crypto.getRandomValues`، المولّد الآمن تشفيريًا في المتصفح، ولا تأتي أبدًا من `Math.random`. وقد تسبب هذا الفرق في ثغرات حقيقية: فـ `Math.random` سريع لكنه قابل للتنبؤ، وقد خُمّنت فعليًا رموز جلسات بُنيت عليه. ويحتوي UUID من الإصدار v4 على 122 بتًا عشوائيًا، وهذا يكفي لئلا يكون التصادم مصدر قلق عملي.
هل تُنشأ على جهازي؟
نعم، بالكامل، وهذا مهم للمعرّفات. فـ UUID الذي يُجلب من خادم شخص آخر هو UUID رآه شخص آخر — وهذا يُفسد الغرض إن كنت تنشئ سرًا. هذه المعرّفات لا تغادر متصفحك أبدًا. بعد تحميل الصفحة، أوقف تشغيل Wi-Fi وستعمل تمامًا بالطريقة نفسها. هذه أبسط طريقة لتتأكد من ادعاء الخصوصية بنفسك بدلًا من أن تكتفي بكلامنا.
ما UUID الصفري (nil)؟
كله أصفار: 00000000-0000-0000-0000-000000000000. إنه UUID صالح ومحجوز يُستخدم للدلالة على «لا شيء» أو «غير مُعيَّن» حيث لا يمكن استخدام null. ونقيضه، UUID الأقصى (max) المكوّن كله من الحرف f، يُستخدم أحيانًا كقيمة حدّية في الفرز. ويتوفر الاثنان هنا لأن الحاجة إليهما تظهر أحيانًا، وكتابتهما بشكل صحيح مزعجة.
معلومة مفيدة: تأتي معرّفات UUID من الإصدار 4 من مصدر العشوائية التشفيري في المتصفح، لا من Math.random، لذا فهي آمنة للاستخدام كمعرّفات. أما الإصدار 7 فيتضمن طابعًا زمنيًا بدقة جزء من الألف من الثانية، وهذا ما يجعله قابلًا للفرز جيدًا — ويعني أيضًا أنه يكشف تقريبًا وقت إنشائه. لا تستخدم v7 حيث يهم ذلك.
أضِف هذه الأداة إلى موقعك
مجانية لأي مدونة أو صفحة فصل دراسي أو مقالة مساعدة. الصق مقتطفًا واحدًا وسيتمكن زوارك من استخدامها مباشرةً على صفحتك.