Công cụ dành cho nhà phát triển · Trình tạo UUID
UUID Phiên bản 1 đến 8 Đã giải thích: Bạn nên tạo phiên bản nào?
· Lý lịch
uuid mật mã browser-apis
Tám phiên bản chia sẻ một định dạng nhưng giải quyết các vấn đề khác nhau: thứ tự thời gian, khả năng tái tạo, tính ngẫu nhiên hoặc bố cục tùy chỉnh. Bài đăng này giải thích từng vấn đề và đưa ra đường dẫn quyết định.
Một định dạng, tám công thức nấu ăn — tại sao phiên bản lại quan trọng khi bạn chọn một chức năng thư viện
Tiêu chuẩn UUID xác định định dạng 128-bit dưới dạng ba mươi sáu ký tự thập lục phân có dấu gạch nối. RFC 9562 xác định tám công thức riêng biệt—các phiên bản từ một đến tám—để lấp đầy những phần đó bằng các mẫu và ý nghĩa khác nhau. Phiên bản nibble (ký tự đầu tiên của nhóm thứ ba) xác định phương thức nào tạo ra giá trị, đóng vai trò là nhãn. Chọn sai phiên bản có nghĩa là lưu trữ thông tin tạm thời không cần thiết, thiếu đảm bảo thứ tự cho hiệu suất cơ sở dữ liệu hoặc hiểu sai vai trò bảo mật của mã định danh. Bài đăng này giới thiệu từng phiên bản, vấn đề cụ thể mà nó giải quyết, khi các nhà phát triển gặp phải nó trong thực tế và cung cấp khung quyết định để chọn phiên bản phù hợp với yêu cầu hệ thống cụ thể của bạn.
v1 và v6: nút cộng thời gian - bố cục dựa trên thời gian ban đầu và phiên bản được sắp xếp lại để sắp xếp chính xác
Phiên bản 1 kết hợp dấu thời gian 60-bit với mã nhận dạng nút (ban đầu là địa chỉ MAC, mặc dù các cách triển khai hiện đại sử dụng các giá trị ngẫu nhiên để tránh rò rỉ thông tin phần cứng). Dấu thời gian ghi lại các khoảng thời gian 100 nano giây kể từ tháng 10 15, 1582. Trường nút có thể tiết lộ thời điểm số nhận dạng được tạo và vị trí của số nhận dạng đó về mặt địa lý, đó là lý do tại sao việc triển khai hiện đại tránh các địa chỉ MAC. Phiên bản 6 sắp xếp lại cùng dấu thời gian và thông tin nút để cải thiện khả năng sắp xếp bằng cách di chuyển các bit thời gian bậc cao lên phía trước, giúp UUID v6 sắp xếp chính xác theo thứ tự từ điển. Nếu ứng dụng của bạn cần UUID sắp xếp tự nhiên theo thời gian tạo với vị trí chỉ mục ưu việt thì v6 là lựa chọn hiện đại.
v2: DCE Bảo mật — biến thể hiếm khi được sử dụng nhúng mã định danh POSIX
Phiên bản 2 hiếm khi được sử dụng trong các hệ thống mới. Nó nhúng POSIX số nhận dạng người dùng hoặc nhóm vào bố cục UUID, khiến nó chỉ hữu ích trong các môi trường cũ nơi những số nhận dạng đó mang ý nghĩa tổ chức. Thiết kế v2 giả định một mô hình điện toán cụ thể (DCE Security) không phổ biến trong các hệ thống phân tán hiện đại. Hầu hết các tổ chức liên kết UUID với người dùng hoặc nhóm trong lớp ứng dụng của họ thông qua các phép nối cơ sở dữ liệu hoặc bảng tra cứu, chứ không phải bằng cách mã hóa ID người dùng thành chính mã định danh. Việc tách biệt các mối quan tâm này giúp việc thay đổi mô hình ủy quyền, di chuyển dữ liệu người dùng và duy trì các quy trình kiểm tra trở nên dễ dàng hơn. Mã hóa thông tin xác thực trực tiếp vào UUID tạo ra sự liên kết chặt chẽ và khiến hệ thống khó phát triển hơn.
v3 và v5: dựa trên tên — ID xác định được băm từ một vùng tên và tên có MD5 hoặc SHA-1
Các phiên bản 3 và 5 UUID mang tính xác định: cùng một vùng tên và tên luôn tạo ra cùng một mã định danh, lý tưởng để thể hiện ánh xạ ổn định từ dữ liệu bên ngoài. Phiên bản 3 sử dụng MD5 và phiên bản 5 sử dụng SHA-1 làm thuật toán băm, phản ánh độ tuổi và việc áp dụng tương ứng của chúng. Khi một bản ghi khách hàng đến để nhập, v5 UUID bắt nguồn từ một vùng tên cố định sẽ giống hệt nhau qua nhiều lần nhập, ngăn chặn các bản ghi trùng lặp. Tính xác định này có nghĩa là UUID có thể tái tạo và dự đoán được đối với bất kỳ ai biết không gian tên và thông tin đầu vào. Giá trị thực tế tỏa sáng trong các tình huống tích hợp dữ liệu: đối chiếu hồ sơ khách hàng từ nhiều hệ thống, ngăn ngừa trùng lặp trong quá trình nhập định kỳ và gán ID ổn định cho các mặt hàng.
v4: ngẫu nhiên — 122 bits từ CSPRNG và lựa chọn mặc định khi đặt hàng không thành vấn đề
Phiên bản 4 là lựa chọn mặc định khi không cần đặt hàng và bạn muốn tạo độc lập mà không cần sự phối hợp trung tâm. Phiên bản v4 UUID bao gồm 122 bits từ một nguồn ngẫu nhiên được bảo mật bằng mật mã, với sáu bit được đặt thành giá trị cố định (phiên bản nibble 4 và RFC 9562 bit biến thể 10). Tính ngẫu nhiên là toàn bộ vấn đề: mỗi cuộc gọi tạo ra một giá trị khác nhau, xung đột hầu như không thể xảy ra và không cần trạng thái hoặc sự phối hợp bên ngoài. Đây là phiên bản ToolAcre được tạo bằng crypto.randomUUID() hoặc crypto.getRandomValues(). Phiên bản này phù hợp với các tham chiếu đối tượng, dữ liệu phi cấu trúc và hầu hết các vai trò bên ngoài khóa chính hoặc bối cảnh sắp xếp.
v7 và v8: Thời gian và tùy chỉnh Unix — phiên bản được sắp xếp theo thời gian hiện đại cho các khóa cơ sở dữ liệu và lối thoát cho các bố cục riêng
Phiên bản 7, được chuẩn hóa ở RFC 9562, đưa các thuộc tính theo thứ tự thời gian hiện đại sang định dạng UUID. Nó sử dụng dấu thời gian mili giây Unix 48-bit, 12 bits có độ chính xác dưới một phần nghìn giây và 62 bit ngẫu nhiên được kết hợp. Dấu thời gian mili giây của Unix vẫn hoạt động cho đến năm 10889, khiến nó phù hợp với các hệ thống. Kết quả sắp xếp chính xác theo thứ tự từ điển và khớp với cột 128-bit UUID tiêu chuẩn mà không cần xử lý hoặc chuyển đổi mã hóa đặc biệt. Nếu ứng dụng của bạn cần số nhận dạng sắp xếp theo thời gian tạo theo định dạng UUID tiêu chuẩn thì v7 là phương pháp hay nhất hiện tại. Phiên bản 8 là phiên bản tổng hợp được tiêu chuẩn hóa cho các định dạng do triển khai xác định, chỉ hữu ích nếu bạn cần bố cục bit cụ thể không có trong v1-v7.
Ví dụ đã hoạt động — đường dẫn quyết định được áp dụng cho ba trường hợp: tham chiếu API công khai, khóa chính và ID ổn định cho các bản ghi đã nhập
Ba tình huống trong thế giới thực minh họa việc lựa chọn phiên bản: Thứ nhất, tham chiếu API công khai phải ổn định trên các phiên bản API, không được rò rỉ thời gian tạo và phải giống nhau trong các lần khởi động lại máy chủ để các phiên bản khác nhau tạo ra cùng một tham chiếu cho cùng một tài liệu. Sử dụng v5 với không gian tên và tên tài liệu ổn định. Thứ hai, khóa chính cho một bảng đang phát triển liên tục cần phải là duy nhất, không được gây phân mảnh chỉ mục và phải được tạo bởi bất kỳ phiên bản ứng dụng nào mà không cần sự phối hợp trung tâm. Sử dụng phiên bản 7 cho các số nhận dạng có thể sắp xếp với sự hỗ trợ của hệ sinh thái UUID tiêu chuẩn. Thứ ba, các hồ sơ lưu trữ yêu cầu tra cứu ổn định cần có mã định danh bất biến.
Bài học rút ra: chọn theo thuộc tính, không phải theo thói quen — trình tạo ToolAcre tạo ra các UUID ngẫu nhiên từ CSPRNG của trình duyệt cho các trường hợp yêu cầu v4
Việc lựa chọn phiên bản tuân theo yêu cầu hệ thống và thiết kế lược đồ của bạn chứ không phải theo quy ước hoặc sự quen thuộc. UUID ngẫu nhiên (v4) là mặc định vì chúng không yêu cầu trạng thái hoặc sự phối hợp và tạo ra các mã định danh độc lập phù hợp với hầu hết các vai trò. Các phiên bản theo thứ tự thời gian (v6, v7) giải quyết các vấn đề về vị trí chỉ mục với cái giá phải trả là rò rỉ thông tin tạm thời hoặc yêu cầu đồng bộ hóa đồng hồ. Các phiên bản xác định (v3, v5) ngăn chặn việc nhập trùng lặp và cho phép ánh xạ bên ngoài ổn định với chi phí có thể dự đoán được—bất kỳ ai biết không gian tên của bạn đều có thể tính toán lại chúng. ToolAcre tạo UUID v4 ngẫu nhiên từ trình tạo bảo mật bằng mật mã của trình duyệt. Khi bạn cần một phiên bản khác, việc kiểm tra được định dạng đúng sẽ xác nhận phân tích cú pháp số nhận dạng là hợp lệ.