ساخت UUID و GUID

راهنمای استفاده از ساخت UUID

1. نسخه (v4 تصادفی یا v7 زمان‌محور) را انتخاب کنید.
2. تعداد و قالب (حروف بزرگ، بدون خط تیره) را مشخص کنید.
3. شناسه‌ها را کپی کنید.

UUID چیست؟

هر رکوردی در پایگاه داده، هر فایلی در سیستم، هر سفارشی در فروشگاه و هر پیامی در صف پردازش، شناسه‌ای لازم دارد که آن را از بقیه جدا کند. ساده‌ترین روش، شمارهٔ ترتیبی است؛ یک، دو، سه. اما شمارهٔ ترتیبی یک مشکل بزرگ دارد؛ باید جایی مرکزی وجود داشته باشد که بداند شمارهٔ بعدی چند است. وقتی چند سرور، چند پایگاه داده یا برنامهٔ گوشی بدون اینترنت باید همزمان شناسه بسازند، این هماهنگی دشوار یا ناممکن است.

UUID، کوتاه‌شدهٔ عبارتی انگلیسی به معنای شناسهٔ یکتای جهانی، این مشکل را با عددی بسیار بزرگ حل می‌کند. ۱۲۸ بیت، یعنی بیش از ۳۴۰ میلیارد میلیارد میلیارد میلیارد حالت ممکن. هر سیستمی، هر جای دنیا و بدون پرسیدن از کسی، می‌تواند UUID تازه‌ای بسازد و احتمال اینکه با شناسه‌ای که سیستم دیگری ساخته یکی شود، آن‌قدر کم است که در عمل صفر فرض می‌شود. مایکروسافت همین شناسه را GUID می‌نامد؛ نام فرق دارد، اما قالب و ساختار یکی است.

ساختار UUID

UUID معمولا به شکل ۳۲ رقم هگزادسیمال در پنج گروه نوشته می‌شود که با چهار خط تیره جدا شده‌اند؛ گروه‌هایی با هشت، چهار، چهار، چهار و دوازده رقم. جمعا ۳۶ نویسه. همهٔ ۱۲۸ بیت تصادفی نیستند. اولین رقم گروه سوم، نسخه را نشان می‌دهد؛ برای شناسه‌های این ابزار، یا ۴ یا ۷. اولین رقم گروه چهارم، گونه را نشان می‌دهد و برای UUIDهای استاندارد امروزی، یکی از چهار مقدار ۸، ۹، a یا b است. پس با یک نگاه به رقم سیزدهم، می‌فهمید یک UUID چه نسخه‌ای است.

استاندارد UUID ابتدا در دههٔ نود و دو هزار میلادی تعریف شد و در سال ۲۰۲۴ با استاندارد تازه‌ای به‌روز شد که نسخه‌های جدیدتر، از جمله نسخهٔ ۷، را هم رسمی کرد. نسخه‌های دیگری هم هستند؛ نسخهٔ ۱ که زمان و نشانی سخت‌افزاری کارت شبکه را در خود دارد و به همین دلیل اطلاعات دستگاه سازنده را فاش می‌کند، و نسخه‌های ۳ و ۵ که از هش یک نام ساخته می‌شوند و برای نام یکسان، همیشه UUID یکسان می‌دهند. این ابزار دو نسخهٔ پرکاربرد امروزی را می‌سازد.

ساخت UUID نسخهٔ ۴

نسخهٔ ۴ ساده‌ترین و رایج‌ترین نسخه است. از ۱۲۸ بیت آن، شش بیت برای نسخه و گونه رزرو شده و ۱۲۲ بیت باقی کاملا تصادفی‌اند. هیچ اطلاعاتی، نه زمان، نه دستگاه و نه هیچ چیز دیگری، در آن نیست. این ویژگی آن را برای جاهایی مناسب می‌کند که شناسه در معرض دید کاربر است و نباید چیزی دربارهٔ زمان یا ترتیب ساخت فاش کند؛ مثلا شناسهٔ سفارش در نشانی صفحه که نباید معلوم کند فروشگاه روزانه چند سفارش دارد.

احتمال تکراری شدن نسخهٔ ۴ را با مسئلهٔ معروف تولد در ریاضی حساب می‌کنند؛ همان مسئله‌ای که می‌گوید در جمعی ۲۳ نفره، احتمال اینکه دو نفر تولد یکسان داشته باشند، از نصف بیشتر است. برای UUID نسخهٔ ۴، باید حدود دو و هفت دهم میلیارد میلیارد شناسه بسازید تا احتمال یک تکرار به نصف برسد. اگر هر ثانیه یک میلیارد UUID بسازید، حدود هشتادوشش سال طول می‌کشد. برای هر کاربرد واقعی، این یعنی یکتایی تضمین‌شده، به شرطی که مولد تصادفی امن باشد؛ که در این ابزار هست.

ساخت UUID نسخهٔ ۷

نسخهٔ ۷ جدیدتر است و چهل‌وهشت بیت اولش، زمان ساخت به میلی‌ثانیه از مبدأ زمانی یونیکس است و بقیه، به جز بیت‌های نسخه و گونه، تصادفی. نتیجه این است که UUIDهای نسخهٔ ۷، وقتی به شکل متن یا عدد مرتب شوند، به ترتیب زمان ساختشان مرتب می‌شوند. اگر در ابزار چند UUID نسخهٔ ۷ بسازید، می‌بینید دوازده رقم اولشان یکی یا بسیار نزدیک است؛ چون در یک میلی‌ثانیه ساخته شده‌اند. هفتادوچهار بیت تصادفی باقی‌مانده، یکتایی را حتی برای شناسه‌هایی که در یک میلی‌ثانیه ساخته می‌شوند، تضمین می‌کنند.

دوازده رقم اول یک UUID نسخهٔ ۷، اگر به عدد دهدهی تبدیل شوند، همان تایم‌استمپ میلی‌ثانیه‌ای زمان ساخت‌اند. این یعنی از روی شناسه می‌شود فهمید رکورد دقیقا کی ساخته شده. برای پایگاه داده این خوب است، چون نیازی به ستون جداگانهٔ زمان ساخت برای مرتب‌سازی نیست؛ اما اگر زمان ساخت نباید فاش شود، نسخهٔ ۴ را انتخاب کنید. برای تبدیل تایم‌استمپ به تاریخ شمسی، تبدیل تایم استمپ را ببینید.

کدام نسخه برای پایگاه داده؟

بسیاری از برنامه‌نویسان UUID نسخهٔ ۴ را کلید اصلی جدول‌های پایگاه داده می‌کنند و بعد با کند شدن درج‌ها روبه‌رو می‌شوند. دلیلش ساختار ایندکس‌هاست. پایگاه‌های داده ایندکس کلید اصلی را به شکل درختی مرتب نگه می‌دارند. با شناسهٔ ترتیبی یا نسخهٔ ۷، هر رکورد تازه به انتهای ایندکس اضافه می‌شود؛ سریع و بدون جابه‌جایی. با نسخهٔ ۴ تصادفی، هر رکورد تازه جایی تصادفی در وسط ایندکس می‌نشیند و پایگاه داده باید صفحه‌های ایندکس را مدام بشکند و جابه‌جا کند. در جدول‌های میلیون‌رکوردی، این تفاوت محسوس است.

برای ذخیره، اگر پایگاه داده نوع دادهٔ مخصوص UUID دارد، از آن استفاده کنید؛ شناسه را در ۱۶ بایت ذخیره می‌کند، در حالی که ذخیره به شکل متن ۳۶ نویسه می‌گیرد. اگر مجبورید متنی ذخیره کنید، شکل بدون خط تیره ۳۲ نویسه است و کمی فشرده‌تر. گزینهٔ بدون خط تیرهٔ ابزار برای همین است. حروف بزرگ و کوچک در UUID معنای متفاوتی ندارند، اما در مقایسهٔ متنی فرق می‌کنند؛ در کل سیستم یکی را انتخاب و رعایت کنید. استاندارد، نوشتن با حروف کوچک را توصیه می‌کند.

داده‌های آزمایشی

یکی از کاربردهای عملی ابزار، ساختن شناسه برای داده‌های آزمایشی است. اگر جدولی را برای آزمایش با صد رکورد پر می‌کنید، تعداد را صد بگذارید، شناسه‌ها را کپی کنید و در فایل داده یا اسکریپت درج بگذارید. هر بار که دکمهٔ ساخت را بزنید، مجموعهٔ کاملا تازه‌ای ساخته می‌شود. حداکثر تعداد در هر بار پانصد است؛ برای بیشتر، چند بار بسازید. برای داده‌های آزمایشی در قالب JSON، پس از ساختن فایل، آن را با مرتب‌سازی JSON بررسی کنید.

UUID و امنیت

UUID برای یکتایی ساخته شده، نه برای امنیت. نسخهٔ ۴، اگر با مولد تصادفی امن ساخته شود، قابل حدس نیست و برخی سیستم‌ها از آن برای لینک‌های اشتراک‌گذاری خصوصی استفاده می‌کنند. اما این کاربرد محدودیت‌هایی دارد؛ هر کسی که لینک را ببیند، دسترسی دارد و استاندارد UUID تضمینی برای استفاده از مولد امن نمی‌دهد. نسخهٔ ۷ بخشی قابل پیش‌بینی، یعنی زمان، دارد و برای چنین کاربردی مناسب‌تر نیست. برای رمز عبور، توکن احراز هویت و کلیدهای API، از ابزارهای مخصوص استفاده کنید؛ برای رمز، ساخت پسورد را ببینید.

نمونه؛ برنامهٔ آفلاین و همگام‌سازی

فرض کنید برنامهٔ گوشی‌ای برای ثبت سفارش ویزیتورها دارید که باید بدون اینترنت هم کار کند. ویزیتور در مغازه‌ای بدون آنتن سفارش ثبت می‌کند و برنامه بعدا، وقتی اینترنت وصل شد، سفارش‌ها را به سرور می‌فرستد. اگر شناسهٔ سفارش‌ها شمارهٔ ترتیبی سرور باشد، برنامه نمی‌تواند هنگام ثبت آفلاین شناسه بدهد و ده ویزیتور ممکن است همه سفارشی با شمارهٔ صد بسازند. با UUID، هر گوشی خودش شناسه می‌سازد و وقتی سفارش‌ها به سرور می‌رسند، هیچ تداخلی پیش نمی‌آید.

مزیت دیگر این است که اگر ارسال سفارش به سرور نیمه‌کاره بماند و برنامه دوباره تلاش کند، سرور از روی UUID تشخیص می‌دهد که این سفارش قبلا رسیده و آن را دو بار ثبت نمی‌کند. همین الگو در پرداخت‌ها هم به کار می‌رود؛ شناسهٔ یکتای هر درخواست پرداخت، جلوی برداشت دوباره را می‌گیرد اگر کاربر دو بار دکمهٔ پرداخت را بزند. در این کاربرد، نسخهٔ ۷ مزیت اضافه‌ای دارد؛ سفارش‌ها در سرور به ترتیب زمان ثبت مرتب‌اند، حتی اگر به ترتیب دیگری رسیده باشند.

UUID در زبان‌های برنامه‌نویسی

تقریبا همهٔ زبان‌ها و پایگاه‌های داده امروزی ابزار داخلی برای ساختن UUID دارند. مرورگرها تابعی مخصوص ساخت UUID نسخهٔ ۴ دارند که همین ابزار هم از آن استفاده می‌کند. پایتون، جاوا، سی‌شارپ، گو و بیشتر زبان‌های دیگر کتابخانهٔ استاندارد برای UUID دارند و پشتیبانی از نسخهٔ ۷ در نسخه‌های جدیدتر بسیاری از آن‌ها اضافه شده یا با کتابخانه‌های رایج در دسترس است. پایگاه‌های دادهٔ رایج هم نوع دادهٔ UUID و تابع ساختنش را دارند.

این ابزار برای وقتی است که بیرون از کد، چند UUID لازم دارید؛ برای فایل تنظیمات، داده‌های آزمایشی، نوشتن مستندات یا آزمایش دستی API. در کد واقعی، UUID را با کتابخانهٔ زبان خودتان بسازید، نه با کپی از ابزارهای آنلاین؛ چون هر بار اجرا باید شناسهٔ تازه‌ای ساخته شود.

جایگزین‌های UUID

UUID تنها راه ساختن شناسهٔ یکتای توزیع‌شده نیست. برخی سیستم‌ها از قالب‌هایی استفاده می‌کنند که مثل نسخهٔ ۷ با زمان شروع می‌شوند اما با الفبای فشرده‌تری نوشته می‌شوند و کوتاه‌ترند. شبکه‌های اجتماعی بزرگ گاهی شناسه‌های ۶۴ بیتی با زمان، شمارهٔ سرور و شمارندهٔ ترتیبی می‌سازند که در یک عدد صحیح معمولی جا می‌شوند. برخی کتابخانه‌ها شناسه‌های تصادفی کوتاه‌تر با الفبای امن برای نشانی وب می‌سازند. هر کدام مزیت خودش را دارد، اما UUID به دلیل استاندارد بودن و پشتیبانی همه‌جایی‌اش، انتخاب پیش‌فرض بیشتر پروژه‌هاست.

خطاهای رایج

خطای اول، ساختن UUID با تابع‌های تصادفی معمولی زبان برنامه‌نویسی به جای مولد امن است که احتمال تکرار را بالا می‌برد. خطای دوم، استفاده از نسخهٔ ۴ برای کلید اصلی جدول‌های بسیار بزرگ بدون در نظر گرفتن اثرش بر ایندکس. خطای سوم، ذخیرهٔ UUID به شکل متن با حروف ناهمسان، گاهی بزرگ و گاهی کوچک، که مقایسه‌ها را خراب می‌کند. خطای چهارم، فرض اینکه UUID نسخهٔ ۷ زمان ساخت را پنهان می‌کند. و خطای پنجم، کوتاه کردن UUID برای زیبایی؛ برداشتن چند رقم، احتمال تکرار را به شدت بالا می‌برد.

UUID در نشانی‌ها و API

UUID در نشانی صفحه‌ها و API‌ها رایج است؛ مثلا نشانی صفحهٔ یک سفارش یا درخواست دریافت یک فایل. مزیتش در برابر شمارهٔ ترتیبی این است که حدس زدن شناسه‌های دیگر ممکن نیست. با شمارهٔ ترتیبی، کسی که سفارش شمارهٔ ۱۰۰۵ را دارد، می‌تواند ۱۰۰۴ را امتحان کند و اگر سیستم دسترسی را درست بررسی نکند، سفارش دیگری را ببیند. با UUID نسخهٔ ۴، چنین حدسی ممکن نیست. البته این جای بررسی درست دسترسی را نمی‌گیرد؛ سیستم همیشه باید بررسی کند که کاربر اجازهٔ دیدن آن رکورد را دارد یا نه.

عیب UUID در نشانی‌ها طولش است؛ ۳۶ نویسه، نشانی را بلند و ناخوانا می‌کند. اگر نشانی قرار است دست‌به‌دست شود یا در پیامک فرستاده شود، این طول مهم است. برخی سیستم‌ها UUID را برای نشانی با الفبای فشرده‌تری می‌نویسند تا کوتاه‌تر شود، در حالی که در پایگاه داده همان ۱۲۸ بیت را نگه می‌دارند.

یکتایی در عمل

اگرچه احتمال تکرار UUID ریاضی صفر نیست، اما از احتمال خطاهای سخت‌افزاری، مثل خرابی حافظه یا دیسک، بسیار کمتر است. برای همین، سیستم‌ها معمولا برای تکرار UUID بررسی جداگانه‌ای انجام نمی‌دهند و فقط قید یکتایی در پایگاه داده را به‌عنوان آخرین سد نگه می‌دارند. اگر روزی با UUID تکراری روبه‌رو شدید، تقریبا همیشه دلیلش باگ در کد است، مثلا کپی شدن یک شیء همراه شناسه‌اش، نه بدشانسی ریاضی.

خواندن یک UUID ناشناس

اگر UUIDی در گزارش، لاگ یا نشانی دیدید و می‌خواهید بدانید چه نوعی است، رقم سیزدهم را نگاه کنید؛ اولین رقم پس از خط تیرهٔ دوم. اگر ۴ است، شناسه تصادفی است و اطلاعات دیگری ندارد. اگر ۷ است، دوازده رقم اول را به عدد دهدهی تبدیل کنید؛ تایم‌استمپ میلی‌ثانیه‌ای زمان ساخت است. اگر ۱ است، شناسهٔ قدیمی زمان‌محور است که بخش آخرش ممکن است نشانی سخت‌افزاری دستگاه سازنده باشد. همین ویژگی است که نسخهٔ ۱ را در سیستم‌های امروزی کمتر محبوب کرده؛ شناسه‌ای که قرار است فقط یکتا باشد، نباید اطلاعاتی دربارهٔ دستگاه و زمان ساختش فاش کند، مگر اینکه عمدا نسخهٔ ۷ را برای مرتب‌سازی زمانی انتخاب کرده باشید. این ابزار نسخهٔ ۱ نمی‌سازد.

ابزارهای مرتبط

برای ساختن عدد تصادفی در بازهٔ دلخواه، عدد تصادفی را ببینید و برای اثر انگشت داده‌ها، ساخت هش. همهٔ ابزارهای برنامه‌نویسی در ابزارهای برنامه‌نویسی آمده‌اند.