ToolDeck

ตัวถอดรหัส UUID

ถอดรหัสและตรวจสอบโครงสร้าง เวอร์ชัน และข้อมูลที่ฝังใน UUID

ลองตัวอย่าง

ป้อน UUID

วาง UUID ด้านบนเพื่อตรวจสอบ

โครงสร้าง UUID

UUID (Universally Unique Identifier) คือค่า 128 บิตที่แสดงเป็นตัวเลข hexadecimal 32 หลัก แบ่งเป็นห้ากลุ่มด้วยขีดกลาง:

Format
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
xxxxxxxx (8)8 หลัก hex — 32 บิต
xxxx (4)4 หลัก hex — 16 บิต
Mxxx (4)4 หลัก hex — 16 บิต ตัวแรก M เข้ารหัส UUID version (1–8)
Nxxx (4)4 หลัก hex — 16 บิต ตัวแรก N เข้ารหัส UUID variant (RFC 4122, NCS, Microsoft หรือสงวนไว้)
xxxxxxxxxxxx (12)12 หลัก hex — 48 บิต

version และ variant เป็นสองฟิลด์เดียวที่รับประกันว่ามีใน UUID ทุกตัว ฟิลด์อื่นทั้งหมดขึ้นอยู่กับ version

ฟิลด์ Version

version nibble คือตัวเลข hex แรกของกลุ่มที่สาม (ตำแหน่ง 14 ใน string เต็ม) ระบุ UUID version ที่ใช้สร้าง identifier

JavaScript
const hex = uuid.replace(/-/g, '')
const version = parseInt(hex[12], 16)  // single hex digit → 1, 2, 3, 4, 5, 6, 7, or 8

Version 7 (UUID v7) คือ version ที่ใช้กันมากที่สุดที่ใหม่ที่สุด แนะนำใน RFC 9562 (2024) มันเข้ารหัส Unix millisecond timestamp ใน high bits เพื่อการเรียงลำดับ

ฟิลด์ Variant

variant เข้ารหัสใน high bits ของ byte แรกของกลุ่มที่สี่ ระบุ layout และข้อตกลง byte ordering ที่ UUID ใช้

High bitsช่วง hex แรกVariantคำอธิบาย
0xxx xxxx0x00–0x7FNCS backward compatibilityUUID ของ Network Computing System (NCS) แบบ legacy สงวนไว้เพื่อ backward compatibility
10xx xxxx0x80–0xBFRFC 4122 / RFC 9562UUID variant มาตรฐาน RFC 4122 / RFC 9562 ใช้โดย UUID version สมัยใหม่ทั้งหมด (v1–v8)
110x xxxx0xC0–0xDFMicrosoft backward compatibilityMicrosoft COM/DCOM GUID แบบ legacy ที่มี byte ordering ต่างกัน ยังพบใน Windows COM component
111x xxxx0xE0–0xFFสงวนไว้สงวนไว้สำหรับการกำหนดในอนาคต ไม่ได้ใช้โดย UUID version ปัจจุบัน

ในทางปฏิบัติ UUID ที่คุณพบเกือบทั้งหมดใช้ตัวแปร RFC 4122 / RFC 9562 (รูปแบบบิต 10xx xxxx ไบต์แรกของกลุ่มที่สี่ในช่วง 0x80–0xBF) ตัวแปร NCS, Microsoft COM และ Reserved เป็นรูปแบบเก่าที่แทบไม่พบในระบบสมัยใหม่

UUID Versions Reference

RFC 4122 กำหนด version 1–5 RFC 9562 (2024) เพิ่ม version 6, 7 และ 8:

Versionชื่อมาตรฐานคำอธิบาย
v1Time-basedRFC 4122Timestamp (Gregorian epoch, ความแม่นยำ 100ns) + MAC address เรียงลำดับต่อ host แต่รั่ว host identity
v2DCE SecurityRFC 4122อิงจาก UUID v1 โดยแทนที่ time_low field ด้วย POSIX UID/GID ไม่ค่อยใช้นอกจากระบบ DCE/RPC แบบ legacy
v3Name-based MD5RFC 4122Deterministic: MD5 hash ของ namespace UUID + name string input เดิมให้ UUID เดิมเสมอ แนะนำ v5
v4สุ่มRFC 4122ความสุ่มที่ cryptographically secure 122 บิต UUID version ทั่วไปที่พบบ่อยที่สุด
v5Name-based SHA-1RFC 4122เหมือน v3 แต่ใช้ SHA-1 ต้านทาน collision ได้ดีกว่า MD5 แนะนำมากกว่า v3 สำหรับ UUID แบบ name-based ใหม่
v6Reordered TimeRFC 9562จัดเรียง timestamp field ของ UUID v1 ใหม่ให้ UUID เรียงตามลำดับเวลา กำหนดใน RFC 9562
v7Unix TimeRFC 9562Unix millisecond timestamp 48 บิตใน high bits + ข้อมูลสุ่ม เรียงลำดับได้และเป็นมิตรกับ B-tree index แนะนำสำหรับ time-ordered ID ใหม่
v8CustomRFC 9562Free-form: บิตทั้งหมดยกเว้น version และ variant กำหนดโดย application ไม่มี generation algorithm ที่ระบุ

การถอดรหัส UUID v1 Timestamp

UUID v1 ฝัง Gregorian timestamp 60 บิต (ช่วง 100 นาโนวินาทีนับจาก 15 ตุลาคม 1582) กระจายใน สามฟิลด์: time_low (bits 0–31), time_mid (bits 32–47), และ time_hi (bits 48–59) เครื่องมือนี้ประกอบใหม่และแปลงเป็น UTC date มาตรฐาน

JavaScript
// UUID v1: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
//           ^^^^^^^^ ^^^^ ^^^^ ^^^^^ ^^^^^^^^^^^^
//           time-low  mid  hi  clk   node (MAC)
//                          ^
//                          version nibble (1)

const hex = '6ba7b8109dad11d180b400c04fd430c8'

const tLow = parseInt(hex.slice(0, 8),  16)  // 0x6ba7b810
const tMid = parseInt(hex.slice(8, 12), 16)  // 0x9dad
const tHi  = parseInt(hex.slice(13, 16), 16) // 0x1d1 (skip version nibble at index 12)

// Reconstruct 60-bit timestamp (100-ns intervals since Oct 15, 1582)
const t = (BigInt(tHi) << 48n) | (BigInt(tMid) << 32n) | BigInt(tLow)

// Subtract Gregorian offset (Oct 15, 1582 → Jan 1, 1970 in 100-ns units)
const GREGORIAN_OFFSET = 122192928000000000n
const unixMs = (t - GREGORIAN_OFFSET) / 10000n

console.log(new Date(Number(unixMs)).toISOString())
// → 1998-02-04T22:13:53.578Z
Note:ฟิลด์ clock sequence (14 บิต) ป้องกัน duplicate เมื่อ clock เดินถอยหลัง ฟิลด์ node (48 บิต) โดยทั่วไปคือ MAC address ของ host ที่สร้าง

UUID v1 ควรถือว่า sensitive: MAC address ที่ฝังและ timestamp ที่แม่นยำสามารถระบุทั้งเครื่องที่สร้างและเวลาที่สร้าง

การถอดรหัส UUID v7 Timestamp

UUID v7 ฝัง Unix millisecond timestamp 48 บิต ใน 48 บิตแรก (กลุ่มแรก + 4 หลักแรกของกลุ่มที่สอง) เครื่องมือนี้อ่าน bit เหล่านั้นและแปลงเป็น UTC date ที่มีความแม่นยำ millisecond

JavaScript
// UUID v7: 018e4bc8-1000-7000-8000-000000000001
//           ^^^^^^^^^^^^
//           48-bit Unix ms timestamp

const hex = '018e4bc8100070008000000000000001'

// First 48 bits (12 hex chars) = Unix timestamp in milliseconds
const ms = parseInt(hex.slice(0, 12), 16)  // 0x018e4bc81000

console.log(new Date(ms).toISOString())
// → 2024-03-11T…Z

// Everything after byte 6 is random (except version/variant bits)

ต่างจาก UUID v1 timestamp ของ UUID v7 ใช้ Unix epoch ที่คุ้นเคย (1 มกราคม 1970) และไม่ฝังข้อมูล host ใดๆ อีก 74 บิตที่เหลือเป็นสุ่ม

เครื่องมือนี้ตรวจจับ UUID Version และ Variant อย่างไร

decoder อ่านตำแหน่ง 14 (version nibble) และตำแหน่ง 19 (variant nibble) ของ UUID string แบบ canonical ไม่ต้องการ state หรือ context ภายนอก ข้อมูลทั้งหมดอยู่ใน UUID string เอง

JavaScript
// Detect UUID version from the 13th hex character (index 12)
function uuidVersion(uuid) {
  const clean = uuid.replace(/-/g, '')
  return parseInt(clean[12], 16)
}

uuidVersion('550e8400-e29b-41d4-a716-446655440000') // → 4
uuidVersion('018e4bc8-1000-7000-8000-000000000001') // → 7
uuidVersion('6ba7b810-9dad-11d1-80b4-00c04fd430c8') // → 1

// Detect variant from the 17th hex character (index 16, first char of 4th group)
function uuidVariant(uuid) {
  const clean = uuid.replace(/-/g, '')
  const b = parseInt(clean[16], 16)
  if ((b & 0x8) === 0)      return 'NCS'
  if ((b & 0xC) === 0x8)    return 'RFC 4122'
  if ((b & 0xE) === 0xC)    return 'Microsoft'
  return 'Reserved'
}

UUID พิเศษ

Nil UUID

Nil UUID 00000000-0000-0000-0000-000000000000 คือศูนย์ทั้งหมด RFC 4122 กำหนดให้เป็นค่า sentinel ที่หมายความว่า 'ไม่มี UUID' — คล้าย null มันไม่ใช่ UUID ที่สร้างแบบสุ่ม

Max UUID

Max UUID ffffffff-ffff-ffff-ffff-ffffffffffff คือหนึ่งทั้งหมด (0xFF ในทุก byte) กำหนดใน RFC 9562 เป็นส่วนเสริมของ Nil UUID และเป็นค่า sentinel สูงสุด

คำถามที่พบบ่อย

รู้ได้อย่างไรว่า UUID เป็น version ใด?
ดูตำแหน่ง 14 ใน UUID string แบบ canonical (ตัวอักษรแรกของกลุ่มที่สามที่คั่นด้วยขีดกลาง) หลัก hex เดียวนั้นคือ version number: 1, 2, 3, 4, 5, 6, 7 หรือ 8 วาง UUID ลงในเครื่องมือนี้และมันจะถอดรหัส version ให้คุณ
สามารถถอดรหัส UUID เพื่อกู้คืนข้อมูลดั้งเดิมได้ไหม?
ขึ้นอยู่กับ version UUID v1 และ v7 ฝัง timestamp ที่กู้คืนได้ทั้งหมด UUID v1 ยังฝัง MAC address ด้วย UUID v3 และ v5 เป็น one-way hash — คุณไม่สามารถกู้คืน name ดั้งเดิมจาก UUID UUID v4 เป็นสุ่มล้วน — ไม่มีอะไรที่จะกู้คืน
'variant' ใน UUID หมายความว่าอะไร?
ฟิลด์ variant ระบุ byte layout และข้อตกลงการตีความของ UUID UUID เกือบทั้งหมดที่คุณพบจะมี RFC 4122 variant (high bits 10) เข้ารหัสเป็น hex digit 8, 9, a หรือ b ในตำแหน่ง 19 Variant อื่นๆ (NCS, Microsoft) เป็นรูปแบบ legacy จากทศวรรษ 1990
ทำไม UUID บางตัวถึงดูต่างจากตัวอื่น?
ความแตกต่างทางภาพอยู่ที่ version nibble (ตำแหน่ง 14) และ variant nibble (ตำแหน่ง 19) เช่น UUID v4 มี 4 ที่ตำแหน่ง 14 เสมอ ในขณะที่ UUID v7 มี 7 เสมอ ภายในข้อจำกัดเหล่านั้น หลักที่เหลือเป็นสุ่มหรือได้จาก timestamp ขึ้นอยู่กับ version
Nil UUID เหมือน empty UUID ไหม?
ตามแนวคิดใช่ — Nil UUID (ศูนย์ทั้งหมด) ใช้แทนการขาดหาย UUID คล้าย null มันไม่ใช่ UUID ที่สร้างแบบสุ่มและไม่ควรเก็บเป็น identifier จริง บางระบบใช้เป็นค่าเริ่มต้นหรือ placeholder
UUID จะ invalid ได้ไหม?
UUID สามารถ valid ทาง syntax (รูปแบบถูกต้อง) แต่ผิดปกติทาง semantic เช่น มี version nibble เป็น 0 หรือ variant เป็น 11x (สงวนไว้) Nil UUID และ Max UUID valid ทาง syntax แต่เป็นค่า sentinel เครื่องมือนี้จะแสดง version และ variant nibble ใดๆ ที่มีอยู่และ flag version ที่ไม่รู้จัก
UUID กับ GUID ต่างกันอย่างไร?
GUID (Globally Unique Identifier) คือชื่อ Microsoft สำหรับแนวคิดเดียวกัน GUID ตาม RFC 4122 รูปแบบ 128 บิตเดิม ความแตกต่างในทางปฏิบัติเดียวคือ Microsoft GUID แบบ legacy อาจใช้ Microsoft variant (high bits 110) แทน RFC 4122 variant — ซึ่งกระทบ byte ordering ในการแสดงผลแบบ binary การแสดงผลแบบ text เหมือนกัน

เครื่องมือที่เกี่ยวข้อง