UUID v4 জেনারেটর

অনলাইনে UUID v4 মান তৈরি করুন: ১২২টি র‍্যান্ডম বিট, স্ট্যান্ডার্ড UUID ফরম্যাট এবং আপনার ব্রাউজারেই কপি করার জন্য প্রস্তুত ফলাফল।

ফরম্যাট
তৈরিকৃত আইডিসমূহ
প্রস্তুত। আপনার ব্রাউজারেই UUID v4 মান তৈরি করুন।

এই ID যেভাবে তৈরি হয়

লেআউট
ভার্সন ৪ এবং RFC ভ্যারিয়েন্ট বিট সহ ১২৮-বিট UUID, যা 8-4-4-4-12 হেক্স গ্রুপ হিসেবে প্রদর্শিত হয়।
এনট্রপি
crypto.randomUUID() থেকে প্রাপ্ত ১২২টি র‍্যান্ডম বিট।
সময়
কোনো টাইমস্ট্যাম্প নেই; v4 ID-গুলো কখন তৈরি করা হয়েছিল তা প্রকাশ করে না।
কলিশন বা সংঘর্ষের ঝুঁকি
কলিশন ১২২টি র‍্যান্ডম বিট দ্বারা নিয়ন্ত্রিত হয়, যা সাধারণ সিস্টেমের ব্যবহারিক পরিমাণের চেয়ে অনেক বেশি নিরাপদ।
উদাহরণ
50fe0e43-f144-4ee1-9547-b61a14242aee

আপনার আইডিগুলো শক্তিশালী ব্রাউজার র্যান্ডমনেস দিয়ে স্থানীয়ভাবে তৈরি করা হয়। BroBroGo-তে কিছুই পাঠানো হয় না।

সাধারণ জিজ্ঞাসা (FAQ)

আমার কখন UUID v4 ব্যবহার করা উচিত?

যখন আপনার এমন র‍্যান্ডম আইডেন্টিফায়ার প্রয়োজন যা তৈরির সময় অনুযায়ী সাজানো যায় না এবং তৈরির সময় প্রকাশ করে না, তখন UUID v4 ব্যবহার করুন।

আমি কি হাইফেন সরাতে পারি বা আউটপুট বড় হাতের অক্ষরে করতে পারি?

হ্যাঁ। লক করা UUID v4 টুলে অপশন প্যানেলটি থাকে, যার মাধ্যমে আপনি হাইফেন বাদ দিতে পারেন বা আউটপুট বড় হাতের অক্ষরে (uppercase) পরিবর্তন করতে পারেন।

UUID v4 জেনারেটর: সম্পূর্ণ নির্দেশিকা

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

এই পৃষ্ঠাকে কী অনন্য করে তোলে?

UUID v4-এ ১২২ বিট খাঁটি র্যান্ডমনেস থাকে, বাকি ৬ বিট নির্দিষ্ট ভার্সন এবং ভ্যারিয়েন্ট বিট। ফলে এই UUID গুলো সময়-ভিত্তিক নয় – এদের কোনো ক্রম বা অর্ডার নেই। ডাটাবেসে প্রাইমারি কী হিসেবে ব্যবহার করলে এরা B-ট্রি ইনডেক্স খণ্ডিত (fragment) করে, যা সময়-সাজানো ফরম্যাটের মতো ভালো পারফরম্যান্স দেয় না।

  • UUID v4-এর কোনো টাইমস্ট্যাম্প নেই, তাই এদের ক্রম এলোমেলো।
  • ডাটাবেস ইঞ্জিন যখন এলোমেলোভাবে ছড়িয়ে থাকা কীগুলো সাজায়, ইনডেক্স পৃষ্ঠাগুলো ভেঙে যায় এবং ডিস্ক I/O বাড়ে।
  • তুলনায়, UUID v7 বা ULID-এর শুরুতে টাইমস্ট্যাম্প থাকে, তাই তারা কালানুক্রমিকভাবে সাজানো যায় এবং ইনডেক্সিং দ্রুত হয়।

কিন্তু এই এলোমেলোতা একটি শক্তি: সিকোয়েন্সিয়াল আইডি থেকে রেকর্ড সংখ্যা অনুমান করা যায় না, এবং অফলাইন বা ডিস্ট্রিবিউটেড পরিবেশে সেন্ট্রাল কোঅর্ডিনেশন ছাড়াই ইউনিক আইডি তৈরি করা যায়।

UUID v4-এর গঠন ও বৈশিষ্ট্য

UUID v4-এর ক্যানোনিকাল ফরম্যাট হলো xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, যেখানে:

  • x = এলোমেলো হেক্সাডেসিমেল ডিজিট (0-9, a-f)
  • 4 = স্থির ভার্সন নম্বর (UUID v4 নির্দেশ করে)
  • y = ভ্যারিয়েন্ট বিট, যার মান 8, 9, a, বা b (দুই বিট নির্দিষ্ট)

অর্থাৎ মোট ১২৮ বিটের মধ্যে ১২২ বিট এলোমেলো (6টি স্থির বিট কমিয়ে)। এই ১২২ বিট র্যান্ডমনেসের কারণে সংঘর্ষের (collision) সম্ভাবনা নগণ্য। একটি জনপ্রিয় হিসাব: যদি আপনি প্রতি সেকেন্ডে ১ বিলিয়ন UUID v4 তৈরি করেন, তাহলে ১০০ বছরে একটি মাত্র সংঘর্ষের সম্ভাবনা ৫০%। তবে বাস্তবে এটি আরও কম, কারণ ক্রিপ্টোগ্রাফিক মানসম্পন্ন র‍্যান্ডম নম্বর জেনারেটর (CSPRNG) ব্যবহার করা হয়।

আপনার এই পৃষ্ঠায় কী পরিবর্তন করতে পারেন?

  • ফরম্যাট: ড্রপডাউন থেকে UUID v4, v7, ULID, বা NanoID বেছে নিতে পারেন।
  • সংখ্যা: ১ থেকে ১০০ পর্যন্ত যেকোনো সংখ্যা।
  • বড় হাতের অক্ষর: চালু করলে হেক্সাডেসিমেল অক্ষর a-f বড় হাতের A-F হয়ে যায়।
  • হাইফেন অন্তর্ভুক্তি: বন্ধ করলে হাইফেন সরিয়ে ৩২ অক্ষরের স্ট্রিং পাওয়া যায়।

যেকোনো বিকল্প পরিবর্তন করলেই অবিলম্বে নতুন আইডি তৈরি হয়।

কাদের জন্য এই টুল?

অ্যাপ্লিকেশন ডেভেলপার

কোনো ওয়েব অ্যাপ্লিকেশনে ইউজার সেশন, ইভেন্ট লগ, বা অবজেক্ট আইডি দরকার – UUID v4 একটি আদর্শ সমাধান। সার্ভার বা ডাটাবেস দরকার নেই, ব্যবহারকারীর ব্রাউজারেই সব তৈরি হয়।

ডাটাবেস ডিজাইনার

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

নিরাপত্তা প্রকৌশলী

API টোকেন, রিকোয়েস্ট আইডি, বা যেকোনো অপ্রত্যাশিত আইডি দরকার – UUID v4-এর ১২২ বিট র্যান্ডমনেস হ্যাকিং বা এনুমারেশন প্রতিরোধ করে। সময়-ভিত্তিক আইডি থেকে লিক হতে পারে যে কবে আইডি তৈরি হয়েছে, কিন্তু v4-এ সেই ঝুঁকি নেই।

টেস্টার ও ডাটা জেনারেটর

বড় ডাটাসেটে বাস্তবসম্মত ইউনিক আইডি পপুলেট করতে এই টুল ব্যবহার করুন। ১০০টি আইডি একবারে কপি করে ডাটাবেসে ইনসার্ট করতে পারেন।

র‍্যান্ডম UUID v4-এর বাস্তব ব্যবহার ও ঝুঁকি

বেনিফিট

  • কো-অর্ডিনেশন ছাড়াই ইউনিক: দুইটি আলাদা কম্পিউটার একই সময়ে UUID v4 তৈরি করলেও যুক্তিহীনভাবে মিলবে না।
  • নিরাপত্তা: সিকোয়েন্সিয়াল আইডি থেকে সহজে অনুমান করা যায় পরবর্তী আইডি, কিন্তু UUID v4-এর ক্ষেত্রে তা অসম্ভব।
  • স্কেল: বিলিয়ন বিলিয়ন আইডির পরেও সংঘর্ষের আশঙ্কা অত্যন্ত কম।

খরচ

  • ইনডেক্স ফ্র্যাগমেন্টেশন: ডাটাবেসে UUID v4 প্রাইমারি কী হিসেবে ব্যবহার করলে B-ট্রি ইনডেক্স এলোমেলো হয়ে যায়। প্রতিটি নতুন রোড প্রায় কোথাও বসে, আগের কী-এর পাশে নয়। ফলে ইনডেক্স পৃষ্ঠা পুনর্গঠন (rebalancing) বাড়ে এবং লেখার পারফরম্যান্স কমে যায়।
  • ক্লাস্টারড ইনডেক্স: SQL সার্ভার বা MySQL-এ ক্লাস্টারড ইনডেক্স যদি UUID v4 হয়, তাহলে প্রতিটি INSERT-এ ডিস্কে ভৌতভাবে এলোমেলো অবস্থানে লেখা হয়, যা I/O উন্নতি বাধা দেয়।

সমাধান

  • UUID v7 ব্যবহার করুন, যাতে টাইমস্ট্যাম্প অন্তর্ভুক্ত থাকে এবং ইনডেক্স ক্রমবদ্ধ থাকে।
  • অথবা ডাটাবেসে sequential GUID (যেমন SQL Server-এর NEWSEQUENTIALID) ব্যবহার করুন।
  • তবে যদি অর্ডারিং গুরুত্বপূর্ণ না হয় এবং আপনি ছোট স্কেলে কাজ করেন, UUID v4 এখনও গ্রহণযোগ্য।

ফর্ম্যাট কাস্টমাইজেশন: কখন হাইফেন ও বড় হাতের অক্ষর প্রয়োজন?

হাইফেন

UUID-এর ক্যানোনিকাল ফরম্যাটে হাইফেন থাকে (8-4-4-4-12)। কিন্তু কিছু জায়গায় হাইফেনহীন সংস্করণ সুবিধাজনক:

  • URL: https://example.com/items/550e8400e29b41d4a716446655440000 এখানে হাইফেন না থাকলে URL আরও ছোট হয়।
  • ফাইল নাম: উইন্ডোজ ও কিছু ফাইল সিস্টেমে হাইফেন ফাইলের নামে সমস্যা তৈরি করতে পারে।
  • ডাটাবেস: অনেক ডাটাবেসে VARCHAR-এ হাইফেন সহ স্ট্রিং সংরক্ষণ করলে স্থান বাড়ে। তবে ইউনিক আইডি হিসেবে হাইফেনহীন ৩২ অক্ষরের স্ট্রিং বাইট সংরক্ষণ করে না (প্রতি অক্ষর ২৪ বাইট – বাইট সংরক্ষণের জন্য সরাসরি binary(16) ব্যবহার ভালো)।

বড় হাতের অক্ষর

UUID সাধারণত ছোট হাতের হেক্স অক্ষর দিয়ে লেখা হয়, কিন্তু কিছু সিস্টেমে বড় হাতের অক্ষর বাধ্যতামূলক। যেমন:

  • কিছু কেস-সংবেদনশীল ডাটাবেস প্রশ্নে ইউনিক ডাটা ট্র্যাকিং সহজ হয়।
  • রেজেক্সে প্যাটার্ন মিলানোর সময় বড় হাতের ফরম্যাট প্রায়ই ব্যবহার করা হয়।
  • তবে UUID-এর অক্ষর অর্ডার গুরুত্বপূর্ণ নয়; আপনি চাইলে মিক্সড কেসও ব্যবহার করতে পারেন। কিন্তু এই পৃষ্ঠায় টগল দিয়ে একটি নির্দিষ্ট কেস বেছে নেওয়া সহজ।

FAQ

প্রশ্ন ১: UUID v4 সংঘর্ষের (collision) সম্ভাবনা কত?

উত্তর: ১২২ বিট র্যান্ডমনেসের কারণে এটি অত্যন্ত কম। গণিত অনুসারে, যদি আপনি ২.৭১ × ১০^১৮ টি UUID তৈরি করেন, তাহলে একটি মাত্র সংঘর্ষের ৫০% সম্ভাবনা। বাস্তব ব্যবহারে কখনোই সংঘর্ষ দেখা যাবে না, তবে একেবারে শূন্য নয়।

প্রশ্ন ২: আমি কি এই UUID v4 ডাটাবেসে প্রাইমারি কী হিসেবে ব্যবহার করতে পারি?

উত্তর: হ্যাঁ, কিন্তু সতর্ক থাকুন। বড় ডাটাবেসে (বিশেষ করে ক্লাস্টারড ইনডেক্স সহ) পারফরম্যান্স খারাপ হতে পারে। ছোট বা মাঝারি সিস্টেমের জন্য এটি গ্রহণযোগ্য। অর্ডারিং প্রয়োজনে UUID v7 বা ULID বিবেচনা করুন।

প্রশ্ন ৩: সংখ্যা ১০০ কেন সীমা?

উত্তর: পৃষ্ঠাটি ডিজাইন করা হয়েছে ১ থেকে ১০০ পর্যন্ত বিস্তৃত কয়েকটি আইডি একসাথে জেনারেট করার জন্য। এর বেশি দরকার হলে বারবার জেনারেট করতে পারেন। ১০০-এর বেশি একবারে দেখালে ব্রাউজার পারফরম্যান্সে প্রভাব পড়তে পারে, কিন্তু আসলে এই সীমা কৃত্রিম।

প্রশ্ন ৪: হাইফেন তুলে ফেললে কি UUID-এর বৈধতা নষ্ট হয়?

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

প্রশ্ন ৫: বড় হাতের অক্ষর ব্যবহার করলে কি সংঘর্ষের হার বাড়ে?

উত্তর: না। হেক্সাডেসিমেল অক্ষর a-f এবং A-F সমতুল্য। শুধু উপস্থাপনার পরিবর্তন, অন্তর্নিহিত বিট একই থাকে। সংঘর্ষের সম্ভাবনা একই থাকে।

প্রশ্ন ৬: এই টুল কি ইন্টারনেট ছাড়া কাজ করে?

উত্তর: হ্যাঁ, সব প্রজন্ম ব্রাউজারে সম্পন্ন হয়। পৃষ্ঠাটি লোড হওয়ার পর ইন্টারনেট সংযোগ ছাড়াই কাজ করবে। তবে প্রথমবার পৃষ্ঠা লোডের জন্য ইন্টারনেট দরকার।

প্রশ্ন ৭: আমি কীভাবে একটি একক UUID কপি করব?

উত্তর: পৃষ্ঠায় প্রদর্শিত তালিকা থেকে যেকোনো UUID-তে ক্লিক করুন। সেটি স্বয়ংক্রিয়ভাবে আপনার ক্লিপবোর্ডে কপি হবে। নিচের বাটন দিয়ে সবগুলো একসাথে কপি করতে পারবেন।