UUID জেনারেটর

UUID v4 জেনারেটর পৃষ্ঠার মূল কাজ ও বৈশিষ্ট্য

এই পৃষ্ঠাটি UUID v4 আইডি তৈরি করে—প্রতিটি ৩৬ অক্ষরের একটি স্ট্রিং, যার মধ্যে ৩২টি হেক্সাডেসিমেল অক্ষর ও ৪টি হাইফেন (যদি হাইফেন চালু থাকে)। আপনি একবারে ১ থেকে ১০০টি পর্যন্ত আইডি জেনারেট করতে পারেন, এবং প্রতিটি আইডি দেখতে পারেন ছোট হাতের (lowercase) বা বড় হাতের (uppercase) অক্ষরে, হাইফেনসহ বা হাইফেন ছাড়া। সব জেনারেশন সম্পূর্ণরূপে আপনার ব্রাউজারে ঘটে, সার্ভারে কিছু পাঠানো হয় না। ফলে এই টুলটি দ্রুত, নিরাপদ এবং অফলাইনেও চলে।

যা এই পৃষ্ঠাকে আলাদা করে তা হলো UUID v4 এর নির্মাণশৈলী: এতে ১২২ বিট বিশুদ্ধ র্যান্ডমনেস থাকে, কোনো সময়-সংকেত এম্বেড করা নেই। তাই প্রতিটি আইডি কার্যত অনুমানযোগ্য নয় এবং সংঘর্ষের সম্ভাবনা নগণ্য। তবে UUID v7 বা ULID-এর মতো সময়-ভিত্তিক আইডির বিপরীতে v4 আইডিগুলো ক্রমবিন্যাসহীন—এদের কোনো কালানুক্রমিক আদেশ নেই, যা ডাটাবেসে প্রাইমারি কী হিসেবে ব্যবহার করলে ইনডেক্সে ফ্র্যাগমেন্টেশন তৈরি করতে পারে।

UUID v4-এর অভ্যন্তরীণ গঠন: ১২২ বিট র্যান্ডমনেস

UUID v4 স্পেসিফিকেশন RFC 4122-এ সংজ্ঞায়িত। একটি UUID v4 মোট ১২৮ বিটের হয়, কিন্তু তার মধ্যে ৬ বিট নির্দিষ্ট থাকে: ৪ বিট ভার্সন (0100, অর্থাৎ 4) এবং ২ বিট ভ্যারিয়েন্ট (10)। বাকি ১২২ বিট এলোমেলো। এই ১২২ বিটকে ১৬টি অক্টেটে (বাইট) সাজানো হয়, এবং প্রতিটি অক্টেটকে হেক্সাডেসিমেলে রূপান্তর করে ৩২টি হেক্স অক্ষর পাওয়া যায়। তারপর সেগুলোকে ৮-৪-৪-৪-১২ এই প্যাটার্নে সাজিয়ে হাইফেন যোগ করা হয়। যেমন: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx—এখানে 4 নির্দিষ্ট, y-এর প্রথম দুটি বিট 10 (বাইনারিতে)।

ব্রাউজার এই এলোমেলো বিটগুলো তৈরি করে ক্রিপ্টোগ্রাফিক সিউডোর্যান্ডম নাম্বার জেনারেটর (CSPRNG) ব্যবহার করে—যেমন crypto.getRandomValues()। এটি সিস্টেম-স্তরের এনট্রপি (যেমন মাউস মুভমেন্ট, কিবোর্ড টাইমিং) ব্যবহার করে, তাই গুণমান খুব উচ্চ।

সংঘর্ষ সম্ভাবনা: ১২২ বিট র্যান্ডমনেস মানে মোট সম্ভাব্য আইডির সংখ্যা 2^122 ≈ 5.3 × 10^36। জন্মদিনের প্যারাডক্স অনুযায়ী, ৫০% সম্ভাবনায় একটি সংঘর্ষ পেতে প্রায় 2^61টি আইডি জেনারেট করতে হবে—যা বাস্তবে কখনোই ঘটবে না। তাই UUID v4-কে বিশ্বব্যাপী অনন্য ধরা যায়।

আউটপুট কাস্টমাইজেশন: আপারকেস, হাইফেন ও সংখ্যা

এই পৃষ্ঠায় আপনি তিনটি নিয়ন্ত্রণ পাবেন:

• Count: ১ থেকে ১০০ পর্যন্ত একটি পূর্ণসংখ্যা। ডিফল্ট সম্ভবত ১। এই সীমা অতিক্রম করলে ইনপুট গ্রহণ করা হয় না।
• Uppercase: একটি টগল, ডিফল্ট বন্ধ (অর্থাৎ ছোট হাতের অক্ষর)। চালু করলে প্রতিটি আইডি বড় হাতের অক্ষরে প্রদর্শিত হয়, যেমন F47AC10B-58CC-4372-A567-0E02B2C3D479।
• Include hyphens: একটি টগল, ডিফল্ট চালু। বন্ধ করলে হাইফেনগুলো বাদ পড়ে এবং শুধু ৩২টি হেক্স অক্ষর দেখায়: f47ac10b58cc4372a5670e02b2c3d479।

মজার ব্যাপার হলো, এই অপশনগুলোর যেকোনোটি পরিবর্তন করলেই পুরো সেটটি পুনরায় জেনারেট হয়। কারণ ভেতরে থাকা র্যান্ডমনেস একই থাকে—শুধু ফরম্যাটিং বদলায়। তবে পৃষ্ঠার লজিক প্রতিবার নতুন করে আইডি তৈরি করে, কারণ ক্লায়েন্ট-সাইডে ইতিমধ্যে তৈরি আইডি সংরক্ষণ করে না।

আউটপুট তালিকার পাশে IDs count দেখায় কতগুলি আইডি তৈরি হয়েছে। পৃষ্ঠার নিচে একটি স্ট্যাটাস বার থাকে যা “Ready.” থেকে “Generated.”-এ পরিবর্তিত হয়। “Copied all!” বার্তাটি দেখা যায় যখন আপনি “Copy all” বাটনে ক্লিক করেন।

কপি করার অপশন: যে কোনো একটি আইডিতে ক্লিক করলে তা ক্লিপবোর্ডে কপি হয়। “Copy all” বাটন পুরো তালিকাটি কপি করে (সাধারণত নতুন লাইন দ্বারা পৃথক)।

নোট: যদি ফরম্যাটটি UUID v4 থেকে পরিবর্তন করে UUID v7, ULID বা NanoID-তে নিয়ে যান, তাহলে uppercase ও hyphens অপশনগুলি পরিবর্তিত হতে পারে—কারণ প্রতিটি ফরম্যাটের নিজস্ব ফরম্যাটিং প্রয়োজন। এই নিবন্ধ শুধু UUID v4 নিয়ে।

UUID v4 বনাম সময়-ভিত্তিক আইডি: কখন কী ব্যবহার করবেন

UUID v4-এর সবচেয়ে বড় গুণ হলো অপ্রত্যাশিততা। যেখানে আইডি অনুমান করা বিপজ্জনক, যেমন সেশন টোকেন, অ্যাক্সেস টোকেন, বা নিরাপত্তা কী—সেখানে UUID v4 উপযুক্ত। অন্যদিকে, সময়-ভিত্তিক আইডি যেমন UUID v7 বা ULID কালানুক্রমিকভাবে সাজানো যায়, যা ডাটাবেস ইনডেক্সের জন্য ভালো।

ডাটাবেসের উপর প্রভাব: UUID v4 এলোমেলোভাবে সাজানো থাকে, তাই যখন আপনি এটি প্রাইমারি কী হিসেবে ব্যবহার করেন, ডাটাবেসের B-tree ইনডেক্সে নতুন কীগুলো এলোমেলো অবস্থানে ঢোকে। এর ফলে পৃষ্ঠা বিভাজন (page split) বেড়ে যায় এবং ইনডেক্স ফ্র্যাগমেন্টেশন হয়। সময়-ভিত্তিক আইডি ব্যবহার করলে কীগুলোর একটি ক্রম থাকে, যার ফলে নতুন রেকর্ড শেষের দিকে যোগ হয় এবং ইনডেক্স কম ফ্র্যাগমেন্ট হয়।

তবে অনেক ডাটাবেস ইঞ্জিন (যেমন PostgreSQL) UUID v4-এর জন্য আলাদা কৌশল ব্যবহার করতে পারে, যেমন clustered index-এ ব্যবহার করা এড়ানো। সঠিক সিদ্ধান্ত নির্ভর করে আপনার ডাটাবেসের আর্কিটেকচার ও কুয়েরি প্যাটার্নের উপর।

কখন UUID v4 ব্যবহার করবেন না:

• যদি আইডিগুলোকে সময় অনুসারে সাজানো প্রয়োজন হয় (যেমন লগ এন্ট্রি)।
• যদি ডাটাবেস ইনডেক্সের পারফরম্যান্স সবচেয়ে গুরুত্বপূর্ণ হয় এবং আপনি সময়-অর্ডারড কী গ্রহণ করতে পারেন।
• যদি আইডি ছোট হতে হয় (UUID v4 ৩৬ অক্ষর, কিছু ক্ষেত্রে বড়)।

কখন UUID v4 ব্যবহার করবেন:

• নিরাপত্তা-সংবেদনশীল অ্যাপ্লিকেশন যেখানে আইডি অনুমান করা যাবে না।
• বিতরিত সিস্টেম যেখানে কেন্দ্রীয় সিকোয়েন্স ছাড়া অনন্য আইডি প্রয়োজন।
• টেস্ট ডেটা বা এক্সটার্নাল আইডি যেখানে সময় অপ্রাসঙ্গিক।

ব্রাউজার-ভিত্তিক জেনারেশন: নিরাপত্তা ও গোপনীয়তা

এই টুলটি সম্পূর্ণ ক্লায়েন্ট-সাইডে চলে। যখন আপনি “Generate” বাটনে ক্লিক করেন, ব্রাউজার নিজেই window.crypto.getRandomValues() ব্যবহার করে র্যান্ডম বাইট তৈরি করে এবং তা UUID ফরম্যাটে রূপান্তর করে। কোনো ডেটা সার্ভারে পাঠানো হয় না, কোনো কুকি সেট করা হয় না, কোনো ট্র্যাকিং হয় না।

নিরাপত্তা: ব্রাউজারের CSPRNG আধুনিক ক্রিপ্টোগ্রাফিক স্ট্যান্ডার্ড অনুযায়ী কাজ করে। এটি অপারেটিং সিস্টেমের এনট্রপি ব্যবহার করে, তাই ফলাফল ভবিষ্যদ্বাণী করা কার্যত অসম্ভব। তবে মনে রাখবেন, পুরনো ব্রাউজার বা কিছু মোবাইল ব্রাউজারে এনট্রপি কম থাকতে পারে—তবে আধুনিক ব্রাউজারগুলোতে এটি নির্ভরযোগ্য।

গোপনীয়তা: যেহেতু কোনো সার্ভার রিকোয়েস্ট নেই, আপনার জেনারেট করা আইডিগুলো শুধু আপনার ডিভাইসেই থাকে। পৃষ্ঠা রিফ্রেশ করলে বা বন্ধ করলে সেগুলো হারিয়ে যায়, কারণ কোনো স্টোরেজ নেই। আপনি চাইলে কপি করে নিজের ফাইলে সংরক্ষণ করতে পারেন।

অফলাইন ব্যবহার: পৃষ্ঠাটি একবার লোড হয়ে গেলে, ইন্টারনেট সংযোগ বিচ্ছিন্ন অবস্থাতেও আইডি জেনারেট করা যায়—যতক্ষণ না পৃষ্ঠাটি আবার রিফ্রেশ করতে হয়। কারণ সমস্ত কোড (HTML, CSS, JavaScript) ক্যাশে থাকে।

সাধারণ ভুল ও সতর্কতা

১. UUID v4-কে টাইম-সর্টেবল ভাবা: অনেক ডেভেলপার ভুলবশত মনে করেন UUID v4 সময় অনুযায়ী সাজানো যায়। আসলে তা নয়। UUID v4-এ কোনো টাইমস্ট্যাম্প নেই। তাই যদি আপনাকে আইডি সর্ট করতে হয়, তাহলে জেনারেশনের সময় একটি আলাদা টাইমস্ট্যাম্প সংরক্ষণ করুন, অথবা UUID v7 ব্যবহার করুন।

২. হাইফেন সরিয়ে ফেলা: হাইফেন ছাড়া UUID v4 এখনও বৈধ, কিন্তু কিছু সিস্টেম (যেমন ডাটাবেসে স্ট্রিং ফিল্ড) হাইফেন ছাড়া ৩২-অক্ষরের স্ট্রিং গ্রহণ করে না যদি তারা নির্দিষ্ট ফরম্যাট আশা করে। তাই ডিফল্ট হাইফেনসহ রাখাই ভালো।

৩. আপারকেস ব্যবহারের প্রভাব: UUID-এর মান অক্ষরের আকারের উপর নির্ভর করে না—f47ac10b এবং F47AC10B একই মান নির্দেশ করে। তবে কিছু সিস্টেম কেস-সেনসিটিভ তুলনা করে; তাই পুরো সিস্টেম জুড়ে একটি নির্দিষ্ট কেস বেছে নেওয়া ভালো।

৪. সংঘর্ষের ভয়: যদিও সংঘর্ষ সম্ভাবনা নগণ্য, তবুও অনেক ডেভেলপার UUID v4-কে “সংঘর্ষ-মুক্ত” বলে। বাস্তবে এটি নয়—শুধু অত্যন্ত অসম্ভাব্য। যদি আপনার অ্যাপ্লিকেশনে বিলিয়ন বিলিয়ন আইডি তৈরি হয়, তবুও সংঘর্ষ ঘটার সম্ভাবনা খুবই কম, কিন্তু তাত্ত্বিকভাবে শূন্য নয়।

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

প্রশ্ন ১: UUID v4 কি সত্যিই অনন্য? উত্তর: হ্যাঁ, ব্যবহারিকভাবে অনন্য। ১২২ বিট র্যান্ডমনেসের কারণে সংঘর্ষের সম্ভাবনা এত কম যে দৈনন্দিন ব্যবহারে এটি অনন্য ধরা হয়। জন্মদিনের প্যারাডক্স অনুযায়ী, ২^৬১ (প্রায় ২.৩ × ১০^১৮)টি আইডি জেনারেট না করলে ৫০% সম্ভাবনায় সংঘর্ষ হয় না।

প্রশ্ন ২: আমি কি হাইফেন ছাড়া UUID v4 ব্যবহার করতে পারি? উত্তর: হ্যাঁ। হাইফেনগুলি শুধু পঠনযোগ্যতার জন্য। অন্তর্নিহিত হেক্সাডেসিমেল অক্ষরগুলো একই থাকে। তবে অনেক ডাটাবেস ও অ্যাপ্লিকেশন হাইফেনসহ UUID আশা করে; তাই ডিফল্ট ফরম্যাট রাখাই নিরাপদ।

প্রশ্ন ৩: এই টুল কি অফলাইনে কাজ করে? উত্তর: পৃষ্ঠাটি একবার লোড করার পর, ইন্টারনেট ছাড়াই আপনি আইডি জেনারেট ও কপি করতে পারেন। তবে পৃষ্ঠাটি রিফ্রেশ করতে গেলে আবার অনলাইন প্রয়োজন হতে পারে (যদি ক্যাশে সাফ করা হয়)।

প্রশ্ন ৪: UUID v4 কি UUID v7-এর চেয়ে ভালো? উত্তর: নির্ভর করে প্রয়োজন। UUID v4 বেশি অনির্বাচনীয়, তাই নিরাপত্তা-সংবেদনশীল কাজে ভালো। UUID v7 সময়-সর্টেবল, তাই ডাটাবেস ইনডেক্স পারফরম্যান্স ভালো এবং আইডি অনুসারে ডেটা সাজানো সহজ।

প্রশ্ন ৫: আমি কি কয়েকটি আইডি নির্বাচন করে কপি করতে পারি? উত্তর: পৃষ্ঠাটি বর্তমানে একটি নির্দিষ্ট আইডিতে ক্লিক করে তা কপি করার অনুমতি দেয়, অথবা “Copy all” দিয়ে সবকটি কপি করে। কোনো মাল্টি-সিলেক্ট অপশন নেই। প্রয়োজন হলে ম্যানুয়ালি কপি করুন।

প্রশ্ন ৬: ১০০-এর বেশি আইডি কেন জেনারেট করতে পারি না? উত্তর: পৃষ্ঠার সীমা ১০০। এটি UI-তে সহজে প্রদর্শনের জন্য। বেশি আইডি প্রয়োজন হলে একাধিকবার জেনারেট করুন ও কপি করুন। ভবিষ্যতে সীমা বাড়তে পারে, কিন্তু বর্তমানে এটি ১০০-তে সীমাবদ্ধ।