Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã Base64
Base64 vs hex vs base32: so sánh ba cách ghi byte dưới dạng văn bản
· Lý lịch
base64 mã hóa
Hex, base32 và Base64 giải quyết cùng một vấn đề với sự cân bằng khác nhau về kích thước, khả năng đọc và độ an toàn. Bài đăng này so sánh chúng về mật độ, phân biệt chữ hoa chữ thường, URL độ an toàn và lỗi của con người.
Khóa API bị nhập sai do l, 1, I và O — một lỗi cụ thể về khả năng đọc mà hệ thập lục phân lẽ ra không có
Ba cách phổ biến để biểu diễn byte dưới dạng văn bản là hex, base32 và base64. Tất cả chúng đều giải quyết cùng một vấn đề (biểu thị các byte tùy ý ở dạng ASCII có thể in được) nhưng có sự đánh đổi khác nhau về kích thước, khả năng đọc và khả năng phục hồi lỗi. Hệ thập lục phân có 2 ký tự trên mỗi byte (F3 A2 B1 ...), vì vậy 16 bytes trở thành 32 ký tự. Base32 có 1.6 ký tự trên mỗi byte (khoảng 5 ký tự trên 3 bytes), vì vậy 16 bytes trở thành 26 ký tự.
Base64 có 1.33 ký tự trên mỗi byte (chính xác là 4 ký tự trên 3 bytes), vì vậy 16 bytes trở thành 24 ký tự trở xuống. Nếu kích thước tệp quan trọng thì base64 là nhỏ gọn nhất. Nếu phiên âm của con người có vấn đề, hex và base32 sẽ an toàn hơn. Sự khác biệt về khả năng đọc là rất quan trọng khi một giá trị được nhập, sao chép hoặc nói. Hex sử dụng 0-9 và a-f (không phân biệt chữ hoa chữ thường trong hầu hết các ngữ cảnh). Kênh phiên âm thay đổi quyết định vì cách trình bày được tối ưu hóa cho máy móc có thể gây khó khăn cho con người. Base64 phân biệt chữ hoa chữ thường và sử dụng hai ký hiệu dấu chấm câu; hex sử dụng từ vựng trực quan nhỏ hơn. Việc triển khai ở đây kiểm tra các chuỗi chính xác chứ không phải tỷ lệ lỗi do con người, do đó không có xác suất được phát minh nào được đính kèm.
Mật độ: 2×, 1.6× và 1.33× — mỗi mã hóa cần bao nhiêu ký tự cho mỗi byte và lý do
Base32 sử dụng A-Z và 2-7, tránh 0, 1, O và I dễ bị nhầm lẫn trên giấy tờ. Base64 sử dụng A-Z, a-z, 0-9, + và /, bao gồm cả chữ hoa và chữ thường, làm cho nó phân biệt chữ hoa chữ thường và trộn các chữ số trông giống nhau (0 so với O, 1 so với I so với chữ thường l). Khóa API ở dạng hex có thể là f3a2b1e4; các byte tương tự trong base64 có thể là 86KrvE== (có phần đệm) hoặc trong base32 6VEV7FI= (có phần đệm).
Nếu người dùng phải nhập giá trị bằng tay, hex hoặc base32 sẽ an toàn hơn base64. Các ký tự dành riêng trong URL rất quan trọng. Hex và base32 an toàn cho URL; cả hai đều chỉ sử dụng ký tự chữ và số (hex cũng sử dụng 0-9, base32 cũng sử dụng 2-7). Base64 sử dụng dấu cộng và dấu gạch chéo được dành riêng URL (dấu cộng biểu thị khoảng trắng trong dữ liệu được mã hóa biểu mẫu, dấu gạch chéo là dấu phân cách đường dẫn). Mật độ Base64 theo sau trực tiếp từ sáu bit hữu ích cho mỗi ký hiệu đầu ra và phần đệm cho các khối bốn ký tự. Hex mang bốn bit cho mỗi ký hiệu, tạo thành hai ký tự trên mỗi byte. Base32 chỉ được thảo luận dưới dạng bối cảnh so sánh vì kho lưu trữ này không cung cấp bảng chữ cái cũng như bộ mã hóa để xác minh kết quả đầu ra.
Mật độ từ độ rộng bit - số học Base64 và hex chính xác, với Base32 được coi là bối cảnh so sánh
Chuỗi base64 trong tham số URL phải được mã hóa theo phần trăm (cộng trở thành %2B, dấu gạch chéo trở thành %2F), thêm 4 ký tự bổ sung cho mỗi lần xuất hiện. Base64url (RFC 4648 phần 5) thay thế dấu cộng bằng dấu gạch ngang và dấu gạch chéo bằng dấu gạch dưới, làm cho nó URL an toàn mà không cần mã hóa phần trăm. Hầu hết các API sử dụng base64 trong URL thực tế đều sử dụng base64url, nhưng sự khác biệt thường không rõ ràng trong tài liệu.
TOTP bí mật (mã được ứng dụng xác thực sử dụng) thường được phân phối dưới dạng base32. Màn hình đăng ký TOTP hiển thị bí mật base32 vì nó dễ nhập và phiên âm hơn so với các byte tương tự ở base64 hoặc hex. SHA thông báo băm thường được hiển thị ở dạng hex vì đây là định dạng truyền thống và do hex không phân biệt chữ hoa chữ thường nên ít xảy ra lỗi chính tả hơn. Phân biệt chữ hoa chữ thường quan trọng khi ai đó đọc to một giá trị hoặc gõ lại nó, vì việc thay đổi kiểu chữ của một chữ cái sẽ làm thay đổi chỉ mục của nó. ToolAcre bảo toàn chính xác kiểu chữ và sẽ giải mã các byte khác nhau thu được mà không biết con người đã mắc lỗi phiên mã. Bản thân sự biểu diễn không có tổng kiểm tra.
Các ký tự dành riêng và sự an toàn URL — vị trí + và / cắn cũng như cách base32 và hex tránh được sự cố
JWT sử dụng base64url. Tổng kiểm tra tệp có thể là hex hoặc base64; cả hai đều phổ biến. Sự lựa chọn là quy ước lịch sử, không phải là sự cần thiết về mặt kỹ thuật. Khả năng phục hồi lỗi là một sự khác biệt tinh tế nhưng quan trọng. Base32 tránh các chữ số 0, 1, 8 và 9 (trông giống như các chữ cái), giảm lỗi phiên âm. Base64 bao gồm tất cả các chữ số, làm cho 1 không rõ ràng (đó là chữ cái I, chữ l thường hay chữ số 1?).
Hex thậm chí còn dễ bị lỗi hơn: 0 trông giống O, l trông giống 1. Tổng kiểm tra phải được gõ hoặc đọc từ bản in sẽ an toàn hơn trong base32. Khóa API được dán trực tiếp từ máy tính sẽ an toàn ở mọi định dạng; khả năng đọc chỉ quan trọng khi có sự tham gia của mắt người. Các byte giống nhau nhưng mã hóa khác nhau: chuỗi 16-byte [0xf3, 0xa2, 0xb1, ...] trở thành f3a2b1... Dấu cộng và dấu gạch chéo của Base64 tiêu chuẩn cần xử lý nhận biết kênh; URL-chế độ an toàn thay thế chúng bằng dấu gạch nối và dấu gạch dưới. Hex tránh những dấu phân cách đó bằng cách chỉ sử dụng chữ số và chữ cái. Các quy ước Base32 khác nhau nên bài viết này tránh các đặc tính an toàn đầy hứa hẹn mà kho lưu trữ không triển khai hoặc kiểm tra.
Ví dụ đã hoạt động: 16 bytes giống nhau ở cả ba bảng mã — so sánh độ dài và kiểm tra trực quan
ở dạng hex, 6VEV7FI=... trong base32 và 86KrvE== trong base64. Không có chuỗi nào trong số này có thể hoán đổi cho nhau. Một ứng dụng nhận được f3a2b1... mong đợi hex và sẽ cố gắng phân tích nó dưới dạng hex. Việc nhận 86KrvE== sẽ không thành công nếu ứng dụng mong đợi hex. Định dạng mã hóa là một phần trong hợp đồng của dữ liệu: người gửi và người nhận phải đồng ý về việc sử dụng mã hóa nào. Đệm là một sự khác biệt khác.
Hex không sử dụng phần đệm (4 bytes luôn là 8 ký tự hex, không có ngoại lệ). Cả Base32 và base64 đều sử dụng phần đệm bằng nhau để căn chỉnh đầu ra thành bội số ký tự (8 cho base32, 4 cho base64). Phần đệm là cần thiết về mặt toán học; nó đảm bảo rằng mỗi đầu vào n byte tạo ra số lượng ký tự xác định. Các quy tắc đệm khác nhau: một số ứng dụng yêu cầu đệm, một số khác cho phép bỏ qua nó. Việc so sánh được thực hiện sử dụng một chuỗi byte cố định và tính toán Base64 và hex một cách máy móc. Độ dài Base32 của nó có thể được thảo luận từ nhóm năm bit, nhưng giá trị văn bản Base32 chính xác bị bỏ qua vì không có triển khai được xem xét nào tạo ra nó. Số học độ dài và xác minh đầu ra được giữ riêng biệt.
Trong đó mỗi cái đều là quy ước — băm ở dạng hex, TOTP bí mật trong base32, JWT và dữ liệu: URI trong Base64
Khi dán giá trị base32 hoặc base64 mà không có phần đệm, bộ giải mã có thể chấp nhận hoặc từ chối giá trị đó tùy thuộc vào việc triển khai. Khóa mật mã và mã thông báo cho thấy sự khác biệt về mã hóa.
Khóa HMAC là 32 bytes, trở thành 64 ký tự hex, 52 ký tự base32 (có phần đệm) hoặc 44 ký tự base64 (có phần đệm). Khi phân phối khóa, mã hóa phải được ghi lại. Nếu tài liệu cho biết khóa là 44 ký tự base64 nhưng bạn nhận được 52 ký tự thì đã xảy ra lỗi. Quy ước có thể hướng dẫn người đọc nhưng không chứng minh được sự phù hợp. Thông báo băm thường được hiển thị dưới dạng hex, trong khi phân đoạn JWT sử dụng Base64url. Lựa chọn đúng vẫn phụ thuộc vào các quy tắc kênh, liệu mọi người có sao chép giá trị hay không và liệu một giao thức khác đã sửa lỗi biểu diễn hay chưa.
Điều này không bao gồm những gì - mã hóa base58, base85 và tổng kiểm tra
Mã hóa base64 ngắn hơn giúp việc gắn mã thông báo vào các hệ thống có giới hạn ký tự (như mã QR hoặc URL) dễ dàng hơn một chút. Việc lựa chọn mã hóa cho một giá trị được đặt bởi bất kỳ hệ sinh thái nào mà nó đến từ đó. API web thường sử dụng base64url. Tài liệu mật mã thường sử dụng hex. Ứng dụng xác thực sử dụng base32. Khi xây dựng một hệ thống, hãy chọn một mã hóa, ghi lại nó một cách rõ ràng và gắn bó với nó.
Trộn các mã hóa (nói base64 hoặc base32) gây ra sự nhầm lẫn. Khi gỡ lỗi, bước đầu tiên là xác định giá trị sử dụng mã hóa nào; công cụ mã hóa & giải mã Base64 có thể trợ giúp bằng cách cố gắng giải mã nó theo nhiều cách và xem cách nào tạo ra đầu ra hợp lý. Không có mã hóa nào là tốt hơn trên toàn cầu. Base64 nhỏ gọn nhất để lưu trữ thô. Hex quen thuộc nhất với các nhà mật mã và dễ đọc nhất đối với các chuỗi nhỏ. Các mã hóa Base58, Base85 và tổng kiểm tra tạo ra sự đánh đổi khác nhau và không có trong bảng điều khiển Base64 của ToolAcre. Bảng chữ cái, quy tắc mơ hồ và tổng kiểm tra của chúng phải được đánh giá bằng các nguồn và cách triển khai chuyên dụng thay vì ngoại suy từ hành vi đã được thử nghiệm của công cụ này.
Bài học rút ra: chọn mã hóa cho kênh và đầu đọc - cách bộ mã hóa & giải mã Base64 bao gồm trường hợp Base64 trong trình duyệt, cùng với máy tính hàm băm SHA trong cùng một sản phẩm
Base32 có khả năng phục hồi tốt nhất đối với các lỗi sao chép. Sự lựa chọn phụ thuộc vào bối cảnh: giá trị tồn tại ở đâu, nó được chia sẻ như thế nào và hệ thống nào sẽ sử dụng nó.
Hiểu được sự đánh đổi giúp bạn lựa chọn sáng suốt khi thiết kế một API hoặc một hệ thống. Công cụ mã hóa & giải mã Base64 thể hiện mã hóa base64; việc sử dụng nó cùng với công cụ hex hoặc base32 cho phép bạn xem các byte giống nhau ở cả ba định dạng và hiểu được sự khác biệt về kích thước cũng như khả năng đọc của chúng. Đối với trường hợp Base64, mã hóa mẫu, lưu ý chính xác UTF-8-byte và số lượng ký tự đầu ra, và tiêu chuẩn kiểm tra so với URL-dấu câu an toàn. Đối với công việc tiêu hóa, hãy sử dụng riêng SHA bảng điều khiển. Việc giữ các hoạt động đó riêng biệt sẽ giúp lựa chọn mã hóa không bị nhầm lẫn với việc băm hoặc bảo vệ tính toàn vẹn.