UUID জেনারেটর

একটি ফ্রি অনলাইন UUID জেনারেটর ও ডিকোডার, সবই আপনার ব্রাউজারে

এই ফ্রি অনলাইন UUID জেনারেটর সর্বজনীনভাবে অনন্য শনাক্তকারী (universally unique identifier) — যা GUID নামেও পরিচিত — তাৎক্ষণিকভাবে তৈরি করে, কোনো সাইন-আপ বা সীমা ছাড়াই। প্রতিটি UUID স্থানীয়ভাবে আপনার ব্রাউজারের ক্রিপ্টোগ্রাফিকভাবে নিরাপদ র‍্যান্ডম নম্বর জেনারেটর (CSPRNG) দিয়ে তৈরি হয়, তাই কিছুই কখনও সার্ভারে পাঠানো হয় না এবং আপনি নিশ্চিন্তে প্রোডাকশন কী, টেস্ট ডেটা বা সংবেদনশীল সিস্টেমে এই আইডিগুলো ব্যবহার করতে পারেন। এটি অফলাইনে কাজ করে, একটি একক আইডি বা বাল্কে হাজার হাজার তৈরি করে, এবং জেনারেটরের সাথে একটি বিল্ট-ইন UUID ডিকোডার যুক্ত করে যাতে আপনি এক জায়গাতেই শনাক্তকারী তৈরি ও পরিদর্শন দুটোই করতে পারেন।

আপনার একটি র‍্যান্ডম UUID দরকার হোক, একটি ডেটাবেস সিড করার জন্য একটি ব্যাচ দরকার হোক, বা হাতে পাওয়া কোনো UUID দ্রুত ডিকোড করার উপায় দরকার হোক — এই টুলটি পুরো ওয়ার্কফ্লো কভার করে; কোনো ইনস্টলেশন নেই, কোনো লাইব্রেরি নেই, এবং এক লাইনও কোড নেই। এটি uuidgenerator.net বা guidgenerator.com-এর মতো সাইট যা দেয় তার চেয়ে অনেক বেশি এগিয়ে, ছয়টি UUID ভার্সন, প্রতিটি আউটপুট ফরম্যাট, বাল্ক এক্সপোর্ট এবং একটি সম্পূর্ণ ডিকোডারকে একটি একক প্রাইভেট পেজে একত্র করে।

প্রতিটি UUID ভার্সন: v1, v3, v4, v5, v6 এবং v7

আপনার ব্যবহারের উপযোগী ভার্সনটি বেছে নিন। UUID v4 সম্পূর্ণ র‍্যান্ডম এবং সবচেয়ে সাধারণ পছন্দ — Python-এ uuid.uuid4(), Java-তে java.util.UUID.randomUUID(), বা JavaScript-এ crypto.randomUUID() থেকে আপনি যে মানটি পাবেন সেটাই। UUID v7 একটি Unix মিলিসেকেন্ড টাইমস্ট্যাম্প এম্বেড করে, তাই আইডিগুলো সময় অনুযায়ী সর্টযোগ্য এবং v4-এর তুলনায় অনেক ভালো ইনডেক্স লোকালিটিসহ চমৎকার ডেটাবেস প্রাইমারি কী হয়। v1 এবং v6 হলো গ্রেগরিয়ান-টাইমস্ট্যাম্প UUID (v6 হলো পুনর্বিন্যস্ত, সর্টযোগ্য রূপ), এখানে একটি র‍্যান্ডম নোড দিয়ে তৈরি হয় যাতে কোনো MAC অ্যাড্রেস কখনও ফাঁস না হয়। আপনি RFC 9562-এর বিশেষ NIL (সম্পূর্ণ শূন্য) এবং Max (সম্পূর্ণ এক) মানও তৈরি করতে পারেন।

স্থিতিশীল, পুনরুৎপাদনযোগ্য আইডির জন্য নেম-বেসড ভার্সন বেছে নিন: v5 (SHA-1) এবং v3 (MD5) একটি namespace-কে একটি নাম স্ট্রিংয়ের সাথে হ্যাশ করে, তাই একই ইনপুট সবসময় একই UUID দেয়। একটি স্ট্যান্ডার্ড namespace বেছে নিন — DNS, URL, OID বা X.500 — অথবা নিজেরটি পেস্ট করুন, যেকোনো নাম লিখুন, এবং একটি ডোমেন, URL বা কী থেকে একটি ডিটারমিনিস্টিক শনাক্তকারী নির্ণয় করুন। আউটপুট Python-এর uuid.uuid5() / uuid.uuid3()-এর সাথে ঠিক মিলে যায়।

বাল্ক জেনারেশন এবং নমনীয় আউটপুট ফরম্যাট

একবারে ১০,০০০টি পর্যন্ত UUID তৈরি করুন এবং সেগুলো প্লেইন টেক্সট, একটি JSON অ্যারে, একটি CSV কলাম, বা চালানোর জন্য প্রস্তুত SQL VALUES হিসেবে এক্সপোর্ট করুন — টেবিল সিড করা, ফিক্সচার তৈরি করা, বা কয়েক সেকেন্ডে বাস্তবসম্মত টেস্ট ডেটা তৈরির জন্য আদর্শ। আপনার স্ট্যাকের সাথে মিলিয়ে আউটপুট ফরম্যাট করুন: আপারকেস টগল করুন, কমপ্যাক্ট রূপের জন্য হাইফেন সরিয়ে ফেলুন, .NET GUID লিটারালের জন্য কার্লি ব্রেসে মুড়ে দিন, বা RDF ও XML ডকুমেন্টের জন্য urn:uuid: প্রিফিক্স যোগ করুন।

যেহেতু সবকিছু ক্লায়েন্ট-সাইডে চলে, হাজার হাজার আইডির বাল্ক জেনারেশন তাৎক্ষণিক এবং কখনও নেটওয়ার্ক স্পর্শ করে না — এটিকে uuidtools.com বা it-tools.tech-এর ভেতরের UUID প্যানেলের তুলনায় একটি দ্রুততর ও আরও প্রাইভেট বিকল্প করে তোলে।

যেকোনো UUID অনলাইনে ডিকোড ও পরিদর্শন করুন

যেকোনো শনাক্তকারী বিল্ট-ইন ডিকোডারে পেস্ট করে তাৎক্ষণিকভাবে এর গঠন ভেঙে দেখুন। অনলাইন UUID ডিকোডার ভার্সন এবং ভেরিয়েন্ট রিপোর্ট করে, এবং সময়-ভিত্তিক UUID-এর জন্য এম্বেড করা ডেটা বের করে আনে: v1, v6 এবং v7 থেকে সঠিক তৈরির টাইমস্ট্যাম্প, সেই সাথে v1 এবং v6 থেকে ক্লক সিকোয়েন্স এবং নোড (নোডটি একটি র‍্যান্ডম মান নাকি একটি প্রকৃত MAC অ্যাড্রেস তা চিহ্নিত করে)। এটি RFC 4122/9562 ভেরিয়েন্ট এবং NIL ও Max বিশেষ মান শনাক্ত করে, এবং ব্রেস, URN প্রিফিক্স, মিশ্র কেস ও অনুপস্থিত হাইফেন সহ্য করে।

এটি দৈনন্দিন ডিবাগিংয়ের জন্য একটি সহায়ক সঙ্গী করে তোলে: একটি আইডি সত্যিই র‍্যান্ডম (v4) নাকি সময়-ভিত্তিক তা নিশ্চিত করুন, একটি v1/v6/v7 রেকর্ড কখন তৈরি হয়েছিল তা পুনরুদ্ধার করুন, একটি নেম-বেসড v3/v5 আইডিতে কোনো লুকানো ডেটা নেই তা যাচাই করুন, অথবা কোডে পৌঁছানোর আগেই কোনো স্ট্রিং একটি সঠিকভাবে গঠিত UUID কিনা তা কেবল যাচাই করে নিন।

কোন UUID ভার্সন আপনার ব্যবহার করা উচিত?

বেশিরভাগ প্রয়োজনের জন্য একটি র‍্যান্ডম v4 UUID-ই সঠিক ডিফল্ট: এটি কখন বা কোথায় তৈরি হয়েছিল সে সম্পর্কে কোনো তথ্য বহন করে না, যা সর্বজনীন শনাক্তকারী, সেশন টোকেন, বা এমন যেকোনো কিছুর জন্য ঠিক প্রয়োজন যা তৈরির সময় ফাঁস করা উচিত নয়। শনাক্তকারীটি যখন একটি ডেটাবেস কী-ও হয় তখন v7 বেছে নিন — এর এম্বেড করা টাইমস্ট্যাম্প রো-গুলোকে মোটামুটি সন্নিবেশ-ক্রমে রাখে, যা ইনডেক্স ফ্র্যাগমেন্টেশন কমায় এবং উচ্চ-রাইট টেবিলে রেঞ্জ কোয়েরি দ্রুত করে।

নেম-বেসড v5 আদর্শ যখন আপনার প্রতিবার একই লজিক্যাল এনটিটির জন্য একই UUID দরকার — যেমন একটি ক্যানোনিক্যাল URL থেকে একটি স্থিতিশীল প্রোডাক্ট আইডি নির্ণয় করা। আপনি যখন একটি REPL-এ ঢুকতে বা একটি লাইব্রেরি সেটআপ করতে চান না, তখন অনলাইনে UUID তৈরি করাই একটি সঠিক, সংঘর্ষ-প্রতিরোধী আইডি পাওয়ার দ্রুততম উপায়। প্রতিটি v4-এর পিছনে ১২২ বিট এনট্রপি থাকায়, বিশাল স্কেলেও সংঘর্ষের সম্ভাবনা কার্যত শূন্য।

UtiloKit বনাম uuidgenerator.net, guidgenerator.com এবং it-tools.tech

Uuidgenerator.net সবচেয়ে বেশি ভিজিট করা UUID টুলগুলোর একটি কিন্তু প্রতি পেজ ভিজিটে একটি একক v4 UUID তৈরি করে — কোনো বাল্ক মোড নেই, কোনো v7 নেই, কোনো ডিকোডার নেই, এবং কোনো ফরম্যাট অপশন নেই। Guidgenerator.com একই রকম: সহজ, দ্রুত, কিন্তু একটি ফরম্যাট ও একটি ভার্সনে সীমাবদ্ধ। It-tools.tech একটি বড় টুলবক্সের অংশ হিসেবে UUID কভার করে এবং এর UI পরিষ্কার, কিন্তু জেনারেশন ও ডিকোডিংকে আলাদা স্ক্রিনে ভাগ করে এবং বাল্ক SQL এক্সপোর্ট সমর্থন করে না।

UtiloKit ছয়টি UUID ভার্সন (v1, v3, v4, v5, v6, v7), প্রতিটি ফরম্যাট (স্ট্যান্ডার্ড, আপারকেস, নো-হাইফেন, ব্রেসড, URN), JSON/CSV/SQL-এ বাল্ক এক্সপোর্ট এবং একটি সম্পূর্ণ ডিকোডার একটি একক স্ক্রিনে রাখে। সবকিছু CSPRNG সহ আপনার ব্রাউজারে চলে — কোনো সার্ভার নেই, কোনো অ্যাকাউন্ট নেই, কোনো ফাইল আপলোড নেই। টুলটি প্রথম লোডের পর অফলাইনেও কাজ করে, যা গুরুত্বপূর্ণ যদি আপনি প্লেনে বা অনির্ভরযোগ্য সংযোগযুক্ত জায়গায় একটি ডেটাবেস সিড করছেন।

UUID ভার্সন গভীরভাবে ব্যাখ্যা: v1 থেকে v7

UUID v1 সময়-ভিত্তিক: এটি একটি ৬০-বিট গ্রেগরিয়ান টাইমস্ট্যাম্প (১৫৮২ সালের অক্টোবর থেকে ১০০-ন্যানোসেকেন্ড ব্যবধানে) একটি ক্লক সিকোয়েন্স এবং যে নেটওয়ার্ক ইন্টারফেস এটি তৈরি করেছে তার MAC অ্যাড্রেস সহ এনকোড করে। MAC অ্যাড্রেসই মূল গোপনীয়তা সমস্যা — একটি v1 UUID কখন এবং কোথায় তৈরি হয়েছিল দুটোই ফাঁস করে, যা এটিকে সর্বজনীন শনাক্তকারীর জন্য অনুপযুক্ত করে। UUID v2 (DCE Security) লিগ্যাসি Unix সিস্টেমের বাইরে খুব কমই দেখা যায়; এটি টাইমস্ট্যাম্পের অংশ একটি POSIX UID বা GID দিয়ে প্রতিস্থাপন করে, প্রক্রিয়ায় অনন্যতার নিশ্চয়তা বিসর্জন দেয়।

UUID v3 এবং v5 নেম-বেসড: এরা একটি namespace UUID-কে একটি নির্বিচার নাম স্ট্রিংয়ের সাথে হ্যাশ করে এবং ফলাফলটি একটি UUID হিসেবে এনকোড করে। v3 MD5 ব্যবহার করে; v5 SHA-1 ব্যবহার করে এবং নতুন কোডের জন্য এটিই পছন্দনীয়। উভয়ই ডিটারমিনিস্টিক — একই namespace সহ একই নাম সবসময় একই UUID দেয়, যা এদের URL, ডোমেন নাম বা যেকোনো ক্যানোনিক্যাল কী থেকে স্থিতিশীল আইডি নির্ণয়ের জন্য আদর্শ করে। UUID v4 এর বিপরীত: কোনো এম্বেড করা তথ্য ছাড়াই ১২২ বিট বিশুদ্ধ র‍্যান্ডমনেস, CSPRNG দিয়ে তৈরি। এটি আজ পর্যন্ত সবচেয়ে বহুল ব্যবহৃত ভার্সন এবং JavaScript-এ crypto.randomUUID() ও Python-এ uuid.uuid4() যা ফেরত দেয়।

UUID v6 v1-এর টাইমস্ট্যাম্প ফিল্ডগুলো পুনর্বিন্যস্ত করে যাতে বাইটগুলো কালানুক্রমিকভাবে সর্ট হয় — v1-এর তথ্য না বদলে এর সর্টযোগ্যতা ঠিক করে। UUID v7, RFC 9562 (২০২২)-এ প্রবর্তিত, একটি পরিচ্ছন্ন পদ্ধতি নেয়: প্রথম ৪৮ বিট একটি স্ট্যান্ডার্ড Unix মিলিসেকেন্ড টাইমস্ট্যাম্প, তারপর ৭৪ বিট র‍্যান্ডমনেস। যেহেতু টাইমস্ট্যাম্প সবচেয়ে-গুরুত্বপূর্ণ বিটগুলো দখল করে, v7 UUID তৈরির ক্রমে লেক্সিকোগ্রাফিকভাবে সর্ট হয় — v1-এর মতো MAC অ্যাড্রেস ফাঁস না করেই এদের v4-এর চেয়ে অনেক ভালো ডেটাবেস প্রাইমারি কী করে তোলে। সর্টযোগ্য, বিশ্বব্যাপী অনন্য আইডি প্রয়োজন এমন বেশিরভাগ নতুন প্রকল্পের জন্য v7 এখন প্রস্তাবিত ডিফল্ট।

UUID সংঘর্ষের সম্ভাবনা: কেন ডুপ্লিকেট কার্যত অসম্ভব

একটি UUID v4-এ ১২২ বিট র‍্যান্ডম ডেটা থাকে (৬ বিট ভার্সন ও ভেরিয়েন্টের জন্য সংরক্ষিত)। সম্ভাব্য মানের মোট সংখ্যা হলো 2¹²² — প্রায় ৫.৩ × ১০^৩৬। বার্থডে প্রবলেম আমাদের বলে যে অন্তত একটি ডুপ্লিকেট জোড়া তৈরির ৫০% সম্ভাবনায় পৌঁছাতে আপনাকে প্রায় ২.৭ × ১০^১৮টি UUID তৈরি করতে হবে — ২.৭ কুইন্টিলিয়ন। প্রতি সেকেন্ডে এক বিলিয়ন UUID-এর থ্রুপুটে, সেই সীমায় পৌঁছাতে ৮৫ বছর ধারাবাহিক জেনারেশন লাগবে। যেকোনো বাস্তবসম্মত সিস্টেমে, সফটওয়্যারের আয়ুষ্কালে সংঘর্ষের সম্ভাবনা শূন্য থেকে আলাদা করা যায় না।

বার্থডে প্যারাডক্স সূত্র এটিকে সুনির্দিষ্ট করে: d আকারের একটি স্পেসে সংঘর্ষের সম্ভাবনা p-এর জন্য প্রয়োজনীয় নমুনার সংখ্যা প্রায় n ≈ √(2d × ln(1/(1−p)))। d = 2¹²² এবং p = ০.৫ দিলে, তা দেয় ২.৭ × ১০^১৮। এমনকি এক-ট্রিলিয়নে-এক সম্ভাবনার জন্যও (p = ১০^−১২), আপনাকে এখনও প্রায় ২.৬ বিলিয়ন UUID তৈরি করতে হবে।

একমাত্র বাস্তব ঝুঁকি গণিতে নয় বরং র‍্যান্ডম নম্বর জেনারেটরের মানে। একটি ভাঙা বা দুর্বলভাবে সিড করা PRNG কার্যকর এনট্রপি নাটকীয়ভাবে কমিয়ে দেয় — OS এনট্রপি পুল শুরু হওয়ার আগে ক্লোন করা প্রাথমিক ভার্চুয়াল মেশিন ইমেজ প্রোডাকশনে ডুপ্লিকেট UUID তৈরি করেছে। সবসময় একটি CSPRNG (যেমন ব্রাউজারের crypto.getRandomValues()) ব্যবহার করুন, Math.random() বা কোনো সিড করা ছদ্ম-র‍্যান্ডম উৎস নয়, এবং পুনরায় সিড না করে কখনও একটি প্রসেস ফর্ক করবেন না। এই টুলটি একচেটিয়াভাবে ব্রাউজার CSPRNG ব্যবহার করে, তাই এটি যে প্রতিটি UUID তৈরি করে তা সম্পূর্ণ ১২২ বিট এনট্রপি বহন করে।

ডেটাবেস প্রাইমারি কী হিসেবে UUID: v4 বনাম v7 বনাম অটো-ইনক্রিমেন্ট বনাম ULID

অটো-ইনক্রিমেন্ট ইন্টিজার আইডি কমপ্যাক্ট (INT-এর জন্য ৪ বাইট, BIGINT-এর জন্য ৮ বাইট), স্বাভাবিকভাবে সাজানো এবং দ্রুত ইনডেক্সযোগ্য — কিন্তু যে কেউ একটি URL বা API রেসপন্স দেখলে এরা রো-সংখ্যা প্রকাশ করে, এবং এরা ডিস্ট্রিবিউটেড রাইটে ভেঙে পড়ে: দুটি ডেটাবেস সার্ভার নিজ নিজ কাউন্টার ইনক্রিমেন্ট করলে একটি বাহ্যিক সমন্বয় স্তর ছাড়া ডুপ্লিকেট আইডি তৈরি করবে। UUID v4 (১৬ বাইট) সেই সমন্বয় সমস্যা সমাধান করে — প্রতিটি নোড স্বাধীনভাবে বিশ্বব্যাপী অনন্য আইডি তৈরি করে — কিন্তু এর র‍্যান্ডম বিট প্যাটার্ন মানে পরপর ইনসার্টগুলো একটি B-tree ইনডেক্সে এলোমেলো অবস্থানে পড়ে। টেবিল যত বড় হয়, প্রায় প্রতিটি ইনসার্ট একটি পেজ মিস হয়, যা ইনডেক্স ফ্র্যাগমেন্টেশন, ঘন ঘন পেজ স্প্লিট এবং বড় টেবিলে নাটকীয়ভাবে ধীর রাইট থ্রুপুটের দিকে নিয়ে যায়।

UUID v7 এই টানাপোড়েন সমাধান করে। এর সবচেয়ে-গুরুত্বপূর্ণ বিটে থাকা Unix মিলিসেকেন্ড টাইমস্ট্যাম্প মানে কাছাকাছি সময়ে তৈরি আইডিগুলো সংখ্যাগতভাবে সন্নিহিত, তাই ইনসার্টগুলো অটো-ইনক্রিমেন্টের মতোই ইনডেক্সের ডান প্রান্তে গুচ্ছবদ্ধ হয় — তবুও বিশ্বব্যাপী অনন্য থাকে এবং কোনো সমন্বয়ের প্রয়োজন হয় না। অটো-ইনক্রিমেন্টের তুলনায় ট্রেড-অফ হলো আকার (১৬ বনাম ৮ বাইট) এবং আইডিতে আনুমানিক তৈরির সময় দৃশ্যমান থাকা। বেশিরভাগ আধুনিক অ্যাপ্লিকেশনের জন্য সেই ট্রেড-অফ করা ভালো। ULID (Universally Unique Lexicographically Sortable Identifier) Crockford Base32 এনকোডিং (২৬ অক্ষর, কোনো হাইফেন নেই, কেস-ইনসেনসিটিভ) ব্যবহার করে একই ফল অর্জন করে, যা লগ ও URL-এ বেশি পাঠযোগ্য হতে পারে। Snowflake ID, Twitter ও Discord স্কেলে ব্যবহৃত, একটি ৪১-বিট মিলিসেকেন্ড টাইমস্ট্যাম্প, একটি ডেটাসেন্টার আইডি, একটি ওয়ার্কার আইডি এবং একটি সিকোয়েন্স নম্বর একটি ৬৪-বিট ইন্টিজারে প্যাক করে — সময়-সর্টযোগ্য, অত্যন্ত দ্রুত, কিন্তু ওয়ার্কার আইডির কেন্দ্রীয় বরাদ্দ প্রয়োজন।

ব্যবহারিক সিদ্ধান্ত গাছ: বিশ্বব্যাপী অনন্য, সর্টযোগ্য প্রাইমারি কী প্রয়োজন এমন বেশিরভাগ নতুন প্রকল্পের জন্য UUID v7 ব্যবহার করুন; যখন আপনি স্পষ্টভাবে এমন আইডি চান যা তৈরির সময় বা ক্রম সম্পর্কে কিছুই প্রকাশ করে না তখন UUID v4 ব্যবহার করুন; পরিচ্ছন্ন URL উপস্থাপনা ও ক্রস-ল্যাঙ্গুয়েজ ইকোসিস্টেম সমর্থনসহ সময়-সর্টযোগ্য আইডি প্রয়োজন হলে ULID ব্যবহার করুন; এবং Snowflake শুধু তখনই বিবেচনা করুন যখন আপনি Twitter-স্কেলে কাজ করছেন এবং ওয়ার্কার আইডি বরাদ্দের অবকাঠামো সামলাতে পারেন।

বিকল্প অনন্য শনাক্তকারী: ULID, NanoID, CUID এবং MongoDB ObjectID

UUID স্পেসিফিকেশনই বিশ্বব্যাপী অনন্য শনাক্তকারী তৈরির একমাত্র উপায় নয়, এবং কিছু ব্যবহারের ক্ষেত্রে বিকল্পগুলোর বাস্তব সুবিধা আছে। ULID (Universally Unique Lexicographically Sortable Identifier) ৪৮ বিট মিলিসেকেন্ড টাইমস্ট্যাম্প এবং ৮০ বিট র‍্যান্ডমনেস ২৬টি Crockford Base32 অক্ষরে এনকোড করে — এটিকে URL-নিরাপদ, কেস-ইনসেনসিটিভ এবং কোনো হাইফেন ছাড়াই সময়-সর্টযোগ্য করে তোলে। NanoID একটি ভিন্ন কৌশল নেয়: এটি একটি URL-নিরাপদ বর্ণমালা (A–Za–z0–9_-) ব্যবহার করে UUID v4-এর সাথে তুলনীয় সংঘর্ষ প্রতিরোধসহ ২১-অক্ষরের আইডি তৈরি করে, স্ট্রিং হিসেবে প্রায় ৪০% ছোট থাকে। NanoID বিশেষত JavaScript পরিবেশে জনপ্রিয় যেখানে ৩৬-অক্ষরের UUID হেক্স ফরম্যাটের চেয়ে ছোট, পরিচ্ছন্ন আইডি বেশি পছন্দনীয়।

CUID (Collision-resistant Unique ID) বিশেষভাবে ওয়েব ব্যবহারের জন্য ডিজাইন করা হয়েছিল: এটি একটি টাইমস্ট্যাম্প, একটি ব্রাউজার ফিঙ্গারপ্রিন্ট, একটি প্রতি-প্রসেস কাউন্টার এবং র‍্যান্ডম বাইট সংযুক্ত করে, এমন আইডি তৈরি করে যা একাধিক ক্লায়েন্টে একসাথেও সংঘর্ষ-প্রতিরোধী। MongoDB ObjectID একটি ১২-বাইট শনাক্তকারী (২৪ হেক্স অক্ষর হিসেবে রেন্ডার করা) যা একটি ৪-বাইট Unix টাইমস্ট্যাম্প, একটি ৫-বাইট মেশিন-ও-প্রসেস শনাক্তকারী এবং একটি ৩-বাইট র‍্যান্ডম কাউন্টার প্যাক করে — চেতনায় UUID v7-এর অনুরূপ কারণ এটি সময়-সর্টযোগ্য এবং মেশিন পরিচয় এম্বেড করে, UUID v7 স্পেসিফিকেশনের এক দশকেরও বেশি আগে থেকে।

এই ফরম্যাটগুলোর মধ্যে বেছে নেওয়া আপনার সীমাবদ্ধতার ওপর নির্ভর করে। আপনার যদি বিস্তৃত RFC সম্মতি ও ইকোসিস্টেম সমর্থন দরকার হয় (প্রতিটি প্রধান ডেটাবেস, ORM এবং ল্যাঙ্গুয়েজে UUID সমর্থন বিল্ট-ইন আছে), সর্টযোগ্য কী-র জন্য UUID v7 এবং অস্বচ্ছ টোকেনের জন্য UUID v4 ব্যবহার করুন। আপনার যদি URL-এ ছোট স্ট্রিং দরকার হয়, NanoID বা ULID চমৎকার পছন্দ। আপনি যদি ইতিমধ্যে MongoDB ইকোসিস্টেমে থাকেন, ObjectID স্বাভাবিক মানানসই। মূল অন্তর্দৃষ্টি হলো এই সব ফরম্যাট একই মূল সমস্যা সমাধান করে — কেন্দ্রীয় সমন্বয় ছাড়া একটি বিশ্বব্যাপী অনন্য শনাক্তকারী তৈরি করা — এবং পার্থক্যগুলো আকার, সর্টযোগ্যতা, পাঠযোগ্যতা ও তথ্য প্রকাশের মধ্যকার ট্রেড-অফে।