ULID Generator: ตัวระบุที่สั้นกว่า เรียงลำดับได้ ไม่รู้สึกตัว
เครื่องมือสร้าง ULID ในหน้านี้แตกต่างจากหน้า UUID หรือ NanoID ตรงที่ ULID เป็นฟอร์แมตที่ออกแบบมาให้สั้นกว่า UUID (26 ตัวอักษร เทียบ 36) แต่ยังคงพื้นที่ 128 บิตไว้ครบถ้วน ULID ใช้เฉพาะอักษร Crockford base32 ทำให้เป็น case‑insensitive (ไม่แยกตัวพิมพ์เล็กใหญ่) และไม่มียัติภังค์ ไม่มี toggle ให้เลือก เพราะ ULID มีโครงสร้างตายตัว ส่วนสำคัญที่สุดคือ ULID เรียงลำดับตามเวลาที่สร้างได้ เพราะ 10 ตัวอักษรแรกคือ timestamp ความละเอียดระดับมิลลิวินาที
โครงสร้างภายในของ ULID: 48 บิตเวลา + 80 บิตสุ่ม
ULID 128 บิต แบ่งเป็นสองส่วน:
- ส่วนเวลา (48 บิต) → แทนค่า timestamp ตั้งแต่ epoch (Unix time) หน่วยมิลลิวินาที เก็บเป็นเลขจำนวนเต็ม 48 บิต แล้วเข้ารหัสด้วย Crockford base32 ได้ 10 ตัวอักษร
- ส่วนสุ่ม (80 บิต) → เกิดจาก
crypto.getRandomValues()ในเบราว์เซอร์ ให้เอนโทรปี 80 บิต เข้ารหัส base32 ได้อีก 16 ตัวอักษร รวมเป็น 26 ตัวอักษร
เพราะ timestamp อยู่ด้านหน้า ทำให้ ULID เรียงตามลำดับเวลาได้ตามธรรมชาติ เมื่อเรียงตามพจนานุกรม (lexicographic sort) ก็จะเรียงตามเวลาสร้างจากน้อยไปมาก ซึ่งต่างจาก UUID v4 ที่สุ่มล้วน ๆ
Crockford base32: ทำไมไม่ใช่ I L O U
Crockford base32 ใช้ตัวอักษรต่างจาก base32 ทั่วไป คือใช้ 0123456789ABCDEFGHJKMNPQRSTVWXYZ (ไม่ใช้ I, L, O, U) เพื่อหลีกเลี่ยงความสับสน เช่น I กับ 1, L กับ 1, O กับ 0, U กับ V นอกจากนี้ยังไม่区分ตัวพิมพ์เล็กใหญ่ (case‑insensitive) ทำให้มนุษย์อ่านและพิมพ์ผิดน้อยลง
ตัวอย่าง:
- UUID:
550e8400-e29b-41d4-a716-446655440000(36 ตัว, มี hyphen) - ULID:
01ARZ3NDEKTSV4RRFFQ69G5FAV(26 ตัว, ไม่มี hyphen)
ทั้งสองมี 128 บิตเท่ากัน แต่ ULID สั้นกว่าเกือบ 30%
การเรียงลำดับตามเวลา: ข้อดีและข้อควรระวัง
ULID เรียงตามเวลาที่สร้างได้อย่างแม่นยำ เนื่องจาก timestamp 10 ตัวแรกเพิ่มขึ้นเรื่อย ๆ แต่ข้อจำกัดคือ ULID ไม่รับประกันลำดับเมื่อสร้างหลาย ID ในมิลลิวินาทีเดียวกัน เพราะส่วนสุ่ม 80 บิตไม่ได้ขึ้นกับเวลา ดังนั้นหากสร้าง 100 ULID ใน millisecond เดียวกัน ID ที่ได้จะไม่เรียงตามลำดับการสร้างภายใน millisecond นั้น แต่เมื่อเรียง lexicographic จะยังคงกลุ่ม ID ที่เกิดใน millisecond ไว้ติดกัน
สำหรับการใช้งานเป็น primary key ในฐานข้อมูล (เช่น B‑tree) การเพิ่มขึ้นโดยประมาณ (monotonic) ยังช่วยลดการแตกแยกของ index เมื่อเทียบกับ UUID v4 ที่สุ่มโดยสมบูรณ์
วิธีใช้หน้า ulid-generator
หน้าให้เลือกฟอร์แมต "ULID" และกำหนดจำนวนตั้งแต่ 1 ถึง 100 เมื่อกดสร้างจะได้รายการ ULID ตามจำนวนที่ระบุ สถานะแสดง "พร้อม" "สร้างแล้ว" และ "คัดลอกทั้งหมด!" เมื่อกดคัดลอกทีเดียว ทั้งหมดถูกสร้างในเบราว์เซอร์ด้วย crypto.getRandomValues() ไม่มีการส่งข้อมูลไปเซิร์ฟเวอร์
ข้อควรรู้:
- ถ้าเปลี่ยนจำนวน (นับ) หรือเปลี่ยนฟอร์แมตเป็นอย่างอื่น รายการจะถูกสร้างใหม่ทันที
- คลิกที่ ULID แต่ละตัวเพื่อคัดลอกเดี่ยว
- ไม่มีตัวเลือกให้เพิ่ม hyphen หรือเปลี่ยนเป็นตัวพิมพ์ใหญ่ เพราะ ULID ไม่มี hyphen และ case‑insensitive อยู่แล้ว
- จำนวนที่ยอมรับคือ 1–100 ถ้านอกช่วงจะไม่ถูกสร้าง
ความน่าจะเป็นในการชนและความปลอดภัยในการสร้างเฉพาะที่ (Local Generation)
ULID มีพื้นที่ 80 บิตสุ่ม ทำให้โอกาสเกิดซ้ำ (collision) ต่ำมาก ในทางปฏิบัติ หากสร้าง 1 ล้าน ID ต่อวินาที โอกาสชนใน 100 ปีมีเพียง ~1 ใน 4.3×10¹³ (จากสูตร Birthday problem โดยประมาณ) แม้จะสร้างจำนวนมากภายในมิลลิวินาทีเดียวกันก็ยังปลอดภัย
การสร้างในเบราว์เซอร์ใช้ crypto.getRandomValues() ซึ่งเป็นตัวสร้างเลขสุ่มที่แข็งแกร่งระดับระบบปฏิบัติการ ไม่ต้องพึ่งพาเซิร์ฟเวอร์ ทำให้ไม่มีความเสี่ยงในการรั่วไหลของข้อมูลผ่านเครือข่าย และเหมาะกับแอปพลิเคชันที่ต้องทำงานออฟไลน์หรือมีความเป็นส่วนตัว
ใครควรใช้ ULID และข้อควรระวัง
| ผู้ใช้ | เหตุผล |
|---|---|
| นักพัฒนาเว็บ/มือถือ | ต้องการ ID สั้นกว่า UUID แต่ยังเรียงตามเวลาได้ |
| DBA / นักออกแบบฐานข้อมูล | ต้องการ primary key ที่เพิ่มขึ้นแบบ monotonic เพื่อลด index fragmentation |
| สถาปนิกระบบ distributed | ต้องการ ID ไม่ซ้ำข้ามโหนด และเรียงลำดับการสร้างได้โดยไม่ต้องมี timestamp แยก |
| นักออกแบบ API | ต้องการ ID ที่อ่านง่าย ไม่มี hyphen, case‑insensitive, URL-safe (ไม่ต้อง percent-encode) |
ข้อควรระวัง:
- หากต้องการลำดับที่เคร่งครัดภายใน millisecond ULID ไม่เหมาะ (แต่ UUID v7 ก็มีปัญหาเดียวกัน)
- การใช้ ULID เป็นส่วนหนึ่งของ URL ที่เปิดเผยอาจเปิดเผยเวลาสร้างโดยประมาณ (timestamp) ซึ่งอาจเป็นความเสี่ยงด้านความปลอดภัยในบางกรณี
คำถามที่พบบ่อย (FAQ)
1. ULID ปลอดภัยกว่า UUID หรือไม่? ทั้งคู่สุ่ม 128 บิต (สำหรับ ULID 80 บิตสุ่ม, UUID v4 122 บิตสุ่ม) ULID ใช้ 80 บิตสุ่ม + 48 บิตเวลา ซึ่งยังเพียงพอสำหรับการไม่ซ้ำในทางปฏิบัติ เอนโทรปี 80 บิตยังมากพอที่จะป้องกันการคาดเดาได้ดี
2. สามารถสร้าง ULID แล้วคัดลอกทั้งหมดไปใช้ทันทีได้หรือไม่? ได้ เมื่อกด "คัดลอกทั้งหมด!" รายการจะถูกคัดลอกเป็นข้อความคั่นบรรทัดใหม่ พร้อมแสดงข้อความ "Copied all!" หากคลิกทีละตัวจะคัดลอกเฉพาะ ID นั้น
3. ULID 26 ตัวอักษรนี้ใช้กับ Unicode ได้หรือไม่? ไม่ ULID เกิดจากการ encode ข้อมูลไบนารี 128 บิตด้วย Crockford base32 ซึ่งใช้เฉพาะอักขระ ASCII (0-9, A-Z) ดังนั้น ULID จึงเป็น ASCII ล้วน ไม่เกี่ยวข้องกับ Unicode
4. ถ้าสร้าง 100 ULID ใน millisecond เดียวกัน โอกาสซ้ำสูงหรือไม่? ต่ำมาก 80 บิตสุ่มให้ช่องว่าง 2^80 ≈ 1.2×10^24 ค่า แม้สร้าง 100 ID ใน millisecond เดียวกัน โอกาสชนยังน้อยกว่า 1 ใน 10^20 โดยประมาณ
5. ULID แตกต่างจาก UUID v7 อย่างไร? UUID v7 ก็มี timestamp 48 บิต + สุ่ม แต่ UUID v7 ใช้ random bits แค่ 74 บิต (รวมแล้ว 122 บิตสุ่ม) และใช้รูปแบบ 36 ตัวอักษรมี hyphen ULID ใช้ 80 บิตสุ่ม และยาว 26 ตัวอักษร ไม่มี hyphen ทำให้สั้นกว่าและอ่านง่ายกว่า
6. ฉันสามารถใช้ ULID ในการสร้าง ID สำหรับผู้ใช้หรือ session ได้หรือไม่? ได้ แต่ควรระวังว่าส่วน timestamp อาจเปิดเผยเวลาที่สร้าง ผู้ใช้ที่สังเกตอาจเดาช่วงเวลาได้ สำหรับ session ที่ต้องการความเป็นส่วนตัวสูง ควรใช้ random ID แทน