Trình tạo mã UUID v4

UUID v4: Kiến trúc 128 bit với 122 bit ngẫu nhiên thuần túy

Công cụ này tạo một hoặc nhiều định danh UUID phiên bản 4 (UUID v4) – những chuỗi 36 ký tự hex ngẫu nhiên theo định dạng chuẩn 8‑4‑4‑4‑12. Điểm làm nên khác biệt của trang này nằm ở ba yếu tố then chốt. Thứ nhất, mỗi UUID sử dụng 122 bit ngẫu nhiên thực sự; 6 bit còn lại là các bit phiên bản và biến thể cố định (theo tiêu chuẩn RFC 4122). Thứ hai, các giá trị UUID v4 sắp xếp tùy ý – chúng không mang thông tin thời gian hay thứ tự, do đó nếu dùng làm khóa chính trong cơ sở dữ liệu sẽ gây phân mảnh chỉ mục B‑tree (trái ngược với các định dạng có thể sắp xếp theo thời gian). Thứ ba, xác suất va chạm là không đáng kể đối với mọi mục đích thực tế.

Người dùng có thể kiểm soát số lượng UUID cần tạo (từ 1 đến 100), chọn chế độ chữ hoa (hex a–f thành A–F) và tùy chọn loại bỏ dấu gạch nối (khi đó chuỗi rút gọn còn 32 ký tự). Tất cả đều được sinh ngay trong trình duyệt, không gửi lên máy chủ.

Cấu trúc 128 bit của UUID v4

Một UUID v4 là một số nguyên 128 bit, nhưng không phải bit nào cũng ngẫu nhiên. Theo chuẩn RFC 4122, phiên bản 4 được xây dựng như sau:

• Bit 0 đến 47: hoàn toàn ngẫu nhiên (6 octet đầu tiên).
• Bit 48 đến 51: 4 bit biến thể (variant bits), luôn là 10xx trong nhị phân (tức 8, 9, a, hoặc b ở ký tự hex thứ 13). Điều này đảm bảo UUID tuân thủ chuẩn tương thích ngược.
• Bit 52 đến 63: hoàn toàn ngẫu nhiên (octet thứ 7 và một nửa octet thứ 8).
• Bit 64 đến 71: 4 bit phiên bản (version bits), luôn là 0100 (giá trị 4 ở ký tự hex thứ 15). 4 bit còn lại trong octet này ngẫu nhiên.
• Bit 72 đến 127: hoàn toàn ngẫu nhiên (7 octet cuối).

Kết quả: 122 bit ngẫu nhiên + 2 bit cố định cho phiên bản + 4 bit cố định cho biến thể = 128 bit. Biểu diễn hex chuẩn gồm 8‑4‑4‑4‑12: ví dụ f47ac10b-58cc-4372-a567-0e02b2c3d479. Ký tự ở vị trí thứ 13 (sau dấu gạch nối thứ hai) luôn là 8, 9, a hoặc b; ký tự ở vị trí thứ 17 luôn là 4. Công cụ cho phép bỏ dấu gạch nối, khi đó chuỗi trở thành 32 ký tự hex liên tiếp, nhưng cấu trúc nội tại không thay đổi.

Xác suất va chạm và nguồn ngẫu nhiên thực tế

Với 122 bit entropy, số lượng UUID khả dụng là 2^122 ≈ 5,3 × 10^36. Theo bài toán ngày sinh (birthday paradox), xác suất va chạm đạt 50% chỉ khi số lượng UUID tạo ra vào khoảng √(2^122) ≈ 2,6 × 10^18 – tức 2,6 tỷ tỷ. Trong thực tế, nếu tạo 1 triệu UUID mỗi giây, phải mất khoảng 82 triệu năm để đạt ngưỡng va chạm 50%. Vì thế va chạm là không đáng kể với mọi ứng dụng hiện tại.

Nguồn ngẫu nhiên trong công cụ hoàn toàn dựa trên API crypto.randomUUID() hoặc crypto.getRandomValues() của trình duyệt – đây là bộ sinh số ngẫu nhiên mật mã học (CSPRNG), đủ mạnh cho cả mục đích bảo mật. Không có yếu tố thời gian hay seed nào từ máy chủ. Mọi ID đều được sinh cục bộ, không gửi qua mạng, đảm bảo quyền riêng tư và độ trễ thấp.

Ảnh hưởng đến hiệu suất cơ sở dữ liệu

Đây là điểm mà UUID v4 khác biệt rõ rệt so với các định danh có thứ tự như UUID v7 (nhúng thời gian Unix) hay ULID. Vì UUID v4 hoàn toàn ngẫu nhiên, các giá trị mới không có tính tương quan vị trí với các giá trị cũ. Khi được dùng làm khóa chính (clustered index) trong các hệ quản trị cơ sở dữ liệu như PostgreSQL, MySQL hay SQL Server, các bản ghi mới sẽ được chèn vào các trang chỉ mục ngẫu nhiên, gây ra:

• Phân mảnh mức độ cao của cây B‑tree, làm tăng số lần tách trang (page split).
• Tỉ lệ lấp đầy trang thấp – các trang chỉ mục thường chỉ lấp đầy khoảng 60–70% thay vì gần 100% như với khóa tự tăng.
• Chi phí ghi lớn hơn: mỗi lần chèn có thể phải đọc và ghi nhiều trang, làm giảm throughput ghi.

Ngược lại, UUID v7 với 48 bit thời gian ở đầu giúp các giá trị mới nối tiếp nhau, phù hợp với cấu trúc B‑tree hơn. Tuy nhiên, nếu ứng dụng yêu cầu ẩn số lượng bản ghi, chống dò tìm tuần tự, hoặc hoạt động trong môi trường phân tán offline (không có bộ sinh khóa trung tâm), UUID v4 vẫn là lựa chọn tối ưu. Công cụ này cũng hỗ trợ UUID v7 và ULID trong cùng dropdown, cho phép so sánh trực tiếp.

Tùy chỉnh định dạng: chữ hoa và dấu gạch nối

Hai nút bật/tắt trên giao diện cho phép thay đổi biểu diễn của UUID v4, nhưng không làm thay đổi giá trị nội tại.

Chữ hoa: Khi bật, các chữ cái hex a–f được viết hoa thành A–F. Điều này chỉ ảnh hưởng đến khả năng đọc và tương thích với một số hệ thống yêu cầu chữ hoa (ví dụ một số API cũ, phần mềm kế thừa). Về mặt dữ liệu, a và A là cùng một giá trị hex. Tuy nhiên, một số cơ sở dữ liệu xử lý chữ hoa/chữ thường khác nhau trong so sánh chuỗi; nếu dùng làm khóa, cần đảm bảo tính nhất quán toàn bộ hệ thống.

Dấu gạch nối: Khi tắt, dấu gạch nối bị loại bỏ, chuỗi trở thành 32 ký tự hex liên tục. Định dạng này thường được dùng trong URL (không cần mã hóa), các tên file, hoặc khi lưu trữ dưới dạng số 128 bit trong cơ sở dữ liệu (thường lưu dưới dạng BINARY(16)). Tuy nhiên, cần lưu ý rằng một số thư viện hoặc hệ thống mong đợi định dạng có dấu gạch nối để kiểm tra tính hợp lệ. Công cụ không đưa ra cảnh báo về khả năng tương thích; người dùng tự chịu trách nhiệm kiểm tra.

Cả hai tùy chỉnh đều kích hoạt tạo lại ngay lập tức toàn bộ danh sách ID, vì vậy thứ tự các ID sẽ thay đổi giữa các lần bật/tắt ngay cả khi không thay đổi count.

Ai cần công cụ này

• Lập trình viên ứng dụng: cần một lượng lớn khóa ngẫu nhiên để gán cho phiên người dùng, sự kiện, hoặc các object trong hệ thống phân tán không có bộ sinh khóa trung tâm.
• Nhà thiết kế cơ sở dữ liệu: hiểu rõ đánh đổi về chỉ mục và cần định danh chuẩn cho các bảng có khả năng mở rộng ngang.
• Kỹ sư bảo mật: cần các định danh không thể đoán trước (ví dụ token API, request ID) – nơi có thể sử dụng thời gian (như UUID v7) bị coi là rủi ro vì tiết lộ thời điểm tạo.
• Người kiểm thử: tạo dữ liệu mẫu chứa các giá trị duy nhất, thực tế cho cơ sở dữ liệu thử nghiệm.

Các trường hợp không nên dùng UUID v4: (1) khi cần khóa có thứ tự để tối ưu ghi, (2) khi hệ thống có hạn chế về bộ nhớ đệm chỉ mục, (3) khi ứng dụng chỉ chạy trên một máy và có thể dùng khóa tự tăng đơn giản.

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

Hỏi: Tôi có thể tạo tối đa bao nhiêu UUID cùng lúc? Công cụ giới hạn số lượng từ 1 đến 100. Không có giới hạn kỹ thuật nào khác ngoài hiệu suất trình duyệt.

Hỏi: ID có thực sự an toàn để dùng làm token xác thực không? Có, vì được sinh từ nguồn ngẫu nhiên mật mã học (crypto). Tuy nhiên, nếu cần bảo mật cao hơn, nên kết hợp với các cơ chế khác (hạn chế thời gian sống, lưu hash). UUID v4 chỉ đảm bảo không thể đoán trước, không tự động bảo vệ chống tấn công.

Hỏi: Tại sao UUID v4 không thể sắp xếp theo thời gian? Vì tất cả 122 bit ngẫu nhiên đều độc lập, không có bit nào chứa dấu thời gian. Đây là đặc điểm thiết kế cố hữu của phiên bản 4. Để sắp xếp theo thời gian, dùng UUID v7 hoặc ULID.

Hỏi: Có thể dùng UUID v4 làm khóa chính cho bảng có hàng tỷ bản ghi không? Về mặt lý thuyết, xác suất va chạm vẫn cực thấp. Về mặt hiệu năng, chỉ mục B-tree sẽ bị phân mảnh nặng, dẫn đến tăng dung lượng lưu trữ và giảm tốc độ ghi. Có thể chấp nhận được nếu dùng bảng không có chỉ mục cluster (heap) hoặc nếu dùng UUID v7 thay thế.

Hỏi: Làm sao để biết UUID có đúng chuẩn v4 không? Kiểm tra ký tự thứ 13 (tính từ trái sau dấu gạch nối thứ hai) phải là 8, 9, a hoặc b; ký tự thứ 17 phải là 4. Công cụ tự động đảm bảo điều này.

Hỏi: Dữ liệu của tôi có bị gửi lên máy chủ không? Không. Toàn bộ quá trình sinh UUID diễn ra trong JavaScript ở trình duyệt. Không có yêu cầu mạng nào được thực hiện ngoài việc tải trang. Bạn có thể kiểm tra bằng tab Network của Developer Tools.