ToolDeck

เครื่องสร้าง UUID v3

สร้าง UUID v3 แบบ deterministic ตามชื่อโดยใช้ MD5

Namespace

6ba7b810-9dad-11d1-80b4-00c04fd430c8

ชื่อ

UUID v3 ที่สร้างแล้ว

ป้อนชื่อแล้วคลิกสร้าง
Namespace + ชื่อเดิมจะได้ UUID เดิมเสมอ
Note:UUID v3 เป็นรูปแบบ legacy ที่ใช้ MD5 hashing สำหรับการพัฒนาใหม่ที่ต้องการ UUID แบบ deterministic ควรใช้ UUID v5 (SHA-1) สำหรับ unique ID ทั่วไป ใช้ UUID v4

UUID v3 คืออะไร?

UUID v3 คือ UUID version name-based ที่กำหนดใน RFC 4122 แทนที่จะใช้ข้อมูลสุ่มหรือ timestamp มันได้ UUID แบบ deterministic จากสองอินพุต: UUID namespace และ string name คู่ namespace + name ถูก hash ด้วย MD5 และ hash ที่ได้ format เป็น UUID

คุณสมบัติหลักของ UUID v3 คือ determinism: namespace และ name เดิมจะให้ UUID เดิมเสมอ บนเครื่องใดก็ตาม ในเวลาใดก็ตาม ทำให้เหมาะสำหรับ content-addressing — การสร้าง identifier ที่เสถียรสำหรับ resource ที่ระบุด้วยชื่อที่มีความหมาย

UUID v3 ใช้ MD5 เป็น hash function MD5 ถือว่าเสียหายทางการเข้ารหัสสำหรับวัตถุประสงค์ด้านความปลอดภัย ซึ่งเป็นเหตุผลที่ UUID v5 (ใช้ SHA-1) มักถูกแนะนำสำหรับการพัฒนาใหม่ ทั้ง v3 และ v5 ไม่มีความสุ่มเลย — เป็น deterministic ล้วน

Namespace มาตรฐาน

RFC 4122 กำหนด namespace UUID ที่กำหนดไว้ล่วงหน้าสี่รายการ การใช้ namespace มาตรฐานรับประกันความสามารถทำงานร่วมกัน — สอง implementation อิสระจะสร้าง UUID v3 เดิมสำหรับ name เดิมใน namespace เดิม:

NamespaceUUIDใช้สำหรับ
DNS6ba7b810-9dad-11d1-80b4-00c04fd430c8Fully qualified domain name (เช่น 'example.com')
URL6ba7b811-9dad-11d1-80b4-00c04fd430c8URL และ URI (เช่น 'https://example.com/resource')
OID6ba7b812-9dad-11d1-80b4-00c04fd430c8ISO Object Identifier (เช่น '1.2.840.113556')
X.5006ba7b814-9dad-11d1-80b4-00c04fd430c8X.500 Distinguished Name (เช่น 'cn=John,dc=example,dc=com')

คุณยังสามารถใช้ UUID ใดก็ตามเป็น custom namespace เช่น UUID v4 ที่คุณสร้างครั้งเดียวและฝังในแอปพลิเคชันเป็นค่าคงที่ ทำให้คุณสร้าง private namespace สำหรับ name-to-UUID mapping ของตัวเอง

UUID v3 vs UUID v5

UUID v3 และ UUID v5 มีโครงสร้างเหมือนกัน — ทั้งคู่เป็น UUID แบบ deterministic, name-based ความแตกต่างเดียวคือ hash function:

UUID v3
  • ใช้ MD5 hashing
  • output 128 บิต (ขนาด UUID)
  • กำหนดใน RFC 4122
  • MD5 เสียหายทางการเข้ารหัส
  • รองรับโดย UUID library ทั้งหมด
UUID v5
  • ใช้ SHA-1 hashing
  • SHA-1 hash 160 บิตตัดทอนเหลือ 128 บิต
  • กำหนดใน RFC 4122
  • SHA-1 เลิกใช้สำหรับด้านความปลอดภัยแต่แข็งแกร่งกว่า MD5
  • รองรับโดย UUID library ทั้งหมด

เลือก UUID v5 แทน UUID v3 สำหรับการพัฒนาใหม่ทั้งหมด SHA-1 hash แข็งแกร่งกว่า MD5 และความแตกต่างด้านประสิทธิภาพไม่มีนัยสำคัญ ใช้ UUID v3 เฉพาะเมื่อต้องสร้าง UUID ซ้ำจากระบบที่ใช้มันอยู่แล้ว

เมื่อไรควรใช้ UUID v3

UUID v3 (และ v5) เหมาะเมื่อต้องการ identifier ที่เสถียรและสร้างซ้ำได้จากชื่อที่มีความหมาย แทนที่จะเป็น random ID ที่ต้องเก็บและค้นหา:

URL canonicalization
สร้าง UUID แบบ deterministic สำหรับ URL ใดๆ เพื่อใช้เป็น key ขนาดคงที่กระชับในฐานข้อมูลหรือ cache โดยไม่ต้องเก็บ mapping table
DNS-based identifier
กำหนด UUID ที่เสถียรให้ hostname หรือ domain name ที่สอดคล้องกันใน deployment และฐานข้อมูลต่างๆ
Content addressing
สร้าง ID ที่สร้างซ้ำได้สำหรับ content item ที่ระบุด้วยชื่อ canonical — บทความ, ผลิตภัณฑ์ หรือ configuration key
Idempotent resource creation
สร้าง UUID เดิมสำหรับชื่อ resource เดิม ดังนั้นความพยายามสร้างซ้ำๆ จึงเป็น idempotent ตามธรรมชาติโดยไม่ต้องค้นหา
Test fixture
สร้าง UUID ที่เสถียรและคาดเดาได้ใน test data เพื่อให้ test assertion ไม่ต้องอัปเดตเมื่อรัน test ซ้ำ
Cross-system deduplication
สองระบบอิสระสามารถได้ UUID เดิมสำหรับชื่อเดิมโดยไม่ต้องสื่อสาร ช่วย deduplication โดยไม่ต้องมี ID registry ที่ใช้ร่วมกัน

เข้าใจ Determinism

Determinism ของ UUID v3 เป็นทั้งจุดแข็งที่ยิ่งใหญ่ที่สุดและข้อจำกัดที่สำคัญที่สุด ด้วย namespace UUID ใดก็ตาม และ name string ใดก็ตาม UUID output จะ fixed อย่างสมบูรณ์ — ไม่มีความสุ่มเข้ามาเกี่ยวข้อง ซึ่งหมายความว่า:

ตัวอย่าง (DNS namespace, name = 'example.com'):9073926b-929f-31c2-abc9-fad77ae3e8eb

ให้เสมอ: 9073926b-929f-31c2-abc9-fad77ae3e8eb

หากผู้โจมตีรู้ namespace และสามารถเดา name ได้ พวกเขาสามารถคำนวณ UUID ล่วงหน้าได้ ค่า UUID v3 ไม่ควรใช้เป็น token ที่ไม่สามารถคาดเดา, session ID หรือ secret ใช้ UUID v4 สำหรับ identifier ที่ sensitive ด้านความปลอดภัย

ตัวอย่างโค้ด

UUID v3 ต้องการ namespace UUID และ name string ใช้ standard package uuid:

JavaScript / Node.js
// Browser / Node.js — UUID v3 without dependencies
function uuidV3(namespace, name) {
  // namespace must be a UUID string like '6ba7b810-9dad-11d1-80b4-00c04fd430c8'
  const nsBytes = namespace.replace(/-/g, '').match(/../g).map(h => parseInt(h, 16))
  const nameBytes = [...new TextEncoder().encode(name)]
  const combined = new Uint8Array([...nsBytes, ...nameBytes])

  // md5(combined) — use your preferred MD5 library or the inline implementation
  const hash = md5(combined) // returns Uint8Array(16)
  hash[6] = (hash[6] & 0x0f) | 0x30 // version 3
  hash[8] = (hash[8] & 0x3f) | 0x80 // variant

  const h = [...hash].map(b => b.toString(16).padStart(2, '0')).join('')
  return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`
}

// Using the 'uuid' npm package
import { v3 as uuidv3 } from 'uuid'
const DNS = '6ba7b810-9dad-11d1-80b4-00c04fd430c8'
console.log(uuidv3('example.com', uuidv3.DNS))
// → '9073926b-929f-31c2-abc9-fad77ae3e8eb' (always the same)
Python
import uuid

# Using the standard library
dns_uuid = uuid.uuid3(uuid.NAMESPACE_DNS, 'example.com')
print(dns_uuid)
# → 9073926b-929f-31c2-abc9-fad77ae3e8eb

url_uuid = uuid.uuid3(uuid.NAMESPACE_URL, 'https://example.com/page')
print(url_uuid)

# Custom namespace
MY_NS = uuid.UUID('a1b2c3d4-e5f6-7890-abcd-ef1234567890')
custom = uuid.uuid3(MY_NS, 'my-entity-name')
print(custom)
Go
package main

import (
    "fmt"
    "github.com/google/uuid"
)

func main() {
    // Standard DNS namespace
    ns := uuid.MustParse("6ba7b810-9dad-11d1-80b4-00c04fd430c8")
    id := uuid.NewMD5(ns, []byte("example.com"))
    fmt.Println(id)
    // → 9073926b-929f-31c2-abc9-fad77ae3e8eb

    // URL namespace
    urlNS := uuid.MustParse("6ba7b811-9dad-11d1-80b4-00c04fd430c8")
    idURL := uuid.NewMD5(urlNS, []byte("https://example.com/page"))
    fmt.Println(idURL)
}

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

UUID v3 และ UUID v5 แทนกันได้ไหม?
ไม่ — พวกมัน output ต่างกันสำหรับ input เดิมเพราะใช้ hash function ต่างกัน (MD5 vs SHA-1) UUID v3 และ UUID v5 ที่สร้างจาก namespace + name เดิมจะเป็น UUID ต่างกัน ไม่สามารถแทนกันได้ แต่มีโครงสร้างและ use case ที่เทียบเท่ากันในเชิงฟังก์ชัน
UUID v3 ต้านทาน collision ได้ไหม?
ภายใน namespace ที่กำหนด สอง name ที่ต่างกันจะให้ค่า UUID v3 ต่างกันตราบที่ MD5 ไม่ collision สำหรับ input เหล่านั้น การโจมตี MD5 collision มีอยู่ แต่ต้องการ input ที่สร้างขึ้นอย่างระมัดระวัง ในทางปฏิบัติ name ที่เกิดขึ้นตามธรรมชาติ (URL, domain name, product ID) จะไม่ collision สำหรับความน่าเชื่อถือสูงกว่า ใช้ UUID v5
สามารถใช้ UUID v3 เป็น primary key ในฐานข้อมูลได้ไหม?
ใช่ หากเข้าใจ trade-off UUID v3 เป็น deterministic ดังนั้น key เดิมจะสร้างสำหรับชื่อเดิม — ให้ idempotency ตามธรรมชาติ อย่างไรก็ตาม UUID v3 ไม่เรียงลำดับตาม generation order และการ fragmentation ของ index ใช้เหมือนกับ UUID v4 สำหรับ primary key ที่เรียงตามเวลาได้ ใช้ UUID v7
ควรใช้ encoding ใดสำหรับ name input?
RFC 4122 ระบุว่า name ควรแปลงเป็น bytes โดยใช้ canonical form ของ namespace สำหรับ DNS namespace ใช้ domain name เป็น UTF-8 string โดยไม่มีจุดท้าย สำหรับ URL namespace ใช้ URL เต็มเป็น UTF-8 string ใช้ encoding เดิมสม่ำเสมอเสมอ — encoding ต่างกันของ name ตรรกะเดิมจะให้ UUID ต่างกัน
UUID v3 ซ่อน name ดั้งเดิมไหม?
MD5 เป็น one-way function — คุณไม่สามารถย้อนกลับ UUID v3 เพื่อกู้คืน name ดั้งเดิม อย่างไรก็ตาม หากผู้โจมตีรู้ namespace และสงสัย name ที่เป็นไปได้จำนวนน้อย พวกเขาสามารถคำนวณล่วงหน้าค่า UUID v3 สำหรับผู้สมัครแต่ละคนและเปรียบเทียบ สำหรับ name จากพื้นที่ขนาดเล็กหรือคาดเดาได้ UUID v3 ไม่มีการรักษาความลับ ใช้ UUID v4 หากต้องการ identifier ที่ทึบแสงและไม่สามารถเดาได้

เครื่องมือที่เกี่ยวข้อง