UUID v4 জেনারেটর
ক্রিপ্টোগ্রাফিকভাবে র্যান্ডম UUID v4 তৈরি করুন
…
ফরম্যাট
UUID v4 আধুনিক সফটওয়্যারে সবচেয়ে বেশি ব্যবহৃত UUID সংস্করণ। টাইমস্ট্যাম্প বা নেমস্পেস হ্যাশ থেকে বিট তৈরি করা অন্যান্য সংস্করণের মতো নয় — UUID v4 সম্পূর্ণ র্যান্ডম ডেটা দিয়ে তৈরি। যখনই আপনার উৎস সম্পর্কে কোনো মেটাডেটা বহন করে না এমন একটি ইউনিক আইডেন্টিফায়ার দরকার, তখন এটি সবচেয়ে সহজ ও বহনযোগ্য পছন্দ।
এই জেনারেটর crypto.randomUUID() ব্যবহার করে — ব্রাউজার ও Node.js-এর নেটিভ API — যা অপারেটিং সিস্টেমের ক্রিপ্টোগ্রাফিক্যালি সিকিউর র্যান্ডম নম্বর জেনারেটর থেকে এনট্রপি নেয়। TLS কী ম্যাটেরিয়ালের জন্যও একই উৎস ব্যবহার করা হয়।
UUID v4 কী?
Universally Unique Identifier (UUID) হলো একটি 128-বিট লেবেল যা RFC 4122-এ মানকীভূত। এটি সাধারণত 32টি হেক্সাডেসিমাল অঙ্ক হাইফেন দিয়ে 8-4-4-4-12 প্যাটার্নে উপস্থাপিত হয়:
UUID v4-এ 128 বিটের মধ্যে 122 বিট র্যান্ডম। বাকি 6 বিট স্পেক অনুযায়ী নির্ধারিত: 4 বিট ভার্সন এনকোড করে (0100 = 4) এবং 2 বিট RFC 4122 ভেরিয়েন্ট এনকোড করে (10)। এই নির্ধারিত বিটগুলোর কারণেই তৃতীয় গ্রুপ সবসময় 4 দিয়ে শুরু হয় এবং চতুর্থ গ্রুপ সবসময় 8, 9, a, বা b দিয়ে শুরু হয়।
UUID v4-এর গঠন
550e8400-e29b-41d4-a716-446655440000 বিশ্লেষণ:
| সেগমেন্ট | বিট | অর্থ |
|---|---|---|
| 550e8400 | ৩২টি র্যান্ডম | time_low (নামটি ঐতিহাসিক — v4-এ সম্পূর্ণ র্যান্ডম) |
| e29b | ১৬টি র্যান্ডম | time_mid (ঐতিহাসিক নাম — v4-এ সম্পূর্ণ র্যান্ডম) |
| 41d4 | ৪টি নির্ধারিত + ১২টি র্যান্ডম | ভার্সন নিবল 4 (বাইনারি 0100) + ১২টি র্যান্ডম বিট |
| a716 | ২টি নির্ধারিত + ১৪টি র্যান্ডম | ভেরিয়েন্ট বিট 10 (প্রথম বাইটের MSB) + ১৪টি র্যান্ডম বিট |
| 446655440000 | ৪৮টি র্যান্ডম | node (v4-এ সম্পূর্ণ র্যান্ডম) |
8, 9, a, বা b-এর মধ্যে একটি — কারণ সেই বাইটের উচ্চ দুই বিট 10-তে (RFC 4122 ভেরিয়েন্ট মার্কার) নির্ধারিত থাকে, বাকি দুই বিট পরিবর্তনযোগ্য।UUID v4 বনাম অন্যান্য সংস্করণ
RFC 4122 পাঁচটি UUID সংস্করণ সংজ্ঞায়িত করে। প্রতিটি ভিন্ন সমস্যার সমাধান করে:
৬০-বিট টাইমস্ট্যাম্প (অক্টোবর ১৫৮২ থেকে ১০০-ন্যানোসেকেন্ড বিরতিতে) ও হোস্ট MAC ঠিকানা একত্রিত করে। একটি মেশিনের মধ্যে একটানা বাড়তে থাকে।
Use when: আপনার সময়-ক্রমানুসারী IDs দরকার এবং সার্ভার পরিচয় ও তৈরির সময় প্রকাশ হওয়া নিয়ে আপত্তি নেই।
নির্ধারণযোগ্য: একই নেমস্পেস + নাম সবসময় একই UUID তৈরি করে। MD5 হ্যাশিং ব্যবহার করে।
Use when: পরিচিত নেমস্পেস থেকে পুনরুৎপাদনযোগ্য IDs দরকার (যেমন DNS নাম)। v3-এর বদলে v5 পছন্দ করুন।
১২২ বিট ক্রিপ্টোগ্রাফিক্যালি সিকিউর র্যান্ডমনেস। কোনো টাইমস্ট্যাম্প নেই, কোনো MAC নেই, কোনো নেমস্পেস নেই। সবচেয়ে সাধারণ সাধারণ-উদ্দেশ্য পছন্দ।
Use when: কোনো কাঠামোগত অর্থ ছাড়া এবং সর্বোচ্চ গোপনীয়তা সহ ইউনিক IDs দরকার।
v3-এর মতো কিন্তু SHA-1 ব্যবহার করে। নেমস্পেস + নাম থেকে এখনও নির্ধারণযোগ্য।
Use when: পুনরুৎপাদনযোগ্য, কন্টেন্ট-অ্যাড্রেসড আইডেন্টিফায়ার দরকার (যেমন URL দ্বারা চিহ্নিত রিসোর্সের জন্য স্থায়ী IDs)।
নতুন (RFC 9562, ২০২৪)। উচ্চ বিটে Unix মিলিসেকেন্ড টাইমস্ট্যাম্প এনকোড করে, তারপর র্যান্ডম বিট। সর্টযোগ্য ও ডেটাবেস-বান্ধব।
Use when: স্বাভাবিক সময়-ক্রম সহ ডেটাবেস-ইনডেক্স-বান্ধব IDs দরকার (নতুন প্রকল্পে v1-এর বদলে পছন্দ করুন)।
UUID v4 কখন ব্যবহার করবেন
বেশিরভাগ পরিস্থিতিতে যেখানে আপনার শুধু "একটি ইউনিক ID" দরকার অতিরিক্ত শর্ত ছাড়া, সেখানে UUID v4 সঠিক পছন্দ:
ব্যবহারকারী ও অ্যাকাউন্ট ID
অস্বচ্ছ ব্যবহারকারী ID যা অ্যাকাউন্ট তৈরির সময় বা সার্ভার পরিচয় সম্পর্কে কিছু প্রকাশ করে না। গণনা বা অনুমান করা যায় না।
ডেটাবেস প্রাইমারি কী
যেকোনো ডেটাবেস ইঞ্জিনে কাজ করে। UUID v4 ক্লায়েন্ট-সাইডে তৈরি এবং সমন্বয় ছাড়াই বিতরণ করা উৎস থেকে মার্জ করা নিরাপদ — কোনো সিকোয়েন্স টেবিল বা কেন্দ্রীয় ID সার্ভিস দরকার নেই।
সেশন ও টোকেন ID
১২২ বিট র্যান্ডমনেস ব্রুট-ফোর্স অনুমানকে গণনাগতভাবে অসম্ভব করে তোলে — ১২২-বিট র্যান্ডম টোকেনের সমতুল্য শক্তি।
ফাইল ও অবজেক্টের নাম
আপলোড, S3 অবজেক্ট কী, বা ক্যাশ এন্ট্রির জন্য ডিডুপ্লিকেশন-নিরাপদ ফাইলনাম। দুই ক্লায়েন্ট একই কীতে লেখার কোনো ঝুঁকি নেই।
আইডেম্পোটেন্সি কী
রিকোয়েস্ট পাঠানোর আগে ক্লায়েন্টে একটি UUID তৈরি করুন। সার্ভার শেয়ার করা কাউন্টার ছাড়াই পুনরায় পাঠানো রিকোয়েস্ট নিরাপদে ডিডুপ্লিকেট করতে পারে।
কোরিলেশন ও ট্রেস ID
প্রতিটি লগ লাইন ও ডিস্ট্রিবিউটেড ট্রেস স্প্যানে একটি UUID যুক্ত করুন। সার্ভিস বা মেশিন জুড়ে কোনো সমন্বয়ের প্রয়োজন নেই।
কোলিশনের সম্ভাবনা
১২২টি র্যান্ডম বিট সহ, UUID v4 স্পেসে 2122 ≈ 5.3 × 1036 সম্ভাব্য মান রয়েছে। কোলিশনের সম্ভাবনা জন্মদিন সমস্যা অনুসরণ করে:
সাধারণত উদ্ধৃত মানদণ্ড: একটি কোলিশনের ৫০% সম্ভাবনার জন্য আপনাকে প্রায় 2.71 × 1018 UUID তৈরি করতে হবে। প্রতি সেকেন্ডে ১ বিলিয়ন UUID হারে, এটি প্রায় ৮৫ বছর ক্রমাগত তৈরি করতে সময় নেবে। যেকোনো বাস্তব অ্যাপ্লিকেশনে কোলিশন একটি ব্যবহারিক উদ্বেগ নয়।
কোড উদাহরণ
JavaScript — ব্রাউজার ও Node.js 14.17+
crypto.randomUUID() পদ্ধতি সমস্ত আধুনিক ব্রাউজারে (Chrome 92+, Firefox 95+, Safari 15.4+) এবং Node.js 14.17+-এ নেটিভলি পাওয়া যায়। কোনো প্যাকেজ ইনস্টলেশনের প্রয়োজন নেই।
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — পুরনো সংস্করণ (uuid প্যাকেজ)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
প্রায়শই জিজ্ঞাসিত প্রশ্ন
UUID v4 কি ক্রিপ্টোগ্রাফিক্যালি সিকিউর?
UUID v4 নিজেই একটি নিরাপত্তা প্রিমিটিভ নয় — এটি একটি আইডেন্টিফায়ার ফরম্যাট। তবে crypto.randomUUID() (ব্রাউজার বা Node.js) বা সমতুল্য OS-স্তরের API-এর মাধ্যমে তৈরি হলে, অন্তর্নিহিত এনট্রপি ক্রিপ্টোগ্রাফিক্যালি সিকিউর। এর মানে UUID v4 মান সেশন টোকেন বা আইডেম্পোটেন্সি কী হিসেবে ব্যবহারের জন্য উপযুক্ত, যেখানে অপ্রত্যাশিততা গুরুত্বপূর্ণ। নিরাপত্তা-সংবেদনশীল প্রেক্ষাপটে Math.random()-ভিত্তিক UUID জেনারেটর ব্যবহার করবেন না — শুধুমাত্র OS CSPRNG থেকে স্পষ্টভাবে আঁকা API ব্যবহার করুন।
দুটি UUID v4 কি কখনো সমান হতে পারে?
তাত্ত্বিকভাবে হ্যাঁ, কিন্তু বাস্তবে না। যেকোনো বাস্তবসম্মত ডেটাসেটে (বিলিয়ন IDs) ডুপ্লিকেট তৈরির সম্ভাবনা অত্যন্ত ক্ষুদ্র — হার্ডওয়্যার ত্রুটির কারণে ডেটা দুর্নীতির চেয়েও অনেক কম। UUID v4 কোলিশনকে প্রোডাকশন সিস্টেম ডিজাইনে অসম্ভব বলে গণ্য করা হয়। যদি সত্যিই শূন্য-কোলিশনের গ্যারান্টি দরকার হয়, তাহলে কেন্দ্রীভূত কাউন্টার বা ডেটাবেস সিকোয়েন্স ব্যবহার করুন।
UUID v4 বনাম nanoid — কোনটি ব্যবহার করব?
উভয়ই CSPRNG-সমর্থিত র্যান্ডম ID জেনারেটর। মূল পার্থক্যগুলো:
- UUID v4 RFC 4122 মান অনুসরণ করে, প্রতিটি ডেটাবেস ও ফ্রেমওয়ার্ক দ্বারা স্বীকৃত, এবং শূন্য নির্ভরতা প্রয়োজন (নেটিভ
crypto.randomUUID())। - nanoid URL-নিরাপদ অ্যালফাবেট ব্যবহার করে এবং ডিফল্টে ছোট (২১ অক্ষর বনাম ৩৬)। URL দৈর্ঘ্য বা পাঠযোগ্যতা গুরুত্বপূর্ণ হলে উপযোগী। একটি npm প্যাকেজ প্রয়োজন।
বাহ্যিক সিস্টেমের (API, ডেটাবেস, লগিং ইনফ্রাস্ট্রাকচার) সাথে আন্তঃক্রিয়াযোগ্যতা গুরুত্বপূর্ণ হলে UUID v4 পছন্দ করুন। ছোট IDs চাইলে এবং পুরো স্ট্যাক নিয়ন্ত্রণ করলে nanoid পছন্দ করুন।
ডেটাবেসে UUID স্ট্রিং হিসেবে নাকি বাইনারি হিসেবে সংরক্ষণ করব?
বেশিরভাগ ডেটাবেসে, UUID বা BINARY(16) কলাম হিসেবে (১৬ বাইট) সংরক্ষণ করা VARCHAR(36) স্ট্রিং (৩৬ বাইট) এর চেয়ে বেশি দক্ষ। PostgreSQL-এ নেটিভ uuid টাইপ আছে। MySQL ও MariaDB BINARY(16) এবং UUID_TO_BIN() / BIN_TO_UUID() হেল্পারের সাথে ভালো কাজ করে। SQLite ব্যবহারকারীরা সাধারণত TEXT হিসেবে সংরক্ষণ করেন। সংরক্ষণ পছন্দ অনন্যতা বা সঠিকতাকে প্রভাবিত করে না।
UUID v4-এ হাইফেন কেন — এবং আমি কি সেগুলো বাদ দিতে পারি?
হাইফেন RFC 4122 দ্বারা সংজ্ঞায়িত ক্যানোনিকাল UUID উপস্থাপনার অংশ। এগুলো সম্পূর্ণ সাজসজ্জামূলক — কোনো তথ্য বহন করে না এবং 128-বিট মানকে প্রভাবিত করে না। সেগুলো বাদ দিলে একটি কম্প্যাক্ট 32-অক্ষরের হেক্স স্ট্রিং পাওয়া যায় যা কার্যকরীভাবে সমতুল্য। বেশিরভাগ UUID পার্সার উভয় ফর্ম গ্রহণ করে। সন্দেহ হলে তৃতীয়-পক্ষের টুল ও ডেটাবেসের সাথে সর্বোচ্চ সামঞ্জস্যতার জন্য ক্যানোনিকাল হাইফেনযুক্ত ফর্ম ব্যবহার করুন।
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"