UUID তৈরি করুন
ব্যক্তিগত — আপনার ফাইল কখনো সংরক্ষণ করা হয় না
কোন সংস্করণ?
আপনার ০টি UUID এখানে দেখা যাবে।
যেভাবে কাজ করে
ভার্সন বেছে নিন
অনুমান করা যাবে না এমন যেকোনো কিছুর জন্য v4। ডেটাবেস কি-র জন্য v7। পার্থক্যটা ধরে না নিয়ে পেজেই ব্যাখ্যা করা আছে।
কয়টি চান বেছে নিন
একটি, অথবা একবারে দশ হাজার পর্যন্ত, ইচ্ছামতো ফরম্যাটিংসহ — বড় হাতের অক্ষর, ব্রেস, হাইফেন ছাড়া, বা কোডের জন্য তৈরি কোটেশনযুক্ত তালিকা।
কপি করুন
সব কপি করুন, অথবা টেক্সট ফাইল হিসেবে ডাউনলোড করুন।
ভার্সন ৪ নাকি ভার্সন ৭, আর ডেটাবেসে কেন এটা গুরুত্বপূর্ণ
একটি UUID হলো ১২৮ বিট, পরিচিত ৮-৪-৪-৪-১২ বিন্যাসে ৩২টি হেক্স ডিজিট হিসেবে লেখা। এর ছয়টি বিট খরচ হয় এটি কোন ভার্সন ও ভ্যারিয়েন্ট তা জানাতে, ফলে ভার্সন ৪-এ থাকে ১২২টি র্যান্ডম বিট — এতটাই যে এক শতাব্দী ধরে প্রতি সেকেন্ডে একশো কোটি তৈরি করলেও একই UUID দুবার দেখার সম্ভাবনা নগণ্য। পুরো আকর্ষণ এটাই: কখনো যোগাযোগ হয়নি এমন দুটি সিস্টেম দুজনেই আইডেন্টিফায়ার বানাতে পারে, আর নিশ্চিন্তে ধরে নিতে পারে যে সেগুলো কখনো মিলে যাবে না।
এটা সত্য হতে হলে র্যান্ডমনেস সত্যিকারের হতে হয়, আর এখানে তা আসে সাধারণ র্যান্ডম নম্বর জেনারেটর নয়, ক্রিপ্টোগ্রাফিক র্যান্ডম উৎস থেকে। আইডেন্টিফায়ার যখন অ্যাক্সেসের টোকেন হিসেবে ব্যবহার হয় — পাসওয়ার্ড রিসেট লিংক, অনুমান করা যায় না এমন শেয়ার URL — তখন পার্থক্যটা গুরুত্বপূর্ণ, কারণ অনুমানযোগ্য জেনারেটর হলে আগের মানগুলো থেকে কেউ পরেরটা বের করে ফেলতে পারে। ক্রিপ্টোগ্রাফিক উৎসে অনুমান করার কিছু থাকে না।
ভার্সন ৭ আছে কারণ ডেটাবেসের প্রাইমারি কি হিসেবে ভার্সন ৪ খারাপ আচরণ করে। এটি শুরুতে ৪৮-বিটের একটি মিলিসেকেন্ড টাইমস্ট্যাম্প বসায় আর বাকিটা র্যান্ডমনেস দিয়ে পূরণ করে, তাই পরপর তৈরি করা UUID তৈরির ক্রমেই সর্ট হয়। কথাটা শুধু দেখার ব্যাপার মনে হলেও তা নয়: র্যান্ডম কি প্রতিটি ইনসার্টকে পুরো ইনডেক্সে ছড়িয়ে দেয়, তাই প্রতিটি রাইট আলাদা পেজ ছোঁয় আর ক্যাশ আর কাজে আসে না, অন্যদিকে সময়-ক্রমের কি এক প্রান্তে যুক্ত হয়। বড় টেবিলে ইনসার্টের গতিতে পার্থক্য উল্লেখযোগ্য, আর v7 স্ট্যান্ডার্ড হওয়ার কারণও এটাই।
বিনিময়টা বাস্তব, আর ভেবে দেখার মতো। একটি ভার্সন ৭ UUID যে-ই দেখুক, সে মোটামুটি জেনে যায় এটি কখন তৈরি হয়েছে, মিলিসেকেন্ড পর্যন্ত, আর পরপর কয়েকটি দেখলে বোঝা যায় আপনি কত দ্রুত রেকর্ড তৈরি করেন। ইন্টারনাল কি-র জন্য এতে সমস্যা নেই। কিন্তু URL-এ প্রকাশ পাওয়া আইডেন্টিফায়ারের জন্য — অর্ডার নম্বর, ডকুমেন্টের লিংক, ইউজার আইডি — এটা ছোট একটি তথ্য ফাঁস, যা ভার্সন ৪-এ নেই। দুটোই গুরুত্বপূর্ণ হলে প্রাইমারি কি-র জন্য v7 আর পাবলিক যেকোনো কিছুর জন্য v4 ব্যবহার করুন।
অন্য কিছু দরকার হলে
যেখানে ব্যবহার হবে, সেখানেই তৈরি করুন। প্রতিটি ডেটাবেস ও ভাষায় এটি বিল্ট-ইন আছে — PostgreSQL-এ gen_random_uuid(), MySQL-এ UUID(), JavaScript-এ crypto.randomUUID(), Python-এ uuid.uuid4() — আর ব্রাউজারে একগুচ্ছ তৈরি করে কোডে পেস্ট করা ফিক্সচার বা টেস্টের জন্য ঠিক আছে, কিন্তু যা চালু থাকে এমন কিছুর জন্য ভুল।
v7-এর কারণ যদি সর্টযোগ্য কি হয়, তাহলে কয়েকটি বিকল্প জেনে রাখা ভালো। ULID একই ধারণা ২৬টি অক্ষরে প্রকাশ করে, যা ছোট এবং বড়-ছোট হাতের অক্ষরে পার্থক্য করে না; Snowflake আইডেন্টিফায়ার ৬৪ বিটে এঁটে যায়, যা UUID-এর ১২৮ বিটের তুলনায় ইনডেক্সের সাইজ অর্ধেক করে। আর অনেক ডেটাবেসে সাধারণ অটো-ইনক্রিমেন্টিং ইন্টিজার এখনো এদের যেকোনোটির চেয়ে দ্রুত ও ছোট — UUID-এর খরচ তখনই পোষায়, যখন একসাথে কয়েক জায়গায় আইডেন্টিফায়ার বানাতে হয়, অন্যথায় নয়।
সাধারণ প্রশ্নোত্তর
v4 নাকি v7 — আমার কোনটি দরকার?
ডেটাবেসের প্রাইমারি কি হলে v7। যদি অনুমান করা একেবারে অসম্ভব হতে হয় — পাসওয়ার্ড রিসেট লিংক, ইনভাইট কোড, সেশন আইডেন্টিফায়ার — তাহলে v4। পুরো সিদ্ধান্ত এটুকুই, আর বেশিরভাগ মানুষ কখনো জানতেই পারেন না যে এখানে কোনো সিদ্ধান্ত ছিল, কারণ প্রায় সব জেনারেটরই শুধু v4 দেয়।
ডেটাবেস কি হিসেবে v4 খারাপ কেন?
কারণ এটি সম্পূর্ণ র্যান্ডম, আর ডেটাবেস ইনডেক্স সাজানো থাকে। নতুন র্যান্ডম কি ইনডেক্সের এলোমেলো জায়গায় পড়ে, তাই প্রতিটি ইনসার্ট আলাদা পেজ ছোঁয়, ক্যাশ আর কাজে আসে না, আর ইনডেক্স খণ্ডিত হয়ে বড় হতে থাকে। বড়, ব্যস্ত টেবিলে এটি মাপার মতো ধীরগতি, যা সময়ের সঙ্গে আরও খারাপ হয়। এটা তাত্ত্বিক দুশ্চিন্তা নয় — এ কারণেই এখন Postgres ও MySQL দুটির ডকুমেন্টেশনেই এ নিয়ে আলোচনা আছে।
UUID v7 কী?
এমন একটি UUID, যার প্রথম ৪৮ বিট একটি মিলিসেকেন্ড টাইমস্ট্যাম্প, তারপর র্যান্ডমনেস। এটি এখনো বিশ্বজুড়ে অনন্য আর এখনো ১২৮ বিট, কিন্তু সময় আগে থাকায় v7 UUID তৈরির ক্রমেই সর্ট হয়। নতুন কি ইনডেক্সে ছড়িয়ে না পড়ে শেষে যুক্ত হয়, ঠিক যেমন অটো-ইনক্রিমেন্টিং ইন্টিজার করে — সঙ্গে UUID-এর অনন্যতা। এটি ২০২৪ সালে RFC 9562-এ স্ট্যান্ডার্ড হয়েছে, আর নতুন টেবিলের জন্য এখন এটাই সুপারিশ।
এখানকার v7 UUID কি সত্যিই সর্ট হয়?
হ্যাঁ, একই মিলিসেকেন্ডের মধ্যেও, আর বেশিরভাগ ইমপ্লিমেন্টেশন ঠিক এই অংশেই ভুল করে। টাইমস্ট্যাম্পের রেজোলিউশন শুধু মিলিসেকেন্ড, তাই লুপে এক হাজার আইডি তৈরি করা এক মিলিসেকেন্ডের মধ্যেই শেষ হয় — আর নিচের বিটগুলো পুরোপুরি র্যান্ডম হলে সেই এক হাজার তৈরির ক্রমে সর্ট হয় না। এই জেনারেটর RFC 9562-এ বর্ণিত মনোটোনিক কাউন্টার ব্যবহার করে, তাই একটি ব্যাচ প্রতিবারই কঠোরভাবে ঊর্ধ্বক্রমে থাকে। এক হাজার তৈরি করে সর্ট করে দেখুন; তৈরির ক্রমেই ফিরে আসবে।
v7 UUID কি প্রকাশ্যে দেখানো নিরাপদ?
একটি বিষয় মাথায় রেখে: নকশাগতভাবেই এটি জানিয়ে দেয় কখন তৈরি হয়েছে, মিলিসেকেন্ড পর্যন্ত। ডেটাবেস কি-র জন্য এটা সাধারণত নিরীহ, এমনকি কাজেরও। কিন্তু তৈরির সময়টাই যদি সংবেদনশীল হয়, বা আইডেন্টিফায়ারটি অনুমান-অযোগ্য হওয়া দরকার হয়, তাহলে v4 ব্যবহার করুন — v7-এ এখনো ৭৪টি র্যান্ডম বিট আছে, যা অনেক, কিন্তু আইডিটি যার কাছে আছে সে-ই এর টাইমস্ট্যাম্প সরাসরি পড়তে পারে।
এগুলো কি নিরাপদ হওয়ার মতো যথেষ্ট র্যান্ডম?
হ্যাঁ। র্যান্ডমনেস আসে `crypto.getRandomValues` থেকে, যা ব্রাউজারের ক্রিপ্টোগ্রাফিকভাবে নিরাপদ জেনারেটর, কখনোই `Math.random` থেকে নয়। এই পার্থক্যের কারণে বাস্তবে দুর্বলতা তৈরি হয়েছে: `Math.random` দ্রুত কিন্তু অনুমানযোগ্য, আর এর ওপর বানানো সেশন টোকেন বাস্তবে অনুমান করে ফেলা হয়েছে। একটি v4 UUID-এ ১২২টি র্যান্ডম বিট থাকে, যা এতটাই যে মিলে যাওয়া বাস্তবে কোনো দুশ্চিন্তার বিষয় নয়।
এগুলো কি আমার ডিভাইসেই তৈরি হয়?
হ্যাঁ, পুরোপুরি, আর আইডেন্টিফায়ারের জন্য এটা গুরুত্বপূর্ণ। অন্য কারও সার্ভার থেকে আনা UUID মানে এমন একটি UUID যা অন্য কেউ দেখেছে — আপনি সিক্রেট তৈরি করলে এতে উদ্দেশ্যই ব্যর্থ হয়। এগুলো কখনো আপনার ব্রাউজার ছেড়ে যায় না। পেজ লোড হওয়ার পর Wi-Fi বন্ধ করে দিন, এটি হুবহু একইভাবে কাজ করবে। আমাদের কথায় বিশ্বাস না করে নিজেই গোপনীয়তার দাবিটি যাচাই করার এটাই সবচেয়ে সহজ উপায়।
nil UUID কী?
সবগুলো শূন্য: 00000000-0000-0000-0000-000000000000। এটি একটি বৈধ, সংরক্ষিত UUID, যা ব্যবহার হয় “কিছু নেই” বা “সেট করা হয়নি” বোঝাতে, যেখানে null রাখা সম্ভব নয়। এর বিপরীত, সব f দিয়ে গঠিত max UUID, কখনো কখনো সর্টিংয়ের সীমাচিহ্ন হিসেবে ব্যবহার হয়। দুটিই এখানে দেওয়া আছে, কারণ মাঝে মাঝে এগুলো দরকার হয়, আর ঠিকভাবে টাইপ করা ঝামেলার।
জেনে রাখুন: ভার্সন ৪ UUID আসে ব্রাউজারের ক্রিপ্টোগ্রাফিক র্যান্ডম উৎস থেকে, Math.random থেকে নয়, তাই আইডেন্টিফায়ার হিসেবে ব্যবহার করা নিরাপদ। ভার্সন ৭-এ একটি মিলিসেকেন্ডের টাইমস্ট্যাম্প থাকে, যার জন্যই এটি ভালোভাবে সর্ট হয় — আবার এর মানে, এটি কখন তৈরি হয়েছে তা মোটামুটি ফাঁস করে দেয়। যেখানে এটা গুরুত্বপূর্ণ, সেখানে v7 ব্যবহার করবেন না।
এই টুলটি আপনার ওয়েবসাইটে যোগ করুন
যেকোনো ব্লগ, ক্লাসের পেজ বা হেল্প আর্টিকেলের জন্য ফ্রি। একটি স্নিপেট পেস্ট করলেই আপনার ভিজিটররা আপনার পেজেই এটি ব্যবহার করতে পারবেন।