Tạo UUID

Công cụ tạo UUID/GUID trực tuyến miễn phí. Tạo UUID v1, v4 và v5 (Nil UUID) ngay lập tức. Tạo hàng loạt, sao chép vào clipboard và tải xuống file. Hoàn hảo cho developers cần unique identifiers.

Có góp ý? Báo lỗi, đề xuất tính năng, hoặc chia sẻ suy nghĩ — chúng tôi đọc tất cả

Tạo UUID - Generate Unique Identifiers Trực Tuyến

Công cụ tạo UUID/GUID mạnh mẽ tạo ra unique identifiers phổ quát với nhiều phiên bản. Tạo UUID đơn lẻ hoặc hàng loạt ngay lập tức với tùy chọn định dạng tùy chỉnh. Hoàn hảo cho database primary keys, session IDs, tên file và bất kỳ tình huống nào cần unique identifiers.

UUID v4 có thực sự duy nhất không?

UUID v4 không được đảm bảo duy nhất — nó duy nhất về mặt xác suất đến mức va chạm không phải là mối lo thực tế. Một UUID v4 có 122 bit ngẫu nhiên (6 bit được dành riêng cho các dấu hiệu phiên bản và biến thể), cho 2^122 giá trị có thể (khoảng 5,3 × 10^36). Theo nghịch lý ngày sinh, bạn cần phải tạo khoảng 2,71 tỷ tỷ UUID để có 50% cơ hội va chạm duy nhất — với một tỷ mỗi giây, điều đó mất 85 năm. Để so sánh, mỗi hạt cát trên Trái Đất là khoảng 7,5 × 10^18, nên không gian UUID v4 lớn hơn 10^17 lần. Điều kiện là chất lượng nguồn ngẫu nhiên của bạn: một PRNG yếu (Math.random thay vì crypto.getRandomValues, hoặc RNG bị gieo sai khi khởi động lần đầu) giảm đáng kể entropy hiệu dụng. Bộ tạo này dùng Web Crypto API cho ngẫu nhiên chất lượng mật mã.

Tôi nên dùng phiên bản UUID nào: v1, v4, v6 hay v7?

UUID v1 (dấu thời gian + địa chỉ MAC, RFC 4122) hầu hết đã lỗi thời vì nó rò rỉ MAC máy chủ và tiết lộ thời gian tạo. UUID v4 (ngẫu nhiên, RFC 4122) là lựa chọn mặc định cho các định danh chung — ID không nên tiết lộ gì. UUID v6 sắp xếp lại các byte dấu thời gian của v1 để có thể sắp xếp nhưng vẫn rò rỉ MAC. UUID v7 (RFC 9562, hoàn thiện 2024) là người chiến thắng hiện đại cho khóa chính cơ sở dữ liệu: 48 bit đầu tiên là dấu thời gian Unix mili giây theo sau bởi 74 bit ngẫu nhiên, nên ID v7 sắp xếp theo thời gian và hoạt động tốt với chỉ mục B-tree trong khi vẫn không thể đoán được. UUID v8 là phiên bản tùy chỉnh tự do dành riêng cho bố cục đặc thù ứng dụng. Cho các hệ thống mới trong 2026, mặc định là v7 cho khóa cơ sở dữ liệu, v4 cho bất cứ thứ gì không nên rò rỉ thông tin.

Các bit phiên bản và biến thể là gì, và chúng ở đâu trong UUID?

Một UUID được hiển thị dưới dạng tám-bốn-bốn-bốn-mười hai chữ số hex (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). Nibble đầu tiên của nhóm thứ ba (M) là phiên bản: 1, 4, 7, v.v. Hai bit đầu tiên của nhóm thứ tư (N) mã hóa biến thể: 10 trong nhị phân (nên ký tự đầu tiên luôn là 8, 9, a hoặc b) đánh dấu UUID RFC 4122 / RFC 9562. Đây là lý do tại sao một UUID v4 hợp lệ luôn có mẫu xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Một kiểm tra regex nhanh từ chối các ID dị dạng trước khi chúng đến cơ sở dữ liệu của bạn. Các bit dành riêng tốn tổng cộng sáu — để lại 122 bit ngẫu nhiên trong v4 — và đảm bảo UUID từ các đặc tả khác nhau (biến thể GUID cũ của Microsoft, các phiên bản tương lai) có thể phân biệt được mà không mơ hồ.

Tôi có nên dùng UUID làm khóa chính trong cơ sở dữ liệu SQL của tôi không?

Tùy thuộc vào cơ sở dữ liệu và phiên bản UUID. UUID v4 làm khóa chính làm tổn hại đáng kể hiệu suất InnoDB và SQL Server: các vị trí chèn ngẫu nhiên gây ra chia trang và phân mảnh chỉ mục cụm, và kích thước 16 byte gấp đôi lưu trữ của mỗi chỉ mục phụ so với int 4 byte. PostgreSQL với kiểu uuid và chỉ mục btree xử lý v4 tốt hơn nhưng vẫn mất một số lợi thế chèn tuần tự. Tiền tố tăng đơn điệu của UUID v7 giải quyết vấn đề phân mảnh — việc chèn được thêm vào cuối chỉ mục giống như một số nguyên tự tăng. Lợi ích của UUID: duy nhất toàn cầu mà không cần phối hợp, an toàn để hợp nhất cơ sở dữ liệu, không có tấn công liệt kê trên URL /users/123, thân thiện với hệ thống phân tán. Cho các lược đồ mới, mặc định là UUID v7 trừ khi bảng nhỏ hoặc độ trễ đường nóng chiếm ưu thế.

Tạo UUID — Công cụ tạo UUID/GUID trực tuyến miễn phí. Tạo UUID v1, v4 và v5 (Nil UUID) ngay lập tức. Tạo hàng loạt, sao chép vào cl — **Tạo UUID**

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

Về chức năng không có gì — "GUID" (Globally Unique Identifier) là tên của Microsoft cho cùng định danh 128-bit được định nghĩa trong RFC 4122. Bố cục byte được mã hóa giống hệt nhau: 16 byte thô. Biểu diễn văn bản giống nhau: tám-bốn-bốn-bốn-mười hai hex. Sự khác biệt lịch sử nhỏ là thứ tự byte: định dạng GUID kế thừa của Microsoft lưu trữ ba trường đầu tiên ở little-endian (Data1, Data2, Data3) trên đĩa, trong khi RFC 4122 chỉ định big-endian (thứ tự byte mạng). Điều này có nghĩa là một GUID nhị phân được xuất từ API COM Windows và đọc lại dưới dạng byte trên hệ thống Unix sẽ xuất hiện hoán đổi byte trong 8 byte đầu tiên. Các hệ thống hiện đại chuẩn hóa trên biểu diễn hex văn bản, là chuẩn và không mơ hồ. Đối với kiểu uniqueidentifier của Microsoft SQL Server, các byte trên đĩa vẫn ở thứ tự kế thừa.

Tôi có thể rút ngắn UUID để dùng trong URL mà không mất tính duy nhất không?

Có — 128 bit của một UUID có thể được mã hóa nén hơn dạng hex 36 ký tự (có dấu gạch nối) bằng cách chuyển bảng chữ cái. UUID mã hóa Base64 là 22 ký tự (24 với đệm), Base64 an toàn cho URL với đệm bị loại bỏ là 22 ký tự, và Base58 (không có ký tự nhầm lẫn như 0/O/l/I) là 22 ký tự. Crockford Base32 là 26 ký tự và thân thiện với con người. Tất cả những điều này không mất dữ liệu: người nhận giải mã trở lại cùng 16 byte. KHÔNG BAO GIỜ cắt ký tự — điều đó phá hủy đảm bảo tính duy nhất. Một hash 64-bit như FNV hoặc xxHash từ UUID cho đầu ra 16 ký tự nhưng đánh đổi va chạm lấy độ dài và không còn là UUID. Các thay thế như Nano ID hoặc ULID cho thân thiện URL tương tự ngay từ đầu mà không cần bước dịch UUID. ULID thậm chí dùng Crockford Base32 có thể sắp xếp theo thiết kế.

UUID có an toàn về mật mã hoặc phù hợp cho token bảo mật không?

UUID v4 được tạo từ RNG mật mã (Web Crypto, /dev/urandom, BCryptGenRandom) có 122 bit entropy, vượt quá hướng dẫn đối xứng 128-bit trừ đi 6 bit phiên bản/biến thể cố định. Điều đó đủ cho token phiên, liên kết đặt lại mật khẩu và khóa bất biến — tương đương với chuỗi Base64 ngẫu nhiên 21 ký tự. Lưu ý: UUID từ các thư viện ngôn ngữ cũ phụ thuộc vào Math.random hoặc gieo dựa trên thời gian KHÔNG an toàn về mật mã và đã bị phá vỡ trong thực tế (tấn công dự đoán UUID tiếp theo chống lại uniqid của PHP, java.util.UUID với hạt giống không an toàn). Xác minh nguồn của bạn dùng crypto.randomUUID (trình duyệt/Node 19+), uuid.uuid4 được hỗ trợ bởi os.urandom (Python), hoặc System.Security.Cryptography (.NET). UUID v1, v6 và v7 tiết lộ dấu thời gian và không nên dùng làm bí mật — chúng là định danh, không phải thông tin xác thực.

Tại sao UUID của tôi trông như 00000000-0000-0000-0000-000000000000 và UUID nil là gì?

UUID toàn số không là UUID nil (RFC 4122 mục 4.1.7), dành riêng làm dấu hiệu có nghĩa "vắng mặt" hoặc "chưa được gán". Đó là tương đương UUID của NULL, hữu ích trong cơ sở dữ liệu nơi cột là NOT NULL nhưng hàng chưa được gán định danh thực sự. Đối tác của nó, UUID tối đa (toàn F, ffffffff-ffff-ffff-ffff-ffffffffffff) được chính thức hóa trong RFC 9562 như giới hạn trên phổ quát — hữu ích cho truy vấn phạm vi và như tương đương LSN trong log chỉ-thêm. Cả hai đều là UUID hợp pháp nhưng không bao giờ xuất hiện như đầu ra ngẫu nhiên: cơ hội tạo bất kỳ một cách tình cờ là 1 trong 2^122, hiệu quả là không. Nếu bạn thấy UUID nil trong dữ liệu sản xuất, mã của bạn rất có thể đã không khởi tạo giá trị trước khi chèn — thêm kiểm tra phòng thủ và truy ngược về hàm khởi tạo.