Công cụ dành cho nhà phát triển · Trình tạo UUID
Từ 128 Bits đến 36 Ký tự: Cách thức hoạt động của mã hóa văn bản UUID
· Cách thức hoạt động
uuid mật mã browser-apis
UUID là 16 bytes nhưng dạng quen thuộc của nó là 36 ký tự. Bài đăng này giải thích cách nhân đôi hex, dấu gạch nối, quy tắc viết hoa và cách mã hóa ngắn hơn mà mọi người sử dụng khi biểu mẫu chuẩn quá dài.
Tại sao cột rộng hơn giá trị — giá trị 16 byte có giá 36 ký tự trong văn bản và điều đó có ý nghĩa gì đối với URL và bộ nhớ
Chiều rộng cột lưu trữ tăng vọt khi bạn chọn định dạng UUID. Giá trị 128 bit là 16 bytes, nhưng cách trình bày văn bản của nó phụ thuộc vào mã hóa: thập lục phân (36 ký tự có dấu gạch ngang, 32 không có), base64url (22 ký tự), base58 (22–23 ký tự), Crockford base32 (26 ký tự). Nếu lược đồ của bạn lưu trữ UUID dưới dạng VARCHAR(36), thì bạn đang sử dụng 36 ký tự trong mỗi hàng. Trong một bảng có 1 tỷ hàng và không có cột nào khác, tức là tiêu tốn 36 gigabyte văn bản so với 16 gigabyte nhị phân. Sự lựa chọn không chỉ mang tính thẩm mỹ; nó ảnh hưởng đến kích thước truy vấn, số lần truyền khứ hồi mạng và áp lực bộ nhớ đệm. Định dạng chuẩn là 36 ký tự: tám chữ số thập lục phân, dấu gạch ngang, bốn chữ số thập lục phân, dấu gạch ngang, bốn chữ số thập lục phân, dấu gạch ngang, bốn chữ số thập lục phân, dấu gạch nối, mười hai chữ số thập lục phân.
Hex nhân đôi mọi thứ — mỗi byte trở thành hai ký tự và bốn dấu gạch nối hoàn thành 36
Mỗi byte trở thành chính xác hai ký tự thập lục phân (0–9, a–f). Các dấu gạch nối có ở đó vì lý do dễ đọc và kế thừa từ khi UUID được chỉ định lần đầu tiên. Mã hóa thập lục phân tăng gấp đôi số byte: 16 bytes trở thành 32 chữ số thập lục phân cộng với 4 dấu gạch nối. Đây là cách mã hóa chậm nhất và dài nhất nhưng con người có thể đọc được và được hỗ trợ ở mọi nơi. Quy tắc viết hoa: RFC 9562 bắt buộc phải viết thường cho đầu ra chuẩn, nhưng đầu vào không phân biệt chữ hoa chữ thường. Việc lưu trữ chữ hoa sẽ lãng phí cơ hội chuẩn hóa, vì vậy hãy lưu trữ chữ thường và so sánh không phân biệt chữ hoa chữ thường trên đầu vào. Mã hóa Base64url biểu thị ba byte dưới dạng bốn ký tự bằng cách sử dụng bảng chữ cái ký tự 64 (A–Z, a–z, 0–9, dấu trừ, dấu gạch dưới). Mười sáu byte trở thành 21 ký tự cộng với một ký tự đệm, tổng cộng 22 ký tự. Base64url loại bỏ phần đệm và các ký tự chuẩn (dấu cộng và dấu gạch chéo) được dành riêng trong URL.
Quy tắc viết hoa - chữ thường ở đầu ra, không phân biệt chữ hoa chữ thường ở đầu vào và lý do so sánh giữa các chữ hoa chữ thường gây ra sự không khớp thầm lặng
UUID ở định dạng base64url lưu 14 ký tự so với hex và hợp lệ trong các URL không cần mã hóa phần trăm. Đổi lại: nó khó đọc hơn (các chữ cái viết thường trông giống chữ số; b, 8, B và 8 rất dễ nhầm lẫn). Base58 được Bitcoin và các chuỗi khối khác sử dụng và loại bỏ các ký tự không rõ ràng (0, O, I, l), tạo ra kết quả 22–23 ký tự trong khi vẫn có thể đọc được. Crockford base32 (được thiết kế cho các định dạng giống như ISBN được tổng kiểm tra) sử dụng các ký tự 26 và ưu tiên tính chính xác hơn là sự ngắn gọn. Bẫy thứ tự byte GUID của Microsoft áp dụng cho bộ lưu trữ UUID trong một số cơ sở dữ liệu. RFC 9562 chỉ định thứ tự byte mạng (cuối lớn) cho tất cả byte. Một số cấu hình máy chủ Microsoft SQL lưu trữ GUID với thứ tự byte cuối nhỏ trong ba trường đầu tiên.
Mã hóa ngắn hơn — base64url ở 22 ký tự, base58 và Crockford base32, với sự cân bằng giữa khả năng đọc và độ an toàn khi sao chép-dán
Cùng một giá trị 128-bit được lưu trữ trong big-endian và little-endian tạo ra các chuỗi hex khác nhau. UUID 550e8400-e29b-41d4-a716-446655440000 được lưu trữ dưới dạng Microsoft GUID có thể được truy xuất dưới dạng 00840e55-9be2-d441-a716-446655440000 (byte 0–3 và 4–5 và 6–7 bị đảo ngược). Nếu hệ thống của bạn kết nối giữa các hệ thống tuân thủ RFC và Microsoft, bạn phải biết điều này và chuẩn hóa ở ranh giới hoặc ghi lại định dạng bạn đang sử dụng trong mỗi cột. Ví dụ đã hoạt động: v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 ở dạng thập lục phân chiếm 36 ký tự. Vì 16 bytes nó là 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60. Trong base64url: chia thành các đoạn ba byte, chuyển đổi thành base64, phần đệm dải: my5PGk8-TBqKfRssPTRPX2A. Ở dạng thập lục phân không có dấu gạch nối: 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 ký tự).
Bẫy thứ tự byte của Microsoft — cách ba trường đầu tiên của GUID được lưu trữ ở endian nhỏ, do đó, các byte giống nhau có thể in dưới dạng hai chuỗi khác nhau
Base64url lưu 14 ký tự; base58 sẽ tiết kiệm gần như nhau; thập lục phân là tiêu chuẩn. Chọn dựa trên trường hợp sử dụng của bạn: nếu mã định danh xuất hiện trong URL và mọi ký tự đều quan trọng, hãy sử dụng base64url; nếu nó xuất hiện trong nhật ký và giao diện người dùng nơi con người đọc nó, hãy sử dụng dạng chuẩn thập lục phân; nếu bạn đang xây dựng một hệ thống blockchain hoặc hệ thống phân tán trong đó việc kiểm tra tổng quan là vấn đề quan trọng, hãy sử dụng base58 hoặc Crockford base32. Khi chọn loại cột, hãy lưu trữ giá trị tối ưu hóa cho mẫu truy cập thực tế của bạn. Nếu bạn thường xuyên truy vấn UUID và cần khớp không phân biệt chữ hoa chữ thường, hãy lưu trữ nhị phân(16) và để cơ sở dữ liệu xử lý việc biểu diễn. Nếu bạn truy vấn theo chuỗi con (tìm kiếm UUID bắt đầu bằng tiền tố), hệ thập lục phân sẽ dễ đọc hơn trong đầu ra gỡ lỗi.
Ví dụ đã hoạt động - một mã định danh được viết dưới dạng byte, hex chuẩn và dạng rút gọn, hiển thị từng bước chuyển đổi
Nếu bạn xuất sang CSV và gửi email cho người dùng không rành về kỹ thuật thì hệ thập lục phân sẽ dễ nhận biết hơn. Nếu bạn bị hạn chế về không gian (ứng dụng di động có bộ đệm cục bộ), base64url hoặc base58 sẽ tiết kiệm băng thông. Trình tạo ToolAcre xuất ra định dạng thập lục phân 36 ký tự chuẩn; nếu bạn cần một mã hóa khác, kiểm tra đúng định dạng vẫn hoạt động vì nó bình thường hóa mọi biểu diễn hợp lệ trước khi kiểm tra định dạng. Vấn đề cân nhắc về hiệu suất rất quan trọng khi mã hóa hoặc giải mã hàng triệu UUID. Mã hóa thập lục phân rất đơn giản: chuyển đổi mỗi byte thành hai ký tự trong thời gian O(1) trên mỗi byte. Việc giải mã cũng đơn giản không kém. Mã hóa và giải mã Base64 sử dụng bảng tra cứu và chậm hơn một chút (chậm hơn khoảng 2–3x so với hex trên mỗi byte, tùy thuộc vào phần cứng và cách triển khai). Base58 chậm hơn đáng kể vì về cơ bản nó là chuyển đổi cơ sở và yêu cầu số học mô-đun.
Điều này không bao gồm những gì - các lựa chọn cột cơ sở dữ liệu, chẳng hạn như loại uuid gốc so với nhị phân (16), được đề cập riêng
Nếu hệ thống của bạn mã hóa hoặc giải mã UUID theo vòng lặp nóng (tạo mã định danh tần số cao, xuất hàng loạt), hệ thập lục phân sẽ nhanh hơn. Nếu quá trình mã hóa diễn ra không thường xuyên và vấn đề tiết kiệm ký tự 14 thì base64url là một sự cân bằng hợp lý. Trình tạo ToolAcre xuất ra dạng hex, do đó bạn sẽ có được lợi thế về hiệu suất mà không phải hy sinh khả năng tương thích. Ngữ nghĩa so sánh chuỗi khác nhau tùy theo mã hóa. UUID thập lục phân có thể được so sánh dưới dạng chuỗi: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (so sánh từ điển hoạt động). UUID nhị phân có thể được so sánh dưới dạng byte: so sánh từng byte cũng giống như so sánh số. Tuy nhiên, các UUID được mã hóa Base64url và base58 không giữ nguyên thứ tự số trong so sánh chuỗi từ điển. Nếu hệ thống của bạn dựa vào cách sắp xếp từ điển của UUID (một mẫu phổ biến đáng ngạc nhiên để xây dựng chỉ mục hoặc khóa cơ sở dữ liệu), thì bạn phải sử dụng biến thể thập lục phân, nhị phân hoặc biến thể UUID có thể sắp xếp (v6 hoặc v7).
Bài học rút ra: giữ dạng chuẩn ở các ranh giới - trình tạo ToolAcre xuất ra các UUID ký tự 36 tiêu chuẩn và kiểm tra của nó chấp nhận các chuỗi ở dạng đó
Trình tạo ToolAcre hiện tạo ra UUID v4, không thể sắp xếp theo thứ tự mã hóa. Khả năng tương tác yêu cầu tiêu chuẩn hóa trên một mã hóa duy nhất. Một hệ thống chấp nhận đồng thời UUID ở dạng hex, base64 và base58 phải chuẩn hóa tất cả đầu vào thành dạng chuẩn trước khi xử lý. Điều này là có thể nhưng làm tăng thêm sự phức tạp. Các API hoặc cơ sở dữ liệu bên ngoài có thể yêu cầu mã hóa cụ thể: một số API yêu cầu urn:uuid: hex có tiền tố, một số khác yêu cầu hex không gạch nối, một số khác yêu cầu base64url. Ghi lại kỳ vọng mã hóa UUID của hệ thống của bạn một cách rõ ràng trong hợp đồng API. Trình tạo ToolAcre luôn xuất ra hệ thập lục phân chuẩn; nếu bạn cần các cách mã hóa khác, hãy thực hiện chuyển đổi một cách rõ ràng và ghi lại những cân bằng (không gian, hiệu suất, khả năng đọc, khả năng sắp xếp) cho nhóm.