ToolDeck

UUID v1 Generator

Generate time-based UUID v1 with embedded timestamp

ফরম্যাট

Count:
Note:UUID v1 হোস্টের MAC অ্যাড্রেস ও তৈরির টাইমস্ট্যাম্প এমবেড করে, যা বেশিরভাগ আধুনিক অ্যাপ্লিকেশনে গোপনীয়তার ঝুঁকি তৈরি করে। নতুন প্রজেক্টে UUID v4 ব্যবহারের পরামর্শ দেওয়া হয়, যদি না আপনার বিশেষভাবে সময়-ক্রমানুসারী, ডিকোডযোগ্য শনাক্তকারী প্রয়োজন হয়।

UUID v1 কী?

UUID v1 হলো UUID-এর মূল সংস্করণ, যা RFC 4122 (2005)-এ মানকীকৃত হয়েছে। এটি উচ্চ-নির্ভুলতার টাইমস্ট্যাম্পের সাথে তৈরিকারী হোস্টের MAC অ্যাড্রেস এবং সাব-টাইমস্ট্যাম্প রেজোলিউশন পরিচালনার জন্য একটি সংক্ষিপ্ত ক্লক সিকোয়েন্স মিলিয়ে অনন্য শনাক্তকারী তৈরি করে।

টাইমস্ট্যাম্প এমবেড থাকায়, একই হোস্ট থেকে UUID v1-এর মানগুলো সময়ের সাথে ক্রমশ বৃদ্ধি পায় — ফলে এগুলো স্বাভাবিকভাবেই ক্রমানুসারী। এটি বিতরণকৃত সিস্টেমের জন্য ডিজাইন করা হয়েছিল যেখানে প্রতিটি নোড কোনো সমন্বয় ছাড়াই স্বাধীনভাবে UUID তৈরি করতে পারে।

আজ UUID v1 মূলত UUID v7 (sortable, MAC ফাঁস নেই) এবং UUID v4 (সম্পূর্ণ র‍্যান্ডম, প্রাইভেট) দ্বারা প্রতিস্থাপিত হয়েছে। এটি Apache Cassandra এবং লেগ্যাসি বিতরণকৃত ডেটাবেসের মতো সিস্টেমে ব্যবহৃত হচ্ছে।

RFC 9562 — Universally Unique IDentifiers (UUID) →

UUID v1-এর গঠন

550e8400-e29b-11d4-a716-446655440000-এর মতো একটি UUID v1 স্ট্রিং ছয়টি স্বতন্ত্র ক্ষেত্র এনকোড করে:

ক্ষেত্রআকারবিবরণ
time_low32 bits৬০-বিট গ্রেগরিয়ান টাইমস্ট্যাম্পের ৩২-বিট নিম্ন ক্ষেত্র (১৫৮২ সালের ১৫ অক্টোবর থেকে ১০০-ন্যানোসেকেন্ড ব্যবধান)
time_mid16 bits৬০-বিট টাইমস্ট্যাম্পের মধ্যবর্তী ১৬-বিট ক্ষেত্র
time_hi_and_version16 bits৬০-বিট টাইমস্ট্যাম্পের শীর্ষ ১২ বিট এবং ৪-বিট সংস্করণ নম্বর (সর্বদা <code>1</code>)
clock_seq_hi_res8 bits২-বিট RFC 4122 ভেরিয়েন্ট মার্কারের সাথে যুক্ত ৬-বিট ক্লক সিকোয়েন্স উচ্চ ক্ষেত্র
clock_seq_low8 bitsক্লক সিকোয়েন্সের নিচের ৮ বিট
node48 bits৪৮-বিট নোড শনাক্তকারী — সাধারণত তৈরিকারী নেটওয়ার্ক ইন্টারফেসের MAC অ্যাড্রেস, অথবা MAC পাওয়া না গেলে একটি র‍্যান্ডম ৪৮-বিট মান

ক্লক সিকোয়েন্স ক্ষেত্র (clock_seq_hi_res + clock_seq_low) হলো একটি ১৪-বিট কাউন্টার। সিস্টেম ঘড়ি পিছিয়ে গেলে (যেমন NTP সমন্বয়) বা শেষ পরিচিত টাইমস্ট্যাম্প সংরক্ষণ না করে সিস্টেম পুনরায় চালু হলে এটি বৃদ্ধি পায়। এটি নিশ্চিত করে যে ঘড়ি একঘেয়েভাবে না বাড়লেও নকল UUID তৈরি হবে না।

UUID v1 টাইমস্ট্যাম্প ডিকোড করা

৬০-বিট টাইমস্ট্যাম্প UUID-এর তিনটি ক্ষেত্রে ছড়িয়ে আছে। তৈরির সময় পুনর্গঠন করতে:

  1. time_low (বাইট ০–৩), time_mid (বাইট ৪–৫), এবং time_hi (বাইট ৬–৭, সংস্করণ নিবল বাদে) বের করুন
  2. পুনর্গঠন করুন: (time_hi &lt;&lt; 48) | (time_mid &lt;&lt; 32) | time_low
  3. ফলাফল হলো ১৫৮২ সালের ১৫ অক্টোবর (গ্রেগরিয়ান ক্যালেন্ডার যুগ) থেকে ১০০-ন্যানোসেকেন্ড ব্যবধানের ৬০-বিট গণনা
  4. গ্রেগরিয়ান-থেকে-Unix অফসেট বিয়োগ করুন: ১২২,১৯২,৯২৮,০০০,০০০,০০০ (১৫৮২ সালের ১৫ অক্টোবর থেকে ১৯৭০ সালের ১ জানুয়ারির মধ্যে ১০০-ns ব্যবধান)
  5. ১০০-ন্যানোসেকেন্ড ব্যবধান থেকে মিলিসেকেন্ডে রূপান্তরের জন্য ১০,০০০ দিয়ে ভাগ করুন
  6. ফলাফলটি Date অবজেক্ট তৈরির জন্য Unix মিলিসেকেন্ড টাইমস্ট্যাম্প হিসেবে ব্যবহার করুন
  7. মানুষের পাঠযোগ্য আউটপুটের জন্য ISO 8601 ফরম্যাটে উপস্থাপন করুন

টাইমস্ট্যাম্পের নির্ভুলতা ১০০ ন্যানোসেকেন্ড — UUID v7-এর মিলিসেকেন্ড নির্ভুলতার চেয়ে অনেক বেশি সূক্ষ্ম। তবে বাস্তবে বেশিরভাগ অপারেটিং সিস্টেম সাব-মিলিসেকেন্ড ক্লক রেজোলিউশন প্রকাশ করে না, তাই নিচের বিটগুলো প্রায়ই শূন্য বা কৃত্রিমভাবে তৈরি হয়।

গোপনীয়তার ঝুঁকি

UUID v1-এর সবচেয়ে উল্লেখযোগ্য অসুবিধা হলো এটি নোড ক্ষেত্রে তৈরিকারী হোস্টের MAC অ্যাড্রেস এমবেড করে। এর মানে প্রতিটি UUID v1-এ যে মেশিন এটি তৈরি করেছে তার একটি স্থায়ী, বৈশ্বিকভাবে অনন্য পরিচয় বহন করে।

যে আক্রমণকারী UUID v1 পায় সে আনুমানিক তৈরির সময় এবং তৈরিকারী হোস্টের MAC অ্যাড্রেস জানতে পারে।

এই কারণে, আপনি এই তথ্য প্রকাশে স্বাচ্ছন্দ্যবোধ না করলে UUID v1 কখনো পাবলিক-মুখী শনাক্তকারী হিসেবে (যেমন URL বা API রেসপন্সে) ব্যবহার করা উচিত নয়। RFC 4122 নিজেই উল্লেখ করে যে একটি সিস্টেম MAC অ্যাড্রেসের পরিবর্তে র‍্যান্ডম ৪৮-বিট মান ব্যবহার করতে পারে, তবে অনেক বাস্তবায়ন তা করে না।

UUID v1 এখনো কোথায় উপযুক্ত

Apache Cassandra প্রাইমারি কী
Cassandra UUID v1 (TimeUUID টাইপের মাধ্যমে) একটি মূল ডিজাইন প্যাটার্ন হিসেবে ব্যবহার করে। টাইমস্ট্যাম্পের ক্রম Cassandra-এর স্টোরেজ মডেলের সাথে স্বাভাবিকভাবে মিলে যায়, যা দক্ষ টাইম-রেঞ্জ কোয়েরি সক্ষম করে।
লেগ্যাসি বিতরণকৃত সিস্টেম
UUID v7 আসার আগে (২০২৪-পূর্ব) তৈরি সিস্টেম যা টাইমস্ট্যাম্প-ক্রমানুসারী UUID-এর উপর নির্ভরশীল এবং সহজে নতুন ফরম্যাটে স্থানান্তর করতে পারে না।
অডিট ও ইভেন্ট লগ
যখন তৈরিকারী হোস্টের পরিচয় পরিচিত ও বিশ্বস্ত, তখন MAC অ্যাড্রেস এমবেড করলে অডিট ইভেন্টের জন্য অতিরিক্ত ট্রেসযোগ্যতা পাওয়া যায়।
অভ্যন্তরীণ শনাক্তকারী
এমন ID যা কখনো নিয়ন্ত্রিত অভ্যন্তরীণ সিস্টেমের বাইরে প্রকাশ পায় না, যেখানে MAC অ্যাড্রেস প্রকাশ উদ্বেগের বিষয় নয়।
আলাদা টাইমস্ট্যাম্প কলাম ছাড়া টাইম-রেঞ্জ কোয়েরি
এমবেড করা টাইমস্ট্যাম্প ডিকোড করে তৈরির সময় অনুযায়ী সারি ফিল্টার করা যায়, যা একটি সম্মিলিত ID ও টাইমস্ট্যাম্প হিসেবে কাজ করে।
বাহ্যিক সিস্টেম থেকে UUID v1 পড়া
যখন কোনো বাহ্যিক সিস্টেম UUID v1 মান নির্গত করে, তখন আলাদা created_at কলাম ছাড়াই প্রদর্শন, ফিল্টারিং বা বিশ্লেষণের জন্য এমবেড করা টাইমস্ট্যাম্প ডিকোড করা যায়।

UUID v1 বনাম UUID v7

UUID v7 হলো সময়-ক্রমানুসারী শনাক্তকারীর জন্য UUID v1-এর আধুনিক উত্তরসূরি। এখানে একটি সরাসরি তুলনা করা হয়েছে:

দিকUUID v1UUID v7
যুগ / সময় ভিত্তিগ্রেগরিয়ান যুগ (১৫ অক্টোবর, ১৫৮২)Unix যুগ (১ জানুয়ারি, ১৯৭০)
নির্ভুলতা১০০ ন্যানোসেকেন্ড১ মিলিসেকেন্ড
নোড শনাক্তকারীMAC অ্যাড্রেস (হোস্ট পরিচয় ফাঁস করে)র‍্যান্ডম (প্রাইভেট)
গোপনীয়তাMAC অ্যাড্রেস ও তৈরির টাইমস্ট্যাম্প ফাঁস করেকোনো হোস্ট তথ্য এমবেড নেই
DB ইন্ডেক্স পারফরম্যান্সভালো — প্রতি হোস্টে ক্রমানুসারীচমৎকার — সব জেনারেটর জুড়ে k-sortable
মানRFC 4122 (2005)RFC 9562 (2024)

নতুন প্রজেক্টে UUID v7 হলো UUID v1-এর সঠিক প্রতিস্থাপন। এটি আরও ভালো বৈশ্বিক সাজানোর ক্রম প্রদান করে — শুধু প্রতি হোস্টে ক্রমানুসারী নয়, সব জেনারেটর জুড়ে k-sortable — এবং কোনো MAC অ্যাড্রেস ফাঁস নেই।

কোড উদাহরণ

UUID v1 ব্রাউজারের বিল্ট-ইন API-তে নেই, তবে crypto.getRandomValues() ও Date.now() থেকে এটি তৈরি করা যায়। Python-এর uuid মডিউলে এটি সরাসরি আছে; Go-তে github.com/google/uuid প্যাকেজ প্রয়োজন:

JavaScript (browser)
// Generate a UUID v1 using the Web Crypto API
function generateUuidV1() {
  const buf = new Uint8Array(16)
  crypto.getRandomValues(buf)

  const ms = BigInt(Date.now())
  const gregorianOffset = 122192928000000000n
  const t = ms * 10000n + gregorianOffset

  const tLow   = Number(t & 0xFFFFFFFFn)
  const tMid   = Number((t >> 32n) & 0xFFFFn)
  const tHiVer = Number((t >> 48n) & 0x0FFFn) | 0x1000  // version 1

  const clockSeq    = (buf[8] & 0x3F) | 0x80  // variant 10xxxxxx
  const clockSeqLow = buf[9]

  const hex  = (n, pad) => n.toString(16).padStart(pad, '0')
  const node = [...buf.slice(10)].map(b => b.toString(16).padStart(2, '0')).join('')

  return `${hex(tLow,8)}-${hex(tMid,4)}-${hex(tHiVer,4)}-${hex(clockSeq,2)}${hex(clockSeqLow,2)}-${node}`
}

// Extract the embedded timestamp from a UUID v1
function extractTimestamp(uuid) {
  const parts = uuid.split('-')
  const tHex = parts[2].slice(1) + parts[1] + parts[0]
  const t = BigInt('0x' + tHex)
  const ms = (t - 122192928000000000n) / 10000n
  return new Date(Number(ms))
}

const id = generateUuidV1()
console.log(id)                      // e.g. "1eb5e8b0-6b4d-11ee-9c45-a1f2b3c4d5e6"
console.log(extractTimestamp(id))    // e.g. 2023-10-15T12:34:56.789Z
Python
import uuid
from datetime import datetime, timezone

# Generate UUID v1 (uses MAC address by default)
uid = uuid.uuid1()
print(uid)

# Extract embedded timestamp
# uuid.time is 100-ns intervals since Oct 15, 1582
GREGORIAN_OFFSET = 122192928000000000  # 100-ns intervals
ts_100ns = uid.time
ts_ms = (ts_100ns - GREGORIAN_OFFSET) // 10000
dt = datetime.fromtimestamp(ts_ms / 1000, tz=timezone.utc)
print(dt.isoformat())   # e.g. "2023-10-15T12:34:56.789000+00:00"
Go
package main

import (
    "fmt"
    "time"

    "github.com/google/uuid"  // go get github.com/google/uuid
)

func main() {
    id, _ := uuid.NewUUID()  // UUID v1
    fmt.Println(id)

    // Extract timestamp from UUID v1
    // uuid.Time is 100-ns ticks since Oct 15, 1582
    t := id.Time()
    sec  := int64(t)/1e7 - 12219292800  // convert to Unix seconds
    nsec := (int64(t) % 1e7) * 100
    ts   := time.Unix(sec, nsec).UTC()
    fmt.Println(ts.Format(time.RFC3339Nano))
}

সাধারণ জিজ্ঞাসা

UUID v1 থেকে কি টাইমস্ট্যাম্প ডিকোড করা যায়?
হ্যাঁ। তৈরির টাইমস্ট্যাম্প UUID v1 স্ট্রিং থেকে সম্পূর্ণভাবে পুনরুদ্ধারযোগ্য। এই টুলটি ঠিক তাই করে — যেকোনো UUID v1 পেস্ট করুন এবং এটি ডিকোড করা UTC টাইমস্ট্যাম্প প্রদর্শন করবে। অ্যালগরিদমের জন্য উপরের ডিকোডিং ধাপগুলো দেখুন।
UUID v1-এ কি সবসময় MAC অ্যাড্রেস থাকে?
অবশ্যই নয়। RFC 4122 বাস্তবায়নকারীদের নেটওয়ার্ক ইন্টারফেস না থাকলে বা গোপনীয়তা কাম্য হলে MAC অ্যাড্রেসের পরিবর্তে র‍্যান্ডম ৪৮-বিট মান ব্যবহার করার অনুমতি দেয়। বাস্তবে অনেক সার্ভার-সাইড বাস্তবায়ন আসল MAC অ্যাড্রেস এমবেড করে। ব্রাউজারে তৈরি UUID v1 সবসময় র‍্যান্ডম নোড মান ব্যবহার করে কারণ ব্রাউজার MAC অ্যাড্রেস প্রকাশ করে না।
UUID v1 টাইমস্ট্যাম্প কেন ১৫৮২ সালকে যুগ হিসেবে ব্যবহার করে?
গ্রেগরিয়ান ক্যালেন্ডার সংস্কার ১৫৮২ সালের ১৫ অক্টোবর কার্যকর হয়েছিল। UUID v1 টাইমস্ট্যাম্প এই তারিখের সাপেক্ষে সংজ্ঞায়িত হয়েছিল যাতে Unix যুগ (১৯৭০) এর আগের একটি স্থিতিশীল, সর্বজনীন রেফারেন্স পয়েন্ট পাওয়া যায়। এটি ৬০-বিট টাইমস্ট্যাম্প ক্ষেত্রকে আনুমানিক ৩৪০০ খ্রিষ্টাব্দ পর্যন্ত অনন্য থাকার মতো পর্যাপ্ত পরিসর দেয়।
UUID v1 বনাম UUID v7 — কখন এখনো v1 ব্যবহার করব?
আজ UUID v1 ব্যবহারের প্রধান কারণ হলো বিদ্যমান সিস্টেমের সাথে সামঞ্জস্য — বিশেষত Apache Cassandra, যা v1 তার TimeUUID টাইপ হিসেবে ব্যবহার করে। সব নতুন সিস্টেমের জন্য UUID v7 কঠোরভাবে ভালো: এটি আরও পরিচিত Unix যুগ ব্যবহার করে, কোনো MAC অ্যাড্রেস ফাঁস নেই, এবং B-tree ইন্ডেক্সের জন্য ভালো পারফরম্যান্স দেয়।
UUID v1 মান কি সংঘর্ষ করতে পারে?
তাত্ত্বিকভাবে, একই MAC অ্যাড্রেস একই ১০০-ন্যানোসেকেন্ড ব্যবধানে দুটি UUID তৈরি করলে এবং ক্লক সিকোয়েন্স একই হলে দুটি UUID v1 সংঘর্ষ করতে পারে। ক্লক সিকোয়েন্স ঠিক এটি রোধ করতেই আছে — দ্রুত পর পর কল করলে এটি বৃদ্ধি পায়। বাস্তবে সঠিকভাবে বাস্তবায়িত সিস্টেমে UUID v1 সংঘর্ষ অত্যন্ত বিরল।