ToolDeck

رمزگشای UUID

رمزگشایی و بررسی ساختار، نسخه و داده‌های جاسازی‌شده UUID

یک مثال امتحان کنید

ورودی UUID

یک UUID در بالا بچسبانید تا بررسی شود

ساختار UUID

UUID (شناسه منحصربه‌فرد جهانی) یک مقدار ۱۲۸ بیتی است که به صورت ۳۲ رقم هگزادسیمال در پنج گروه با خط تیره نمایش داده می‌شود:

فرمت
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
xxxxxxxx (8)۸ رقم هگز — ۳۲ بیت
xxxx (4)۴ رقم هگز — ۱۶ بیت
Mxxx (4)۴ رقم هگز — ۱۶ بیت. رقم اول M نسخه UUID را کدگذاری می‌کند (۱ تا ۸).
Nxxx (4)۴ رقم هگز — ۱۶ بیت. رقم اول N variant UUID را کدگذاری می‌کند (RFC 4122، NCS، Microsoft یا reserved).
xxxxxxxxxxxx (12)۱۲ رقم هگز — ۴۸ بیت

نسخه و variant تنها دو فیلدی هستند که در تمام UUIDها تضمین می‌شوند. تمام فیلدهای دیگر به نسخه بستگی دارند.

فیلد نسخه

nibble نسخه اولین رقم هگز گروه سوم است (موقعیت ۱۴ در رشته کامل). این رقم مشخص می‌کند که کدام نسخه UUID برای تولید این شناسه استفاده شده است.

JavaScript
const hex = uuid.replace(/-/g, '')
const version = parseInt(hex[12], 16)  // single hex digit → 1, 2, 3, 4, 5, 6, 7, or 8

نسخه ۷ (UUID v7) جدیدترین نسخه پرکاربرد است که در RFC 9562 (2024) معرفی شده. یک تایم‌استمپ Unix با دقت میلی‌ثانیه در بیت‌های بالایی کدگذاری می‌کند تا مرتب‌سازی ممکن باشد.

فیلد Variant

variant در بیت‌های بالایی اولین بایت گروه چهارم کدگذاری می‌شود. این فیلد چیدمان و قراردادهای ترتیب بایت UUID را مشخص می‌کند.

بیت‌های بالاییمحدوده اولین رقم هگزVariantتوضیحات
0xxx xxxx0x00–0x7Fسازگاری با NCSUUIDهای قدیمی Network Computing System (NCS). برای سازگاری با نسخه‌های قبلی رزرو شده.
10xx xxxx0x80–0xBFRFC 4122 / RFC 9562variant استاندارد RFC 4122 / RFC 9562. در تمام نسخه‌های مدرن UUID (v1 تا v8) استفاده می‌شود.
110x xxxx0xC0–0xDFسازگاری با MicrosoftGUIDهای قدیمی Microsoft COM/DCOM با ترتیب بایت متفاوت. هنوز در کامپوننت‌های Windows COM دیده می‌شود.
111x xxxx0xE0–0xFFرزرو شدهبرای تعریف آینده رزرو شده. در هیچ نسخه UUID فعلی استفاده نمی‌شود.

در عمل، تقریباً تمام UUIDهایی که با آن‌ها روبرو می‌شوید از variant RFC 4122 / RFC 9562 استفاده می‌کنند (الگوی بیت ۱۰xx xxxx، اولین بایت گروه چهارم در محدوده 0x80 تا 0xBF). variantهای NCS، Microsoft COM و رزرو شده فرمت‌های قدیمی هستند که به ندرت در سیستم‌های مدرن دیده می‌شوند.

مرجع نسخه‌های UUID

RFC 4122 نسخه‌های ۱ تا ۵ را تعریف کرد. RFC 9562 (2024) نسخه‌های ۶، ۷ و ۸ را اضافه کرد:

نسخهناماستانداردتوضیحات
v1مبتنی بر زمانRFC 4122تایم‌استمپ (epoch گرگوری، دقت ۱۰۰ نانوثانیه) + آدرس MAC. به ازای هر host ترتیبی است اما هویت host را فاش می‌کند.
v2DCE SecurityRFC 4122مبتنی بر UUID v1 با جایگزینی فیلد time_low با POSIX UID/GID. به ندرت خارج از سیستم‌های قدیمی DCE/RPC استفاده می‌شود.
v3مبتنی بر نام — MD5RFC 4122قطعی: هش MD5 از یک namespace UUID به علاوه رشته نام. ورودی‌های یکسان همیشه UUID یکسانی تولید می‌کنند. بهتر است از v5 استفاده شود.
v4تصادفیRFC 4122۱۲۲ بیت از تصادف رمزنگاری‌شده امن. رایج‌ترین نسخه UUID برای استفاده عمومی.
v5مبتنی بر نام — SHA-1RFC 4122مانند v3 اما از SHA-1 استفاده می‌کند. مقاومت بیشتری در برابر تصادم نسبت به MD5 دارد. برای UUIDهای مبتنی بر نام جدید به جای v3 ترجیح داده می‌شود.
v6زمان مرتب‌شدهRFC 9562فیلدهای تایم‌استمپ UUID v1 را مرتب می‌کند تا UUID به‌صورت زمانی مرتب‌پذیر باشد. در RFC 9562 تعریف شده.
v7زمان UnixRFC 9562تایم‌استمپ ۴۸ بیتی Unix با دقت میلی‌ثانیه در بیت‌های بالایی + داده تصادفی. مرتب‌پذیر و مناسب B-tree index. برای شناسه‌های مرتب‌شده بر اساس زمان ترجیح داده می‌شود.
v8سفارشیRFC 9562آزاد: تمام بیت‌ها به جز نسخه و variant توسط برنامه تعریف می‌شوند. هیچ الگوریتم تولیدی مشخص نشده است.

رمزگشایی تایم‌استمپ‌های UUID v1

UUID v1 یک تایم‌استمپ ۶۰ بیتی گرگوری (فاصله‌های ۱۰۰ نانوثانیه‌ای از ۱۵ اکتبر ۱۵۸۲) را در سه فیلد جاسازی می‌کند: time_low (بیت‌های ۰ تا ۳۱)، time_mid (بیت‌های ۳۲ تا ۴۷) و time_hi (بیت‌های ۴۸ تا ۵۹). این ابزار آن‌ها را بازسازی کرده و به تاریخ UTC استاندارد تبدیل می‌کند.

JavaScript
// UUID v1: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
//           ^^^^^^^^ ^^^^ ^^^^ ^^^^^ ^^^^^^^^^^^^
//           time-low  mid  hi  clk   node (MAC)
//                          ^
//                          version nibble (1)

const hex = '6ba7b8109dad11d180b400c04fd430c8'

const tLow = parseInt(hex.slice(0, 8),  16)  // 0x6ba7b810
const tMid = parseInt(hex.slice(8, 12), 16)  // 0x9dad
const tHi  = parseInt(hex.slice(13, 16), 16) // 0x1d1 (skip version nibble at index 12)

// Reconstruct 60-bit timestamp (100-ns intervals since Oct 15, 1582)
const t = (BigInt(tHi) << 48n) | (BigInt(tMid) << 32n) | BigInt(tLow)

// Subtract Gregorian offset (Oct 15, 1582 → Jan 1, 1970 in 100-ns units)
const GREGORIAN_OFFSET = 122192928000000000n
const unixMs = (t - GREGORIAN_OFFSET) / 10000n

console.log(new Date(Number(unixMs)).toISOString())
// → 1998-02-04T22:13:53.578Z
Note:فیلد clock sequence (۱۴ بیت) از تکراری شدن جلوگیری می‌کند وقتی ساعت به عقب برمی‌گردد. فیلد node (۴۸ بیت) معمولاً آدرس MAC دستگاه تولیدکننده است.

UUID v1 باید حساس تلقی شود: آدرس MAC و تایم‌استمپ دقیق جاسازی‌شده می‌توانند هم دستگاه تولیدکننده و هم زمان تولید را شناسایی کنند.

رمزگشایی تایم‌استمپ‌های UUID v7

UUID v7 یک تایم‌استمپ ۴۸ بیتی Unix با دقت میلی‌ثانیه را در ۴۸ بیت اول (گروه اول + ۴ رقم اول گروه دوم) جاسازی می‌کند. این ابزار آن بیت‌ها را خوانده و به تاریخ UTC با دقت میلی‌ثانیه تبدیل می‌کند.

JavaScript
// UUID v7: 018e4bc8-1000-7000-8000-000000000001
//           ^^^^^^^^^^^^
//           48-bit Unix ms timestamp

const hex = '018e4bc8100070008000000000000001'

// First 48 bits (12 hex chars) = Unix timestamp in milliseconds
const ms = parseInt(hex.slice(0, 12), 16)  // 0x018e4bc81000

console.log(new Date(ms).toISOString())
// → 2024-03-11T…Z

// Everything after byte 6 is random (except version/variant bits)

برخلاف UUID v1، تایم‌استمپ UUID v7 از epoch آشنای Unix (۱ ژانویه ۱۹۷۰) استفاده می‌کند و هیچ اطلاعات host را جاسازی نمی‌کند. ۷۴ بیت باقی‌مانده تصادفی هستند.

نحوه تشخیص نسخه و Variant UUID توسط این ابزار

رمزگشا موقعیت ۱۴ (nibble نسخه) و موقعیت ۱۹ (nibble variant) رشته استاندارد UUID را می‌خواند. هیچ وضعیت خارجی یا زمینه‌ای لازم نیست — تمام اطلاعات در خود رشته UUID موجود است.

JavaScript
// Detect UUID version from the 13th hex character (index 12)
function uuidVersion(uuid) {
  const clean = uuid.replace(/-/g, '')
  return parseInt(clean[12], 16)
}

uuidVersion('550e8400-e29b-41d4-a716-446655440000') // → 4
uuidVersion('018e4bc8-1000-7000-8000-000000000001') // → 7
uuidVersion('6ba7b810-9dad-11d1-80b4-00c04fd430c8') // → 1

// Detect variant from the 17th hex character (index 16, first char of 4th group)
function uuidVariant(uuid) {
  const clean = uuid.replace(/-/g, '')
  const b = parseInt(clean[16], 16)
  if ((b & 0x8) === 0)      return 'NCS'
  if ((b & 0xC) === 0x8)    return 'RFC 4122'
  if ((b & 0xE) === 0xC)    return 'Microsoft'
  return 'Reserved'
}

UUIDهای ویژه

UUID نیل

UUID نیل 00000000-0000-0000-0000-000000000000 تمام صفر است. در RFC 4122 به عنوان یک مقدار sentinel به معنای «بدون UUID» تعریف شده — مشابه null. این یک UUID تولیدشده معتبر نیست.

UUID حداکثر

UUID حداکثر ffffffff-ffff-ffff-ffff-ffffffffffff تمام یک است (0xFF در هر بایت). در RFC 9562 تعریف شده و مکمل UUID نیل است و به عنوان مقدار sentinel حداکثر عمل می‌کند.

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

چطور بفهمم یک UUID چه نسخه‌ای دارد؟
به موقعیت ۱۴ در رشته استاندارد UUID نگاه کنید (اولین کاراکتر گروه سوم جدا شده با خط تیره). آن رقم هگز تنها، شماره نسخه است: ۱، ۲، ۳، ۴، ۵، ۶، ۷ یا ۸. UUID را در این ابزار بچسبانید تا نسخه آن رمزگشایی شود.
آیا می‌توانم یک UUID را رمزگشایی کنم تا داده اصلی را بازیابی کنم؟
بستگی به نسخه دارد. UUID v1 و v7 یک تایم‌استمپ جاسازی کرده‌اند که می‌توان کاملاً بازیابی کرد. UUID v1 همچنین آدرس MAC را جاسازی می‌کند. UUID v3 و v5 هش‌های یک‌طرفه هستند — نمی‌توان نام اصلی را از UUID بازیابی کرد. UUID v4 کاملاً تصادفی است — چیزی برای بازیابی وجود ندارد.
«Variant» در یک UUID به چه معناست؟
فیلد variant چیدمان بایت و قرارداد تفسیر UUID را مشخص می‌کند. تقریباً تمام UUIDهایی که با آن‌ها روبرو می‌شوید variant RFC 4122 دارند (بیت‌های بالایی ۱۰) که به صورت ارقام هگز ۸، ۹، a یا b در موقعیت ۱۹ کدگذاری می‌شود. سایر variantها (NCS، Microsoft) فرمت‌های قدیمی دهه ۱۹۹۰ هستند.
چرا بعضی UUIDها از نظر ظاهری با بقیه متفاوت هستند؟
تفاوت ظاهری در nibble نسخه (موقعیت ۱۴) و nibble variant (موقعیت ۱۹) است. مثلاً UUID v4 همیشه عدد ۴ در موقعیت ۱۴ دارد، در حالی که UUID v7 همیشه عدد ۷ دارد. در آن محدودیت‌ها، ارقام باقی‌مانده تصادفی یا مشتق از تایم‌استمپ هستند بسته به نسخه.
آیا UUID نیل همان UUID خالی است؟
از نظر مفهومی بله — UUID نیل (تمام صفر) برای نمایش نبود یک UUID استفاده می‌شود، مشابه null. این یک UUID تولیدشده به صورت تصادفی نیست و نباید به عنوان یک شناسه واقعی ذخیره شود. برخی سیستم‌ها از آن به عنوان مقدار پیش‌فرض یا placeholder استفاده می‌کنند.
آیا یک UUID می‌تواند نامعتبر باشد؟
یک UUID می‌تواند از نظر نحوی معتبر (فرمت صحیح) اما از نظر معنایی غیرعادی باشد — مثلاً داشتن nibble نسخه ۰ یا variant از نوع ۱۱x (رزرو شده). UUID نیل و UUID حداکثر از نظر نحوی معتبرند اما مقادیر sentinel هستند. این ابزار هر nibble نسخه و variant موجود را نمایش می‌دهد و نسخه‌های ناشناخته را علامت‌گذاری می‌کند.
تفاوت بین UUID و GUID چیست؟
GUID (شناسه منحصربه‌فرد جهانی) نام Microsoft برای همین مفهوم است. GUIDها از همان فرمت ۱۲۸ بیتی RFC 4122 پیروی می‌کنند. تنها تفاوت عملی این است که GUIDهای قدیمی Microsoft ممکن است از Microsoft variant (بیت‌های بالایی ۱۱۰) به جای RFC 4122 variant استفاده کنند — این بر ترتیب بایت در نمایش باینری تأثیر می‌گذارد. نمایش متنی یکسان است.