Đang xem bằng Tiếng Việt Chuyển sang tiếng Anh

Trình tạo UUID

Tạo UUID v4 (ngẫu nhiên) hoặc v7 (sắp xếp theo thời gian) trong trình duyệt của bạn. Sử dụng Web Crypto API cho tính ngẫu nhiên.

  1. Chọn v4 cho UUID ngẫu nhiên hoặc v7 cho loại sắp xếp theo thời gian.
  2. Đặt Số lượng (tối đa 1000) và nhấp Tạo.
  3. Sử dụng Sao chép tất cả để lấy toàn bộ danh sách, hoặc chọn một dòng đơn thủ công.
Công cụ này làm gì?

UUID v4 là 122 bit tính ngẫu nhiên mạnh về mặt mật mã — mặc định phổ biến cho khóa idempotency, ID phiên, và bất cứ nơi nào bạn muốn một định danh mờ, không có thứ tự. UUID v7 nhúng một dấu thời gian Unix-millisecond 48-bit vào các byte dẫn đầu, nên các giá trị được tạo gần nhau về thời gian sẽ sắp xếp gần nhau theo thứ tự từ điển. Điều đó làm cho v7 phù hợp hơn cho khóa chính cơ sở dữ liệu, nơi các lần chèn có thể làm phân mảnh chỉ mục B-tree.

Ví dụ

Ba UUID v4 (ngẫu nhiên, không có thứ tự):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

Ba UUID v7 được tạo trong cùng một millisecond (lưu ý tiền tố chung):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

Lỗi và cạm bẫy thường gặp

Đây là những cạm bẫy thực sự mà các nhà phát triển gặp phải khi đưa UUID vào ứng dụng:

  • Sử dụng v4 ở nơi thứ tự chèn quan trọng. Lập chỉ mục 10 triệu v4 ngẫu nhiên gây ra phân tách trang nặng trong B-tree. Nếu bạn giữ v4, hoặc chấp nhận khuếch đại ghi hoặc chuyển khóa chính sang v7.
  • Loại bỏ dấu gạch ngang và mất nibble phiên bản. f47ac10b58cc4372a5670e02b2c3d479 vẫn là UUID hex 32 ký tự hợp lệ, nhưng ký tự thứ 13 (4) là dấu phiên bản — không phải nibble ngẫu nhiên. Đừng cho rằng toàn bộ 32 ký tự là ngẫu nhiên.
  • Dựa vào Math.random(). Các thư viện cũ xây trên Math.random() không mạnh về mật mã và có thể đoán trước. Sử dụng crypto.randomUUID() (trình duyệt và Node 19+) hoặc thư viện v7 đọc từ crypto.
  • Xem v7 như một dấu thời gian. 48 bit dẫn đầu mang thời gian nhưng phần còn lại là ngẫu nhiên, nên hai v7 với cùng millisecond không được sắp xếp một cách xác định. Đừng dựa vào phá thế hòa.
  • Lưu trữ dưới dạng VARCHAR(36). Nó hoạt động nhưng gấp đôi lưu trữ so với cột UUID / BINARY(16) 16-byte native và làm chậm join. Sử dụng kiểu native của cơ sở dữ liệu (uuid trong Postgres, UNIQUEIDENTIFIER trong SQL Server).
  • Regex yêu cầu một phiên bản cụ thể. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i chỉ khớp với v4. Nếu sau này bạn phát ra v7, regex đó âm thầm từ chối các ID hợp lệ.
Câu hỏi thường gặp

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

v4 là 122 bit ngẫu nhiên cộng với dấu phiên bản và variant, không có thành phần thời gian. v7 đặt tiền tố một dấu thời gian Unix-millisecond 48-bit và lấp đầy phần còn lại bằng các bit ngẫu nhiên, nên các giá trị v7 được tạo gần nhau về thời gian sẽ sắp xếp theo thứ tự từ điển. Sử dụng v7 làm khóa chính cơ sở dữ liệu để giữ các lần chèn B-tree cục bộ; sử dụng v4 khi bạn hoàn toàn không muốn tín hiệu thứ tự nào.

Tôi có bao giờ nhận được UUID trùng lặp không?

Thực tế là không. Một UUID v4 có 122 bit ngẫu nhiên, nên xác suất hai cái va chạm trong một lô một tỷ là khoảng 10^-18. Bạn sẽ cần tạo khoảng 2,7 tỷ tỷ UUID v4 trước khi đạt đến 50% cơ hội một va chạm đơn. Coi việc tạo duy nhất là điều hiển nhiên và đừng thêm kiểm tra duy nhất.

v4 có ngẫu nhiên về mặt mật mã không?

Công cụ này sử dụng crypto.randomUUID() mà theo spec phải lấy từ một PRNG mạnh về mật mã. Điều đó đủ cho ID phiên, khóa idempotency, và hầu hết các token bảo mật. Nó không thay thế token đã ký hoặc API secret dài, và bạn không nên suy ra khóa mã hóa từ một UUID.

UUID v7 có được tiêu chuẩn hóa không?

Có. UUID v7 được định nghĩa trong RFC 9562 (tháng 5 năm 2024), thay thế RFC 4122 và chính thức hóa v6, v7, và v8 cùng với các phiên bản gốc. Hầu hết các ngôn ngữ hiện đại đều có triển khai v7 — Postgres, MySQL, và SQL Server đều chấp nhận các giá trị v7 như một cột UUID mà không cần thay đổi.

Dạng nhị phân trông như thế nào và endianness có quan trọng không?

Một UUID là 16 byte. Dạng văn bản chính tắc nhóm chúng thành ký tự hex 8-4-4-4-12. Các byte được viết theo thứ tự mạng (big-endian) theo RFC 9562, nên 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 bắt đầu bằng byte 0x01. GUID của Microsoft lịch sử lưu ba nhóm đầu tiên little-endian trong bộ nhớ — hãy cẩn thận khi interop với .NET binary dumps.

Bạn có lưu các UUID mà công cụ này tạo không?

Không. Chúng tôi không lưu các UUID bạn tạo ở đây. Mọi giá trị được hiển thị trong vùng đầu ra và biến mất ngay khoảnh khắc bạn làm mới hoặc đóng tab — không có gì được lưu trữ, không có telemetry nào được thu thập về các giá trị. Hoan nghênh bạn xác minh trong công cụ phát triển của trình duyệt.