تولیدکننده UUID v4

تولید آنلاین مقادیر UUID v4: ۱۲۲ بیت تصادفی، ساختار استاندارد UUID و نتایج آماده برای کپی در مرورگر شما.

فرمت
شناسه‌های تولیدشده
آماده. مقادیر UUID v4 را در مرورگر خود تولید کنید.

ساختار این شناسه

طرح‌بندی
شناسه ۱۲۸ بیتی UUID نسخه ۴ با بیت‌های نوع RFC، که به صورت گروه‌های هگزادسیمال ۸-۴-۴-۴-۱۲ نمایش داده می‌شود.
آنتروپی
۱۲۲ بیت تصادفی از تابع crypto.randomUUID().
زمان
ندارد؛ شناسه‌های نسخه ۴ زمان ساخت خود را فاش نمی‌کنند.
خطر تداخل (Collision)
تداخل‌ها توسط ۱۲۲ بیت تصادفی کنترل می‌شوند که فراتر از حجم‌های عملیاتی برای سیستم‌های معمولی است.
نمونه
c39ba5a7-b4da-4456-ab77-767223399fff

شناسه‌های شما به صورت محلی با توابع تصادفی امن مرورگر تولید می‌شوند. هیچ چیز به BroBroGo ارسال نمی‌شود.

سوالات متداول

چه زمانی باید از UUID v4 استفاده کنم؟

زمانی از UUID v4 استفاده کنید که به شناسه‌های تصادفی مبهم نیاز دارید که بر اساس زمان ساخت مرتب نمی‌شوند و اطلاعات زمان‌بندی را فاش نمی‌کنند.

آیا می‌توانم خط تیره‌ها را حذف کنم یا خروجی را با حروف بزرگ دریافت کنم؟

بله. ابزار اختصاصی UUID v4 پنل تنظیمات را حفظ می‌کند تا بتوانید خط تیره‌ها را حذف کرده یا خروجی را به حروف بزرگ تبدیل کنید.

مولد UUID نسخه ۴: تولید شناسه‌های تصادفی با ۱۲۲ بیت آنتروپی

این صفحه به شما امکان می‌دهد یک یا چند UUID نسخه ۴ – شناسه‌های ۳۶ رقمی تصادفی در قالب استاندارد ۸‑۴‑۴‑۴‑۱۲ هگز – تولید کنید. شما تعداد (از ۱ تا ۱۰۰)، استفاده از حروف بزرگ و وجود خط تیره را کنترل می‌کنید. شناسه‌ها بلافاصله در مرورگر شما ظاهر می‌شوند و می‌توانید یک شناسه را با کلیک روی آن یا همه را یکباره کپی کنید.

ویژگی‌های منحصربه‌فرد این صفحه

برخلاف بسیاری از ابزارهای مشابه که صرفاً یک عدد تصادفی را در قالب UUID قالب‌بندی می‌کنند، این صفحه از ۱۲۲ بیت تصادفی خالص برای هر UUID استفاده می‌کند. شش بیت باقی‌مانده برای نشان‌دادن نسخه (version) و نوع (variant) UUID ثابت هستند. این یعنی هیچ بیتی از ورودی تصادفی برای اهداف دیگر مصرف نشده است. تمام تولیدات با استفاده از crypto.randomUUID یا API‌های مشابه مرورگر انجام می‌شود که تضمین می‌کند اعداد از نظر رمزنگاری قوی و غیرقابل پیش‌بینی هستند.

نکته کلیدی دیگر این است که UUID v4 هیچ ترتیب یا زمان را در خود ندارد. برخلاف شناسه‌هایی مثل UUID v7 که شش بیت اول آنها بر اساس تایم‌استمپ است، UUID v4 کاملاً تصادفی مرتب می‌شود. این امر وقتی آن را به عنوان کلید اصلی در پایگاه داده استفاده می‌کنید، باعث خردشدگی (fragmentation) ایندکس‌های B‑tree می‌شود – یعنی درج‌های جدید ممکن است در صفحات تصادفی ایندکس قرار گیرند و عملکرد نوشتن را کاهش دهند. این صفحه آگاهانه این موضوع را به کاربران یادآوری می‌کند تا انتخاب آگاهانه‌ای داشته باشند.

همچنین صفحه برای این قالب خاص (UUID v4) گزینه‌های قالب‌بندی مخصوصی ارائه می‌دهد: حروف بزرگ (uppercase) و شامل خط تیره (hyphens). این گزینه‌ها فقط برای UUID v4 و v7 معنا دارند و برای سایر انواع شناسه (مثل ULID یا NanoID) از کنترل‌های متفاوتی استفاده می‌شود.

ساختار UUID نسخه ۴ و میزان تصادفی بودن

UUID نسخه ۴ طبق استاندارد RFC 4122 تعریف شده است. هر UUID شامل ۱۲۸ بیت است که به صورت یک رشته ۳۶ کاراکتری (در حالت پیش‌فرض با خط تیره) نمایش داده می‌شود. از این ۱۲۸ بیت:

  • ۴۸ بیت برای بخش اول (۸ کاراکتر هگز)
  • ۱۶ بیت برای بخش دوم (۴ کاراکتر هگز)
  • ۱۶ بیت برای بخش سوم (۴ کاراکتر هگز – که چهار بیت اول آن نسخه را نشان می‌دهد، یعنی 0100 باینری)
  • ۶۴ بیت برای بخش چهارم (۱۲ کاراکتر هگز – که دو بیت اول آن نوع variant را نشان می‌دهد)

بیت‌های ثابت نسخه و variant در مجموع ۶ بیت هستند. بنابراین ۱۲۲ بیت تصادفی باقی می‌ماند. این یعنی برای هر UUID v4، ۲^۱۲۲ حالت ممکن وجود دارد – عددی تقریباً ۵٫۳ × ۱۰^۳۶. احتمال برخورد (collision) برای تولید ۱ میلیارد UUID در حدود ۱۰^-19 است که عملاً صفر محسوب می‌شود.

وقتی گزینه خط تیره را غیرفعال کنید، رشته به ۳۲ کاراکتر هگز تبدیل می‌شود (بدون خط تیره) اما محتوای تصادفی همان ۱۲۲ بیت است. حروف بزرگ فقط نحوه نمایش h, e, f, d, c, b, a را تغییر می‌دهد (به A-F) و بر محتوای بایت‌ها تأثیری ندارد.

تأثیر بر ایندکس‌گذاری پایگاه داده

یکی از رایج‌ترین اشتباهات توسعه‌دهندگان، استفاده از UUID v4 به عنوان کلید اصلی در پایگاه داده‌های رابطه‌ای است بدون در نظر گرفتن هزینه ایندکس. ایندکس‌های B-tree (که در MySQL، PostgreSQL و SQL Server استفاده می‌شوند) برای داده‌هایی طراحی شده‌اند که به ترتیب صعودی یا نزولی نزدیک به هم وارد می‌شوند. وقتی یک رکورد جدید با UUID v4 تصادفی درج می‌شود، احتمالاً مقدار آن بین دو مقدار موجود قرار می‌گیرد و ایندکس باید صفحه جدیدی را در جای نامناسبی ایجاد کند. این عمل Page Split نام دارد و باعث افزایش ورودی/خروجی دیسک و کاهش کارایی نوشتن می‌شود.

برای پایگاه‌های داده با تراکنش بالا (۱۰۰۰+ درج در ثانیه) این موضوع می‌تواند به افت محسوس عملکرد منجر شود. راه‌های کاهش این مشکل عبارتند از:

  • استفاده از UUID v7 که شش بیت اول آن تایم‌استمپ است و شناسه‌ها تقریباً به ترتیب تولید می‌شوند.
  • استفاده از ULID که کاملاً مبتنی بر زمان است و قابلیت مرتب‌سازی دارد.
  • ذخیره UUID به صورت binary(16) به جای varchar برای کاهش حجم ایندکس.
  • استفاده از ایندکس کلاستر شده غیر از کلید اصلی (مثلاً یک فیلد خودکار افزایشی).

این صفحه برای آگاهی کاربران این نکات را در وضعیت نمایشی یا راهنمای خود ذکر کرده است.

مقایسه با شناسه‌های مبتنی بر زمان (UUID v7, ULID)

همانطور که اشاره شد، مهم‌ترین تفاوت UUID v4 با v7 یا ULID در قابلیت مرتب‌سازی زمانی است. جدول زیر تفاوت‌های اصلی را نشان می‌دهد:

ویژگی UUID v4 UUID v7 ULID
طول رشته (با خط تیره) ۳۶ کاراکتر ۳۶ کاراکتر ۲۶ کاراکتر (بدون خط تیره)
تصادفی بودن ۱۲۲ بیت ۷۴ بیت (بقیه زمان) ۸۰ بیت (بقیه زمان)
ترتیب زمانی ندارد تقریباً مرتب کاملاً مرتب
احتمال برخورد بسیار کم کم کم
مناسب برای کلید اصلی پرتراکنش خیر (خردشدگی) بله (در صورت ذخیره بهینه) بله

UUID v4 برتری در تصادفی بودن دارد و برای کاربردهایی که نیاز به غیرقابل حدس بودن مطلق است (مثل توکن‌های API یا شناسه جلسات) مناسب‌تر است. ULID به دلیل رمزگذاری Crockford از حروف بزرگ و کوچک استفاده نمی‌کند و در ۲۶ کاراکتر جای می‌گیرد. UUID v7 هنوز استاندارد RFC نشده است (در پیش‌نویس) اما بسیاری از کتابخانه‌ها از آن پشتیبانی می‌کنند.

موارد استفاده از شناسه‌های غیرمتوالی

UUID v4 در شرایطی کاربرد حیاتی دارد که هماهنگی مرکزی (central coordination) وجود ندارد. مثلاً:

۱. سیستم‌های توزیع شده: چندین سرور در نقاط مختلف دنیا بدون ارتباط با یکدیگر باید شناسه‌های یکتا تولید کنند. UUID v4 این کار را بدون نیاز به سرور متمرکز انجام می‌دهد.

۲. توکن‌های امنیتی: از آنجایی که توالی زمانی ندارد، مهاجم نمی‌تواند با مشاهده چند توکن متوالی، الگویی برای پیش‌بینی توکن بعدی پیدا کند.

۳. شناسه رویدادها و لاگ‌ها: در سیستم‌های event sourcing، هر رویداد باید یک شناسه یکتا داشته باشد. تصادفی بودن به توزیع یکنواخت در شاردها کمک می‌کند.

۴. محیط‌های آفلاین: اپلیکیشن‌های موبایل که بعداً داده‌ها را با سرور همگام می‌کنند، می‌توانند UUID v4 تولید کرده و از برخورد با شناسه‌های تولید شده توسط دیگر دستگاه‌ها جلوگیری کنند.

۵. جلوگیری از شمارش منابع: اگر از کلیدهای عددی متوالی برای شناسایی کاربران یا سفارش‌ها استفاده کنید، رقبا می‌توانند تعداد را حدس بزنند. UUID v4 این اطلاعات را فاش نمی‌کند.

سفارشی‌سازی قالب: حروف بزرگ و خط تیره

دو گزینه قالب‌بندی ارائه شده به ظاهر ساده اما در عمل مهم هستند:

  • حروف بزرگ (Uppercase): وقتی فعال باشد، حروف a-f به A-F تبدیل می‌شود. این موضوع در سیستم‌هایی که UUID را به صورت متنی در لاگ یا فایل ذخیره می‌کنند و قواعد حروف بزرگ/کوچک را رعایت می‌کنند (مثل برخی پایگاه‌های داده کی‌ولوئ) اهمیت دارد. همچنین در نمایش برای انسان خواناتر است.

  • شامل خط تیره (Hyphens): خط تیره‌های موجود در قالب استاندارد ۸-۴-۴-۴-۱۲ فقط برای خوانایی هستند. حذف آنها طول رشته را به ۳۲ کاراکتر کاهش می‌دهد که در محیط‌های محدود مثل URLها یا نام فایل‌ها مفید است. اما توجه داشته باشید که بدون خط تیره، شناسه با UUID بدون خط تیره یکسان است و همچنان ۱۲۸ بیت دارد.

تغییر هر یک از این گزینه‌ها بلافاصله باعث بازتولید همه شناسه‌ها می‌شود. این رفتار عمدی است تا کاربر همیشه نتیجه به‌روز را ببیند.

تولید در مرورگر و مزایای حریم خصوصی

تمام تولید شناسه‌ها کاملاً در مرورگر کاربر و با استفاده از API crypto.getRandomValues یا crypto.randomUUID انجام می‌شود. هیچ داده‌ای به سرور ارسال نمی‌شود. این یعنی:

  • حریم خصوصی: هیچ سرویس ثالثی نمی‌تواند از شناسه‌های تولید شده مطلع شود.
  • سرعت: تولید بلافاصله انجام می‌شود و نیازی به انتظار برای پاسخ سرور نیست.
  • دسترسی آفلاین: اگر صفحه یک‌بار بارگذاری شود (مثلاً با Service Worker)، حتی بدون اتصال اینترنت هم می‌توانید UUID تولید کنید.

تنها محدودیت، محدوده تعداد است: بین ۱ تا ۱۰۰. عدد ۱۰۰ برای عملیات دستی کافی است و برای موارد حجیم (هزاران UUID) بهتر است از ابزار خط فرمان استفاده شود.

پرسش‌های متداول (FAQ)

۱. آیا احتمال برخورد UUID v4 برای حجم بالای شناسه وجود دارد؟

از نظر عملی، خیر. برای رسیدن به احتمال ۵۰٪ برخورد، باید حدود ۲^۶۱ ≈ ۲٫۳ کوئینتیلیون UUID تولید کنید که در هیچ سیستم واقعی ممکن نیست. حتی با تولید ۱ میلیارد UUID در ثانیه به مدت ۱۰۰ سال، احتمال برخورد ناچیز است.

۲. چرا نباید UUID v4 را به عنوان کلید اصلی پایگاه داده استفاده کنم؟

به دلیل خردشدگی ایندکس B-tree. هر درج جدید به طور تصادفی در جایگاه متفاوتی قرار می‌گیرد و باعث Page Split می‌شود. برای پایگاه‌های کوچک (چند هزار رکورد) قابل چشم‌پوشی است، اما برای مقیاس بزرگ بهتر است از UUID v7 یا کلید عددی خودکار افزایشی استفاده کنید.

۳. آیا حذف خط تیره روی شناسه تأثیر می‌گذارد؟

خیر. خط تیره فقط برای نمایش است و محتوای ۱۲۸ بیتی تغییر نمی‌کند. شناسه بدون خط تیره معادل UUID استاندارد است که خط تیره‌های آن حذف شده باشد. برخی کتابخانه‌ها (مثل Python uuid module) از هر دو فرم پشتیبانی می‌کنند.

۴. تفاوت بین گزینه Uppercase و Lowercase چیست؟

تنها در نمایش حروف هگز. هر دو رشته معادل یک مقدار باینری هستند. اما اگر سیستم شما (مثلاً یک سرویس خارجی) UUID را با حروف بزرگ ذخیره می‌کند، فعال‌کردن گزینه Uppercase باعث سازگاری بهتر می‌شود.

۵. آیا می‌توانم بیش از ۱۰۰ UUID تولید کنم؟

در این صفحه حداکثر ۱۰۰ مجاز است. برای تعداد بیشتر می‌توانید از ابزارهای خط فرمان مثل uuidgen در لینوکس یا کتابخانه‌های برنامه‌نویسی استفاده کنید. دلیل محدودیت، جلوگیری از کندی مرورگر و مدیریت مناسب UI است.

۶. چه مرورگرهایی از تولید UUID v4 پشتیبانی می‌کنند؟

تمام مرورگرهای مدرن (Chrome 92+, Firefox 95+, Safari 15+, Edge 92+) از crypto.randomUUID پشتیبانی می‌کنند. در مرورگرهای قدیمی‌تر، صفحه از crypto.getRandomValues و پیاده‌سازی دستی استفاده می‌کند.