ابزارهای uuid آنلاین ToolDeck تمام فرمتهای اصلی شناسه یکتا را در یک جا پوشش میدهند. این مجموعه شامل: تولیدکننده UUID v4 برای شناسههای رمزنگاریشده تصادفی؛ تولیدکننده UUID v7 برای کلیدهای اصلی مرتبپذیر با تایماستمپ؛ تولیدکننده UUID v1 برای شناسههای مبتنی بر زمان و MAC؛ تولیدکننده UUID v2 برای سیستمهای قدیمی DCE؛ تولیدکننده UUID v3 برای شناسههای قطعی مبتنی بر MD5؛ تولیدکننده ULID برای رشتههای فشرده مرتبپذیر؛ تولیدکننده NanoID برای توکنهای کوتاه URL-safe؛ تولیدکننده CUID برای فرمت اصلی مقاوم در برابر تداخل؛ تولیدکننده CUID2 برای جانشین مدرن آن؛ و رمزگشای UUID برای بررسی شناسههای موجود میشود. تمام ابزارها کاملاً در مرورگر شما با استفاده از Web Crypto API اجرا میشوند — هیچ دادهای به سرور ارسال نمیشود، نیازی به حساب کاربری نیست.
ابزارهای UUID و شناسه یکتا چه هستند؟
UUID (شناسه یکتای جهانی) یک شناسه ۱۲۸ بیتی است که در RFC 9562 (پیشتر RFC 4122) استانداردسازی شده. به صورت ۳۲ کاراکتر هگزادسیمال در قالب ۸-۴-۴-۴-۱۲ نوشته میشود و چنین به نظر میرسد: 550e8400-e29b-41d4-a716-446655440000. استاندارد نسخههای متعددی را تعریف میکند که هر کدام از راهبرد متفاوتی برای تضمین یکتایی استفاده میکنند: اعداد تصادفی، تایماستمپ یا هش قطعی.
UUID برای این طراحی شده که سیستمهای توزیعشده بتوانند بدون هماهنگکننده مرکزی شناسه تولید کنند. چه در حال انتساب کلید اصلی در PostgreSQL باشید، چه در حال تولید توکن session در یک وباپ، یا نامگذاری فایل در object storage، UUID به هر گره در سیستم شما اجازه میدهد یک شناسه یکتای جهانی بهطور مستقل ایجاد کند — با احتمال تداخل آنقدر کم که در عمل ناچیز است.
فراتر از استاندارد UUID، چندین فرمت جایگزین شناسه یکتا برای رفع محدودیتهای خاص ظهور کردهاند: ULID و UUID v7 مرتبپذیری لغتنامهای را برای کارایی ایندکسگذاری پایگاه داده اضافه میکنند؛ NanoID حجم را برای URLها و کوکیها کاهش میدهد؛ CUID2 مقاومت در برابر تداخل مبتنی بر اثرانگشت را برای تولید سمت کلاینت با حجم بالا در اولویت قرار میدهد.
چرا از ابزارهای UUID در ToolDeck استفاده کنیم؟
ابزارهای UUID ToolDeck کاملاً در مرورگر شما اجرا میشوند. بدون فراخوانی API، بدون پردازش سمت سرور، بدون ثبت داده. هر تولیدکننده از Web Crypto API (crypto.getRandomValues) برای آنتروپی رمزنگاریشده قوی استفاده میکند — همان منبعی که مرورگرها برای ماده کلیدی TLS استفاده میکنند.
🔐آنتروپی رمزنگاریشده قوی
تمام تولیدکنندههای مبتنی بر تصادف (UUID v4، NanoID، CUID2) از crypto.getRandomValues استفاده میکنند، نه Math.random. خروجی برای موارد استفاده حساس به امنیت مانند توکنهای session و کلیدهای API مناسب است.
📦تمام فرمتهای اصلی ID در یک جا
UUID v1 تا v7، ULID، NanoID، CUID و CUID2 — هر فرمتی که یک توسعهدهنده نیاز دارد، با قابلیت تولید انبوه و کپی با یک کلیک.
🔍رمزگشایی و بررسی شناسههای موجود
رمزگشای UUID نسخه، واریانت، تایماستمپ و فیلدهای node را از هر UUID استخراج میکند. برای دیباگ، ممیزی و درک شناسههای قدیمی در کدبیس شما مفید است.
⚡بدون راهاندازی، آفلاین کار میکند
بدون نصب، بدون ثبتنام، بدون وابستگیهای runtime. صفحه را باز کنید و تولید کنید. تمام ابزارها پس از بارگذاری صفحه بهصورت آفلاین کار میکنند — مفید در محیطهای air-gapped یا شبکههای محدود.
موارد استفاده از ابزارهای UUID
شناسههای یکتا در هر لایهای از stack ظاهر میشوند. در اینجا نقشهای مختلف چگونه از ابزارهای تولید UUID استفاده میکنند:
کلیدهای اصلی پایگاه داده
مهندسان backend از UUID v4 یا UUID v7 به عنوان کلید اصلی در PostgreSQL، MySQL و MongoDB استفاده میکنند. پیشوند تایماستمپ UUID v7 ردیفها را بهصورت فیزیکی روی دیسک مرتب نگه میدارد و از تقسیم صفحه در بارکاریهای سنگین insert جلوگیری میکند.
وضعیت Frontend و شناسههای کامپوننت
توسعهدهندگان frontend از NanoID یا UUID v4 برای تولید کلیدهای پایدار React برای آیتمهای لیست ایجادشده بهصورت پویا، شناسههای dialog برای ویژگیهای دسترسپذیری ARIA و توکنهای idempotency برای ارسال فرم استفاده میکنند.
جریانهای رویداد توزیعشده
در سیستمهای event-driven، هر رویداد به یک شناسه یکتای جهانی و مرتبپذیر نیاز دارد. مهندسان DevOps و platform از ULID یا UUID v7 استفاده میکنند تا مصرفکنندگان Kafka، تجمیعکنندههای log و trailهای ممیزی بدون فیلد تایماستمپ ثانویه بر اساس زمان ایجاد مرتب شوند.
تولید داده آزمایشی
مهندسان QA دستههای UUID را بهصورت انبوه تولید میکنند تا پایگاه دادههای آزمایشی را با شناسههای واقعی و غیرترتیبی پر کنند. UUID v3 یا v5 قطعی به آنها اجازه میدهد همان شناسه را از یک ورودی شناختهشده بازتولید کنند — مفید برای fixtureهای آزمایشی قابل بازتولید.
شناسههای correlation در Microservice
پیوست کردن یک UUID به هر درخواست HTTP ورودی و انتشار آن در فراخوانیهای سرویس (هدر X-Request-ID) به سیستمهای distributed tracing اجازه میدهد لاگها را در سرویسها correlate کنند. UUID v4 استاندارد de facto برای correlation درخواست است.
نامگذاری Asset و Resource
کلیدهای object storage (S3، GCS، Cloudflare R2) و نام فایلهای asset در CDN اغلب یک UUID را برای جلوگیری از تداخل cache و حدس URL جاسازی میکنند. فرمت فشرده ۲۱ کاراکتری NanoID طول URL را نسبت به UUID کامل ۳۶ کاراکتری کاهش میدهد.
مرجع نسخه و فرمت UUID
جدول زیر تمام نسخههای UUID را در کنار پرکاربردترین جایگزینهای UUID مقایسه میکند. از آن برای شناسایی سریع فرمت مناسب با نیازهای خود استفاده کنید.
| شناسه | الگوریتم | مرتبپذیر | قطعی | بهترین برای |
|---|
| UUID v4 | تصادفی (CSPRNG) | — | — | شناسههای عمومی، توکنهای session، کلیدهای اصلی |
| UUID v7 | Unix ms timestamp + تصادفی | ✓ | — | کلیدهای اصلی مرتبپذیر، شناسههای رویداد توزیعشده (RFC 9562) |
| UUID v1 | Timestamp + MAC address | ✓ | — | شناسههای مرتب زمانی، سیستمهای تکگره، سازگاری با سیستمهای قدیمی |
| UUID v3 | Namespace + name + MD5 | — | ✓ | شناسههای قابل بازتولید از ورودیهای شناختهشده (DNS، URL) |
| UUID v5 | Namespace + name + SHA-1 | — | ✓ | مانند v3 با هش قویتر؛ v5 را به v3 ترجیح دهید |
| UUID v2 | Timestamp + DCE UID/GID | ✓ | — | محیطهای قدیمی POSIX/DCE؛ برای پروژههای جدید استفاده نکنید |
| ULID | پیشوند تایماستمپ + تصادفی | ✓ | — | شناسههای مرتبپذیر، URL-safe، بدون خط تیره (۲۶ کاراکتر) |
| NanoID | تصادفی (CSPRNG)، الفبای URL-safe | — | — | شناسههای کوتاه برای URL، کوکی، ویژگیهای HTML (۲۱ کاراکتر) |
| CUID2 | اثرانگشت + تایماستمپ + تصادفی | — | — | تولید سمت کلاینت با حجم بالا، مقاوم در برابر تداخل |
UUID v3 و v5 قطعی هستند: همان namespace + name همیشه همان UUID را تولید میکند. تمام فرمتهای دیگر در هر فراخوانی مقدار جدیدی تولید میکنند.
چگونه ابزار UUID مناسب را انتخاب کنیم
شناسه مناسب به نیازهای مرتبپذیری، حجم و قطعیت شما بستگی دارد. از این راهنمای تصمیمگیری استفاده کنید:
- 1
اگر به یک شناسه یکتای عمومی بدون نیاز خاص نیاز دارید → تولیدکننده UUID v4 - 2
اگر به شناسههایی نیاز دارید که بهصورت زمانی مرتب شوند و با استاندارد UUID سازگار باشند → تولیدکننده UUID v7 - 3
اگر به شناسههای مرتب زمانی با تایماستمپ جاسازیشده برای سیستمهای تکگره یا کمتراکم نیاز دارید → تولیدکننده UUID v1 - 4
اگر به شناسههای مرتبپذیر URL-safe و بدون خط تیره نیاز دارید → تولیدکننده ULID - 5
اگر به شناسههای فشرده URL-safe کوتاهتر از UUID کامل نیاز دارید → تولیدکننده NanoID - 6
اگر شناسههای زیادی سمت کلاینت تولید میکنید و به مقاومت قوی در برابر تداخل نیاز دارید → تولیدکننده CUID2 - 7
اگر برای سازگاری با سیستمهای موجود ساختهشده بر اساس مشخصات اصلی به فرمت CUID v1 نیاز دارید → تولیدکننده CUID - 8
اگر نیاز دارید همان شناسه را بهصورت قطعی از یک namespace و name بازتولید کنید → تولیدکننده UUID v3 - 9
اگر با سیستمهای قدیمی DCE یا POSIX کار میکنید که به شناسههای v2 نیاز دارند → تولیدکننده UUID v2 - 10
اگر یک UUID موجود دارید و میخواهید نسخه، واریانت یا تایماستمپ آن را بررسی کنید → رمزگشای UUID
هر دو UUID v7 و ULID پیشوندهای تایماستمپ با دقت میلیثانیه و مرتبپذیری لغتنامهای ارائه میدهند. تفاوت اصلی: UUID v7 از فرمت استاندارد UUID (۸-۴-۴-۴-۱۲، ۳۶ کاراکتر) برای حداکثر سازگاری با اکوسیستم استفاده میکند، در حالی که ULID از رمزگذاری Base32 سفارشی (۲۶ کاراکتر، URL-safe، بدون خط تیره) استفاده میکند. اگر پایگاه داده، ORM یا فریمورک شما بهطور بومی از ستونهای UUID پشتیبانی میکند، UUID v7 را ترجیح دهید. اگر به شناسههای کوتاهتر بدون محدودیتهای فریمورک نیاز دارید، ULID فشردهتر است.
سوالات متداول
UUID چیست؟
UUID (شناسه یکتای جهانی) یک مقدار ۱۲۸ بیتی است که در RFC 9562 استانداردسازی شده. به صورت ۳۲ رقم هگزادسیمال در پنج گروه جداشده با خط تیره نوشته میشود: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. استاندارد نسخههای متعددی را با راهبردهای مختلف یکتایی تعریف میکند — تصادفی (v4)، مبتنی بر تایماستمپ (v1، v7) یا قطعی مبتنی بر نام (v3، v5).
تفاوت UUID v4 و UUID v7 چیست؟
UUID v4 تمام ۱۲۲ بیت غیرثابت را با داده تصادفی از یک منبع رمزنگاری امن پر میکند. UUID v7 یک تایماستمپ Unix به میلیثانیه ۴۸ بیتی را در ۴۸ بیت اول رمزگذاری میکند و بیتهای تصادفی در پی میآیند. نتیجه: UUIDهای v7 بهعنوان رشته ساده بهصورت زمانی مرتب میشوند که ایندکسهای B-tree پایگاه داده را در insert مرتب نگه میدارد. UUID v7 در RFC 9562 (آوریل ۲۰۲۴) اضافه شد و گزینه ترجیحی برای کلیدهای اصلی پایگاه داده جدید است.
آیا مقادیر UUID v4 از نظر رمزنگاری امن هستند؟
مقادیر UUID v4 با استفاده از یک مولد اعداد شبهتصادفی رمزنگاریشده (CSPRNG) تولید میشوند. برای توکنهای غیرقابل حدس مناسب هستند — شناسههای session، لینکهای بازنشانی رمز عبور و موارد مشابه. با این حال، UUID به خودی خود یک راز نیست: HMAC، انقضا یا اتصال به کاربر خاصی ندارد. UUIDها را بهعنوان شناسههای غیرشفاف در نظر بگیرید، نه بهعنوان اعتبارنامه احراز هویت.
آیا دو سیستم مختلف میتوانند همان UUID را تولید کنند؟
احتمال تداخل UUID v4 تقریباً ۱ در ۲^۱۲۲ به ازای هر جفت است. برای داشتن ۵۰٪ شانس هر تداخلی باید تقریباً ۲.۷ × ۱۰^۱۸ UUID تولید کنید — بسیار فراتر از آنچه هر سیستم واقعی تولید میکند. UUID v1 و v7 علاوه بر این تایماستمپ و/یا بیتهای تصادفی جاسازی میکنند و تداخل تصادفی را حتی کمتر محتمل میسازند. در تمام موارد عملی، UUIDهای سیستمهای جداگانه با هم تداخل نخواهند داشت.
چرا UUIDها ۳۶ کاراکتر طول دارند؟
یک UUID برابر ۱۲۸ بیت = ۱۶ بایت است. بهصورت هگزادسیمال رمزگذاریشده، ۳۲ کاراکتر میشود. فرمت UUID در موقعیتهای ثابت ۴ خط تیره اضافه میکند (بعد از گروههای ۸، ۴، ۴ و ۴ رقم هگز) تا خوانایی را بهبود دهد و تشخیص بیتهای نسخه و واریانت را آسان کند، در نتیجه ۳۶ کاراکتر کل میشود. خط تیرهها هیچ دادهای حمل نمیکنند.
ULID چیست و چه تفاوتی با UUID دارد؟
ULID (شناسه مرتبپذیر لغتنامهای یکتای جهانی) یک شناسه ۱۲۸ بیتی است که در Crockford Base32 رمزگذاری شده (۲۶ کاراکتر، حساسیت به بزرگی/کوچکی حروف ندارد، بدون خط تیره). ۴۸ بیت اول زمان Unix به میلیثانیه را رمزگذاری میکنند؛ ۸۰ بیت باقیمانده تصادفی هستند. ULIDها بهعنوان رشته ساده بهدرستی مرتب میشوند و فشردهتر از UUID هستند. بخشی از UUID RFC نیستند — از رمزگذاری متفاوتی استفاده میکنند و فاقد فیلدهای نسخه/واریانت UUID هستند.
آیا باید از UUID یا اعداد صحیح auto-increment بهعنوان کلید اصلی استفاده کنم؟
اعداد صحیح auto-increment ترتیبی، فشرده و دوستانه برای ایندکس هستند اما نیاز به هماهنگکننده مرکزی (پایگاه داده) برای انتساب دارند — که در سیستمهای توزیعشده خراب میشود و تعداد ردیفها را لو میدهد. UUIDها (بهخصوص v7 یا ULID) میتوانند سمت کلاینت بدون رفتوبرگشت پایگاه داده تولید شوند و insertهای خوشبینانه و نوشتنهای توزیعشده را فعال کنند. مبادله حجم ذخیرهسازی است (۱۶ بایت در مقابل ۴–۸ بایت) و محلیبودن ایندکس کمی پایینتر برای UUIDهای تصادفی (v4). UUID v7 و ULID مشکل محلیبودن ایندکس را با استفاده از پیشوندهای تایماستمپ برطرف میکنند.
تفاوت UUID v3 و UUID v5 چیست؟
هر دو UUID v3 و v5 قطعی هستند: همیشه همان UUID را برای همان جفت namespace + name تولید میکنند که آنها را برای تولید شناسههای قابل بازتولید برای مواردی مانند ورودیهای DNS، URL یا شناسههای object مفید میسازد. تنها تفاوت الگوریتم هش است: v3 از MD5 استفاده میکند (۱۲۸ بیت، قدیمی)، v5 از SHA-1 استفاده میکند (۱۶۰ بیت، truncate شده به ۱۲۸ بیت). برای پروژههای جدید UUID v5 را ترجیح دهید — SHA-1 از MD5 قویتر است، حتی اگر هیچکدام از نسخهها بهعنوان هش رمزنگاری استفاده نشوند.