Công cụ dành cho nhà phát triển · Trình tạo UUID
GUID so với UUID: Giải thích về Niềng răng, Thứ tự byte và Biến thể của Microsoft
· Lý lịch
uuid mật mã browser-apis
GUID là tên Microsoft đặt cho UUID, nhưng thứ tự dấu ngoặc nhọn, chữ hoa và byte có thể làm cho cùng một mã định danh trông khác nhau trên các nền tảng. Bài đăng này giải thích từng sự khác biệt và cách so sánh một cách an toàn.
Cùng một ID không khớp trên các hệ thống — dịch vụ .NET và dịch vụ Java không đồng ý về một bản ghi
Dịch vụ .NET tạo GUID và gửi nó đến dịch vụ Java, dịch vụ này cố gắng khớp giá trị với UUID từ PostgreSQL. Việc so sánh chuỗi không thành công và hệ thống báo cáo rằng số nhận dạng không khớp, mặc dù cả ba dịch vụ đều hoạt động với cùng 16 bytes cơ bản. Sự khác biệt dường như mang tính thẩm mỹ—dấu ngoặc nhọn, cách viết hoa, thứ tự byte—nhưng chúng khiến cho việc so sánh chuỗi không thành công và gây nhầm lẫn cho các điểm tích hợp không chuẩn hóa ở ranh giới. GUID là thuật ngữ của Microsoft cho cái mà RFC 9562 gọi là UUID: mã định danh 128-bit có cùng bố cục bit. Hai cái tên đề cập đến cùng một cấu trúc cơ bản, nhưng cách biểu diễn khác nhau khiến các nhà phát triển phải ngạc nhiên. Hiểu được nguồn gốc của sự nhầm lẫn sẽ ngăn ngừa lỗi tích hợp.
GUID là UUID — định dạng 128-bit được chia sẻ và sự khác biệt về cách đặt tên đến từ đâu
GUID là viết tắt của Mã định danh duy nhất toàn cầu và Mã định danh duy nhất toàn cầu và là tên mà Microsoft sử dụng cho tiêu chuẩn RFC gọi UUID. Bố cục 128-bit và hệ thống phiên bản/variant giống hệt nhau. RFC 4122 và RFC 9562 chỉ định định dạng và ý nghĩa UUID; Microsoft triển khai chúng và sử dụng thuật ngữ GUID. Sự khác biệt về cách đặt tên mang tính lịch sử: Microsoft đã sử dụng GUID trước khi UUID được IETF chuẩn hóa và thuật ngữ của Microsoft đã bị mắc kẹt trong hệ sinh thái .NET. Ở cấp độ bit, GUID và UUID hoàn toàn có thể hoán đổi cho nhau. Ở cấp độ định dạng, chúng khác nhau về cách trình bày: mã .NET thường ghi GUID bằng dấu ngoặc nhọn và chữ in hoa, trong khi RFC UUID chuẩn sử dụng chữ thường và không có dấu ngoặc nhọn.
Dấu ngoặc nhọn và chữ hoa — biểu mẫu {XXXXXXXX-...} kiểu đăng ký và cách chuẩn hóa nó
UUID ở dạng RFC chuẩn được viết dưới dạng tám, bốn, bốn, bốn và mười hai ký tự thập lục phân viết thường, phân tách bằng dấu gạch ngang: 550e8400-e29b-41d4-a716-446655440000. A .NET GUID thường được hiển thị bằng dấu ngoặc nhọn và chữ hoa: {550E8400-E29B-41D4-A716-446655440000}. Các dấu ngoặc nhọn có nguồn gốc từ định dạng Windows Registy; chữ hoa là một quy ước hiển thị. Cả hai biểu mẫu đều thể hiện 128 bits giống hệt nhau. Để khớp GUID từ .NET với UUID từ PostgreSQL, hãy loại bỏ dấu ngoặc nhọn và chuẩn hóa cách viết hoa, sau đó so sánh các chuỗi. ToolAcre séc được định dạng đúng sẽ chấp nhận dạng chuẩn và tự động xóa dấu ngoặc nhọn. Chuẩn hóa là một chuyển đổi văn bản nhỏ nhằm bảo toàn tất cả ý nghĩa.
Thứ tự byte endian hỗn hợp — cách ba trường đầu tiên được lưu trữ endian nhỏ trong cấu trúc GUID và tại sao Guid.ToByteArray khác với thứ tự byte RFC
Sự khác biệt nguy hiểm giữa GUID và UUID là thứ tự byte. RFC 9562 chỉ định rằng ba trường đầu tiên (8, 4 và 4 nhóm thập lục phân) được lưu trữ theo thứ tự byte lớn (mạng). .NET Cấu trúc hướng dẫn lưu trữ ba trường đầu tiên ở dạng endian nhỏ: các byte được đảo ngược trước khi ghi vào bộ lưu trữ. 16 bytes tương tự, khi được viết bởi .NET Guid.ToByteArray() và được giải thích bởi mã tuân thủ RFC, sẽ tạo ra cách trình bày văn bản hoàn toàn khác nhau. UUID 550e8400-e29b-41d4-a716-446655440000 theo thứ tự RFC byte được lưu dưới dạng byte 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00.
Biến thể cũ của Microsoft - c hoặc d trong ký tự đầu tiên của nhóm thứ tư nghĩa là gì
Ngoài thứ tự byte, số nhận dạng cũ của Microsoft đôi khi sử dụng trường biến thể không chuẩn. Trong đó RFC 9562 chỉ định rằng ký tự đầu tiên của nhóm thứ tư phải là 8, 9, a hoặc b, các GUID cũ của Microsoft có thể sử dụng c, d, e hoặc f. Đây vẫn là các UUID hợp lệ nhưng tuân theo một biến thể cũ có trước quá trình tiêu chuẩn hóa RFC. Nếu bạn gặp GUID với c hoặc d trong ký tự đầu tiên của nhóm thứ tư thì bạn có giá trị bit 128 hợp lệ không tuân theo các bit biến thể RFC. .NET hiện đại tạo GUID tuân thủ RFC, vì vậy số nhận dạng mới sẽ không thể hiện vấn đề này. Các bit biến thể kế thừa rất hiếm nhưng quan trọng cần nhận ra.
Ví dụ đã hoạt động — cùng một 16 bytes được hiển thị theo thứ tự RFC và theo thứ tự cấu trúc GUID, hiển thị chính xác những ký tự nào được hoán đổi
Lấy UUID 550e8400-e29b-41d4-a716-446655440000 và chuyển đổi nó thành dạng mảng byte .NET GUID bằng cách sử dụng quy ước endian nhỏ. Theo thứ tự RFC, các byte là: trường đầu tiên (550e8400) bằng 55 0e 84 00, trường thứ hai (e29b) bằng e2 9b, trường thứ ba (41d4) bằng 41 d4, thứ tư và thứ năm bằng a7 16 44 66 55 44 00 00. Trong .NET little-endian: trường đầu tiên trở thành 00 84 0e 55, trường thứ hai trở thành 9b e2, trường thứ ba trở thành d4 41 và phần còn lại vẫn ở dạng big-endian. Mảng byte đầy đủ là 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Nếu hệ thống Java đọc các byte này theo thứ tự RFC, thì nó sẽ hiểu chúng là 00840e55-9be2-d441-a716-446655440000.
Nội dung này không đề cập đến — SQL NEWSEQUENTIALID của máy chủ và đặt hàng, vốn là chủ đề lưu trữ của riêng họ
SQL Hành vi của chức năng NEWSEQUENTIALID của máy chủ và các thuộc tính thứ tự nhận dạng cụ thể của nó là lớp lưu trữ và các chủ đề dành riêng cho cơ sở dữ liệu. Bài đăng này tập trung vào sự khác biệt về định dạng và thứ tự byte ở cấp độ ứng dụng và tuần tự hóa. Các vấn đề xử lý UUID dành riêng cho cơ sở dữ liệu chuyên sâu và các vấn đề về thứ tự byte được giải quyết tốt nhất trong tài liệu dành riêng cho nền tảng cơ sở dữ liệu đó. Các hệ thống cơ sở dữ liệu khác nhau có các cách tiếp cận và cách tiếp cận khác nhau đối với UUID lưu trữ, lập chỉ mục, sắp xếp và hỗ trợ gốc. Một số cơ sở dữ liệu tự động phát hiện phiên bản và bit biến thể, trong khi một số cơ sở dữ liệu khác yêu cầu khai báo loại rõ ràng và xử lý thứ tự byte ở ranh giới giữa hệ thống và bộ lưu trữ.
Bài học rút ra: chuẩn hóa ở ranh giới — kiểm tra ToolAcre chấp nhận dạng chuẩn, đây là hình dạng để chuẩn hóa khi trao đổi ID
Bình thường hóa tại ranh giới khi số nhận dạng vượt qua a .NET/non-.NET ranh giới hệ thống. Tách các dấu ngoặc nhọn, chuẩn hóa cách viết hoa một cách nhất quán và hoán đổi byte trong ba trường đầu tiên nếu byte đến từ .NET Guid.ToByteArray(). kinh điển RFC biểu mẫu là tiêu chuẩn tham chiếu: tám, bốn, bốn, bốn và mười hai ký tự thập lục phân viết thường có dấu gạch nối, không có dấu ngoặc nhọn, thứ tự byte lớn. Khi trao đổi với .NET thống nhất, thống nhất về dạng chuẩn hóa và áp dụng các chuyển đổi một cách rõ ràng trong mã tích hợp. Ghi lại việc xử lý thứ tự byte và kiểm tra chuyển đổi kỹ lưỡng. Điểm tương đồng cơ bản cốt lõi giữa GUID Và UUID có ý nghĩa nhất 128 bits giống hệt nhau.