ตัวสร้าง UUID v4

ตัวสร้าง UUID v4 เป็นเครื่องมือฟรีสำหรับสร้าง Universally Unique Identifier เวอร์ชัน 4 เพื่อใช้เป็นตัวระบุระเบียน ออบเจ็กต์ หรือคำขอ

ตัวสร้าง UUID v4 จัดการข้อมูลของฉันอย่างไร?

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

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

UUID v4 คืออะไร?

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

รูปแบบมาตรฐานที่เขียนเป็นข้อความประกอบด้วยอักขระเลขฐานสิบหก 32 ตัว แบ่งเป็น 5 กลุ่มด้วยเครื่องหมายขีดกลาง มีรูปแบบ 8-4-4-4-12 และมีความยาวรวม 36 อักขระเมื่อนับเครื่องหมายขีดกลางทั้ง 4 ตัว

ตัวอย่างที่มีรูปแบบถูกต้องคือ 550e8400-e29b-41d4-a716-446655440000 สำหรับ UUID เวอร์ชัน 4 อักขระตัวแรกของกลุ่มที่ 3 จะเป็น 4 ส่วนบิตที่มีนัยสำคัญสูงสุด 2 บิตซึ่งใช้ระบุรูปแบบย่อยจะเป็น 10 ทำให้อักขระเลขฐานสิบหกตัวแรกของกลุ่มที่ 4 เป็น 8, 9, a หรือ b

ค่านี้เป็นตัวระบุ ไม่ใช่ข้อมูลที่ผ่านการเข้ารหัส คุณจึงถอดรหัสเพื่อดูวันที่สร้าง ชื่อบัญชี ที่อยู่ของเครื่อง หรือหมายเลขลำดับไม่ได้

ควรเลือก UUID เวอร์ชันไหน?

เลือกเวอร์ชัน 4 เมื่อต้องการตัวระบุที่สร้างขึ้นอย่างเป็นอิสระและไม่เปิดเผยความหมาย โดยไม่จำเป็นต้องให้ข้อมูลอินพุตเดียวกันสร้างผลลัพธ์เดิมทุกครั้ง สรุปสั้นๆ คือ v1 ใช้ข้อมูลเวลาและโหนด, v2 เป็นรูปแบบ DCE Security, v3 สร้าง UUID จากเนมสเปซและชื่อด้วย MD5, v4 ใช้การสุ่ม, v5 สร้างจากข้อมูลดังกล่าวด้วย SHA-1, v6 จัดเรียงข้อมูลที่อิงเวลาใหม่, v7 รวม Unix timestamp เข้ากับข้อมูลสุ่ม และ v8 ออกแบบไว้สำหรับรูปแบบเชิงทดลองหรือรูปแบบเฉพาะของผู้ผลิต

• ใช้ UUID v4 สำหรับ ID ของระเบียน ข้อมูลอ้างอิงการอัปโหลด ID คำขอ API และชุดข้อมูลทดสอบ ในกรณีที่เหมาะกับตัวระบุซึ่งกระจายแบบสุ่ม
• ใช้ UUID v5 เมื่อเนมสเปซและชื่อชุดหนึ่งต้องสร้างตัวระบุเดิมเสมอ เหมาะสำหรับการนำเข้าข้อมูลที่ต้องทำซ้ำได้และกฎการลบข้อมูลซ้ำ
• พิจารณา UUID v7 เมื่อระเบียนต้องมีตัวระบุที่เรียงตามเวลาสร้างโดยประมาณ และฐานข้อมูลหรือซอฟต์แวร์ของคุณรองรับ
• ใช้จำนวนเต็มเรียงลำดับตามปกติ เมื่อค่าทั้งหมดสร้างโดยฐานข้อมูลเดียว และคีย์ที่กะทัดรัดพร้อมลำดับตามธรรมชาติมีความสำคัญกว่าการสร้างแบบกระจายศูนย์

UUID เวอร์ชันเก่ายังคงพบได้ในระบบที่มีอยู่ แต่การออกแบบระบบใหม่ควรเลือกตามข้อกำหนดจริง ไม่ควรมองว่า UUID ทุกเวอร์ชันใช้แทนกันได้

การใช้ UUID v4 ในงานจริง

สร้าง UUID แล้วนำค่าจากช่องผลลัพธ์ UUID v4 ไปใช้ โดยจัดเก็บสตริงรูปแบบมาตรฐานให้ครบถ้วน เว้นแต่ระบบปลายทางจะกำหนดรูปแบบอื่นไว้

1. สร้าง UUID ใหม่สำหรับออบเจ็กต์หรือเหตุการณ์ที่ต้องมีตัวระบุ
2. เก็บทั้ง 5 กลุ่มและเครื่องหมายขีดกลางทั้ง 4 ตัวไว้ครบถ้วนเมื่อส่งค่าระหว่างระบบ
3. จัดเก็บด้วยชนิดข้อมูล UUID ของฐานข้อมูลหากมีให้ใช้ มิฉะนั้นให้ใช้ฟิลด์ข้อความหรือไบนารีที่มีขนาดเหมาะกับรูปแบบที่เลือก
4. เพิ่มข้อกำหนดห้ามค่าซ้ำ เมื่อฐานข้อมูลต้องปฏิเสธค่า UUID v4 ที่สร้างขึ้นซ้ำกัน

ตัวอย่างการใช้งานทั่วไป ได้แก่ การระบุคำสั่งซื้อก่อนส่งเข้าสู่ฐานข้อมูลหลัก การเชื่อมโยงรายการบันทึกเหตุการณ์จากหลายบริการ การตั้งชื่อออบเจ็กต์ที่อัปโหลด หรือการกำหนด ID คงที่ให้แถวข้อมูลที่เตรียมนำเข้า UUID มักรวมข้อมูลจากชุดข้อมูลที่สร้างแยกจากกันได้ง่ายกว่าลำดับจำนวนเต็มภายในระบบ เพราะแต่ละแหล่งอาจมีค่าลำดับซ้ำกัน

ช่องว่าง เครื่องหมายวรรคตอน ตัวอักษรที่มีเครื่องหมายกำกับ และอักขระที่ไม่ใช่อักษรละตินไม่ใช่อินพุตที่สร้างปัญหาให้ UUID v4 เพราะกระบวนการสร้างตัวระบุไม่ได้อ้างอิงจากข้อความ หากต้องการตัวระบุที่อิงกับชื่อซึ่งมีอักขระเหล่านี้ ให้ใช้ UUID แบบอิงชื่อ พร้อมกำหนดการเข้ารหัสอักขระและกฎการปรับรูปแบบให้เป็นมาตรฐานอย่างชัดเจน มิฉะนั้น ข้อความที่ดูเหมือนกันอาจให้ลำดับไบต์ต่างกัน และทำให้ได้ตัวระบุต่างกัน

UUID v4 สองค่าอาจซ้ำกันได้ไหม?

ได้ ในทางทฤษฎี UUID v4 อาจชนกัน แต่โดยทั่วไปไม่ใช่ข้อกังวลในทางปฏิบัติ หากสร้างด้วยแหล่งข้อมูลสุ่มที่เหมาะสม UUID v4 มีบิตที่เปลี่ยนแปลงได้ 122 บิต เพราะบิตที่เหลือใช้ระบุเวอร์ชันและรูปแบบย่อย จึงมีชุดค่าที่เป็นไปได้จำนวนมหาศาล

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

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

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

UUID แยกตัวพิมพ์เล็กกับตัวพิมพ์ใหญ่ไหม?

ไม่ โดยปกติตัวอักษรเลขฐานสิบหกใน UUID จะถือว่าไม่แตกต่างกันตามขนาดตัวพิมพ์ ดังนั้น A และ a จึงแทนค่าเดียวกัน รูปแบบมาตรฐานมักใช้ตัวพิมพ์เล็ก การปรับขนาดตัวพิมพ์ให้เหมือนกันก่อนเปรียบเทียบข้อความจะช่วยป้องกันผลลัพธ์ที่ไม่สอดคล้องกันในระบบที่แยกตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

ใช้ UUID v4 ใน URL หรือชื่อไฟล์ได้ไหม?

ได้ รูปแบบมาตรฐานใช้เฉพาะอักขระเลขฐานสิบหกและเครื่องหมายขีดกลาง ซึ่งเหมาะกับส่วนเส้นทางของ URL ทั่วไปและระบบไฟล์ที่ใช้กันทั่วไป ไม่ต้องใส่วงเล็บปีกกา เว้นแต่ API ที่ใช้งานจะกำหนดไว้ และควรจำไว้ว่าการเปิดเผย UUID ใน URL ไม่ได้ทำให้ทรัพยากรนั้นเป็นส่วนตัว

ควรลบเครื่องหมายขีดกลางออกจาก UUID ไหม?

ลบเฉพาะเมื่อรูปแบบปลายทางระบุชัดเจนว่าต้องการอักขระเลขฐานสิบหก 32 ตัว ไลบรารีและชนิดข้อมูล UUID ของฐานข้อมูลจำนวนมากรองรับรูปแบบมาตรฐานที่มีเครื่องหมายขีดกลาง ซึ่งคนมองออกได้ง่ายกว่าและมีโอกาสสับสนกับค่าเลขฐานสิบหกอื่นน้อยกว่า

ใช้ UUID v4 เป็นรหัสผ่านหรือข้อมูลลับของ API ได้ไหม?

ไม่ได้ ตัวระบุกับข้อมูลลับมีวัตถุประสงค์ต่างกัน การสร้าง UUID บางระบบอาจใช้ข้อมูลสุ่มที่เหมาะสม แต่รูปแบบ UUID เองไม่ได้รับประกันข้อกำหนดด้านการจัดการ การรักษาความลับ หรือเอนโทรปีสำหรับรหัสผ่าน โทเค็นเซสชัน และข้อมูลรับรอง API ควรสร้างข้อมูลรับรองหรือโทเค็นด้วยกลไกที่ออกแบบมาเพื่อจุดประสงค์นั้น ไม่ใช่ตัวสร้าง UUID v4

UUID v4 ถือเป็นข้อมูลส่วนบุคคลตาม PDPA ได้ไหม?

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

ใช้ UUID v4 เป็นคีย์หลักของฐานข้อมูลได้ไหม?

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