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

UUID v4 Generator: ตัวสร้างรหัสระบุเฉพาะแบบสุ่ม 122 บิต

หน้านี้สร้างรหัส UUID เวอร์ชัน 4 ซึ่งเป็นสตริงสุ่มขนาด 36 ตัวอักษรในรูปแบบมาตรฐาน 8‑4‑4‑4‑12 (เช่น 550e8400-e29b-41d4-a716-446655440000) ผู้ใช้สามารถกำหนดจำนวนรหัสที่ต้องการ (ตั้งแต่ 1 ถึง 100) เลือกให้ตัวอักษรเป็นตัวพิมพ์ใหญ่หรือไม่ และเลือกว่าจะรวมยัติภังค์หรือไม่ รหัสถูกสร้างในเบราว์เซอร์ทันที คุณสามารถคัดลอกรหัสเดี่ยวโดยคลิกที่รหัสนั้น หรือคัดลอกทั้งหมดพร้อมกัน

จุดเด่นของหน้านี้

UUID v4 ใช้ บิตสุ่ม 122 บิต ต่อหนึ่งรหัส (อีก 6 บิตที่เหลือเป็นบิตเวอร์ชันและแวเรียนต์ตายตัว) ซึ่งแตกต่างจาก UUID v7 หรือ ULID ที่มีองค์ประกอบของเวลา การเรียงลำดับตามค่า UUID v4 จึงเป็นแบบสุ่มโดยสิ้นเชิง ไม่มีความสัมพันธ์กับลำดับเวลา และเมื่อใช้เป็นคีย์หลักในฐานข้อมูล จะทำให้เกิด การแตกกระจายของดัชนี B-tree (index fragmentation) อย่างมาก ซึ่งส่งผลต่อประสิทธิภาพการเขียน โดยเฉพาะในตารางขนาดใหญ่

ความน่าจะเป็นของการชนกัน (collision) ของ UUID v4 ในทางปฏิบัติถือว่า น้อยมาก หากสร้างรหัส 1 พันล้านรหัสต่อวินาที โอกาสชนกันภายใน 100 ปีมีน้อยกว่า 50% สำหรับจำนวนรหัสที่น้อยกว่า ความเสี่ยงนี้แทบเป็นศูนย์ แม้ในระบบจำหน่ายที่ไม่มีศูนย์กลางประสานงาน

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

UUID v4 ถูกกำหนดโดยมาตรฐาน RFC 4122 ประกอบด้วย 128 บิต แบ่งเป็น:

• 122 บิตสุ่ม (โดยใช้ crypto.randomUUID หรือฟังก์ชันสุ่มที่แข็งแกร่งของเบราว์เซอร์)
• 4 บิต เป็นเวอร์ชัน (fixed: 0100 แทนค่า 4)
• 2 บิต เป็นแวเรียนต์ (fixed: 10 สำหรับ RFC 4122)

รูปแบบบัญญัติคือ 36 ตัวอักษร: 8 ตัวแรก, ยัติภังค์, 4 ตัว, ยัติภังค์, 4 ตัว, ยัติภังค์, 4 ตัว, ยัติภังค์, 12 ตัว (ตัวอักษร a-f และ 0-9) เมื่อปิดการแสดงยัติภังค์ จะเหลือเพียง 32 ตัวอักษรโดยไม่มีตัวคั่น

ผลกระทบต่อดัชนีฐานข้อมูล

การใช้ UUID v4 เป็นคีย์หลักโดยตรงทำให้ดัชนี B-tree ต้องทำงานหนักขึ้น เพราะแถวใหม่จะถูกแทรกในตำแหน่งสุ่ม ไม่ใช่ต่อท้ายตาราง ทำให้เกิดการแตกกระจายของหน้า (page splits) บ่อยครั้ง ส่งผลให้ประสิทธิภาพการเขียนลดลง และการใช้พื้นที่จัดเก็บเพิ่มขึ้น ฐานข้อมูลบางตัว (เช่น PostgreSQL) มีวิธีจัดการ เช่น การใช้ UUID เป็นคีย์หลักร่วมกับ uuid-ossp หรือเปลี่ยนไปใช้ UUID v7 ที่เรียงตามเวลา

สำหรับระบบที่ต้องการลำดับเวลาหรือประสิทธิภาพการเขียนสูง ควรพิจารณา UUID v7, ULID หรือ Snowflake ID แทน

การปรับแต่งรูปแบบ

หน้านี้มีตัวเลือกสองอย่างที่เกี่ยวข้องกับ UUID โดยเฉพาะ:

• ตัวพิมพ์ใหญ่ (Uppercase) – เปลี่ยนตัวอักษร a-f เป็น A-F ไม่ส่งผลต่อความเข้ากันได้ แต่บางระบบอาจกำหนดให้ใช้ตัวพิมพ์ใหญ่ทั้งหมด
• รวมยัติภังค์ (Include hyphens) – การปิดยัติภังค์ทำให้สตริงสั้นลง (32 ตัวอักษร) เหมาะกับ URL หรือพื้นที่จำกัด แต่ไม่ควรใช้ในบริบทที่คาดหวังรูปแบบบัญญัติ

การเปลี่ยนตัวเลือกใดๆ จะสร้างรหัสใหม่ทั้งหมดทันที

ผู้ที่ควรใช้ UUID v4

• นักพัฒนาแอปพลิเคชัน ที่ต้องการรหัสสุ่มที่ไม่สามารถคาดเดาได้ สำหรับ session ID, request ID, หรือ tokens
• วิศวกรความปลอดภัย ต้องการรหัสที่ไม่มีความสัมพันธ์กับเวลา เพื่อป้องกันการเดาลำดับ
• นักทดสอบ ที่ต้องการข้อมูลจำลองที่มีค่าเฉพาะ
• นักออกแบบฐานข้อมูลแบบกระจาย ที่ไม่สามารถใช้ลำดับเลขแบบรวมศูนย์

ข้อควรระวัง

• อย่าใช้ UUID v4 เป็น primary key ในตารางที่มีการเขียนสูงโดยไม่มีกลยุทธ์จัดการ index fragmentation
• การสุ่มในเบราว์เซอร์ (crypto.randomUUID) มีความปลอดภัยเพียงพอสำหรับการใช้งานทั่วไป แต่ถ้าต้องการระดับความปลอดภัยสูงสุด ควรพิจารณาแหล่งกำเนิดเฉพาะทาง
• จำนวนรหัสที่สร้างต่อครั้งถูกจำกัดที่ 100 เพื่อป้องกันการทำงานหนักเกินไปของเบราว์เซอร์

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

1. UUID v4 กับ UUID v7 ต่างกันอย่างไร? UUID v7 มีส่วนของ timestamp ทำให้เรียงลำดับตามเวลาได้ ซึ่งช่วยลด index fragmentation สำหรับตารางที่ใช้คีย์หลัก ส่วน v4 เป็นแบบสุ่มล้วน

2. ถ้าขีดจำนวน 100 รหัส จะสร้างมากกว่านั้นได้ไหม? ไม่สามารถผ่านหน้านี้ แต่สามารถสร้างหลายครั้งติดกันได้ เพราะแต่ละรหัสไม่ซ้ำกัน

3. การคลิกคัดลอกรายการเดียวทำงานอย่างไร? คลิกที่สตริง UUID นั้น ระบบจะคัดลอกไปยังคลิปบอร์ดทันที และแสดงข้อความสั้น ๆ

4. รหัสที่สร้างขึ้นถูกเก็บไว้ที่เซิร์ฟเวอร์หรือไม่? ไม่ กระบวนการทั้งหมดเกิดขึ้นในเบราว์เซอร์ของคุณเท่านั้น ไม่มีการส่งข้อมูลออกไป

5. โอกาสที่รหัสจะซ้ำกันมีเท่าไร? สำหรับ 122 บิตสุ่ม โอกาสชนกันเมื่อสร้าง 1 พันล้านรหัสอยู่ที่ประมาณ 1 ใน 2.7×10^11 ซึ่งแทบเป็นไปไม่ได้ในการใช้งานจริง

6. ทำไมต้องมีตัวเลือกตัวพิมพ์ใหญ่และยัติภังค์? บางระบบกำหนดให้ใช้ตัวพิมพ์ใหญ่ (เช่น API keys) และบางระบบต้องการสตริงที่สั้นกว่าโดยไม่มียัติภังค์ (เช่น ใน URL) แต่ทั้งสองตัวเลือกไม่เปลี่ยนค่าสุ่ม