Trình tạo UUID miễn phí

Về UUID

UUID (Universally Unique Identifier, Định danh duy nhất toàn cầu) là một định danh 128-bit được thiết kế để duy nhất trên cả không gian và thời gian. Phiên bản phổ biến nhất, UUID v4, được tạo bằng các số ngẫu nhiên hoặc giả ngẫu nhiên. Định dạng là 8-4-4-4-12 ký tự thập lục phân, ví dụ 550e8400-e29b-41d4-a716-446655440000.

Lịch sử bốn thập niên, từ Apollo đến RFC 9562

Khái niệm UUID ra đời trong Apollo Network Computing System (NCS) giữa thập niên 1980, do Paul Leach và Rich Salz thiết kế tại Apollo Computer để hỗ trợ tính toán phân tán không có đăng ký trung tâm. Định dạng được Open Software Foundation Distributed Computing Environment (OSF DCE) chấp nhận năm 1989 và chuẩn hóa quốc tế năm 1995 dưới ITU-T X.667 / ISO/IEC 9834-8. IETF tích hợp đặc tả vào RFC 4122 (Leach, Mealling, Salz) tháng 7 năm 2005, trở thành tham chiếu kinh điển trong hai thập niên. RFC 4122 được cập nhật bởi RFC 9562 tháng 5 năm 2024, giữ mọi phiên bản gốc (v1 đến v5), thêm ba phiên bản mới (v6, v7, v8), và chính thức định nghĩa các hằng đặc biệt "Nil UUID" (toàn không) và "Max UUID" (toàn một). Dòng dõi phiên bản quan trọng vì mỗi phiên bản đánh đổi tính chất khác: dựa trên thời gian (sắp xếp được, rò rỉ); dựa trên tên (tất định từ đầu vào); ngẫu nhiên (phổ quát, mờ đục); tùy biến (thứ bạn cần). Thực hành tốt nhất hiện đại cho ứng dụng mới đã chuyển từ v4 (ngẫu nhiên) sang v7 (timestamp + ngẫu nhiên) cho khóa chính, trong khi v4 vẫn là câu trả lời đúng cho định danh mờ đục nơi tính sắp xếp được không mong muốn.

Tám phiên bản, bằng tiếng Việt rõ ràng

• v1 (timestamp + địa chỉ MAC). 60 bit timestamp (khoảng 100 nanosecond từ epoch Gregorian 1582) cộng địa chỉ MAC của máy gốc. Bất lợi lớn: rò rỉ địa chỉ MAC máy phát sinh, đó là quan ngại quyền riêng tư. Tác giả virus Melissa nổi tiếng được nhận diện năm 1999 phần nào nhờ truy UUID v1 trong tài liệu Word về máy cụ thể.
• v2 (DCE security). Biến thể của v1 bao gồm POSIX UID/GID. Gần như không bao giờ dùng trên thực tế; tài liệu hóa cho đầy đủ.
• v3 (dựa trên tên, MD5). UUID tất định dẫn xuất từ hash MD5 của (UUID namespace + chuỗi tên). Cùng đầu vào luôn cho cùng UUID, hữu ích để dịch khóa tự nhiên (URL, tên miền, distinguished name) sang dạng UUID.
• v4 (ngẫu nhiên). 122 bit ngẫu nhiên (6 bit còn lại là tag phiên bản + variant). Phiên bản dùng rộng nhất, mặc định mà gần như mọi thư viện "cho tôi một UUID" trả về.
• v5 (dựa trên tên, SHA-1). Giống v3 nhưng dùng SHA-1 thay vì MD5. Ưu tiên hơn v3 cho ứng dụng mới vì SHA-1 ít vỡ hơn MD5, dù cả hai đều có tấn công va chạm đã biết.
• v6 (RFC 9562, tháng 5 năm 2024, sắp xếp theo thời gian). Sắp xếp lại các bit timestamp v1 để sắp xếp lexicographic khớp với sắp xếp niên đại. Giải khiếu nại "v1 không sắp xếp theo thời gian"; vẫn rò rỉ địa chỉ MAC theo mặc định.
• v7 (RFC 9562, tháng 5 năm 2024, timestamp Unix + ngẫu nhiên). 48 bit đầu là timestamp Unix theo mili-giây; 74 bit còn lại ngẫu nhiên. Sắp xếp tự nhiên theo thời gian tạo, gồm dữ liệu timestamp mà không rò rỉ định danh máy, và là khuyến nghị hiện đại cho khóa chính cơ sở dữ liệu. Postgres 18+ có uuidv7() tích hợp; SQL Server có NEWSEQUENTIALID() với tính chất tương tự.
• v8 (tùy biến). Dành riêng cho bố cục riêng cho ứng dụng. Trường phiên bản đánh dấu nó là v8 và bit variant được đặt đúng; mọi thứ khác phụ thuộc ứng dụng. Dùng khi bạn phải nhúng dữ liệu có cấu trúc của riêng mình vào phong bì hình UUID.

Vì sao v7 ngày càng được ưa hơn v4 cho khóa cơ sở dữ liệu

Khóa chính ngẫu nhiên (UUID v4) có chi phí hiệu năng được ghi chép kỹ trong cơ sở dữ liệu tổ chức hàng theo khóa chính trong B-tree hoặc index tương tự. Mỗi insert mới đáp xuống vị trí ngẫu nhiên trong index, làm phân mảnh trang index, tăng khuếch đại ghi đĩa, và làm vỡ cache trang vì các hàng vừa insert nằm rải rác trên nhiều trang thay vì gom lại. Khóa tuần tự (số nguyên tự tăng, ULID, UUID v7) đều insert ở cạnh phải của index, giữ working set nhỏ và khuếch đại ghi tối thiểu. Phê bình "anti-pattern khóa ngẫu nhiên" có gốc từ tài liệu SQL Server đầu thập niên về NEWID so với NEWSEQUENTIALID, và được cộng đồng Postgres phát biểu lại cho v4 vs v7. Đánh đổi: v7 rò rỉ thời gian tạo của mỗi hàng, có thể là quan ngại quyền riêng tư hoặc rò rỉ thông tin trong một số ứng dụng (ví dụ bạn có thể nói khi nào tài khoản được tạo bằng cách đọc UUID của nó). Cho phần lớn ứng dụng, lợi hiệu năng vượt rò rỉ timestamp; cho ứng dụng quyền riêng tư cao, v4 vẫn là câu trả lời đúng.

Xác suất va chạm, toán học của paradox sinh nhật

UUID v4 có 122 bit ngẫu nhiên, cho khoảng 5,3 × 10³⁶ giá trị có thể. Paradox sinh nhật nói bạn cần khoảng căn bậc hai kích thước namespace để có 50% cơ hội có va chạm bất kỳ, khoảng 2,3 × 10¹⁸ UUID. Để đặt vào ngữ cảnh người: nếu bạn sinh 1 tỷ UUID mỗi giây liên tục, bạn sẽ cần khoảng 86 năm để có 50% cơ hội của một va chạm duy nhất. Với tốc độ sinh quy mô ứng dụng thông thường (hàng nghìn hay hàng triệu mỗi ngày), rủi ro va chạm thực tế là không. Nguyên nhân có khả năng nhất của "UUID trùng" trong hệ thống thật là một bộ sinh có lỗi dùng Math.random() thay vì CSPRNG, hoặc một bộ sinh có entropy không đủ lúc khởi động, hoặc một tiến trình vô tình seed hai bộ sinh giống nhau, không phải toán học bên dưới. Bộ sinh này dùng crypto.randomUUID() của trình duyệt (nơi có sẵn) hoặc crypto.getRandomValues(), cả hai rút từ CSPRNG của hệ điều hành (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes), cùng nguồn entropy được dùng cho khóa phiên TLS.

Triển khai trình duyệt: crypto.randomUUID()

Web Crypto API phơi crypto.randomUUID() như bộ sinh một-cuộc-gọi trả về chuỗi UUID v4 tuân theo RFC 4122. Nó được giao trong Chrome 92 (tháng 7 năm 2021), Firefox 95 (tháng 12 năm 2021) và Safari 15.4 (tháng 3 năm 2022), và baseline-có-sẵn trong mọi trình duyệt hiện đại từ khoảng 2022. Cho trình duyệt cũ hơn, fallback chuẩn là cấp phát Uint8Array 16 byte, đổ đầy bằng crypto.getRandomValues(), đặt nibble phiên bản thành 4 (nibble cao của byte thứ 7 = 0x40), đặt bit variant thành 10xxxxxx (hai bit cao của byte thứ 9 = 0x80), và định dạng các byte thành chuỗi hex 8-4-4-4-12. Bộ sinh này dùng crypto.randomUUID() khi có và fallback thủ công nếu không, đầu ra giống nhau ở cả hai trường hợp, chỉ chậm hơn chút trên đường fallback. Cả hai đường chạy hoàn toàn trong trình duyệt; không gì đi qua mạng.

Trường hợp dùng và mỗi cái thực sự cần gì

• Khóa chính cơ sở dữ liệu, đặc biệt hệ thống phân tán hoặc shard nơi điều phối bộ đếm số nguyên không thực tế. v7 là khuyến nghị hiện đại; v4 nếu bạn cần độ mờ đục timestamp.
• ID tương quan request API. Mỗi request đến nhận một UUID đi qua mọi dịch vụ phía sau trong chuỗi gọi; log của bất kỳ dịch vụ nào có thể được nối lại với request gốc qua ID. Stripe, Twilio và AWS X-Ray đều làm vậy.
• Khóa idempotency cho request HTTP. Header Idempotency-Key của Stripe nhận một UUID; nếu client thử lại cùng request với cùng khóa, Stripe trả phản hồi cache thay vì charge thẻ hai lần. Khuôn mẫu này nay là chuẩn giữa các API thanh toán.
• Token phiên, với cảnh báo. UUID v4 là ngẫu nhiên mật mã và có 122 bit entropy, hơn đủ cho ID phiên. Nhưng token phiên chỉ là UUID dễ bị tấn công liệt kê nếu bất kỳ endpoint liên kết nào rò rỉ chúng; thực hành tốt nhất hiện đại là dùng token dài hơn và đã ký (JWT, Paseto) cho trạng thái phiên.
• Tên tệp cho khử trùng upload. Sinh UUID cho mỗi upload, lưu tệp tại /uploads/{uuid}.ext, bạn sẽ không bao giờ có va chạm tên độc lập với tên tệp gốc, và bạn không thể vô tình phục vụ tệp của người dùng khác bằng cách đoán URL.
• ID tin nhắn trong hệ thống sự kiện. Kafka, RabbitMQ, AWS SQS và phần lớn nền tảng pub/sub khuyến nghị một UUID cho mỗi tin nhắn để truy vết và khử trùng; v7 ngày càng là mặc định cho tính chất sắp xếp được theo timestamp.
• Sinh dữ liệu kiểm thử. Thư viện Faker trong mọi ngôn ngữ dùng UUID làm ID mặc định cho hàng kiểm thử sinh ra.
• Định danh nút hệ thống phân tán. Một nút mới khởi động trong cluster sinh UUID cho chính nó; điều phối cluster dùng ID đó để định tuyến lưu lượng và nhận diện nút trong log.

Các phương án thay thế đáng biết

UUID là mặc định phổ quát nhưng không phải lựa chọn duy nhất, và một số phương án đáng biết cho các trường hợp dùng cụ thể. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 bit như UUID, nhưng mã hóa thành 26 ký tự Crockford-Base32 thay vì 32 chữ số hex, gọn hơn và URL-an-toàn không phân biệt hoa thường. 48 bit đầu là timestamp Unix theo mili-giây, nên ULID sắp xếp lexicographic theo thời gian tạo. Khái niệm rất gần UUID v7, có trước nhiều năm. Snowflake (Twitter, 2010): 64 bit, nhỏ hơn UUID rất nhiều, vừa trong BIGINT SQL. 41 bit timestamp + 10 bit ID máy + 12 bit chuỗi mỗi mili-giây. Được Twitter/X, Discord, Instagram, và nhiều hệ thống quy mô lớn nơi khóa chính 64 bit là ràng buộc cứng dùng. KSUID (Segment, 2017): 27 ký tự, timestamp độ chính xác giây + 128 bit ngẫu nhiên. Đánh đổi độ chính xác mili-giây cho biểu diễn chuỗi nhỏ hơn UUID. nanoid (Andrey Sitnik, 2017): thư viện rất nhỏ tạo định danh ngẫu nhiên URL-an-toàn độ dài cấu hình được. Mặc định 21 ký tự cho khả năng chống va chạm tương tự UUID v4 với rất ít byte hơn. Cho URL công khai nơi bạn sẽ nhúng UUID, nanoid ngắn hơn và thân thiện hơn. Đánh đổi: định danh nanoid không có bit đánh dấu phiên bản + variant phân biệt nó là UUID, nên chúng không khớp vào hệ thống mong giá trị hình UUID.

An toàn URL và biến thể định dạng

UUID ở dạng kinh điển có gạch nối (550e8400-e29b-41d4-a716-446655440000) là URL-an-toàn, mọi ký tự (chữ thường, chữ số, gạch nối) nằm trong tập không-dành-riêng định nghĩa bởi RFC 3986. Nghĩa là bạn có thể thả UUID trực tiếp vào path URL hay query string mà không cần percent-encoding. Một số hệ thống bỏ gạch nối cho gọn, tạo chuỗi hex 32 ký tự (550e8400e29b41d4a716446655440000) vẫn URL-an-toàn; chuyển đổi đảo ngược được vì cấu trúc UUID cố định. Một vài hệ thống bọc UUID trong dấu ngoặc nhọn ({550e8400-e29b-41d4-a716-446655440000}), quy ước GUID của Microsoft; ngoặc nhọn trang trí và không bao giờ đi vào URL. Một số hệ thống đặt ký tự hex thành chữ hoa; UUID không phân biệt hoa thường theo đặc tả, nhưng nhất quán trong một hệ thống quan trọng. Bộ sinh này cho ba tùy chọn (chữ hoa, ngoặc nhọn, không gạch nối) cho khả năng tương thích với bất kỳ pipeline nào bạn cấp UUID.

UUID vs GUID, cùng một thứ, tên khác

UUID là thuật ngữ chuẩn được IETF, ISO và phần lớn dự án mã nguồn mở dùng. GUID (Globally Unique Identifier) là thuật ngữ Microsoft dùng trong Windows, .NET, COM/OLE, SQL Server, Active Directory và Windows Registry. Cả hai chỉ về định danh 128 bit giống hệt nhau ở cùng định dạng hex 8-4-4-4-12. Trao đổi được về chức năng, một GUID sinh bởi Windows có thể dùng ở bất cứ đâu mong UUID, và ngược lại. Khác biệt duy nhất cần biết: việc sinh GUID của Microsoft trong lịch sử đã dùng UUID v4 trong nhiều API nhưng UUID v1 (với địa chỉ MAC) trong một số ngữ cảnh COM/OLE cũ; điều này được tài liệu trong đặc tả COM của Microsoft. Nếu bạn nhận GUID từ hệ thống nguồn Microsoft và muốn biết phiên bản nào, kiểm tra nibble phiên bản (ký tự hex thứ 13, '1' cho v1, '4' cho v4, vân vân).

Quyền riêng tư: vì sao chỉ-trong-trình-duyệt quan trọng ngay cả ở đây

Một UUID không có ý nghĩa nội tại, vậy vì sao việc bộ sinh chạy cục bộ quan trọng? Hai lý do. Thứ nhất, khi UUID được dùng làm token phiên, khóa idempotency hay bất kỳ định danh giống bí mật nào, sinh nó trên server bên thứ ba nghĩa là server đó đã thấy giá trị trước khi bạn dùng, một phơi bày nhỏ nhưng có thật. Thứ hai, các bộ sinh phía server hứa "ngẫu nhiên mật mã" không thể được người dùng kiểm chứng; một server có lỗi hoặc độc hại có thể trả về giá trị không-ngẫu-nhiên trông như ngẫu nhiên, và bạn không có cách nào phát hiện lệch. Một bộ sinh chỉ-trình-duyệt thực thi cùng cuộc gọi crypto.randomUUID() mà ứng dụng của bạn sẽ thực thi phía server; entropy đến từ cùng nguồn hệ điều hành (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); không có bên thứ ba nào thấy đầu ra. Bạn có thể kiểm chứng bằng cách mở tab Network của DevTools khi bạn bấm Sinh, không có request đi ra. Đặt trang offline (chế độ máy bay) sau khi đã tải xong và bộ sinh vẫn hoạt động.

Câu hỏi thường gặp

Sự khác biệt giữa UUID và GUID là gì?

Về bản chất, chúng là cùng một thứ. UUID là thuật ngữ tiêu chuẩn (RFC 4122), trong khi GUID (Globally Unique Identifier) là thuật ngữ của Microsoft. Cả hai đều chỉ một định danh 128-bit theo cùng định dạng hex 8-4-4-4-12.

Hai UUID có bao giờ giống nhau không?

Về mặt lý thuyết là có, nhưng xác suất cực kỳ thấp. UUID v4 có 122 bit ngẫu nhiên, cho khoảng 5.3 × 10³⁶ giá trị khả dĩ. Bạn sẽ cần tạo hàng tỷ UUID mỗi giây trong nhiều thập kỷ để có 50% cơ hội xảy ra một va chạm.

Các UUID này có an toàn về mặt mật mã không?

Có. Trình tạo này sử dụng Web Crypto API (crypto.getRandomValues), cung cấp các giá trị ngẫu nhiên mạnh về mặt mật mã. Đầu ra phù hợp cho các trường hợp sử dụng nhạy cảm về bảo mật như token phiên.

Tôi nên dùng UUID v4 hay v7 cho khóa chính cơ sở dữ liệu của mình?

v7 là khuyến nghị hiện đại nếu cơ sở dữ liệu của bạn hỗ trợ. v4 (ngẫu nhiên) insert ở vị trí ngẫu nhiên trong index B-tree, phân mảnh index, và làm vỡ cache trang. v7 (timestamp + ngẫu nhiên, RFC 9562 tháng 5 năm 2024) insert ở cạnh phải của index vì các ID sắp xếp theo thời gian tạo, cùng hiệu năng ghi như số nguyên tự tăng, với tính phân phối và duy nhất của UUID. Postgres 18+ có uuidv7() tích hợp. Đánh đổi: v7 rò rỉ thời gian tạo của mỗi hàng, có thể là quan ngại quyền riêng tư trong một số ứng dụng. Cho phần lớn trường hợp dùng, lợi hiệu năng vượt rò rỉ timestamp.

ULID, KSUID và nanoid là gì?

Các định dạng ID thay thế. ULID (Alex Knol, ~2016): 128 bit như UUID nhưng mã hóa thành 26 ký tự Crockford-Base32; sắp xếp lexicographic theo timestamp. KSUID (Segment, 2017): 27 ký tự, timestamp độ chính xác giây + 128 bit ngẫu nhiên. nanoid (Andrey Sitnik, 2017): thư viện rất nhỏ tạo ID URL-an-toàn ngẫu nhiên độ dài cấu hình được; mặc định 21 ký tự cho khả năng chống va chạm tương tự UUID v4 với rất ít byte hơn. Snowflake (Twitter, 2010): ID 64 bit vừa trong BIGINT SQL, được Twitter, Discord và Instagram dùng. Dùng UUID khi hệ thống nhận mong định dạng UUID; dùng các phương án thay thế khi bạn có yêu cầu cụ thể về kích thước, sắp xếp được hay thân thiện URL.

UUID có được gửi đi đâu không?

Không. Mỗi UUID được sinh cục bộ trong trình duyệt dùng Web Crypto API. Bộ sinh không bao giờ gọi mạng, hãy kiểm chứng trong tab Network của DevTools khi bạn bấm Sinh, hoặc đặt trang offline sau khi đã tải xong và xác nhận công cụ vẫn hoạt động. An toàn để sinh token phiên, khóa idempotency hay định danh khác mà bạn không muốn bên thứ ba thấy giá trị trước bạn.

Công cụ liên quan