เครื่องสร้าง UUID v4

สร้าง UUID v4 แบบสุ่มที่ปลอดภัยด้านการเข้ารหัส

…

จัดรูปแบบ

จำนวน:

ลองดูด้วย:เครื่องสร้าง UUID v1 เครื่องสร้าง UUID v7 เครื่องสร้าง UUID v3 เครื่องสร้าง UUID v2 เครื่องสร้าง ULID เครื่องสร้าง NanoID เครื่องสร้าง CUID เครื่องสร้าง CUID2 ตัวถอดรหัส UUID

UUID v4 เป็น UUID version ที่ถูกใช้งานแพร่หลายที่สุดในซอฟต์แวร์สมัยใหม่ ต่างจาก version อื่นที่สร้างบิตจาก timestamp หรือ namespace hash UUID v4 สร้างจากข้อมูลสุ่มล้วน ทำให้เป็นตัวเลือกที่ง่ายและพกพาสะดวกที่สุดเมื่อต้องการ identifier ที่ไม่มี metadata เกี่ยวกับแหล่งกำเนิด

เครื่องมือนี้ใช้ crypto.randomUUID() ซึ่งเป็น API ดั้งเดิมของเบราว์เซอร์และ Node.js ที่รับ entropy จาก cryptographically secure random number generator ของระบบปฏิบัติการ ซึ่งเป็นแหล่งเดียวกับที่ใช้สำหรับ TLS key material

UUID v4 คืออะไร?

Universally Unique Identifier (UUID) คือ label 128 บิต ที่กำหนดมาตรฐานใน RFC 4122 โดยทั่วไปแสดงเป็นตัวเลข hexadecimal 32 หลักจัดกลุ่มด้วยขีดกลางในรูปแบบ 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000

ใน UUID v4 122 จาก 128 บิตเป็นค่าสุ่ม อีก 6 บิตที่เหลือเป็น fixed field ตามที่ spec กำหนด: 4 บิตระบุ version (0100 = 4) และ 2 บิตระบุ RFC 4122 variant (10) เพราะบิตที่ fixed เหล่านี้ กลุ่มที่สามจึงเริ่มด้วย 4 เสมอ และกลุ่มที่สี่เริ่มด้วย 8, 9, a, หรือ b เสมอ

โครงสร้างของ UUID v4

การแยกส่วน 550e8400-e29b-41d4-a716-446655440000:

เซกเมนต์	บิต	ความหมาย
550e8400	32 สุ่ม	time_low (ชื่อเป็น historical — สุ่มทั้งหมดใน v4)
e29b	16 สุ่ม	time_mid (ชื่อ historical — สุ่มทั้งหมดใน v4)
41d4	4 fixed + 12 สุ่ม	Version nibble `4` (binary `0100`) + 12 บิตสุ่ม
a716	2 fixed + 14 สุ่ม	Variant bits `10` (MSBs ของ byte แรก) + 14 บิตสุ่ม
446655440000	48 สุ่ม	node (สุ่มทั้งหมดใน v4)

Note:Variant nibble ที่ต้นกลุ่มที่สี่จะเป็นหนึ่งใน 8, 9, a, หรือ b เสมอ เนื่องจากสองบิตสูงของ byte นั้น fixed เป็น 10 (RFC 4122 variant marker) เหลือสองบิตล่างให้แปรผันได้

UUID v4 vs Version อื่น

RFC 4122 กำหนด UUID version ห้า version แต่ละ version แก้ปัญหาต่างกัน:

UUID v1Timestamp + MAC

รวม timestamp 60 บิต (ช่วง 100 นาโนวินาทีนับจาก ต.ค. 1582) กับ MAC address ของ host เพิ่มขึ้นเรื่อยๆ ภายในเครื่องเดียวกัน

Use when: คุณต้องการ ID ที่เรียงตามเวลาและยอมรับการรั่วไหลของ server identity และเวลาที่สร้าง

UUID v3MD5 hash

Deterministic: namespace + name เดิมจะได้ UUID เดิมเสมอ ใช้ MD5 hashing

Use when: คุณต้องการ ID ที่สร้างซ้ำได้จาก namespace ที่รู้จัก (เช่น DNS names) แนะนำให้ใช้ v5 แทน v3

UUID v4สุ่ม

ความสุ่มที่ cryptographically secure 122 บิต ไม่มี timestamp, MAC หรือ namespace เป็นตัวเลือกทั่วไปที่พบบ่อยที่สุด

Use when: คุณต้องการ ID ที่ไม่มีความหมายเชิงโครงสร้างและมีความเป็นส่วนตัวสูงสุด

UUID v5SHA-1 hash

เหมือน v3 แต่ใช้ SHA-1 ยังคงเป็น deterministic จาก namespace + name

Use when: คุณต้องการ identifier ที่สร้างซ้ำได้และอ้างอิงเนื้อหา (เช่น stable ID สำหรับ resource ที่ระบุด้วย URL)

UUID v7สุ่มเรียงตามเวลา

ใหม่กว่า (RFC 9562, 2024) เข้ารหัส Unix millisecond timestamp ใน high bits ตามด้วย random bits เรียงลำดับได้และเป็นมิตรกับฐานข้อมูล

Use when: คุณต้องการ ID ที่เป็นมิตรกับ database index พร้อม time ordering ตามธรรมชาติ (แนะนำแทน v1 สำหรับโปรเจกต์ใหม่)

เมื่อไรควรใช้ UUID v4

UUID v4 เป็นตัวเลือกที่ถูกต้องในกรณีส่วนใหญ่ที่ต้องการ 'ID ที่ไม่ซ้ำ' โดยไม่มีข้อจำกัดเพิ่มเติม:

User และ account ID

User ID ที่ทึบแสงซึ่งไม่เปิดเผยเวลาสร้าง account หรือ server identity ไม่สามารถระบุหรือเดาได้

Primary key ของฐานข้อมูล

ใช้ได้กับทุก database engine UUID v4 ปลอดภัยที่จะสร้าง client-side และรวมจากแหล่งแบบ distributed โดยไม่ต้องประสานงาน ไม่ต้องใช้ sequence table หรือ central ID service

Session และ token ID

ความสุ่ม 122 บิตทำให้การ brute-force เดาไม่ได้ในทางปฏิบัติ เทียบเท่าความแข็งแกร่งของ random token 122 บิต

ชื่อไฟล์และ object

ชื่อไฟล์ที่ปลอดภัยจาก deduplication สำหรับ upload, S3 object key หรือ cache entry ไม่มีความเสี่ยงที่ client สองตัวจะเขียนไปที่ key เดียวกัน

คีย์ Idempotency

สร้าง UUID บน client ก่อน submit request server สามารถ deduplicate request ที่ retry ได้อย่างปลอดภัยโดยไม่ต้องใช้ counter ร่วม

Correlation และ trace ID

แนบ UUID กับทุก log line และ distributed trace span ไม่ต้องประสานงานระหว่าง service หรือเครื่อง

Note:หากกรณีการใช้งานของคุณต้องการ ID ที่ เรียงลำดับได้ (เช่น ต้องการให้ row ในฐานข้อมูล cluster ตามเวลาที่ insert) ควรพิจารณา UUID v7 แทน UUID v4 เป็นแบบสุ่มโดยตั้งใจและจะทำให้ index แตกกระจายใน B-tree index เมื่อ insert อัตราสูง

ความน่าจะเป็นของ Collision

ด้วย 122 บิตสุ่ม ช่วง UUID v4 มีค่าที่เป็นไปได้ 2¹²² ≈ 5.3 × 10³⁶ ค่า ความน่าจะเป็นของ collision ตาม birthday problem:

UUID ที่สร้างความน่าจะเป็นของ collision

1 พันล้าน (10⁹)~1 ใน 5.3 × 10¹⁸

1 ล้านล้าน (10¹²)~1 ใน 5.3 × 10¹²

10¹⁸ (ประมาณ 1 exabyte)~1 ใน 5,300

เกณฑ์ที่อ้างอิงกันบ่อย: เพื่อให้มีโอกาส 50% ของ collision เดียว ต้องสร้าง UUID ประมาณ 2.71 × 10¹⁸ UUIDs ที่อัตรา 1 พันล้าน UUID ต่อวินาที จะใช้เวลาประมาณ 85 ปี ของการสร้างอย่างต่อเนื่อง สำหรับแอปพลิเคชันจริงใดๆ collision ไม่ใช่ข้อกังวลในทางปฏิบัติ

ตัวอย่างโค้ด

JavaScript — Browser และ Node.js 14.17+

Method crypto.randomUUID() ใช้ได้ในเบราว์เซอร์สมัยใหม่ทุกตัว (Chrome 92+, Firefox 95+, Safari 15.4+) และใน Node.js 14.17+ ไม่ต้องติดตั้ง package

// 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 — version เก่า (uuid package)

const { v4: uuidv4 } = require('uuid')

const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"

Python

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

toml

# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }

rust

use uuid::Uuid;

let id = Uuid::new_v4().to_string();
// → "110e8400-e29b-41d4-a716-446655440000"

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

UUID v4 มีความปลอดภัยทางการเข้ารหัสหรือไม่?

UUID v4 เองไม่ใช่ security primitive มันเป็นรูปแบบ identifier อย่างไรก็ตาม เมื่อสร้างผ่าน crypto.randomUUID() (เบราว์เซอร์หรือ Node.js) หรือ OS-level API ที่เทียบเท่า entropy ที่ใช้จะมีความปลอดภัยทางการเข้ารหัส ซึ่งหมายความว่า UUID v4 เหมาะสำหรับใช้เป็น session token หรือ idempotency key ที่ต้องการความไม่สามารถคาดเดาได้ อย่าใช้ UUID generator แบบ Math.random() สำหรับบริบทที่ sensitive ด้านความปลอดภัย ใช้เฉพาะ API ที่ดึงจาก OS CSPRNG อย่างชัดเจน

UUID v4 สองตัวจะเท่ากันได้ไหม?

ในทางทฤษฎีใช่ แต่ในทางปฏิบัติไม่ ความน่าจะเป็นของการสร้าง duplicate ในชุดข้อมูลจริงใดๆ (พันล้าน ID) นั้นเล็กมากจนเทียบไม่ได้ ซึ่งน้อยกว่าโอกาสที่ hardware จะเสียหายและทำให้ข้อมูลเสีย ปัญหา UUID v4 collision ถือว่าเป็นไปไม่ได้ในการออกแบบระบบ production หากต้องการรับประกันว่าจะไม่ collision อย่างแน่นอน ให้ใช้ counter แบบรวมศูนย์หรือ database sequence แทน

UUID v4 vs nanoid — ควรใช้อันไหน?

ทั้งคู่เป็น random ID generator ที่ใช้ CSPRNG ความแตกต่างหลัก:

UUID v4 ตาม RFC 4122 standard ได้รับการยอมรับจากทุก database และ framework และไม่ต้องการ dependency (native crypto.randomUUID())
nanoid ใช้ alphabet ที่ URL-safe และสั้นกว่าตามค่าเริ่มต้น (21 ตัวอักษร vs 36) มีประโยชน์เมื่อความยาว URL หรือความอ่านง่ายสำคัญ ต้องการ npm package

เลือก UUID v4 เมื่อความสามารถทำงานร่วมกับระบบภายนอกสำคัญ (API, ฐานข้อมูล, โครงสร้างพื้นฐาน logging) เลือก nanoid เมื่อต้องการ ID ที่สั้นกว่าและควบคุม stack ทั้งหมด

ควรเก็บ UUID เป็น string หรือ binary ในฐานข้อมูล?

สำหรับฐานข้อมูลส่วนใหญ่ การเก็บเป็น column UUID หรือ BINARY(16) (16 bytes) มีประสิทธิภาพมากกว่า string VARCHAR(36) (36 bytes) PostgreSQL มีประเภท uuid แบบ native MySQL และ MariaDB ทำงานได้ดีกับ BINARY(16) และ helper UUID_TO_BIN() / BIN_TO_UUID() ผู้ใช้ SQLite มักเก็บเป็น TEXT ตัวเลือกการจัดเก็บไม่มีผลต่อความเป็นเอกลักษณ์หรือความถูกต้อง

ทำไม UUID v4 ถึงมีขีดกลาง และสามารถละเว้นได้ไหม?

ขีดกลางเป็นส่วนหนึ่งของการแสดง UUID แบบ canonical ที่กำหนดโดย RFC 4122 มันเป็นเพียงการแสดงผล ไม่มีข้อมูลและไม่กระทบค่า 128 บิต การละเว้นจะได้ string hex ขนาด 32 ตัวอักษรที่กระชับซึ่งทำงานเทียบเท่ากัน UUID parser ส่วนใหญ่รับทั้งสองรูปแบบ หากไม่แน่ใจให้ใช้รูปแบบ canonical พร้อมขีดกลางเพื่อความเข้ากันได้สูงสุดกับเครื่องมือและฐานข้อมูลของบุคคลที่สาม

const id = crypto.randomUUID()              // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '')     // "550e8400e29b41d4a716446655440000"

คู่มือภาษา

สร้าง UUID v4 ด้วย Python

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