สร้าง UUID ฟรี

วิธีใช้งาน

1. เลือก v4 หากต้องการรหัสที่สุ่มล้วน หรือเลือก v7 หากจะนำไปใช้เป็นคีย์ของฐานข้อมูลและต้องการให้เรียงตามเวลาที่สร้าง
2. กำหนดจำนวนที่ต้องการ สร้างได้สูงสุดครั้งละ 500 รายการ
3. ปรับรูปแบบได้ ทั้งตัวพิมพ์ใหญ่ เปิดหรือปิดขีดคั่น และวงเล็บปีกกาแบบที่ Windows Registry ใช้
4. คัดลอกทั้งรายการไปยังคลิปบอร์ด หรือดาวน์โหลดเป็นไฟล์ข้อความ

ควรใช้ v4 หรือ v7

v4 คือบิตสุ่มล้วน 122 บิต ไม่มีข้อมูลอื่นแฝงอยู่เลย จึงไม่บอกว่าถูกสร้างเมื่อใดหรือที่ไหน เหมาะเป็นค่าเริ่มต้นสำหรับสิ่งที่ผู้ใช้มองเห็น เช่น โทเคนของเซสชัน ชื่อไฟล์ URL สาธารณะ หรือรหัสอ้างอิงในล็อก

ส่วน v7 วางเวลาระดับมิลลิวินาทีขนาด 48 บิตไว้ด้านหน้า แล้วตามด้วยค่าสุ่ม เนื่องจากเวลาอยู่ข้างหน้าและเก็บแบบ big-endian การเรียงลำดับ UUID แบบ v7 ในรูปข้อความจึงได้ลำดับเดียวกับเวลาที่สร้าง

ลำดับนี้คือเหตุผลที่ v7 เกิดขึ้นมา ดัชนีของฐานข้อมูลเป็นโครงสร้าง B-tree ซึ่งทำงานได้ดีที่สุดเมื่อคีย์ใหม่ไปต่อท้ายที่ขอบขวา คีย์แบบ v4 ที่สุ่มล้วนจะกระจายการเขียนไปทั่วทั้งดัชนี ทำให้หน้าข้อมูลถูกแตกออกและแคชถูกเบียดทิ้ง ดัชนีจึงบวมขึ้นและเขียนช้าลงเมื่อตารางโตขึ้น ส่วนคีย์แบบ v7 ต่อท้ายเรียงกันไป หน้าที่ใช้งานบ่อยจึงยังอยู่ในแคช

สรุปสั้น ๆ คือ ถ้าเป็นคีย์หลักของฐานข้อมูลให้ใช้ v7 แต่ถ้าผู้ใช้มองเห็นได้และคุณไม่อยากเปิดเผยว่าข้อมูลถูกสร้างเมื่อใด ให้ใช้ v4

ข้อมูลไม่ออกจากเครื่องของคุณ

ค่าทั้งหมดถูกสร้างจากตัวสุ่มเชิงเข้ารหัสของเบราว์เซอร์คุณเอง ซึ่งเป็นตัวเดียวกับที่ใช้สร้างกุญแจ TLS ผ่าน Web Crypto API ไม่มีการเรียกไปยังเซิร์ฟเวอร์ใด รหัสที่คุณสร้างที่นี่จึงไม่เคยผ่านสายตาเราหรือใครทั้งสิ้น และเมื่อหน้าเว็บโหลดเสร็จแล้ว เครื่องมือนี้ยังใช้งานได้แม้ไม่มีอินเทอร์เน็ต

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

นำไปใช้งานจริงได้หรือไม่

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

มีโอกาสที่ UUID สองตัวจะซ้ำกันไหม

ในทางปฏิบัติถือว่าไม่มี UUID แบบ v4 มีบิตสุ่ม 122 บิต หรือราว 5.3 × 10³⁶ ความเป็นไปได้ คุณต้องสร้างพันล้านรายการต่อวินาทีติดต่อกันราว 85 ปี จึงจะมีโอกาส 50% ที่จะเกิดการซ้ำสักครั้งเดียว ส่วน v7 ความไม่ซ้ำภายในมิลลิวินาทีเดียวกันอาศัยบิตสุ่ม 62 บิตร่วมกับตัวนับลำดับ ซึ่งเกินอัตราการสร้างที่เป็นไปได้จริงไปมาก

v7 เปิดเผยเวลาที่สร้างหรือไม่

เปิดเผย และเป็นเรื่องที่ควรพิจารณา ใครก็ตามที่ถือ UUID แบบ v7 สามารถอ่านเวลาที่สร้างได้ละเอียดถึงระดับมิลลิวินาที ซึ่งมักไม่เป็นปัญหาหากใช้เป็นคีย์ภายในระบบ แต่ถ้ารหัสนั้นปรากฏใน URL สาธารณะ เท่ากับเปิดเผยเวลาออกไปด้วย ซึ่งอาจถูกใช้อนุมานเวลาสมัครสมาชิก เวลาสั่งซื้อ หรือปริมาณการใช้งานของระบบได้ กรณีแบบนี้ควรใช้ v4

ควรใช้ UUID หรือเลขรันอัตโนมัติ

เลขจำนวนเต็มมีขนาดเล็กกว่า (4–8 ไบต์ เทียบกับ 16 ไบต์) join ได้เร็วกว่า และอ่านออกเสียงง่ายกว่า ส่วน UUID สร้างที่ไหนก็ได้ ทั้งในเบราว์เซอร์ ในบริการอื่น หรือบนอุปกรณ์ที่ออฟไลน์อยู่ โดยไม่ต้องถามฐานข้อมูลกลางว่าเลขถัดไปคืออะไร นั่นคือเหตุผลที่คุ้มกับไบต์ที่เพิ่มขึ้นในระบบแบบกระจาย และยังไม่เปิดเผยจำนวนแถวข้อมูลแบบที่เลขเรียงลำดับใน URL ทำ

UUID แบบ v7 ที่สร้างจากที่นี่เรียงลำดับถูกต้องจริงหรือไม่

จริง การสร้าง 500 รายการเกิดขึ้นภายในมิลลิวินาทีเดียว เวลาเพียงอย่างเดียวจึงเรียงลำดับไม่ได้ เครื่องมือนี้ใช้วิธี monotonic ตามมาตรฐาน RFC 9562 คือมีตัวนับขนาด 12 บิตเดินหน้าภายในแต่ละมิลลิวินาที ผลลัพธ์ที่ได้จึงเรียงลำดับเรียบร้อยแล้วตั้งแต่ตอนคัดลอก

ทำไมมีแค่ v4 กับ v7

เพราะสองตัวนี้ตอบโจทย์ที่คนใช้จริง ส่วน v1 ฝังหมายเลข MAC ของเครื่องไว้ ซึ่งเปิดเผยตัวตนของฮาร์ดแวร์ จึงเลิกนิยมไป ขณะที่ v3 และ v5 เป็นค่าแฮชแบบกำหนดผลลัพธ์ได้จากชื่อ ซึ่งมีประโยชน์ แต่ต้องระบุ namespace และข้อมูลนำเข้า เครื่องมือแบบนี้จึงสร้างแทนให้ไม่ได้ ส่วน v7 ถือว่ามาแทน v6 สำหรับงานใหม่แล้ว