เครื่องสร้าง UUID ออนไลน์: รองรับ v1-v7, สร้างได้หลายพัน

UUID คืออะไร?

UUID (Universally Unique Identifier) คือตัวระบุขนาด 128 บิตที่ใช้ในระบบคอมพิวเตอร์เพื่อระบุข้อมูลได้อย่างไม่ซ้ำกัน UUID ได้รับการกำหนดมาตรฐานตาม RFC 4122 และด้วยเอนโทรปีที่สูงมาก ทำให้แทบไม่มีโอกาสเกิดการชนกันเลย ซึ่งหมายความว่า UUID สองรายการที่สร้างขึ้นอย่างอิสระจะมีความเป็นเอกลักษณ์เกือบแน่นอน

UUID มีรูปแบบมาตรฐานคือ: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx โดยที่ x แต่ละตัวคือตัวเลขฐานสิบหก (0-9, a-f), M บ่งบอกถึงเวอร์ชันของ UUID และ N บ่งบอกถึงรูปแบบ

เวอร์ชันของ UUID

UUID v1 (Timestamp + ที่อยู่ MAC)

UUID v1 สร้างขึ้นจาก timestamp ปัจจุบันและค่าสุ่ม (ในเบราว์เซอร์จะใช้ค่าสุ่มแทนที่อยู่ MAC) โดยใช้อินเทอร์วัล 100 นาโนวินาที นับจากวันที่ 15 ตุลาคม 1582 (ปฏิทินเกรกอเรียน)

การใช้งาน:

• สถานการณ์ที่คุณต้องการจัดเรียง UUID ตามลำดับเวลา
• การดีบักและการบันทึก (UUID มีข้อมูลเวลาที่สร้าง)
• ระบบแบบกระจายที่ต้องมีการซิงค์เวลา

ตัวอย่าง: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

ข้อดี:

• สามารถจัดเรียง UUID ตามลำดับเวลาที่สร้างได้
• มีประโยชน์สำหรับการตรวจสอบและดีบัก
• มีข้อมูล timestamp

ข้อเสีย:

• ความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้น – มี timestamp
• ในเบราว์เซอร์จะไม่มีที่อยู่ MAC จริง (ถูกแทนที่ด้วยค่าสุ่ม)
• ตำแหน่งข้อมูลใน DB ไม่ดี (timestamp อยู่ในบิตลำดับต่ำ)

UUID v3 (แฮช MD5)

UUID v3 ถูกสร้างขึ้นโดยใช้แฮช MD5 ของ namespace UUID และชื่อ เป็นแบบกำหนดได้ – namespace + ชื่อเดียวกันจะสร้าง UUID เดียวกันเสมอ

การใช้งาน:

• การแปลง URL, ชื่อ DNS หรือตัวระบุอื่นๆ เป็น UUID
• สถานการณ์ที่คุณต้องการ UUID ที่สามารถสร้างซ้ำได้
• การจับคู่ระหว่างระบบระบุตัวตนที่แตกต่างกัน

ตัวอย่าง: a3bb189e-8bf9-3888-9912-ace4e6543002

ข้อดี:

• กำหนดได้ (ข้อมูลเข้าเหมือนกัน = ผลลัพธ์เหมือนกัน)
• เหมาะสำหรับการแปลงตัวระบุที่รู้จัก
• ไม่มีการชนกันสำหรับข้อมูลเข้าที่แตกต่างกัน

ข้อเสีย:

• MD5 เป็นอัลกอริทึมที่ล้าสมัย (ควรใช้ v5)
• ต้องมี namespace และ name
• ไม่สามารถกู้คืนข้อมูลเข้าเดิมได้

UUID v4 (สุ่ม) - แนะนำ

UUID เวอร์ชันที่ใช้บ่อยที่สุด UUID v4 ถูกสร้างขึ้นแบบสุ่มล้วนๆ โดยใช้ตัวสร้างตัวเลขสุ่มที่ปลอดภัยทางคริปโตกราฟี (crypto.getRandomValues())

การใช้งาน:

• คีย์หลักของฐานข้อมูล
• ตัวระบุเซสชัน (session IDs)
• ชื่อไฟล์ที่ไม่ซ้ำกัน
• โทเค็น API
• วัตถุประสงค์ทั่วไปที่คุณต้องการ ID ที่ไม่ซ้ำกันอย่างแน่นอน

ตัวอย่าง: f47ac10b-58cc-4372-a567-0e02b2c3d479

ข้อดี:

• เอนโทรปีและความปลอดภัยสูงสุด
• ไม่ขึ้นกับเวลาหรือพารามิเตอร์ของระบบ
• การใช้งานที่ง่ายที่สุด

โอกาสเกิดการชนกัน: หากสร้าง UUID v4 1 พันล้านรายการต่อวินาที เป็นเวลา 100 ปี โอกาสที่จะเกิดการชนกันจะอยู่ที่ประมาณ 0.00000006%.

UUID v5 (แฮช SHA-1)

UUID v5 เหมือนกับ v3 แต่ใช้ SHA-1 แทน MD5 เป็นทางเลือกที่ทันสมัยและปลอดภัยกว่า v3

การใช้งาน:

• เหมือนกับ v3 แต่มีความปลอดภัยที่ดีกว่า
• ควรใช้มากกว่า v3 สำหรับโปรเจกต์ใหม่
• การสร้าง UUID จาก URL, ชื่อ DNS, OID, X.500 DN

ตัวอย่าง: 886313e1-3b8a-5372-9b90-0c9aee199e5d

ข้อดี:

• กำหนดได้
• SHA-1 แข็งแกร่งกว่า MD5
• เหมาะสำหรับการจับคู่ระหว่างระบบ

ข้อเสีย:

• SHA-1 ก็ถูกพิจารณาว่าล้าสมัยเช่นกัน (แต่ยังคงปลอดภัยกว่า MD5)
• ต้องมี namespace และ name

UUID v6 (Timestamp ที่จัดเรียง)

UUID v6 เป็นเวอร์ชันที่ปรับปรุงจาก v1 โดยมีการจัดเรียงบิตเวลาใหม่เพื่อการทำดัชนี DB ที่ดีขึ้น ออกแบบมาเพื่อแก้ไขปัญหาด้านตำแหน่งข้อมูลในฐานข้อมูล

การใช้งาน:

• คีย์หลักของฐานข้อมูลที่จัดเรียงตามเวลา
• ระบบที่ต้องการทั้งการจัดเรียงตามลำดับเวลาและประสิทธิภาพ DB
• ทางเลือกที่ทันสมัยกว่า v1

ตัวอย่าง: 1ec9414c-232a-6b00-b3c8-9e6bdeced846

ข้อดี:

• ตำแหน่งข้อมูลใน DB ดีกว่า v1 (timestamp อยู่ในบิตลำดับสูง)
• การจัดเรียงตามลำดับเวลา
• เข้ากันได้กับมาตรฐาน UUID

ข้อเสีย:

• ใช้งานน้อยกว่า v1/v4
• ยังคงมีข้อมูลเวลา (ความเสี่ยงด้านความปลอดภัย)

UUID v7 (Unix timestamp)

UUID v7 ใช้ Unix timestamp (มิลลิวินาทีจากปี 1970) + บิตสุ่ม เป็น UUID เวอร์ชันล่าสุดที่มีตำแหน่งข้อมูลใน DB ดีที่สุด

การใช้งาน:

• คีย์หลักของฐานข้อมูลที่ทันสมัย
• ระบบที่ต้องการประสิทธิภาพ + การจัดเรียงตามเวลา
• ใช้แทน v1/v6 ในโปรเจกต์ใหม่

ตัวอย่าง: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f

ข้อดี:

• ตำแหน่งข้อมูลใน DB ดีที่สุดในทุกเวอร์ชัน
• Unix timestamp เป็นมาตรฐาน
• รวมข้อดีของการสุ่มและการจัดเรียงตามเวลา

ข้อเสีย:

• เป็นข้อกำหนดที่ค่อนข้างใหม่ (RFC 4122bis)
• รองรับน้อยในระบบเก่า

ควรใช้ UUID เวอร์ชันใด?

คู่มือการตัดสินใจ

คุณต้องการความปลอดภัยและการสุ่มสูงสุดหรือไม่? → ใช้ UUID v4 (ตัวเลือกที่พบบ่อยที่สุด)

คุณต้องการการจัดเรียงตามเวลาและประสิทธิภาพ DB หรือไม่? → ใช้ UUID v7 (ทันสมัย) หรือ UUID v6 (มาตรฐาน)

คุณต้องการ UUID ที่สามารถสร้างซ้ำได้จากตัวระบุที่มีอยู่หรือไม่? → ใช้ UUID v5 (SHA-1) หรือ UUID v3 (MD5, รุ่นเก่า)

คุณต้องการ timestamp และบันทึกการตรวจสอบหรือไม่? → ใช้ UUID v1 (รุ่นเก่า, ประสิทธิภาพ DB แย่กว่า)

ฐานข้อมูล

สำหรับโปรเจกต์ใหม่: UUID v7 หรือ v4

• v7 เหมาะสำหรับการจัดเรียงตามเวลา + ประสิทธิภาพ
• v4 สำหรับการสุ่มสูงสุดโดยไม่มีข้อมูลเวลา

สำหรับระบบเก่า: UUID v1 หรือ v6

• v6 มีตำแหน่งข้อมูลใน DB ดีกว่า v1
• v1 ได้รับการสนับสนุนอย่างกว้างขวาง

ข้อดีของ UUID เป็นคีย์หลัก:

• ความเป็นเอกลักษณ์ทั่วโลก – คุณสามารถรวมข้อมูลจากฐานข้อมูลที่แตกต่างกันได้โดยไม่มีข้อขัดแย้ง
• ความปลอดภัย – แตกต่างจาก ID แบบลำดับ (1, 2, 3…) ไม่สามารถคาดเดาค่าถัดไปได้
• ระบบแบบกระจาย – UUID สามารถสร้างขึ้นได้อย่างอิสระบนเซิร์ฟเวอร์หลายเครื่องโดยไม่ต้องมีการประสานงาน
• การรวมฐานข้อมูล – เมื่อรวมฐานข้อมูลสองแห่ง จะไม่มีข้อขัดแย้งเกิดขึ้น

ข้อเสีย:

• ขนาดใหญ่กว่า (16 ไบต์ เทียบกับ 4-8 ไบต์สำหรับจำนวนเต็ม)
• การทำดัชนีช้าลงในฐานข้อมูลบางประเภท (ใช้ v6/v7 เพื่อประสิทธิภาพที่ดีขึ้น)
• อ่านยากสำหรับมนุษย์

API และบริการเว็บ

• REST API – ตัวระบุที่ไม่ซ้ำกันสำหรับทรัพยากร
• GraphQL – ตัวระบุทั่วโลกสำหรับโหนด
• Webhook – การติดตามคำขอและการตอบกลับ
• โทเค็น – Session IDs, refresh token

ไฟล์และพื้นที่เก็บข้อมูล

• ชื่อไฟล์ – ป้องกันการชนกันเมื่ออัปโหลด
• S3/Cloud Storage – เส้นทางที่ไม่ซ้ำกันสำหรับอ็อบเจกต์
• คีย์แคช – ตัวระบุในระบบแคช

แอปพลิเคชันส่วนหน้า (Frontend)

• คอมโพเนนต์ React/Vue – คีย์ที่ไม่ซ้ำกันสำหรับรายการ
• Temporary IDs – ID ก่อนบันทึกลงฐานข้อมูล
• Local storage – คีย์สำหรับข้อมูลที่จัดเก็บ
• แอปพลิเคชันแบบออฟไลน์เป็นหลัก – การสร้าง ID โดยไม่ต้องเชื่อมต่อกับเซิร์ฟเวอร์

คุณสมบัติขั้นสูงของเครื่องสร้าง

การสร้าง UUID ด้วยเวลาที่กำหนดเอง

สำหรับเวอร์ชันที่ใช้เวลาเป็นหลัก (v1, v6, v7) คุณสามารถเลือก timestamp ใดก็ได้โดยใช้ตัวเลือกวันที่และเวลา ซึ่งมีประโยชน์สำหรับ:

การทดสอบ:

• การจำลอง UUID ที่สร้างขึ้นในอดีต
• การทดสอบการจัดเรียงตามเวลาในฐานข้อมูล
• การสร้าง UUID ซ้ำเพื่อการดีบัก

การย้ายข้อมูล:

• การสร้าง UUID ด้วย timestamp ย้อนหลัง
• การเติมข้อมูลย้อนหลังด้วยค่า timestamp ที่ถูกต้อง
• การนำเข้าข้อมูลจากช่วงเวลาที่แตกต่างกัน

การตรวจสอบและการปฏิบัติตามข้อกำหนด:

• การสร้าง UUID ใหม่ตามเวลาที่สร้างบันทึก
• การสร้างตัวระบุย้อนหลัง

ตัวอย่างการใช้งาน:

1. เลือกเวอร์ชัน v1, v6 หรือ v7
2. กำหนดวันที่และเวลาโดยใช้ตัวเลือกวันที่และเวลา
3. สร้าง UUID ด้วย timestamp ที่คุณกำหนดเอง

UUID ที่ใช้แฮช (v3, v5)

สำหรับ UUID แบบกำหนดได้ คุณสามารถใช้เวอร์ชัน v3 (MD5) หรือ v5 (SHA-1):

วิธีใช้:

1. เลือก namespace ตามประเภทตัวระบุของคุณ
2. ป้อนชื่อ/ค่า
3. สร้าง UUID

ตัวอย่าง:

คุณสมบัติที่สำคัญ:

• ✅ กำหนดได้: ข้อมูลเข้าเหมือนกัน = UUID เหมือนกันเสมอ
• ✅ สร้างซ้ำได้: คุณสามารถสร้าง UUID ซ้ำได้ทุกเมื่อ
• ✅ สอดคล้องกัน: UUID เดียวกันในระบบที่แตกต่างกัน
• ❌ ไม่สามารถถอดรหัสได้: ไม่สามารถกู้คืนชื่อเดิมจาก UUID ได้
• ℹ️ UUID เดียว: สำหรับ v3/v5 จะสร้างเพียง UUID เดียวเสมอ (ข้อมูลเข้าเหมือนกัน = ผลลัพธ์เหมือนกัน)

การใช้งานจริง:

// ตัวอย่าง: การแปลง URL เป็น UUID v5
Namespace: URL
Název: https://example.com/api/users/123
Výsledek: 886313e1-3b8a-5372-9b90-0c9aee199e5d

// ข้อมูลเข้าเหมือนกัน = UUID เหมือนกันเสมอ
Namespace: DNS
Název: google.com
Výลัพธ์: UUID เดียวกันเสมอสำหรับ google.com

วิธีใช้ UUID อย่างปลอดภัย?

ความปลอดภัยทางคริปโตกราฟี

เครื่องสร้างของเราใช้ crypto.getRandomValues() ซึ่งเป็นตัวสร้างตัวเลขสุ่มที่ปลอดภัยทางคริปโตกราฟี แตกต่างจาก Math.random() ซึ่งสามารถคาดเดาได้และไม่เหมาะสมสำหรับวัตถุประสงค์ด้านความปลอดภัย crypto.getRandomValues() ให้เอนโทรปีจริงที่เหมาะสำหรับ:

• การสร้างโทเค็นความปลอดภัย
• Session IDs
• คีย์ API
• แอปพลิเคชันทางคริปโตกราฟี

การเปรียบเทียบเวอร์ชัน UUID

UUID เทียบกับตัวระบุอื่นๆ

การนำไปใช้ในภาษาต่างๆ

JavaScript/TypeScript

// UUID v4 - วิธีที่ง่ายที่สุด (เบราว์เซอร์ที่ทันสมัย)
const uuid = crypto.randomUUID();

// UUID v4 - การนำไปใช้ด้วยตนเอง
function generateUUIDv4() {
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, (c) => {
    const r = (crypto.getRandomValues(new Uint8Array(1))[0] & 0x0f) >> (c === 'x' ? 0 : 2);
    const v = c === 'x' ? r : (r & 0x3) | 0x8;
    return v.toString(16);
  });
}

// UUID v7 - แนะนำสำหรับฐานข้อมูล
function generateUUIDv7() {
  const timestamp = Date.now();
  const timeHi = (timestamp >> 16).toString(16).padStart(8, '0');
  const timeLow = (timestamp & 0xFFFF).toString(16).padStart(4, '0');

  const randomBytes = crypto.getRandomValues(new Uint8Array(10));
  const randomHex = Array.from(randomBytes)
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');

  return `${timeHi}-${timeLow}-7${randomHex.substr(0, 3)}-${randomHex.substr(3, 4)}-${randomHex.substr(7)}`;
}

Python

import uuid

# UUID v4
uuid_v4 = str(uuid.uuid4())
# ผลลัพธ์: '6ba7b810-9dad-11d1-80b4-00c04fd430c8'

# UUID v1
uuid_v1 = str(uuid.uuid1())

Java

import java.util.UUID;

// UUID v4
String uuidV4 = UUID.randomUUID().toString();

PHP

// UUID v4 (PHP 7+)
function generateUUID() {
    return sprintf('%04x%04x-%04x-%04x-%04x-%04x%04x%04x',
        mt_rand(0, 0xffff), mt_rand(0, 0xffff),
        mt_rand(0, 0xffff),
        mt_rand(0, 0x0fff) | 0x4000,
        mt_rand(0, 0x3fff) | 0x8000,
        mt_rand(0, 0xffff), mt_rand(0, 0xffff), mt_rand(0, 0xffff)
    );
}

C#

using System;

// UUID v4
Guid uuid = Guid.NewGuid();
string uuidString = uuid.ToString();

แนวทางปฏิบัติที่ดีที่สุด

การจัดเก็บ UUID ในฐานข้อมูล

PostgreSQL:

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

MySQL 8.0+:

CREATE TABLE users (
    id BINARY(16) PRIMARY KEY DEFAULT (UUID_TO_BIN(UUID())),
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

เคล็ดลับ: ใน MySQL ควรจัดเก็บ UUID เป็น BINARY(16) แทน CHAR(36) เพื่อประหยัดพื้นที่และทำดัชนีได้เร็วขึ้น

การตรวจสอบ UUID

function isValidUUID(uuid) {
  const regex = /^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
  return regex.test(uuid);
}

การแปลง UUID

// การลบขีดกลาง
const compact = uuid.replace(/-/g, '');

// การเพิ่มขีดกลางกลับ
function formatUUID(compactUuid) {
  return [
    compactUuid.substring(0, 8),
    compactUuid.substring(8, 12),
    compactUuid.substring(12, 16),
    compactUuid.substring(16, 20),
    compactUuid.substring(20, 32)
  ].join('-');
}

การแก้ไขปัญหา (Troubleshooting)

UUID v3/v5 ไม่ทำงาน

ปัญหา: หลังจากเลือก v3 หรือ v5 แล้ว ไม่มีอะไรถูกสร้างขึ้นมา

วิธีแก้ไข:

1. ✅ ตรวจสอบว่าคุณ ป้อนข้อมูลในช่อง “ชื่อ” แล้ว - ซึ่งจำเป็น!
2. ✅ เลือก namespace ที่ถูกต้องตามประเภทข้อมูลเข้าของคุณ
3. ✅ ตัวอย่างข้อมูลเข้าที่ถูกต้อง:
   • DNS: example.com, google.com
   • URL: https://example.com/page
   • ข้อความใดๆ: my-application-v1

เคล็ดลับ: ลองใช้ค่าที่เรียบง่ายเช่น test และ namespace เป็น DNS ก่อน

UUID แบบเวลา (v1, v6, v7) มีเวลาที่แปลกไป

ปัญหา: UUID ที่สร้างขึ้นมี timestamp ที่ไม่คาดคิด

วิธีแก้ไข:

1. ✅ ตรวจสอบตัวเลือกวันที่-เวลา - ตั้งเวลาถูกต้องหรือไม่?
2. ✅ ตัวเลือกวันที่-เวลาใช้เขตเวลาท้องถิ่นของคุณ
3. ✅ ปล่อยตัวเลือกวันที่-เวลาว่างไว้เพื่อใช้เวลาปัจจุบัน

ไม่สามารถคัดลอก UUID ได้

ปัญหา: ปุ่ม “คัดลอกทั้งหมด” ไม่ทำงาน

วิธีแก้ไข:

1. ✅ ตรวจสอบว่าคุณได้สร้าง UUID แล้ว (ไม่ว่างเปล่า)
2. ✅ เบราว์เซอร์บางตัวต้องการ HTTPS สำหรับ clipboard API
3. ✅ อีกทางเลือกหนึ่งคือเลือกข้อความใน textarea แล้วคัดลอกด้วยตนเอง (Ctrl+C)

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

ทางเลือกอื่นสำหรับ UUID

ULID (Universally Unique Lexicographically Sortable Identifier)

• ID ขนาด 128 บิต (เช่นเดียวกับ UUID)
• สามารถจัดเรียงตามพจนานุกรมตามเวลาที่สร้างได้
• การแสดงผลที่กระชับกว่า (26 ตัวอักษรแทน 36 ตัวอักษร)
• การเข้ารหัส base32 ที่ไม่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่

ตัวอย่าง: 01ARZ3NDEKTSV4RRFFQ69G5FAV

NanoID

• ขนาดเล็กกว่า UUID (21 ตัวอักษรโดยมาตรฐาน)
• เป็นมิตรกับ URL (ไม่มีอักขระพิเศษ)
• สร้างได้เร็วกว่า
• กำหนดความยาวและตัวอักษรได้

ตัวอย่าง: V1StGXR8_Z5jdHi6B-myT

Snowflake ID (Twitter)

• ID ขนาด 64 บิต (เล็กกว่า UUID)
• สามารถจัดเรียงตามเวลาได้
• มี worker ID และหมายเลขลำดับ
• ต้องมีการกำหนดค่าแบบรวมศูนย์

ตัวอย่าง: 1234567890123456789

ประสิทธิภาพและการปรับแต่ง

ความเร็วในการสร้าง

เครื่องสร้างของเราสามารถสร้าง:

• 1 UUID: < 1 มิลลิวินาที
• 100 UUID: ~10-20 มิลลิวินาที
• 1000 UUID: ~100-200 มิลลิวินาที

เคล็ดลับสำหรับประสิทธิภาพ

1. การสร้างเป็นชุด – หากคุณต้องการ UUID จำนวนมาก ให้สร้างพร้อมกันทีเดียวแทนที่จะสร้างทีละรายการ
2. การจัดเก็บใน DB – ทำดัชนีคอลัมน์ UUID เพื่อการค้นหาที่รวดเร็ว
3. การบีบอัด – จัดเก็บ UUID ในรูปแบบไบนารี (16 ไบต์) แทนสตริง (36 ไบต์)
4. การแคช – ในบางกรณี คุณสามารถสร้าง UUID ล่วงหน้าและแคชไว้ได้

สำหรับนักพัฒนา

โครงสร้าง UUID v4

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
|        |    |    |    |
|        |    |    |    └─ 48 บิตของข้อมูลสุ่ม (node)
|        |    |    └────── 16 บิตของข้อมูลสุ่มพร้อมรูปแบบ (clock_seq)
|        |    └─────────── 12 บิตของข้อมูลสุ่ม + 4 บิตของเวอร์ชัน (time_hi_and_version)
|        └──────────────── 16 บิตของข้อมูลสุ่ม (time_mid)
└───────────────────────── 32 บิตของข้อมูลสุ่ม (time_low)

• เวอร์ชัน (4 บิต): เสมอ 0100 (ไบนารี) = 4 (เลขฐานสิบหก)
• รูปแบบ (2-3 บิต): เสมอ 10 (ไบนารี) สำหรับ RFC 4122

การทดสอบ UUID

// Jest test
describe('UUID Generator', () => {
  test('สร้าง UUID v4 ที่ถูกต้อง', () => {
    const uuid = generateUUIDv4();
    const regex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
    expect(regex.test(uuid)).toBe(true);
  });

  test('สร้าง UUID ที่ไม่ซ้ำกัน', () => {
    const uuid1 = generateUUIDv4();
    const uuid2 = generateUUIDv4();
    expect(uuid1).not.toBe(uuid2);
  });
});

ประเด็นด้านความปลอดภัย

สิ่งที่ไม่ควรทำกับ UUID

❌ อย่าใช้ UUID v1 สำหรับแอปพลิเคชันที่ละเอียดอ่อน – เนื่องจากมี timestamp ซึ่งอาจเป็นความเสี่ยงด้านความปลอดภัย

❌ อย่าใช้ Math.random() ในการสร้าง UUID – เนื่องจากไม่ปลอดภัยทางคริปโตกราฟี

❌ อย่าพึ่งพา UUID ในการอนุมัติ – UUID สามารถเดาได้ (แม้ว่าจะมีโอกาสน้อยมากก็ตาม)

❌ อย่าเก็บ UUID ในคุกกี้โดยไม่มีการเข้ารหัส – ควรใช้ signed cookies หรือ JWT

สิ่งที่ควรทำ

✅ ใช้ UUID v4 สำหรับกรณีส่วนใหญ่ – ให้เอนโทรปีและความปลอดภัยสูงสุด

✅ ใช้ UUID ร่วมกับมาตรการความปลอดภัยอื่นๆ – สำหรับการจัดการเซสชัน ให้ใช้ HTTPS, คุกกี้ HttpOnly และกำหนดวันหมดอายุสั้นๆ

✅ ตรวจสอบ UUID บนเซิร์ฟเวอร์ – ตรวจสอบรูปแบบและเวอร์ชันของ UUID เสมอ

✅ ใช้แหล่งที่มาของค่าสุ่มที่ปลอดภัยทางคริปโตกราฟี – crypto.getRandomValues() ในเบราว์เซอร์, /dev/urandom บน Linux

ข้อเท็จจริงที่น่าสนใจ

• จำนวน UUID v4 ที่เป็นไปได้: 2^122 ≈ 5.3 × 10^36 (340 undecillion)
• โอกาสชนกัน 50%: คุณต้องสร้าง UUID 2.71 × 10^18 รายการ (2.71 quintillion) เพื่อให้มีโอกาสชนกัน 50%
• ขนาดของ UUID ที่เป็นไปได้ทั้งหมด: หากเราจัดเก็บ UUID แต่ละรายการเป็น 16 ไบต์ พื้นที่ทั้งหมดจะใช้ 85 เซตตะไบต์ (85 พันล้านเทราไบต์)
• ที่มา: UUID ได้รับการกำหนดมาตรฐานเป็นส่วนหนึ่งของ DCE (Distributed Computing Environment) ในปี 1990