UUID জেনারেটর

UUID কী?

একটি UUID (ইউনিভার্সালি ইউনিক আইডেন্টিফায়ার), যাকে GUID-ও বলা হয়, একটি 128-বিট মান যা পাঁচটি হাইফেন-বিভক্ত গ্রুপে 32টি হেক্সাডেসিমাল অঙ্কে লেখা হয় — 8-4-4-4-12, উদাহরণস্বরূপ f47ac10b-58cc-4372-a567-0e02b2c3d479। উদ্দেশ্য এমন একটি শনাক্তকারী তৈরি করা যা কোনো কেন্দ্রীয় কর্তৃপক্ষ ছাড়াই অনন্য, যাতে স্বতন্ত্র সিস্টেম প্রতিটি এমন ID তৈরি করতে পারে যা কখনও সংঘর্ষ করবে না। 13তম অঙ্কটি ভার্সন এনকোড করে এবং 17তম ভ্যারিয়েন্ট এনকোড করে।

এক নজরে UUID ভার্সন

এই টুলটি v4, v7, v1 ও v5 তৈরি করে। ভার্সন 2 (DCE সিকিউরিটি), 6 (পুনর্বিন্যস্ত v1) ও 8 (কাস্টম) অ্যাপ্লিকেশন কোডে খুব কমই প্রয়োজন হয়। আমরা ইচ্ছাকৃতভাবে MD5-ভিত্তিক v3 বাদ দিই — MD5 ভাঙা এবং ব্রাউজারের ক্রিপ্টো API-তে অনুপলব্ধ — এবং স্পেসিফিকেশন দ্বারা প্রাধান্যপ্রাপ্ত SHA-1-ভিত্তিক v5 প্রদান করি।

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

• শুধু একটি অনন্য ID দরকার? v4 (র‍্যান্ডম) ব্যবহার করুন — এটি নিরাপদ ডিফল্ট।
• ডেটাবেস প্রাইমারি কী? v7 ব্যবহার করুন — এর অগ্রণী টাইমস্ট্যাম্প ইনসার্টকে সাজানো রাখে, র‍্যান্ডম v4 কী যে ইনডেক্স-ফ্র্যাগমেন্টেশন তৈরি করে তা এড়িয়ে।
• চান একই ইনপুট সবসময় একই ID দিক? একটি নেমস্পেস ও নাম সহ v5 ব্যবহার করুন।
• কোনো পুরোনো সিস্টেমের সঙ্গে আন্তঃকার্য? v1 ব্যবহার করুন।

একটি UUID পরীক্ষা করুন

যেকোনো UUID পেস্ট করে যাচাই করুন এটি বৈধ কিনা এবং এর ভার্সন, ভ্যারিয়েন্ট ও (v1/v7-এর জন্য) সন্নিবেশিত টাইমস্ট্যাম্প পড়ুন।

UUID কি সত্যিই অনন্য?

র‍্যান্ডম v4-এর জন্য, সংঘর্ষের সম্ভাবনা জ্যোতির্বৈজ্ঞানিকভাবে কম: 122 র‍্যান্ডম বিট সহ আপনি প্রায় 85 বছর ধরে প্রতি সেকেন্ডে একশো কোটি UUID তৈরি করতে পারবেন এবং তবুও একটিমাত্র ডুপ্লিকেটের সম্ভাবনা মাত্র প্রায় 50% থাকবে। বাস্তবে আপনি এগুলিকে অনন্য ধরে নিতে পারেন। তবে একটি UUID একটি শনাক্তকারী, কোনো গোপন রহস্য নয় — এটিকে কখনও পাসওয়ার্ড বা নিরাপত্তা টোকেন হিসেবে ব্যবহার করবেন না।

RFC 4122 থেকে RFC 9562 পর্যন্ত

UUID প্রথম IETF দ্বারা RFC 4122-তে (জুলাই 2005) মানকীকৃত হয়, যা ভার্সন 1 থেকে 5 সংজ্ঞায়িত করে এবং urn:uuid: নেমস্পেস নিবন্ধন করে। প্রায় দুই দশকের বাস্তব ব্যবহার — বিশেষত বিতরণকৃত ডেটাবেসের বিস্ফোরণ — একটি ঘাটতি উন্মোচন করে: মূল টাইম-বেসড ফরম্যাটগুলি তৈরির-ক্রমে সর্ট হওয়ার জন্য নকশা করা হয়নি, যা ডেটাবেসের ভীষণ প্রয়োজন। RFC 9562, মে 2024-তে প্রকাশিত, RFC 4122-কে অপ্রচলিত করে এবং সেই চাহিদার উত্তর দেয়। এটি পুরোনো ভার্সনগুলি অক্ষত রাখে এবং তিনটি নতুন যোগ করে — v6 (একটি পুনর্বিন্যস্ত v1), v7 (Unix-মিলিসেকেন্ড সময় ও র‍্যান্ডমনেস) ও v8 (একটি মুক্ত-রূপ, ভেন্ডর-সংজ্ঞায়িত লেআউট) — সঙ্গে নতুন Max UUID সেন্টিনেল। এটি লিগ্যাসি Microsoft COM ভ্যারিয়েন্টকে পরিধির বাইরে ঘোষণা করে, তাই আধুনিক ভার্সনগুলি কেবল মূলধারার "ভ্যারিয়েন্ট 1" লেআউটে প্রযোজ্য। সংক্ষেপে: আপনি যা ইতিমধ্যে ব্যবহার করেন তা কিছুই ভাঙেনি, এবং সময়-সর্টেবল ID অবশেষে অসামঞ্জস্যপূর্ণ ঘরোয়া স্কিমের জোড়াতালির বদলে একটি মানক হয়ে উঠল।

UUID-র গঠন, বিট-বাই-বিট

সমস্ত 128 বিটের ব্যবহার নির্ধারিত। 16টি অক্টেটে, দুটি ছোট ফিল্ড সংরক্ষিত থাকে এবং বাকিগুলি পেলোড বহন করে — ভার্সনের উপর নির্ভর করে র‍্যান্ডম বিট, একটি টাইমস্ট্যাম্প, বা একটি হ্যাশ। ভার্সন সপ্তম অক্টেটের চারটি উচ্চ বিটে বসে (তৃতীয় গ্রুপের প্রথম হেক্স অঙ্ক), তাই এটি সবসময় 1–8-এর একটি পড়ে। ভ্যারিয়েন্ট নবম অক্টেটের উচ্চ বিটে বসে (চতুর্থ গ্রুপের প্রথম হেক্স অঙ্ক), এবং প্রতিটি মানক UUID-র জন্য সেই বিটগুলি বাইনারিতে 10 — এই কারণেই সেই অঙ্কটি সবসময় 8, 9, a বা b হয়। দুটি সংরক্ষিত মান সম্পূর্ণরূপে ভার্সন স্কিমের বাইরে পড়ে: Nil UUID, সমস্ত শূন্য (00000000-0000-0000-0000-000000000000), যার অর্থ "কোনো মান নেই", এবং Max UUID, সমস্ত এক (ffffffff-ffff-ffff-ffff-ffffffffffff), যা RFC 9562 কোনো পরিসরের (range) শেষ চিহ্নিত করতে যোগ করেছে।

নেম-বেসড UUID ও চারটি মানক নেমস্পেস

ভার্সন 3 ও 5 ডিটারমিনিস্টিক: এগুলি একটি নেমস্পেস UUID-কে একটি নাম স্ট্রিংয়ের সঙ্গে হ্যাশ করে, তাই একই জোড়া যেকোনো মেশিনে, চিরকাল, একই শনাক্তকারী তৈরি করে। এটি এগুলিকে বিদ্যমান কী থেকে উদ্ভূত স্থিতিশীল ID-র জন্য আদর্শ করে তোলে — একটি URL, একটি ফাইলনেম, একটি ডোমেন — কোনো ডেটাবেস লুকআপ ছাড়া এবং কোনো সমন্বয় ছাড়া। দুটির মধ্যে একমাত্র পার্থক্য হ্যাশ: v3 MD5 ব্যবহার করে, v5 SHA-1, এবং স্পেসিফিকেশন v5 সুপারিশ করে। RFC 4122 চারটি প্রস্তুত নেমস্পেস UUID সংজ্ঞায়িত করে যাতে স্বতন্ত্র সিস্টেম একই ইনপুটে একমত হয়:

উদাহরণস্বরূপ, DNS নেমস্পেসকে example.com নামের সঙ্গে v5-এর অধীনে হ্যাশ করলে প্রতিটি সঠিক বাস্তবায়নে সবসময় একই UUID তৈরি হয় — এটিই ঠিক সেই কারণ যে নেম-বেসড UUID কোনো ভাগ করা অবস্থা ছাড়াই পরিষেবাগুলির মধ্যে পুনরুৎপাদনযোগ্য।

ডেটাবেস প্রাইমারি কী-র জন্য ভার্সন 7 কেন এগিয়ে

র‍্যান্ডম v4 UUID খারাপ ক্লাস্টার্ড প্রাইমারি কী তৈরি করে। যেহেতু প্রতিটি মান অপ্রত্যাশিত, পরপর ইনসার্ট সম্পূর্ণ ইনডেক্স জুড়ে ছড়িয়ে যায়; একটি B-ট্রি-কে সমগ্র কাঠামোতে পেজ বিভক্ত করতে হয়, ওয়ার্কিং সেট ক্যাশে ঠিকমতো ফিট হয় না, এবং টেবিল বাড়ার সঙ্গে সঙ্গে রাইট থ্রুপুট কমে যায়। একটি v7 UUID এটি সবচেয়ে গুরুত্বপূর্ণ বিটে একটি 48-বিট Unix-মিলিসেকেন্ড টাইমস্ট্যাম্প বসিয়ে সমাধান করে, তারপর একই মিলিসেকেন্ডের মধ্যে অনন্যতার জন্য র‍্যান্ডম বিট। তাই মানগুলি সময়ের সঙ্গে বাড়ে এবং তৈরির-ক্রমে অভিধানক্রমিকভাবে সর্ট হয়, তাই নতুন সারি ইনডেক্সের "ডান কিনারায়" যুক্ত হয় — একটি অটো-ইনক্রিমেন্ট পূর্ণসংখ্যা যে লোকালিটি দেয় সেটাই, তবে UUID-র বিকেন্দ্রীভূত, অননুমেয়, মার্জ-বান্ধব প্রকৃতি বজায় রেখে।

এই কারণেই v7 আসার আগে অনেক দল ULID-এর দিকে ঝুঁকেছিল। একটি ULID একটি 128-বিট, সময়-সর্টেবল শনাক্তকারী — একটি 48-বিট মিলিসেকেন্ড টাইমস্ট্যাম্প ও 80 র‍্যান্ডম বিট — যা হেক্সাডেসিমালের বদলে 26টি Crockford বেস-32 অক্ষরে উপস্থাপিত। এটি একই লোকালিটি সমস্যা সমাধান করে, তবে এটি কোনো IETF মানক নয় এবং এর টেক্সট রূপ একটি বৈধ UUID নয়। এখন যেহেতু RFC 9562 মূলত একই নকশা সহ v7-কে মানকীকৃত করেছে, নতুন প্রকল্পগুলি সম্পূর্ণ UUID-সামঞ্জস্যপূর্ণ থেকেও সময়-অর্ডার্ড ID পেতে পারে, যা v7-কে র‍্যান্ডম v4 কী ও ULID উভয়ের চেয়ে ক্রমাগত এগিয়ে ঠেলে দিচ্ছে।

"অনন্য"-র পিছনের পরিসংখ্যান, এবং প্রাইভেসির টীকা

v4-এর জন্য সংঘর্ষের সম্ভাবনা সঠিক সংখ্যা সহ বোঝা সহজ। 128-র মধ্যে ছয়টি বিট ভার্সন ও ভ্যারিয়েন্টের জন্য নির্ধারিত, যা 122 র‍্যান্ডম বিট রেখে দেয় — প্রায় 5.3 × 10³⁶ (5.3 আনডেসিলিয়ন) ভিন্ন মান। বার্থডে সমস্যা অনুযায়ী, একটিমাত্র সংঘর্ষ না-হওয়ার চেয়ে বেশি সম্ভাব্য হওয়ার আগে আপনার প্রায় 2.71 কুইন্টিলিয়ন UUID প্রয়োজন হবে, এবং সেগুলির 103 ট্রিলিয়ন তৈরি করলেও কোনো ডুপ্লিকেটের সম্ভাবনা প্রায় একশো-কোটিতে-এক থাকে — বেশিরভাগ সংস্থা তাদের সমস্ত ডেটাবেস মিলিয়ে কখনও যত শনাক্তকারী তৈরি করবে তার চেয়ে অনেক বেশি। একমাত্র সতর্কতা: এটি কেবল একটি ভালো র‍্যান্ডম উৎস-এর সঙ্গেই টেকে। কোনো দুর্বল বা ভুলভাবে সিড করা সিউডো-র‍্যান্ডম জেনারেটর থেকে তৈরি v4 সংঘর্ষ করতে পারে এবং করে।

দুটি সতর্কতা পুনরাবৃত্তি করার মতো। প্রথমত, একটি UUID একটি শনাক্তকারী, গোপন রহস্য নয় — এটিকে কখনও পাসওয়ার্ড, API কী বা সেশন টোকেন হিসেবে ব্যবহার করবেন না, যেখানে আপনার এমন একটি মান দরকার যা অনন্য এবং কোনো নিবেদিত ক্রিপ্টোগ্রাফিক উৎস থেকে অননুমেয়। দ্বিতীয়ত, টাইম-বেসড ভার্সনগুলি তথ্য ফাঁস করতে পারে: একটি ক্লাসিক v1 UUID তৈরির টাইমস্ট্যাম্প এবং জেনারেট করা মেশিনের নেটওয়ার্ক MAC ঠিকানা দুটোই সন্নিবেশিত করে, যা বিখ্যাতভাবে তদন্তকারীদের 1999-এর Melissa ভাইরাসের রচয়িতার কাছে পৌঁছাতে সাহায্য করেছিল। এই কারণেই এই জেনারেটর v1-কে আসল MAC-র বদলে একটি র‍্যান্ডম নোড দিয়ে তৈরি করে, এবং কোনো শনাক্তকারী সর্বজনীনভাবে উন্মুক্ত হতে পারে এমন যেকোনো সময় v4 বা v7 কেন নিরাপদ ডিফল্ট। শেষে, "GUID" — যে শব্দটি Microsoft ব্যবহার করে — কেবল UUID-র আরেকটি নাম; একমাত্র জটিলতা হল কিছু লিগ্যাসি Microsoft GUID মানের অংশগুলিকে ভিন্ন বাইট-ক্রমে সিরিয়ালাইজ করে, তাই সেগুলিকে সবসময় কাঁচা বাইটের বদলে বিহিত 8-4-4-4-12 টেক্সট স্ট্রিং হিসেবে তুলনা করুন।

ব্যবহারিকভাবে UUID সংরক্ষণ ও ফরম্যাটিং

একটি UUID ধারণাগতভাবে 16 বাইট, তবে এটি সাধারণত 36-অক্ষর 8-4-4-4-12 স্ট্রিং হিসেবে লেখা হয়। আপনি এটি কীভাবে সংরক্ষণ করেন তা গুরুত্বপূর্ণ। এটিকে কাঁচা 16 বাইট হিসেবে রাখা — PostgreSQL-এর নেটিভ uuid টাইপ, বা MySQL-এ BINARY(16) — 36-অক্ষর টেক্সট কলামের অর্ধেকেরও কম জায়গা নেয় এবং দ্রুত ইনডেক্স হয়; এটিকে VARCHAR(36) হিসেবে সংরক্ষণ করা সুবিধাজনক কিন্তু বড় মাপে অপচয়মূলক। বিহিত টেক্সট রূপ লোয়ার-কেস, যদিও স্পেসিফিকেশন পার্সারদের আপার-কেসও গ্রহণ করার দাবি করে, তাই তুলনাগুলিকে কেস-অসংবেদনশীল ধরুন এবং আসার সময় মান স্বাভাবিক করুন। হাইফেনগুলি নিছক সাজসজ্জামূলক গ্রুপিং — কিছু সিস্টেম চারটি অক্ষর বাঁচাতে সেগুলি সরিয়ে দেয় — তবে বিহিত, আন্তঃকার্যক্ষম রূপ সেগুলি রাখে।

একটি নকশা সতর্কতা: যেহেতু v1, v6 ও v7 একটি টাইমস্ট্যাম্প সন্নিবেশ করে, এবং v4 অননুমেয়, লোকে কখনও কখনও ধরে নেয় যে কোনো URL-এ যেকোনো UUID উন্মুক্ত করা নিরাপদ। এটি — অনন্যতার জন্য — তবে UUID তবুও একটি শনাক্তকারী, কোনো অনুমোদন নয়। যদি অ্যাক্সেস নিয়ন্ত্রণ মানটি গোপন থাকার উপর নির্ভর করে ("লিঙ্ক থাকা যে কেউ দেখতে পারে"), তবে টাইম-বেসড ভার্সনগুলির বদলে v4 বা একটি নিবেদিত র‍্যান্ডম টোকেনকে প্রাধান্য দিন, কারণ ফাঁস হওয়া v1 বা v7 মোটামুটি জানিয়ে দেয় রেকর্ডটি কখন তৈরি হয়েছিল এবং, v1-এর জন্য, সম্ভবত যে মেশিন এটি তৈরি করেছে।

কখন UUID ভুল টুল

UUID বিনামূল্যে নয়। 128 বিটে সেগুলি 32-বিট পূর্ণসংখ্যার চার গুণ এবং 64-বিটের দ্বিগুণ আকারের, যা কোটি কোটি সারি এবং সেগুলিকে রেফারেন্স করা প্রতিটি ফরেন কী জুড়ে যোগ হয়। সেগুলি মানুষের জন্যও অসুবিধাজনক — কেউ সাপোর্ট টিকিট নম্বর "f47ac10b-58cc…" হিসেবে জোরে পড়ে না। যদি আপনার ID একটি একক ডেটাবেসের মধ্যে থাকে যা ইতিমধ্যে একটি নির্ভরযোগ্য অটো-ইনক্রিমেন্ট ক্রম সরবরাহ করে, এবং আপনার অফলাইনে, একাধিক নোডে, বা সারি সন্নিবেশের আগে ID তৈরি করার দরকার না হয়, তবে একটি সাধারণ ক্রমিক পূর্ণসংখ্যা ছোট, দ্রুত ও বেশি পাঠযোগ্য। UUID-র দিকে ঠিক তখনই যান যখন আপনার বিকেন্দ্রীভূত জেনারেশন দরকার — ক্লায়েন্ট দ্বারা, একাধিক সার্ভার দ্বারা, বা সমন্বয় ছাড়াই আলাদা সিস্টেম থেকে মার্জ করা ID — যেখানে এর কোনো-কেন্দ্রীয়-কর্তৃপক্ষ-নেই গ্যারান্টি নিজের মূল্য উসুল করে। যখন আপনি তা করেন, তখন v7-কে প্রাধান্য দিন যাতে আপনি একটি ডেটাবেস যে ইনডেক্স লোকালিটির উপর নির্ভর করে তা ত্যাগ না করে সেই গ্যারান্টি বজায় রাখেন।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

UUID কি অনন্য হওয়ার গ্যারান্টিযুক্ত?

গাণিতিকভাবে গ্যারান্টিযুক্ত নয়, তবে ব্যবহারিক উদ্দেশ্যে হ্যাঁ। একটি ভার্সন-4 UUID-তে 122 র‍্যান্ডম বিট থাকে — কোনো সংঘর্ষ (collision) হওয়ার সামান্যতম সম্ভাবনা তৈরি হওয়ার আগেই আপনাকে বহু বছর ধরে প্রতি সেকেন্ডে কোটি কোটি UUID তৈরি করতে হবে। ভার্সন 5 ডিটারমিনিস্টিক, তাই একই নেমস্পেস ও নাম ডিজাইন অনুযায়ী সবসময় একই UUID তৈরি করে।

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

সাধারণ অনন্য ID-র জন্য ভার্সন 4 (র‍্যান্ডম) ব্যবহার করুন। আপনি যদি চান ID তৈরির-সময় অনুযায়ী সর্ট হোক, তবে ভার্সন 7 ব্যবহার করুন — এটি ডেটাবেস প্রাইমারি কী-র জন্য আদর্শ, কারণ এটি র‍্যান্ডম v4 কী যে ইনডেক্স-ফ্র্যাগমেন্টেশন তৈরি করে তা এড়ায়। কোনো নাম থেকে উদ্ভূত পুনরুৎপাদনযোগ্য ID দরকার হলে ভার্সন 5 ব্যবহার করুন। ভার্সন 1 মূলত লিগ্যাসি সামঞ্জস্যের জন্য।

UUID কি নিরাপদ বা অনুমান করা কঠিন?

একটি ভার্সন-4 UUID এতটাই অপ্রত্যাশিত যে অনুমান করা কঠিন, তবে UUID একটি শনাক্তকারী, কোনো গোপন রহস্য নয়। এটিকে পাসওয়ার্ড, সেশন টোকেন বা নিরাপত্তা কী হিসেবে ব্যবহার করবেন না — সেগুলির জন্য একটি নিবেদিত ক্রিপ্টোগ্রাফিক গোপন মান তৈরি করুন।

v4 ও v7-এর মধ্যে পার্থক্য কী?

দুটিই অনন্য, তবে v7 সামনে একটি মিলিসেকেন্ড টাইমস্ট্যাম্প বসায়, তাই v7 UUID-র তালিকা তৈরির-ক্রমে সর্ট হয়। v4 সম্পূর্ণ র‍্যান্ডম এবং এর কোনো ক্রম নেই। ডেটাবেস কী-র জন্য v7 (ভালো ইনডেক্স লোকালিটি) এবং ক্রম গুরুত্বপূর্ণ না হলে v4 ব্যবহার করুন।

এখানে ভার্সন 3 কেন নেই?

ভার্সন 3 নেম-বেসড কিন্তু MD5 ব্যবহার করে, যা ক্রিপ্টোগ্রাফিকভাবে ভাঙা, এবং ব্রাউজারের Web Crypto API MD5 সরবরাহ করে না। আমরা ভার্সন 5 প্রদান করি, সেই SHA-1-ভিত্তিক সমতুল্য যা স্পেসিফিকেশন এর বদলে সুপারিশ করে।

সম্পর্কিত টুল

• SHA হ্যাশ জেনারেটর
• Unix টাইমস্ট্যাম্প কনভার্টার
• Base64 এনকোডার / ডিকোডার
• JSON ফরম্যাটার ও ভ্যালিডেটর

সমস্ত ডেভেলপার ও ডেটা রূপান্তর দেখুন →