Cách trang UUID v4 hoạt động và điều gì làm nó khác biệt
Trang này tạo một hoặc nhiều định danh UUID phiên bản 4 (v4) – những chuỗi 36 ký tự ngẫu nhiên theo khuôn mẫu 8-4-4-4-12 tiêu chuẩn. Bạn kiểm soát số lượng UUID (từ 1 đến 100), chế độ chữ hoa hay chữ thường, và có bao gồm dấu gạch nối hay không. Quá trình sinh diễn ra ngay trong trình duyệt của bạn, dùng bộ sinh số ngẫu nhiên mạnh (cryptographic random) – không có dữ liệu nào được gửi lên máy chủ.
Điểm khác biệt chính của trang này so với các công cụ tạo UUID v4 thông thường nằm ở ba khía cạnh: tính không thể đoán trước, xác suất va chạm cực thấp, và không mang dấu thời gian. UUID v4 sử dụng 122 bit ngẫu nhiên thuần túy, không nhúng timestamp như UUID v7 hay ULID. Điều này có nghĩa các giá trị sinh ra sắp xếp tùy ý – không theo thứ tự thời gian – và khi dùng làm khóa chính trong cơ sở dữ liệu, chúng có thể gây phân mảnh chỉ mục (index fragmentation) nếu bạn không thiết kế phù hợp. Trang còn cho phép bật/tắt chữ hoa và dấu gạch nối, nhưng bản chất ngẫu nhiên bên trong là cố định. Mặc định đầu ra là chữ thường, có gạch nối. Bất kỳ thay đổi nào ở tùy chọn đều khiến toàn bộ danh sách được tạo lại ngay lập tức.
Định dạng và cấu trúc của UUID v4
UUID phiên bản 4 được định nghĩa trong chuẩn RFC 4122. Nó chiếm 128 bit tổng cộng, trong đó 122 bit là ngẫu nhiên, 4 bit xác định phiên bản (version 4) và 2 bit xác định biến thể (variant). Trên thực tế, 122 bit ngẫu nhiên này được phân bố vào 16 octet (byte). Khi hiển thị dưới dạng chuỗi hexa, bạn thấy 32 ký tự hex (mỗi ký tự biểu diễn 4 bit) cùng với 4 dấu gạch nối ở các vị trí cố định: 8-4-4-4-12.
Ví dụ một UUID v4 với gạch nối, chữ thường:
f47ac10b-58cc-4372-a567-0e02b2c3d479
Nếu không có gạch nối:
f47ac10b58cc4372a5670e02b2c3d479
Nếu viết hoa:
F47AC10B-58CC-4372-A567-0E02B2C3D479
Hai bit dành cho phiên bản (version) luôn nằm ở vị trí bit thứ 48-51 của UUID (tức octet thứ 7, nửa cao). Trong UUID v4, giá trị hex của nửa octet đó luôn là 4. Bạn có thể kiểm tra: trong chuỗi f47ac10b-58cc-4372-a567..., sau dấu gạch nối thứ hai là 4 (ở 4372). Tương tự, hai bit variant nằm ở octet thứ 9 (sau dấu gạch nối thứ ba), chúng có giá trị nhị phân 10 nên nửa octet đó luôn là 8, 9, a hoặc b. Trong ví dụ trên là a (vì a567). Như vậy, dù các bit ngẫu nhiên thay đổi, hai trường này luôn cố định – đó là lý do UUID v4 chỉ có 122 bit ngẫu nhiên thay vì 128.
Chất lượng ngẫu nhiên và xác suất va chạm
Trang sử dụng crypto.getRandomValues() – bộ sinh số ngẫu nhiên mật mã của trình duyệt hiện đại. Nó lấy entropy từ hệ điều hành, đảm bảo tính không thể đoán trước ở mức độ mật mã. Điều này quan trọng khi UUID v4 được dùng cho token bảo mật, session ID, hoặc các khóa không tuần tự.
Với 122 bit ngẫu nhiên, xác suất va chạm – tức hai UUID khác nhau có cùng giá trị – là cực kỳ thấp. Công thức gần đúng cho xác suất ít nhất một va chạm khi sinh n UUID là:
P ≈ 1 - e^((-n²) / (2 × 2¹²²))
Với n = 10 tỷ (10^10), xác suất va chạm vẫn dưới 10^-10. Thực tế, để có 50% cơ hội va chạm, bạn cần sinh khoảng 2.7 × 10^18 UUID (khoảng 2.7 tỷ tỷ). Vì vậy việc trang giới hạn số lượng tối đa 100 UUID mỗi lần tạo là hoàn toàn an toàn – bạn có thể sinh nhiều lần mà không lo trùng lặp.
Tuy nhiên, xác suất này chỉ đúng nếu bộ sinh ngẫu nhiên hoạt động đúng. Trên một số trình duyệt cũ hoặc môi trường kém chất lượng, crypto.getRandomValues() có thể dựa vào entropy yếu. Nhưng các trình duyệt chính thống hiện nay (Chrome, Firefox, Safari, Edge) đều triển khai đúng chuẩn.
Ảnh hưởng của UUID v4 đến hiệu năng cơ sở dữ liệu
UUID v4 không chứa thông tin thời gian, vì vậy thứ tự sắp xếp của chúng là ngẫu nhiên. Khi dùng làm khóa chính trong cơ sở dữ liệu quan hệ, việc chèn các bản ghi mới sẽ gây ra các trang chỉ mục (index pages) bị phân mảnh nặng. B-tree thông thường hoạt động tốt nhất với khóa tăng dần (sequential), vì dữ liệu mới được chèn vào phía cuối. UUID v4 ngẫu nhiên buộc cơ sở dữ liệu phải chia tách trang liên tục, dẫn đến giảm hiệu suất ghi và tăng kích thước chỉ mục.
Đây là lý do các phiên bản UUID có thứ tự thời gian như UUID v7 hoặc ULID ra đời: chúng nhúng timestamp vào phần đầu, giúp sắp xếp theo thời gian và giảm phân mảnh. Tuy nhiên, UUID v4 vẫn là lựa chọn tốt cho các trường hợp cần tính không thể đoán trước tuyệt đối – chẳng hạn token xác thực, mã đặt lại mật khẩu, ID phiên – nơi thứ tự sắp xếp không quan trọng.
Nếu bạn cần vừa ngẫu nhiên vừa có thứ tự, có thể sử dụng UUID v7 trong cùng trang này (khi thay đổi Format). Nhưng nếu bạn đã chọn UUID v4, hãy cân nhắc việc lưu nó dưới dạng BINARY(16) thay vì CHAR(36) để tiết kiệm dung lượng và tăng tốc so sánh.
Các tùy chọn đầu vào và cách chúng tương tác
Trang cung cấp bốn tùy chọn điều khiển:
| Tùy chọn | Kiểu | Giá trị mặc định | Phạm vi / Ghi chú |
|---|---|---|---|
| Format | Lựa chọn | UUID v4 | UUID v4, UUID v7, ULID, NanoID. Khi chọn UUID v4, các tùy chọn còn lại hoạt động như mô tả. |
| Count | Số | 1 | Số nguyên từ 1 đến 100. Nếu nhập ngoài khoảng, trang không chấp nhận. |
| Uppercase | Bật/tắt | Tắt (false) | Khi bật, tất cả ký tự hex được viết hoa. |
| Include hyphens | Bật/tắt | Bật (true) | Khi tắt, UUID được hiển thị dưới dạng chuỗi 32 ký tự hex liên tục. |
Nguyên tắc quan trọng: Mỗi lần thay đổi bất kỳ tùy chọn nào, toàn bộ danh sách UUID được tạo lại từ đầu, với cùng số lượng và cấu hình mới. Điều này đảm bảo tính nhất quán: nếu bạn tăng số lượng từ 5 lên 10, bạn nhận 10 UUID mới hoàn toàn, không phải thêm 5 cái vào danh sách cũ.
Khi bạn thay đổi Format sang UUID v7 hoặc ULID, các tùy chọn chữ hoa và gạch nối có thể thay đổi hành vi (ví dụ: ULID luôn viết hoa, không có gạch nối). Nhưng với UUID v4, cả hai tùy chọn đều hoạt động linh hoạt: bạn có thể sinh UUID chữ thường không gạch nối, chữ hoa có gạch nối, v.v. Mỗi tổ hợp đều hợp lệ theo RFC 4122 (mặc dù chuẩn khuyến nghị chữ thường có gạch nối).
Sao chép và trạng thái đầu ra
Sau khi sinh, danh sách UUID hiển thị trên trang kèm số lượng ở bên cạnh: ví dụ "Generated IDs (10)". Có ba trạng thái thông báo:
- Ready. – Trạng thái ban đầu, trang sẵn sàng nhưng chưa sinh.
- Generated. – Xuất hiện sau khi bạn thay đổi bất kỳ tùy chọn nào hoặc lần đầu tải trang.
- Copied all! – Hiển thị sau khi bạn nhấn nút "Copy all" để sao chép toàn bộ danh sách.
Cơ chế sao chép linh hoạt: bạn có thể nhấp vào từng UUID riêng lẻ để copy vào clipboard (thường là ký tự chính xác của UUID đó). Hoặc nhấn nút "Copy all" để copy tất cả UUID hiện tại, mỗi UUID trên một dòng riêng. Cả hai đều dùng Clipboard API hiện đại, hoạt động trên HTTPS hoặc localhost.
Không có giới hạn ẩn: bạn có thể sinh tối đa 100 UUID mỗi lần, và lặp lại nhiều lần. Dung lượng bộ nhớ trình duyệt không bị ảnh hưởng đáng kể vì danh sách được tạo và hiển thị tức thì, không lưu trữ lâu dài.
FAQ – Các câu hỏi thường gặp
1. UUID v4 có thực sự ngẫu nhiên 100% không?
Không hoàn toàn. 6 bit trong tổng 128 bit được dành cho phiên bản và biến thể, vì vậy chỉ 122 bit thực sự ngẫu nhiên. Trang sử dụng crypto.getRandomValues() để sinh 16 byte, sau đó điều chỉnh hai byte theo chuẩn RFC 4122. Kết quả cuối cùng đáp ứng định nghĩa UUID v4.
2. Tôi có thể tạo hơn 100 UUID cùng lúc không?
Trang giới hạn Count từ 1 đến 100. Nếu cần nhiều hơn, bạn có thể sinh nhiều lần. Tuy nhiên, 100 là đủ cho hầu hết nhu cầu thử nghiệm hoặc tạo dữ liệu mẫu. Giới hạn này giữ cho giao diện gọn gàng và tránh quá tải trình duyệt.
3. Khi tôi tắt dấu gạch nối, UUID có còn đúng chuẩn không?
Về mặt kỹ thuật, chuẩn RFC 4122 định nghĩa UUID dưới dạng 16 byte, không quy định hình thức hiển thị. Dạng 8-4-4-4-12 có gạch nối là phổ biến nhất, nhưng dạng không gạch nối (32 ký tự hex) vẫn được chấp nhận trong nhiều ngữ cảnh (ví dụ: tên file, khóa API). Trang cho phép cả hai để linh hoạt.
4. Làm thế nào để biết UUID v4 tôi sinh ra có đúng phiên bản không?
Bạn có thể kiểm tra ký tự thứ 13 (tính từ trái, sau dấu gạch nối thứ hai) – nó phải là 4. Và ký tự thứ 17 (sau dấu gạch nối thứ ba) phải là 8, 9, a hoặc b. Ví dụ: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx với y là {8,9,a,b}. Trang đảm bảo điều này.
5. Có cần internet để trang hoạt động không?
Không. Tất cả quá trình sinh và xử lý đều diễn ra trong trình duyệt, không có yêu cầu mạng. Bạn có thể dùng trang offline sau khi đã tải lần đầu (nếu trình duyệt cho phép cache). Điều này có lợi cho bảo mật: không có thông tin nào rời khỏi máy bạn.
6. Tại sao UUID v4 không nên dùng làm khóa chính cho database?
Vì chúng có thứ tự ngẫu nhiên, dẫn đến việc chèn dữ liệu mới gây phân mảnh chỉ mục B-tree, làm chậm tốc độ ghi và tăng kích thước lưu trữ. Nếu cần sắp xếp theo thời gian, hãy chọn UUID v7 hoặc ULID. Tuy nhiên, nếu bạn có cơ sở dữ liệu hỗ trợ chỉ mục hash hoặc clustered index không theo thứ tự, UUID v4 vẫn là lựa chọn an toàn.