เครื่องมือ UUID ของ ToolDeck ครอบคลุมรูปแบบตัวระบุเฉพาะหลักทุกรูปแบบในที่เดียว คอลเลกชันประกอบด้วย: ตัวสร้าง UUID v4 สำหรับ ID แบบสุ่มที่มีความแข็งแกร่งทางการเข้ารหัส; ตัวสร้าง UUID v7 สำหรับคีย์หลักที่เรียงลำดับตาม timestamp ได้; ตัวสร้าง UUID v1 สำหรับตัวระบุที่ใช้เวลาและ MAC address; ตัวสร้าง UUID v2 สำหรับระบบ DCE รุ่นเก่า; ตัวสร้าง UUID v3 สำหรับ ID แบบกำหนดตายตัวบน MD5; ตัวสร้าง ULID สำหรับสตริงขนาดกะทัดรัดที่เรียงลำดับได้; ตัวสร้าง NanoID สำหรับ token สั้นที่ปลอดภัยสำหรับ URL; ตัวสร้าง CUID สำหรับรูปแบบดั้งเดิมที่ต้านทานการชนกัน; ตัวสร้าง CUID2 สำหรับรุ่นสืบทอดสมัยใหม่; และตัวถอดรหัส UUID สำหรับตรวจสอบตัวระบุที่มีอยู่ เครื่องมือทั้งหมดทำงานในเบราว์เซอร์ของคุณอย่างสมบูรณ์โดยใช้ Web Crypto API — ไม่มีข้อมูลถูกส่งไปยังเซิร์ฟเวอร์ใด ไม่ต้องมีบัญชี
เครื่องมือ UUID และ ID เฉพาะคืออะไร?
UUID (Universally Unique Identifier) คือตัวระบุขนาด 128 บิตที่ถูกมาตรฐานไว้ใน RFC 9562 (เดิมคือ RFC 4122) เขียนเป็นอักขระเลขฐานสิบหก 32 ตัวในรูปแบบ 8-4-4-4-12 UUID มีลักษณะดังนี้: 550e8400-e29b-41d4-a716-446655440000 มาตรฐานกำหนดหลายเวอร์ชัน แต่ละเวอร์ชันใช้กลยุทธ์ที่แตกต่างกันเพื่อรับประกันความเป็นเอกลักษณ์: ตัวเลขสุ่ม, timestamps หรือการแฮชแบบกำหนดตายตัว
UUID ถูกออกแบบเพื่อให้ระบบแบบกระจายสร้างตัวระบุโดยไม่ต้องมีตัวประสานงานกลาง ไม่ว่าคุณจะกำหนดคีย์หลักใน PostgreSQL, สร้าง session token ในเว็บแอป หรือตั้งชื่อไฟล์ใน object storage — UUID ช่วยให้ทุกโหนดในระบบของคุณสร้าง ID ที่เป็นเอกลักษณ์ทั่วโลกได้อย่างอิสระ โดยมีความน่าจะเป็นของการชนกันต่ำจนละเลยได้ในทางปฏิบัติ
นอกเหนือจากมาตรฐาน UUID รูปแบบ ID เฉพาะทางเลือกหลายรูปแบบได้ปรากฏขึ้นเพื่อแก้ปัญหาข้อจำกัดเฉพาะ: ULID และ UUID v7 เพิ่มความสามารถในการเรียงลำดับตามพจนานุกรมเพื่อประสิทธิภาพการจัดทำดัชนีฐานข้อมูล; NanoID ลดขนาดสำหรับ URL และคุกกี้; CUID2 ให้ความสำคัญกับการต้านทานการชนกันตาม fingerprint สำหรับการสร้างในปริมาณมากฝั่งไคลเอนต์
ทำไมต้องใช้เครื่องมือ UUID บน ToolDeck?
เครื่องมือ UUID ของ ToolDeck ทำงานในเบราว์เซอร์ของคุณอย่างสมบูรณ์ ไม่มีการเรียก API ไม่มีการประมวลผลฝั่งเซิร์ฟเวอร์ ไม่มีการบันทึกข้อมูล ตัวสร้างแต่ละตัวใช้ Web Crypto API (crypto.getRandomValues) สำหรับ entropy ที่แข็งแกร่งทางการเข้ารหัส — แหล่งเดียวกับที่เบราว์เซอร์ใช้สำหรับวัสดุคีย์ TLS
🔐Entropy ที่แข็งแกร่งทางการเข้ารหัส
ตัวสร้างทุกตัวที่ใช้การสุ่ม (UUID v4, NanoID, CUID2) ใช้ crypto.getRandomValues ไม่ใช่ Math.random ผลลัพธ์เหมาะสำหรับกรณีใช้งานที่ไวต่อความปลอดภัย เช่น session token และ API key
📦รูปแบบ ID หลักทั้งหมดในที่เดียว
UUID v1 ถึง v7, ULID, NanoID, CUID และ CUID2 — ทุกรูปแบบที่นักพัฒนาต้องการ พร้อมตัวเลือกการสร้างจำนวนมากและคัดลอกด้วยคลิกเดียว
🔍ถอดรหัสและตรวจสอบ ID ที่มีอยู่
ตัวถอดรหัส UUID แยกเวอร์ชัน, variant, timestamp และฟิลด์โหนดจาก UUID ใด ๆ มีประโยชน์สำหรับการดีบัก, การตรวจสอบ และการทำความเข้าใจ ID รุ่นเก่าในโค้ดเบสของคุณ
⚡ไม่ต้องตั้งค่า ทำงานออฟไลน์ได้
ไม่ต้องติดตั้ง ไม่ต้องสมัคร ไม่มี dependency ที่ต้องทำงาน เปิดหน้าและสร้างได้เลย เครื่องมือทั้งหมดทำงานออฟไลน์ได้หลังจากโหลดหน้าแล้ว — มีประโยชน์ในสภาพแวดล้อมที่แยกออกจากเครือข่ายหรือเครือข่ายที่ถูกจำกัด
กรณีใช้งานเครื่องมือ UUID
ตัวระบุเฉพาะปรากฏในทุกชั้นของ stack นี่คือวิธีที่บทบาทต่าง ๆ ใช้เครื่องมือสร้าง UUID:
คีย์หลักของฐานข้อมูล
วิศวกร backend กำหนด UUID v4 หรือ UUID v7 เป็นคีย์หลักใน PostgreSQL, MySQL และ MongoDB prefix timestamp ของ UUID v7 ทำให้แถวเรียงลำดับทางกายภาพบนดิสก์ หลีกเลี่ยงการแบ่งหน้าในงานที่มีการแทรกหนัก
State Frontend และ ID Component
นักพัฒนา frontend ใช้ NanoID หรือ UUID v4 เพื่อสร้าง React key ที่เสถียรสำหรับรายการในรายการที่สร้างแบบไดนามิก, dialog ID สำหรับแอตทริบิวต์การเข้าถึง ARIA และ idempotency token สำหรับการส่งแบบฟอร์ม
Distributed Event Stream
ในระบบที่ขับเคลื่อนด้วย event แต่ละ event ต้องการ ID ที่เป็นเอกลักษณ์ทั่วโลกและเรียงลำดับได้ วิศวกร DevOps และแพลตฟอร์มใช้ ULID หรือ UUID v7 เพื่อให้ Kafka consumer, log aggregator และ audit trail เรียงลำดับตามเวลาสร้างได้โดยไม่ต้องใช้ฟิลด์ timestamp สำรอง
การสร้างข้อมูลทดสอบ
วิศวกร QA สร้าง UUID batch จำนวนมากเพื่อเติมฐานข้อมูลทดสอบด้วย ID ที่สมจริงและไม่เรียงลำดับ UUID v3 หรือ v5 แบบกำหนดตายตัวช่วยให้พวกเขาสร้าง ID เดิมซ้ำจากอินพุตที่ทราบ — มีประโยชน์สำหรับ test fixture ที่ทำซ้ำได้
Correlation ID ใน Microservice
การแนบ UUID กับทุก HTTP request ที่เข้ามาและส่งต่อผ่านการเรียก service (header X-Request-ID) ช่วยให้ระบบ distributed tracing เชื่อมโยง log ข้าม service ได้ UUID v4 คือมาตรฐาน de facto สำหรับการเชื่อมโยง request
การตั้งชื่อทรัพยากรและสินทรัพย์
คีย์ใน object storage (S3, GCS, Cloudflare R2) และชื่อไฟล์สินทรัพย์ CDN มักฝัง UUID เพื่อป้องกันการชนกันของ cache และการเดา URL รูปแบบขนาดกะทัดรัด 21 อักขระของ NanoID ลดความยาว URL เมื่อเทียบกับ UUID แบบเต็ม 36 อักขระ
เอกสารอ้างอิงเวอร์ชันและรูปแบบ UUID
ตารางด้านล่างเปรียบเทียบเวอร์ชัน UUID ทั้งหมดกับทางเลือกที่ใช้กันมากที่สุด ใช้เพื่อระบุรูปแบบที่เหมาะกับความต้องการของคุณอย่างรวดเร็ว
| ตัวระบุ | อัลกอริทึม | เรียงลำดับได้ | กำหนดตายตัว | เหมาะที่สุดสำหรับ |
|---|
| UUID v4 | สุ่ม (CSPRNG) | — | — | ID ทั่วไป, session token, คีย์หลัก |
| UUID v7 | Unix timestamp มิลลิวินาที + สุ่ม | ✓ | — | คีย์หลักที่เรียงลำดับได้, ID เหตุการณ์แบบกระจาย (RFC 9562) |
| UUID v1 | Timestamp + MAC address | ✓ | — | ID เรียงตามเวลา, ระบบโหนดเดียว, ความเข้ากันได้กับระบบเก่า |
| UUID v3 | Namespace + ชื่อ + MD5 | — | ✓ | ID ที่ทำซ้ำได้จากอินพุตที่ทราบ (DNS, URL) |
| UUID v5 | Namespace + ชื่อ + SHA-1 | — | ✓ | เหมือน v3 แต่ hash แข็งแกร่งกว่า; ควรใช้ v5 แทน v3 |
| UUID v2 | Timestamp + DCE UID/GID | ✓ | — | สภาพแวดล้อม POSIX/DCE รุ่นเก่า; หลีกเลี่ยงสำหรับโปรเจกต์ใหม่ |
| ULID | Timestamp prefix + สุ่ม | ✓ | — | ID ที่เรียงลำดับได้, ปลอดภัยสำหรับ URL, ไม่มีขีดกลาง (26 อักขระ) |
| NanoID | สุ่ม (CSPRNG), อักขรชุดที่ปลอดภัยสำหรับ URL | — | — | ID สั้นสำหรับ URL, คุกกี้, แอตทริบิวต์ HTML (21 อักขระ) |
| CUID2 | Fingerprint + timestamp + สุ่ม | — | — | การสร้างฝั่งไคลเอนต์ปริมาณมาก, ต้านทานการชนกัน |
UUID v3 และ v5 เป็นแบบกำหนดตายตัว: namespace + ชื่อเดิมมักให้ UUID เดิมเสมอ รูปแบบอื่น ๆ ทั้งหมดสร้างค่าใหม่ในทุกการเรียกใช้
วิธีเลือกเครื่องมือ UUID ที่เหมาะสม
ตัวระบุที่เหมาะสมขึ้นอยู่กับความต้องการด้านการเรียงลำดับ ขนาด และความกำหนดตายตัวของคุณ ใช้คู่มือการตัดสินใจนี้:
- 1
หาก คุณต้องการ ID เฉพาะทั่วไปโดยไม่มีข้อกำหนดพิเศษ → เครื่องสร้าง UUID v4 - 2
หาก คุณต้องการ ID ที่เรียงลำดับตามลำดับเวลาและเข้ากันได้กับมาตรฐาน UUID → เครื่องสร้าง UUID v7 - 3
หาก คุณต้องการ ID ที่เรียงตามเวลาพร้อม timestamp ในตัวสำหรับระบบโหนดเดียวหรือที่มีการทำงานพร้อมกันต่ำ → เครื่องสร้าง UUID v1 - 4
หาก คุณต้องการ ID ที่เรียงลำดับได้ ปลอดภัยสำหรับ URL และไม่มีขีดกลาง → เครื่องสร้าง ULID - 5
หาก คุณต้องการ ID ขนาดกะทัดรัดที่ปลอดภัยสำหรับ URL และสั้นกว่า UUID แบบเต็ม → เครื่องสร้าง NanoID - 6
หาก คุณกำลังสร้าง ID จำนวนมากฝั่งไคลเอนต์และต้องการการต้านทานการชนกันที่แข็งแกร่ง → เครื่องสร้าง CUID2 - 7
หาก คุณต้องการรูปแบบ CUID v1 เพื่อความเข้ากันได้กับระบบที่มีอยู่ที่สร้างบน spec ดั้งเดิม → เครื่องสร้าง CUID - 8
หาก คุณต้องสร้าง ID เดิมซ้ำแบบกำหนดตายตัวจาก namespace และชื่อ → เครื่องสร้าง UUID v3 - 9
หาก คุณกำลังทำงานกับระบบ DCE หรือ POSIX รุ่นเก่าที่ต้องการตัวระบุ v2 → เครื่องสร้าง UUID v2 - 10
หาก คุณมี UUID ที่มีอยู่และต้องการตรวจสอบเวอร์ชัน, variant หรือ timestamp ของมัน → ตัวถอดรหัส UUID
ทั้ง UUID v7 และ ULID มี timestamp prefix ที่มีความแม่นยำระดับมิลลิวินาทีและความสามารถในการเรียงลำดับตามพจนานุกรม ความแตกต่างหลัก: UUID v7 ใช้รูปแบบ UUID มาตรฐาน (8-4-4-4-12, 36 อักขระ) เพื่อความเข้ากันได้สูงสุดกับ ecosystem ในขณะที่ ULID ใช้การเข้ารหัส Base32 แบบกำหนดเอง (26 อักขระ, ปลอดภัยสำหรับ URL, ไม่มีขีดกลาง) หากฐานข้อมูล ORM หรือ framework ของคุณรองรับคอลัมน์ UUID โดยตรง ให้ใช้ UUID v7 หากคุณต้องการ ID ที่สั้นกว่าโดยไม่มีข้อจำกัดของ framework ULID จะกะทัดรัดกว่า
คำถามที่พบบ่อย
UUID คืออะไร?
UUID (Universally Unique Identifier) คือค่า 128 บิตที่กำหนดมาตรฐานใน RFC 9562 เขียนเป็นตัวเลขฐานสิบหก 32 หลักในห้ากลุ่มที่คั่นด้วยขีดกลาง: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx มาตรฐานกำหนดหลายเวอร์ชันที่มีกลยุทธ์ความเป็นเอกลักษณ์ต่างกัน — สุ่ม (v4), อิงตาม timestamp (v1, v7) หรือกำหนดตายตัวตามชื่อ (v3, v5)
UUID v4 และ UUID v7 ต่างกันอย่างไร?
UUID v4 เติมบิตที่ไม่ตายตัวทั้ง 122 บิตด้วยข้อมูลสุ่มจากแหล่งที่ปลอดภัยทางการเข้ารหัส UUID v7 เข้ารหัส Unix timestamp 48 บิตในหน่วยมิลลิวินาทีใน 48 บิตแรก ตามด้วยบิตสุ่ม ผลลัพธ์: UUID v7 เรียงลำดับตามลำดับเวลาในรูปแบบสตริงธรรมดา ซึ่งทำให้ดัชนี B-tree ของฐานข้อมูลเรียงลำดับอยู่เมื่อมีการแทรก UUID v7 ถูกเพิ่มใน RFC 9562 (เมษายน 2024) และเป็นตัวเลือกที่แนะนำสำหรับคีย์หลักฐานข้อมูลใหม่
ค่า UUID v4 ปลอดภัยทางการเข้ารหัสหรือไม่?
ค่า UUID v4 ถูกสร้างโดยใช้ตัวสร้างตัวเลขสุ่มเทียมที่ปลอดภัยทางการเข้ารหัส (CSPRNG) เหมาะสำหรับใช้เป็น token ที่ไม่สามารถเดาได้ — session ID, ลิงก์รีเซ็ตรหัสผ่าน และอื่น ๆ อย่างไรก็ตาม UUID ไม่ใช่ความลับในตัวเอง: ไม่มี HMAC, ไม่มีวันหมดอายุ และไม่ผูกกับผู้ใช้เฉพาะ ให้ถือ UUID เป็นตัวระบุที่ไม่โปร่งใส ไม่ใช่ข้อมูลรับรองการพิสูจน์ตัวตน
ระบบสองระบบที่ต่างกันสามารถสร้าง UUID เดียวกันได้หรือไม่?
ความน่าจะเป็นในการชนกันของ UUID v4 อยู่ที่ประมาณ 1 ใน 2^122 ต่อคู่ เพื่อให้มีโอกาส 50% ของการชนกัน คุณต้องสร้าง UUID ประมาณ 2.7 × 10^18 ตัว — มากกว่าที่ระบบจริงใด ๆ ผลิตได้มาก UUID v1 และ v7 ยังฝัง timestamp และ/หรือบิตสุ่มเพิ่มเติม ทำให้การชนกันโดยบังเอิญน่าจะเกิดขึ้นน้อยกว่าเดิม สำหรับวัตถุประสงค์ทางปฏิบัติทั้งหมด UUID จากระบบที่แยกจากกันจะไม่ชนกัน
ทำไม UUID ถึงมี 36 อักขระ?
UUID มี 128 บิต = 16 ไบต์ เมื่อเข้ารหัสเป็นเลขฐานสิบหก จะได้ 32 อักขระ รูปแบบ UUID เพิ่มขีดกลาง 4 ตัวที่ตำแหน่งคงที่ (หลังกลุ่ม 8, 4, 4 และ 4 หลักเลขฐานสิบหก) เพื่อปรับปรุงความอ่านง่ายและทำให้บิตเวอร์ชันและ variant มองเห็นได้ง่ายทางสายตา รวมเป็นทั้งหมด 36 อักขระ ขีดกลางไม่มีข้อมูลในตัว
ULID คืออะไรและต่างจาก UUID อย่างไร?
ULID (Universally Unique Lexicographically Sortable Identifier) คือตัวระบุ 128 บิตที่เข้ารหัสใน Crockford Base32 (26 อักขระ, ไม่แยกพิมพ์เล็ก/ใหญ่, ไม่มีขีดกลาง) 48 บิตแรกเข้ารหัสเวลา Unix ในมิลลิวินาที; 80 บิตที่เหลือเป็นแบบสุ่ม ULID เรียงลำดับได้อย่างถูกต้องในรูปแบบสตริงธรรมดาและกะทัดรัดกว่า UUID ไม่ใช่ส่วนหนึ่งของ RFC UUID — ใช้การเข้ารหัสที่แตกต่างและขาดฟิลด์เวอร์ชัน/variant ของ UUID
ควรใช้ UUID หรือเลขจำนวนเต็มที่เพิ่มอัตโนมัติเป็นคีย์หลัก?
เลขจำนวนเต็มที่เพิ่มอัตโนมัติเป็นลำดับ กะทัดรัด และเป็นมิตรกับดัชนี แต่ต้องการตัวประสานงานกลาง (ฐานข้อมูล) ในการกำหนด — ซึ่งล้มเหลวในระบบแบบกระจายและเปิดเผยจำนวนแถว UUID (โดยเฉพาะ v7 หรือ ULID) สามารถสร้างได้ฝั่งไคลเอนต์โดยไม่ต้องเดินทางไปฐานข้อมูล ทำให้สามารถแทรกแบบ optimistic และเขียนแบบกระจายได้ การแลกเปลี่ยนคือพื้นที่จัดเก็บ (16 ไบต์เทียบกับ 4–8 ไบต์) และตำแหน่งดัชนีที่ต่ำกว่าเล็กน้อยสำหรับ UUID แบบสุ่ม (v4) UUID v7 และ ULID แก้ปัญหาตำแหน่งดัชนีด้วยการใช้ timestamp prefix
UUID v3 และ UUID v5 ต่างกันอย่างไร?
ทั้ง UUID v3 และ v5 เป็นแบบกำหนดตายตัว: จะสร้าง UUID เดิมเสมอสำหรับคู่ namespace + ชื่อเดิม ทำให้มีประโยชน์ในการสร้าง ID ที่ทำซ้ำได้สำหรับสิ่งต่าง ๆ เช่น DNS entries, URL หรือตัวระบุวัตถุ ความแตกต่างเดียวคืออัลกอริทึม hash: v3 ใช้ MD5 (128 บิต, รุ่นเก่า), v5 ใช้ SHA-1 (160 บิต, ตัดให้เหลือ 128 บิต) ควรใช้ UUID v5 สำหรับโปรเจกต์ใหม่ — SHA-1 แข็งแกร่งกว่า MD5 แม้ว่าจะไม่มีเวอร์ชันใดที่ใช้เป็น cryptographic hash