tooly

Tạo UUID

Tạo định danh duy nhất toàn cầu: UUID v4 ngẫu nhiên hoặc UUID v7 theo thời gian (RFC 9562) sắp xếp theo thời điểm tạo — lý tưởng cho khóa cơ sở dữ liệu. Tạo cục bộ bằng bộ ngẫu nhiên mật mã của trình duyệt.

Mọi thứ chạy trong trình duyệt — không gửi đi đâu cả

Cách sử dụng

  1. 1

    Chọn v4 hoặc v7 và số lượng cần.

  2. 2

    Nhấp Tạo mới để có lô mới.

  3. 3

    Sao chép danh sách.

UUID được dùng ở đâu

UUID (định danh duy nhất toàn cục, trên Windows còn gọi là GUID) là một giá trị 128 bit được viết thành 32 chữ số thập lục phân chia làm năm nhóm: 8-4-4-4-12, ví dụ 3f1c2b7e-9a4d-4c1e-8b2f-6d0e5a7c9b13. Mấu chốt là bất kỳ hệ thống nào cũng tự tạo được một UUID mà không cần hỏi một bộ đếm trung tâm, và vẫn yên tâm rằng nó sẽ không bao giờ trùng với ID được tạo ở nơi khác.

Tính chất đó hữu ích ở rất nhiều nơi:

  • Khóa chính trong cơ sở dữ liệu, nhất là khi bản ghi được tạo trên nhiều máy chủ hoặc ngoại tuyến trên thiết bị người dùng rồi đồng bộ sau.
  • ID yêu cầu và ID tương quan theo dấu một thao tác xuyên qua log của nhiều dịch vụ.
  • Tên tệp cho các lượt tải lên, để hai người cùng tải photo.jpg không bao giờ ghi đè lên nhau.
  • Khóa idempotency cho API thanh toán và đặt hàng.
  • Dữ liệu kiểm thử và dữ liệu mẫu cần ID trông thực tế.

Phiên bản 4 và phiên bản 7

Công cụ cung cấp hai phiên bản quan trọng cho các dự án mới hiện nay. Cả hai có cùng định dạng và độ dài; khác biệt nằm ở nội dung các bit.

UUID v4 (ngẫu nhiên)

Ngoài 6 bit cố định đánh dấu phiên bản và biến thể, toàn bộ 122 bit còn lại là ngẫu nhiên. Bạn có thể nhận ra v4 nhờ chữ số 4 ở đầu nhóm thứ ba. Chúng được tạo bởi crypto.randomUUID() của trình duyệt, vốn lấy từ nguồn ngẫu nhiên an toàn mật mã của hệ điều hành.

Hãy dùng v4 khi ID không được tiết lộ gì: token lời mời trong URL, ID tài nguyên công khai, bất cứ chỗ nào mà biết một ID không được giúp đoán ra ID khác hay biết nó được tạo khi nào.

UUID v7 (theo thời gian)

Được chuẩn hóa trong RFC 9562 năm 2024, v7 đặt một timestamp Unix 48 bit tính bằng mili giây ở đầu và lấp 74 bit còn lại bằng dữ liệu ngẫu nhiên. Nhóm thứ ba bắt đầu bằng 7. Vì timestamp đứng đầu, các giá trị v7 được sắp theo thứ tự tạo khi so sánh như chuỗi hoặc byte thông thường.

Điều này quan trọng với cơ sở dữ liệu. Chỉ mục B-tree lưu khóa theo thứ tự, và khóa v4 ngẫu nhiên rơi vào các trang ngẫu nhiên, gây tách trang và dùng bộ đệm kém khi bảng tăng lên hàng triệu dòng. Khóa theo thời gian được thêm gần cuối chỉ mục, giống như số nguyên tự tăng, mà vẫn giữ được tính chất "tạo ở đâu cũng được". Với bảng mới trong PostgreSQL, MySQL hay SQL Server, v7 thường là khóa chính tốt hơn.

Hai lưu ý: timestamp đọc được, nên v7 tiết lộ thời điểm bản ghi được tạo, chính xác đến mili giây. Và trình tạo này không thêm bộ đếm dưới mức mili giây, nên các ID tạo trong cùng một mili giây, như trong một lần tạo hàng loạt, được sắp xếp với nhau theo phần ngẫu nhiên chứ không theo thứ tự tạo.

Khả năng trùng lặp thấp đến mức nào

Với 122 bit ngẫu nhiên, có khoảng 5,3 × 10^36 giá trị v4 khả dĩ. Theo nghịch lý ngày sinh, bạn cần tạo khoảng 2,7 × 10^18 giá trị để có 50% khả năng xảy ra một lần trùng. Với tốc độ một tỷ mỗi giây, việc đó mất hơn 80 năm.

Với v7, phần ngẫu nhiên là 74 bit, nhưng nó chỉ cần duy nhất trong số các ID được tạo cùng một mili giây. Ngay cả với một triệu ID mỗi mili giây, khả năng trùng vẫn không đáng kể.

Trên thực tế, trùng lặp đến từ lỗi phần mềm chứ không phải từ toán học: một ID ví dụ viết cứng bị chép vào môi trường production, một bộ sinh ngẫu nhiên có seed cố định hoặc không an toàn mật mã, hay một máy ảo được nhân bản phát lại trạng thái cũ. Tạo trong trình duyệt bằng nguồn ngẫu nhiên an toàn của hệ thống tránh được hai trường hợp sau.

Chi tiết định dạng và lưu trữ

  • Chữ hoa chữ thường. RFC 9562 quy định UUID được viết bằng chữ thường và so sánh không phân biệt hoa thường. Tùy chọn Chữ hoa dành cho các hệ thống và tài liệu dùng kiểu GUID của Windows.
  • Dấu ngoặc nhọn và gạch nối. Một số công cụ của Microsoft hiển thị GUID trong {dấu ngoặc nhọn}. Chỉ bỏ chúng, hoặc bỏ dấu gạch nối, khi hệ thống đích yêu cầu dạng đó.
  • Lưu trữ. Hãy lưu UUID bằng kiểu dữ liệu gốc (uuid trong PostgreSQL, BINARY(16) trong MySQL) thay vì CHAR(36). Dạng nhị phân chiếm 16 byte thay vì 36 và so sánh nhanh hơn.
  • Số lượng mỗi lần. Tối đa 500 mỗi lần, mỗi dòng một giá trị, sẵn sàng dán vào script SQL hoặc bảng tính. Nhấp Tạo mới sẽ thay thế toàn bộ danh sách.

UUID là định danh, không phải bí mật. Một v4 khó đoán, nhưng nếu nó cấp quyền truy cập vào thứ gì đó, hãy coi đó là một liên kết tiện lợi chứ không phải cơ chế xác thực. Với thông tin đăng nhập, hãy dùng Tạo mật khẩu. Để đọc thời điểm tạo của một v7, lấy 12 chữ số thập lục phân đầu tiên, chuyển sang thập phân rồi dán con số vào Chuyển đổi Unix timestamp.

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

v4 và v7 khác nhau thế nào?

v4 hoàn toàn ngẫu nhiên. v7 bắt đầu bằng dấu thời gian mili giây nên ID sắp xếp theo thời gian và đánh chỉ mục tốt hơn trong cơ sở dữ liệu.

UUID này có thực sự duy nhất không?

Với 122 bit ngẫu nhiên, khả năng trùng là không đáng kể — phải tạo hàng tỷ mỗi giây trong nhiều thế kỷ.

Có tạo trên máy chủ không?

Không. Chúng đến từ crypto.getRandomValues trong trình duyệt và không bao giờ được truyền đi.

Có tạo nhiều cùng lúc được không?

Đến 500 mỗi lần nhấp.

Công cụ liên quan

Tạo mật khẩuTạo mật khẩu ngẫu nhiên mạnh với chữ, số và ký hiệu. Đặt độ dài, xem độ mạnh, sao chép một chạm. Được tạo cục bộ trong trình duyệt của bạn.Tạo hashTính hash MD5, SHA-1, SHA-256, SHA-384 và SHA-512 của văn bản hoặc tệp trong trình duyệt. Kiểm tra checksum mà không tải lên gì cả.Chuyển đổi Unix timestampChuyển Unix timestamp sang ngày dễ đọc và ngược lại. Giây hoặc mili giây, ISO 8601, UTC, múi giờ của bạn và thời gian tương đối. Đồng hồ trực tiếp.