Các công cụ UUID của ToolDeck bao gồm tất cả các định dạng mã định danh duy nhất chính trong một nơi. Bộ sưu tập bao gồm: Trình tạo UUID v4 cho ID ngẫu nhiên với độ mạnh mật mã cao; Trình tạo UUID v7 cho khóa chính có thể sắp xếp theo dấu thời gian; Trình tạo UUID v1 cho mã định danh dựa trên thời gian và địa chỉ MAC; Trình tạo UUID v2 cho hệ thống DCE cũ; Trình tạo UUID v3 cho ID xác định dựa trên MD5; Trình tạo ULID cho chuỗi nhỏ gọn có thể sắp xếp; Trình tạo NanoID cho token ngắn an toàn cho URL; Trình tạo CUID cho định dạng gốc chống va chạm; Trình tạo CUID2 cho phiên kế thừa hiện đại; và Bộ giải mã UUID để kiểm tra các mã định danh hiện có. Tất cả công cụ chạy hoàn toàn trong trình duyệt của bạn bằng Web Crypto API — không có dữ liệu nào được truyền đến bất kỳ máy chủ nào, không cần tài khoản.
Công cụ UUID và ID duy nhất là gì?
UUID (Mã định danh duy nhất toàn cầu) là mã định danh 128-bit được chuẩn hóa trong RFC 9562 (trước đây là RFC 4122). Được viết dưới dạng 32 ký tự thập lục phân theo định dạng 8-4-4-4-12, một UUID trông như sau: 550e8400-e29b-41d4-a716-446655440000. Tiêu chuẩn định nghĩa nhiều phiên bản, mỗi phiên bản sử dụng chiến lược khác nhau để đảm bảo tính duy nhất: số ngẫu nhiên, dấu thời gian, hoặc băm xác định.
UUID được thiết kế để các hệ thống phân tán có thể tạo mã định danh mà không cần bộ điều phối trung tâm. Dù bạn đang gán khóa chính trong PostgreSQL, tạo token phiên trong ứng dụng web, hay đặt tên tệp trong lưu trữ đối tượng — UUID cho phép mỗi nút trong hệ thống của bạn tạo ID duy nhất toàn cầu một cách độc lập, với xác suất va chạm thấp đến mức không đáng kể trong thực tế.
Ngoài tiêu chuẩn UUID, một số định dạng ID duy nhất thay thế đã xuất hiện để giải quyết các hạn chế cụ thể: ULID và UUID v7 thêm khả năng sắp xếp từ điển để nâng cao hiệu quả chỉ mục cơ sở dữ liệu; NanoID giảm kích thước cho URL và cookie; CUID2 ưu tiên khả năng chống va chạm dựa trên dấu vân tay cho việc tạo khối lượng lớn ở phía máy khách.
Tại sao dùng công cụ UUID trên ToolDeck?
Các công cụ UUID của ToolDeck chạy hoàn toàn trong trình duyệt của bạn. Không có lệnh gọi API, không xử lý phía máy chủ, không ghi dữ liệu. Mỗi trình tạo sử dụng Web Crypto API (crypto.getRandomValues) để có entropy mạnh về mặt mật mã — cùng nguồn mà các trình duyệt sử dụng cho vật liệu khóa TLS.
🔐Entropy mạnh về mặt mật mã
Tất cả các trình tạo dựa trên tính ngẫu nhiên (UUID v4, NanoID, CUID2) sử dụng crypto.getRandomValues, không phải Math.random. Đầ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 và khóa API.
📦Tất cả định dạng ID chính trong một nơi
UUID v1 đến v7, ULID, NanoID, CUID và CUID2 — mọi định dạng mà lập trình viên cần, với các tùy chọn tạo hàng loạt và sao chép chỉ với một cú nhấp chuột.
🔍Giải mã và kiểm tra ID hiện có
Bộ giải mã UUID trích xuất phiên bản, biến thể, dấu thời gian và các trường nút từ bất kỳ UUID nào. Hữu ích để gỡ lỗi, kiểm toán và hiểu các ID cũ trong codebase của bạn.
⚡Không cần cài đặt, hoạt động ngoại tuyến
Không cài đặt, không đăng ký, không có phụ thuộc thời gian chạy. Mở trang và tạo. Tất cả công cụ hoạt động ngoại tuyến sau khi trang đã tải — hữu ích trong môi trường bị cách ly hoặc mạng bị hạn chế.
Các trường hợp sử dụng công cụ UUID
Mã định danh duy nhất xuất hiện ở mọi tầng của stack. Dưới đây là cách các vai trò khác nhau sử dụng công cụ tạo UUID:
Khóa chính cơ sở dữ liệu
Kỹ sư backend gán UUID v4 hoặc UUID v7 làm khóa chính trong PostgreSQL, MySQL và MongoDB. Tiền tố dấu thời gian của UUID v7 giữ các hàng được sắp xếp vật lý trên đĩa, tránh phân trang trong các workload có nhiều thao tác chèn.
Trạng thái Frontend và ID Component
Lập trình viên frontend sử dụng NanoID hoặc UUID v4 để tạo React key ổn định cho các mục danh sách được tạo động, ID dialog cho các thuộc tính trợ năng ARIA, và token idempotency cho việc gửi biểu mẫu.
Luồng sự kiện phân tán
Trong các hệ thống hướng sự kiện, mỗi sự kiện cần một ID duy nhất toàn cầu và có thể sắp xếp. Kỹ sư DevOps và nền tảng sử dụng ULID hoặc UUID v7 để người tiêu dùng Kafka, bộ tổng hợp nhật ký và audit trail có thể được sắp xếp theo thời gian tạo mà không cần trường dấu thời gian phụ.
Tạo dữ liệu kiểm thử
Kỹ sư QA tạo hàng loạt UUID để điền vào cơ sở dữ liệu kiểm thử với các ID thực tế và không tuần tự. UUID v3 hoặc v5 xác định cho phép tái tạo cùng một ID từ đầu vào đã biết — hữu ích cho các fixture kiểm thử có thể tái tạo.
ID tương quan Microservice
Gắn UUID vào mỗi yêu cầu HTTP đến và truyền nó qua các cuộc gọi dịch vụ (header X-Request-ID) cho phép các hệ thống theo dõi phân tán tương quan nhật ký giữa các dịch vụ. UUID v4 là tiêu chuẩn thực tế để tương quan yêu cầu.
Đặt tên tài nguyên và tài sản
Khóa lưu trữ đối tượng (S3, GCS, Cloudflare R2) và tên tệp tài sản CDN thường nhúng UUID để ngăn va chạm cache và đoán URL. Định dạng nhỏ gọn 21 ký tự của NanoID giảm độ dài URL so với UUID đầy đủ 36 ký tự.
Tham chiếu phiên bản và định dạng UUID
Bảng dưới đây so sánh tất cả các phiên bản UUID cùng với các phương án thay thế được sử dụng rộng rãi nhất. Dùng để nhanh chóng xác định định dạng phù hợp với yêu cầu của bạn.
| Mã định danh | Thuật toán | Có thể sắp xếp | Xác định | Tốt nhất cho |
|---|
| UUID v4 | Ngẫu nhiên (CSPRNG) | — | — | ID đa dụng, token phiên, khóa chính |
| UUID v7 | Dấu thời gian Unix ms + ngẫu nhiên | ✓ | — | Khóa chính có thể sắp xếp, ID sự kiện phân tán (RFC 9562) |
| UUID v1 | Dấu thời gian + địa chỉ MAC | ✓ | — | ID theo thứ tự thời gian, hệ thống một nút, tương thích cũ |
| UUID v3 | Namespace + tên + MD5 | — | ✓ | ID có thể tái tạo từ đầu vào đã biết (DNS, URL) |
| UUID v5 | Namespace + tên + SHA-1 | — | ✓ | Giống v3 với băm mạnh hơn; ưu tiên v5 hơn v3 |
| UUID v2 | Dấu thời gian + DCE UID/GID | ✓ | — | Môi trường POSIX/DCE cũ; tránh cho dự án mới |
| ULID | Tiền tố dấu thời gian + ngẫu nhiên | ✓ | — | ID có thể sắp xếp, an toàn cho URL, không có dấu gạch ngang (26 ký tự) |
| NanoID | Ngẫu nhiên (CSPRNG), bảng chữ cái an toàn cho URL | — | — | ID ngắn cho URL, cookie, thuộc tính HTML (21 ký tự) |
| CUID2 | Dấu vân tay + dấu thời gian + ngẫu nhiên | — | — | Tạo khối lượng lớn phía máy khách, chống va chạm |
UUID v3 và v5 là xác định: cùng namespace + tên luôn tạo ra cùng UUID. Tất cả các định dạng khác tạo giá trị mới trong mỗi lần gọi.
Cách chọn công cụ UUID phù hợp
Mã định danh phù hợp phụ thuộc vào yêu cầu về khả năng sắp xếp, kích thước và tính xác định của bạn. Dùng hướng dẫn quyết định này:
- 1
Nếu bạn cần ID duy nhất đa dụng không có yêu cầu đặc biệt → Trình tạo UUID v4 - 2
Nếu bạn cần ID sắp xếp theo thứ tự thời gian và tương thích với tiêu chuẩn UUID → Trình tạo UUID v7 - 3
Nếu bạn cần ID theo thứ tự thời gian với dấu thời gian nhúng cho hệ thống một nút hoặc đồng thời thấp → Trình tạo UUID v1 - 4
Nếu bạn cần ID có thể sắp xếp, an toàn cho URL và không có dấu gạch ngang → Trình tạo ULID - 5
Nếu bạn cần ID nhỏ gọn, an toàn cho URL ngắn hơn UUID đầy đủ → Trình tạo NanoID - 6
Nếu bạn đang tạo nhiều ID phía máy khách và cần khả năng chống va chạm mạnh → Trình tạo CUID2 - 7
Nếu bạn cần định dạng CUID v1 để tương thích với các hệ thống hiện có dựa trên đặc tả gốc → Trình tạo CUID - 8
Nếu bạn cần tái tạo cùng ID một cách xác định từ namespace và tên → Trình tạo UUID v3 - 9
Nếu bạn đang làm việc với hệ thống DCE hoặc POSIX cũ yêu cầu mã định danh v2 → Trình tạo UUID v2 - 10
Nếu bạn có UUID hiện có và muốn kiểm tra phiên bản, biến thể hoặc dấu thời gian của nó → Bộ giải mã UUID
Cả UUID v7 và ULID đều cung cấp tiền tố dấu thời gian với độ chính xác mili giây và khả năng sắp xếp từ điển. Sự khác biệt chính: UUID v7 sử dụng định dạng UUID chuẩn (8-4-4-4-12, 36 ký tự) để đạt khả năng tương thích hệ sinh thái tối đa, trong khi ULID sử dụng mã hóa Base32 tùy chỉnh (26 ký tự, an toàn cho URL, không có dấu gạch ngang). Nếu cơ sở dữ liệu, ORM hoặc framework của bạn hỗ trợ cột UUID một cách tự nhiên, hãy ưu tiên UUID v7. Nếu bạn cần ID ngắn hơn mà không có ràng buộc framework, ULID nhỏ gọn hơn.
Câu hỏi thường gặp
UUID là gì?
UUID (Mã định danh duy nhất toàn cầu) là giá trị 128-bit được chuẩn hóa trong RFC 9562. Được viết dưới dạng 32 chữ số thập lục phân trong năm nhóm được phân tách bằng dấu gạch ngang: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Tiêu chuẩn định nghĩa nhiều phiên bản với các chiến lược tính duy nhất khác nhau — ngẫu nhiên (v4), dựa trên dấu thời gian (v1, v7), hoặc xác định dựa trên tên (v3, v5).
Sự khác biệt giữa UUID v4 và UUID v7 là gì?
UUID v4 điền tất cả 122 bit không cố định với dữ liệu ngẫu nhiên từ nguồn an toàn mật mã. UUID v7 mã hóa dấu thời gian Unix 48-bit tính bằng mili giây vào 48 bit đầu tiên, theo sau là các bit ngẫu nhiên. Kết quả: UUID v7 sắp xếp theo thứ tự thời gian như chuỗi thông thường, giúp chỉ mục B-tree cơ sở dữ liệu được sắp xếp khi chèn. UUID v7 được thêm vào RFC 9562 (tháng 4 năm 2024) và là lựa chọn ưu tiên cho khóa chính cơ sở dữ liệu mới.
Các giá trị UUID v4 có an toàn về mặt mật mã không?
Các giá trị UUID v4 được tạo bằng bộ tạo số giả ngẫu nhiên an toàn mật mã (CSPRNG). Chúng phù hợp làm token không thể đoán được — ID phiên, liên kết đặt lại mật khẩu, v.v. Tuy nhiên, UUID không phải là bí mật: nó không có HMAC, không có thời gian hết hạn và không liên kết với người dùng cụ thể. Hãy coi UUID là mã định danh mờ, không phải thông tin xác thực.
Hai hệ thống khác nhau có thể tạo ra cùng một UUID không?
Xác suất va chạm cho UUID v4 là khoảng 1 trong 2^122 mỗi cặp. Để có 50% cơ hội va chạm bất kỳ, bạn cần tạo khoảng 2,7 × 10^18 UUID — vượt xa những gì bất kỳ hệ thống thực nào tạo ra. UUID v1 và v7 còn nhúng dấu thời gian và/hoặc bit ngẫu nhiên, khiến va chạm ngẫu nhiên càng ít có khả năng hơn. Vì mọi mục đích thực tế, UUID từ các hệ thống riêng biệt sẽ không va chạm.
Tại sao UUID dài 36 ký tự?
UUID là 128 bit = 16 byte. Mã hóa dưới dạng thập lục phân là 32 ký tự. Định dạng UUID thêm 4 dấu gạch ngang ở các vị trí cố định (sau các nhóm 8, 4, 4 và 4 chữ số hex) để cải thiện khả năng đọc và giúp dễ nhận biết trực quan các bit phiên bản và biến thể, tạo ra tổng 36 ký tự. Các dấu gạch ngang không mang dữ liệu.
ULID là gì và khác với UUID như thế nào?
ULID (Mã định danh duy nhất toàn cầu có thể sắp xếp từ điển) là mã định danh 128-bit được mã hóa trong Crockford Base32 (26 ký tự, không phân biệt chữ hoa/thường, không có dấu gạch ngang). 48 bit đầu tiên mã hóa thời gian Unix tính bằng mili giây; 80 bit còn lại là ngẫu nhiên. ULID sắp xếp chính xác như chuỗi thông thường và nhỏ gọn hơn UUID. Chúng không phải là một phần của RFC UUID — sử dụng mã hóa khác và thiếu các trường phiên bản/biến thể của UUID.
Tôi nên sử dụng UUID hay số nguyên tự tăng làm khóa chính?
Số nguyên tự tăng là tuần tự, nhỏ gọn và thân thiện với chỉ mục nhưng cần một bộ điều phối trung tâm (cơ sở dữ liệu) để gán — điều này không hoạt động trong hệ thống phân tán và lộ số lượng hàng. UUID (đặc biệt là v7 hoặc ULID) có thể được tạo ở phía máy khách mà không cần đi lại cơ sở dữ liệu, cho phép chèn lạc quan và ghi phân tán. Sự đánh đổi là lưu trữ (16 byte so với 4–8 byte) và vị trí chỉ mục thấp hơn một chút cho UUID ngẫu nhiên (v4). UUID v7 và ULID loại bỏ vấn đề vị trí chỉ mục bằng cách sử dụng tiền tố dấu thời gian.
Sự khác biệt giữa UUID v3 và UUID v5 là gì?
Cả UUID v3 và v5 đều xác định: chúng luôn tạo ra cùng một UUID cho cùng cặp namespace + tên, khiến chúng hữu ích để tạo ID có thể tái tạo cho các thứ như mục DNS, URL hoặc mã định danh đối tượng. Sự khác biệt duy nhất là thuật toán băm: v3 dùng MD5 (128-bit, cũ), v5 dùng SHA-1 (160-bit, cắt ngắn thành 128-bit). Ưu tiên UUID v5 cho các dự án mới — SHA-1 mạnh hơn MD5, dù không phiên bản nào được dùng làm hàm băm mật mã.