Trình Tạo UUID Hàng Loạt

Tạo tối đa 10.000 UUID: v4 ngẫu nhiên, v7 sắp xếp theo thời gian, v5 tất định dựa trên tên (không gian tên + tên). Xuất TXT, CSV, JSON hoặc SQL INSERT.

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ả

Trình Tạo UUID Hàng Loạt Là Gì?

Công cụ trình duyệt miễn phí để tạo Định Danh Duy Nhất Toàn Cầu (UUID) hàng loạt. UUID là định danh 128 bit được viết dưới dạng 36 ký tự ở dạng chuẩn — 32 chữ số thập lục phân cộng bốn dấu gạch theo mẫu 8-4-4-4-12 (vd. 550e8400-e29b-41d4-a716-446655440000) — dùng để gắn nhãn duy nhất cho hàng cơ sở dữ liệu, sự kiện hệ thống phân tán, phiên người dùng và tệp trên các máy khác nhau mà không cần phối hợp. Trình tạo này hỗ trợ năm phiên bản do RFC 9562 (chuẩn 2024 thay thế RFC 4122) định nghĩa: v1 (mốc thời gian + nút), v4 (ngẫu nhiên thuần — phổ biến nhất), v5 (tất định, dựa trên tên qua SHA-1 từ không gian tên + tên), v7 (sắp xếp theo Unix-ms — hoàn hảo cho khóa chính DB) và v8 (bố cục tùy chỉnh). Mọi thứ chạy trong trình duyệt qua API WebCrypto, không dữ liệu nào rời khỏi thiết bị.

Tính Năng Chính

Tạo tối đa 10.000 UUID chỉ với một cú nhấp — tạo nhanh trong trình duyệt
Năm phiên bản RFC 9562: v1 (thời gian), v4 (ngẫu nhiên), v5 (dựa trên tên), v7 (sắp xếp), v8 (tùy chỉnh)
v5 tất định: cung cấp không gian tên (DNS/URL/OID/X.500 hoặc tùy chỉnh) cùng danh sách tên — cùng đầu vào luôn cho cùng UUID
v4 dùng crypto.randomUUID() bản địa khi có sẵn (an toàn mật mã)
v7 nhúng mili giây Unix vào 48 bit đầu — sắp xếp được, lập chỉ mục được, lý tưởng cho khóa chính
Chuyển đổi chữ hoa/thường (lower / UPPER) và định dạng (có gạch / không gạch / {ngoặc})
Xuất dưới dạng TXT, CSV, JSON hoặc cú pháp SQL INSERT INTO ... VALUES (...)
An toàn quyền riêng tư: v1 dùng bit nút multicast ngẫu nhiên (không bao giờ tiết lộ MAC thật)
100% trong trình duyệt — không gửi máy chủ, không theo dõi

Trình Tạo UUID Hàng Loạt — Tạo tối đa 10.000 UUID: v4 ngẫu nhiên, v7 sắp xếp theo thời gian, v5 tất định dựa trên tên (không gian tên + tên). Xuất — **Trình Tạo UUID Hàng Loạt**

Cách Sử Dụng

Chọn phiên bản: v4 cho mục đích chung, v7 cho khóa DB, v5 cho ID tất định dựa trên tên, v1 cho ID di sản dựa trên thời gian
Với v4/v7/v8/v1: nhập số lượng từ 1 đến 10.000. Với v5: chọn không gian tên và dán mỗi tên một dòng
Tùy chọn đổi kiểu chữ thành CHỮ HOA và định dạng sang không gạch hoặc {ngoặc}
Nhấn Tạo UUID — danh sách xuất hiện ngay lập tức
Sao chép tất cả vào clipboard hoặc tải xuống dưới dạng TXT, CSV, JSON hoặc câu lệnh SQL INSERT
Dán khối SQL trực tiếp vào client cơ sở dữ liệu để chèn ID hàng loạt

Câu Hỏi Thường Gặp

v4 là 122 bit ngẫu nhiên với 6 bit cố định phiên bản/biến thể — hoàn toàn không thể đoán nhưng không có thứ tự nội tại, vì vậy chèn khóa v4 vào chỉ mục B-tree gây ghi trang ngẫu nhiên và phân mảnh chỉ mục. v7 là sự thay thế hiện đại của RFC 9562: 48 bit đầu là mốc thời gian Unix tính bằng mili giây, phần còn lại là ngẫu nhiên. ID v7 sắp xếp theo thời gian dưới dạng chuỗi VÀ dưới dạng nhị phân, vì vậy chúng cụm tốt trong chỉ mục B-tree (PostgreSQL, MySQL InnoDB, SQL Server). Dùng v7 cho khóa chính trong lược đồ mới; dùng v4 cho ID công khai mờ nơi bạn không muốn lộ thời gian tạo.

Dùng v5 bất cứ khi nào bạn cần một ID tất định, có thể tái tạo dẫn xuất từ khóa tự nhiên — email, SKU, URL, đường dẫn tệp, hoặc chuỗi tenant+tài nguyên. v5 là hàm băm SHA-1 của UUID không gian tên nối với một tên, vì vậy cùng không gian tên + tên luôn tạo ra chính xác cùng UUID, trên bất kỳ máy nào, mãi mãi. Điều này khiến nó hoàn hảo cho ETL và nhập liệu idempotent (chạy lại tải dữ liệu không bao giờ tạo hàng trùng), khử trùng lặp, dẫn xuất khóa chính ổn định mà không cần bảng tra cứu, và tạo ID sự kiện/tài liệu dự đoán được. Chọn đúng không gian tên: DNS cho tên máy chủ, URL cho URL, OID cho định danh đối tượng, X.500 cho tên thư mục, hoặc cung cấp UUID không gian tên tùy chỉnh của riêng bạn để giới hạn ID trong ứng dụng. v5 (SHA-1) được ưa chuộng hơn v3 (MD5) cũ. Lưu ý: v5 KHÔNG ngẫu nhiên — đừng bao giờ dùng làm token bí mật, vì bất kỳ ai biết không gian tên và tên đều có thể tính lại UUID.

Một UUID là 128 bit = 16 byte. Lưu dưới dạng văn bản chuẩn cần CHAR(36) (hoặc 32 nếu không gạch), nhưng lưu bản địa chỉ 16 byte — nhỏ hơn 2 lần, giúp thu nhỏ mọi trang chỉ mục và tăng tốc join, tra cứu. Dùng kiểu bản địa: PostgreSQL uuid (16 byte), MySQL/MariaDB BINARY(16) với UUID_TO_BIN()/BIN_TO_UUID(), SQL Server uniqueidentifier, Oracle RAW(16). Lợi ích lớn hơn với bảng ghi nhiều là thứ tự: khóa ngẫu nhiên v4 phân tán chèn khắp B-tree, gây tách trang, phân mảnh chỉ mục và cục bộ bộ đệm kém, trong khi khóa sắp xếp theo thời gian v7 được nối gần cạnh phải của chỉ mục — các benchmark thường cho thấy v7/UUID tuần tự giảm phình chỉ mục và cải thiện thông lượng chèn hàng loạt gấp nhiều lần so với v4 ngẫu nhiên trên InnoDB và Postgres. Quy tắc: lưu 16 byte và ưu tiên v7 (hoặc v5 khi cần tất định) hơn v4 cho khóa chính/khóa cụm.

Thực tế, có. Một UUID v4 có 122 bit ngẫu nhiên, cho 2^122 ≈ 5.3 × 10^36 giá trị có thể. Theo nghịch lý sinh nhật, bạn cần tạo khoảng 2.71 tỷ tỷ (2.71 × 10^18) UUID trước khi xác suất một va chạm đạt 50%. Ngay cả ở 10.000 ID mỗi giây không ngừng, bạn sẽ đạt 50% xác suất va chạm sau khoảng ~9 nghìn tỷ năm. Cho mọi mục đích thực tế — bao gồm hệ thống quy mô hành tinh — v4 chống va chạm.

Đặc tả v1 ban đầu của RFC 4122 mã hóa địa chỉ MAC mạng của trình tạo vào 48 bit cuối, làm rò rỉ danh tính (một UUID v1 đơn lẻ có thể được liên kết với một máy cụ thể — điều này nổi tiếng được dùng để xác định tác giả virus Melissa năm 1999). Trình tạo của chúng tôi tuân theo thực tiễn tốt nhất hiện đại: chúng tôi ngẫu nhiên hóa bit nút và đặt bit multicast, báo hiệu rằng đây KHÔNG phải địa chỉ phần cứng thật. Vì vậy ID v1 từ công cụ này an toàn quyền riêng tư.

v8 là phiên bản 'bố cục tùy chỉnh': RFC 9562 dành riêng cho các cấu trúc ứng dụng cụ thể. Các bit duy nhất bắt buộc là nibble phiên bản (8) và bit biến thể. Bạn tự do mã hóa bất kỳ thứ gì khác vào 122 bit còn lại — tiền tố ID tenant, gợi ý sharding, chữ ký cố định. Trình tạo này xuất v8 với bố cục sắp xếp theo thời gian giống v7, chỉ đổi nhãn. Cho v8 sản xuất, thiết kế bố cục riêng và tài liệu hóa.

Có. PostgreSQL có kiểu uuid bản địa; dùng xuất SQL và INSERT INTO bảng (id) VALUES ('uuid-đây'); — hoặc tải CSV và dùng COPY. MySQL dùng CHAR(36) hoặc BINARY(16) (nhanh hơn); UUID_TO_BIN(chuỗi_uuid, 1) sắp xếp lại v1 cho cục bộ chỉ mục (không cần cho v7 — đã sắp xếp được). MongoDB lưu UUID dưới dạng kiểu phụ Binary 4. Cho SQL Server dùng uniqueidentifier; cho Oracle RAW(16).

v4 có (122 bit entropy CSPRNG = nhiều hơn nhiều so với khóa đối xứng 128 bit). v1, v7 và v8 KHÔNG an toàn làm token bearer vì chúng rò rỉ mốc thời gian tạo và có ít ngẫu nhiên hơn (62-77 bit ngẫu nhiên tùy phiên bản). Nếu kẻ tấn công có thể quan sát một ID v7 và đoán khoảng khi nào tài khoản được tạo, họ có thể thu hẹp đáng kể không gian tìm kiếm. Cho token phiên, liên kết đặt lại mật khẩu, khóa API: dùng v4 hoặc token CSPRNG chuyên dụng.

10.000 là điểm ngọt: đủ lớn cho hầu hết kịch bản gieo hàng loạt (fixture kiểm thử DB, kịch bản di chuyển, kiểm thử tải), đủ nhỏ để hiển thị trong textarea mà không treo trình duyệt. Trình duyệt điển hình tạo 10.000 UUID v4 trong 20-80ms dùng crypto.randomUUID(). Nếu cần hơn 1M UUID, chạy trình tạo này trong vòng lặp hoặc dùng kịch bản phía máy chủ — tạo UUID song song dễ dàng vì mỗi ID độc lập.

Xem thêm