Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã Base64
Phần đệm Base64 đã giải thích: ý nghĩa của dấu = và khi nào chúng được yêu cầu
· Cách thức hoạt động
base64 mã hóa developer-workflow
= ở cuối chuỗi Base64 không phải là trang trí: nó ghi lại nhóm cuối cùng ngắn bao nhiêu byte. Bài đăng này giải thích số học, tại sao một số chuỗi không có chuỗi nào và tại sao bộ giải mã không đồng ý về việc thiếu phần đệm.
Ngoại lệ 'phần đệm không chính xác' từ một mã thông báo có vẻ ổn — giải mã không thành công và một hoặc hai ký tự bị thiếu đằng sau nó
Khi bộ giải mã Base64 báo cáo phần đệm không chính xác, chuỗi trông có vẻ hoàn chỉnh nhưng có lỗi cấu trúc. Các dấu bằng không mang tính thẩm mỹ: mỗi dấu mã hóa nhóm cuối cùng ngắn bao nhiêu byte, cho phép bộ giải mã biết chính xác khi nào dữ liệu thực kết thúc. Hiểu các dấu = đó—và lý do tại sao bộ giải mã nghiêm ngặt từ chối các chuỗi không có chúng—chuyển một lỗi bí ẩn thành số học có thể dự đoán được. Phân đoạn JWT có thể có một =, không có hoặc hai. Phản hồi API có thể kết thúc rõ ràng mà không cần đệm.
Chúng đại diện cho các lựa chọn có chủ ý, không phải các biến thể triển khai. Quá trình giải mã không yêu cầu đệm một cách máy móc. Phần đệm tồn tại để làm cho đầu ra rõ ràng: chỉ cung cấp một chuỗi Base64 không có siêu dữ liệu về độ dài, bộ giải mã sẽ đọc phần đệm và biết chính xác dữ liệu kết thúc ở đâu. Base64 mã hóa các nhóm ba byte thành bốn ký tự. Ba byte là 24 bits, được tập hợp lại hoàn hảo thành bốn chỉ số 6-bit; mỗi người chọn một trong 64 ký hiệu Base64. Khi đầu vào không phải là bội số của ba, bộ mã hóa sẽ phải đối mặt với phần thừa: một hoặc hai byte không thể chia đều cho ba.
Nhóm ba byte, khối bốn ký tự - tại sao modulo độ dài đầu vào 3 quyết định xem các dấu hiệu 0, một hay hai = xuất hiện
Bộ mã hóa đệm các nhóm đó bằng cách chuyển các bit thành các chỉ số đầu tiên, để lại kết quả cuối cùng bằng 0. Để đánh dấu điều này có chủ ý, nó gắn thêm dấu =: zero cho các nhóm hoàn chỉnh, một cho kết quả cuối cùng hai byte, hai cho kết quả cuối cùng một byte. Số học mang tính quyết định: biết độ dài đầu vào tính bằng byte cho phép bạn tính toán phần đệm ngay lập tức. Một byte tạo ra hai ký tự Base64 cộng với hai =. Hai byte tạo ra ba ký tự cộng với một =. Ba byte tạo ra bốn byte không có phần đệm.
Bất kỳ đầu vào nào không phải là bội số của ba byte sẽ có phần đệm; bất kỳ cái nào là bội số sẽ không. Đây không phải là sự lựa chọn – nó là số học. Một chuỗi không có phần đệm phải biểu thị ba byte. Một chuỗi có một bằng phải đại diện cho hai. Phần đệm mã hóa độ dài đầu vào theo modulo ba. Kiểm tra sự biến đổi của ba đầu vào: đơn a, cặp ab, ba abc. ASCII a là byte 0x61; Base64 mã hóa nó thành 0x61 00 00, tập hợp lại thành các nhóm sáu bit.
Các bit đệm chứa nội dung gì và tại sao bộ giải mã nghiêm ngặt lại kiểm tra chúng - các bit phải bằng 0 và mã hóa chuẩn nghĩa là gì
Các chỉ số 24, 4, 0, 0 ánh xạ tới Y, E, A, A. Vì hai nhóm được đệm nên bộ mã hóa sẽ thêm hai dấu =, tạo ra YQ==. Đối với ab, byte 0x61 0x62 trở thành 0x61 0x62 00. Bits tập hợp lại thành các chỉ mục 24, 22, 8, 0, đầu ra YWI=. Đối với abc, các byte tập hợp lại thành các chỉ số 24, 22, 9, 35, xuất YWJj không có phần đệm. Phần đệm không phải là tùy ý: nó nằm ngoài bố cục bit. Khi bạn giải mã chuỗi Base64, bộ giải mã sẽ đọc từng ký tự, tra cứu chỉ mục sáu bit của nó, gói các bit thành byte.
Đối với YQ==, các ký tự Y, E, A, A giải nén thành bit. Việc tập hợp lại thành các byte 8 bit sẽ tạo ra một byte, 0x61. Bộ giải mã loại bỏ các bit đệm (số 0 ở cuối) và báo cáo một byte. Bộ giải mã nghiêm ngặt sẽ kiểm tra xem các bit đệm có thực sự bằng 0 hay không; nếu không, đầu vào không chuẩn, nghĩa là ai đó được mã hóa bằng cách sử dụng bố cục bit khác nhau và việc giải mã sẽ không rõ ràng. Các hệ thống loại bỏ phần đệm hoàn toàn thực hiện sự đánh đổi có chủ ý. Các phân đoạn JWT sử dụng Base64url mà không cần đệm, dựa vào việc người tiêu dùng biết độ dài đầu ra dự kiến hoặc suy ra độ dài đó.
Ví dụ hoạt động: mã hóa 'a', 'ab' và 'abc' bằng tay — ba đầu vào, ba kết quả đệm, hiển thị từng chút một
RFC 4648 cho phép không có phần đệm nhưng hướng dẫn bộ giải mã chấp nhận phần đệm nếu có. Các thư viện mã khác nhau: một số sẽ khôi phục phần đệm bị thiếu và tiếp tục; những người khác sẽ thất bại. Khi bạn gặp phải các mã thông báo không giải mã được, việc thêm đúng số dấu = sẽ khắc phục được lỗi đó. Bắt buộc = các dấu luôn bằng 0, một hoặc hai, tùy thuộc vào độ dài chuỗi theo modulo bốn. Nếu độ dài chuỗi Base64 không phải là bội số của 4 thì phần đệm chắc chắn bị thiếu hoặc bị hỏng.
Độ dài 5 không thể hợp lệ Base64: mỗi ký tự hoàn chỉnh mã hóa sáu bit, do đó bốn ký tự mã hóa 24 bits (ba byte) và năm ký tự mã hóa 30 bits, không phải là bội số của tám và không thể trở thành byte. Bộ giải mã phải từ chối điều này hoặc thêm phần đệm. Nếu độ dài là 2 modulo 4, hãy thêm hai =. Nếu 3 modulo 4, hãy thêm một =. Nếu 0 modulo 4, không thêm gì cả. Một chuỗi có độ dài 3 thiếu = nó cần; thêm một và nó sẽ hợp lệ trước khi giải mã.
Tại sao một số hệ thống bỏ hoàn toàn phần đệm — phân đoạn JWT và mã thông báo an toàn URL bỏ qua = và cách khôi phục phần đệm đó theo chiều dài
Việc nối hai chuỗi Base64 có đệm bị đứt nếu phần đệm vẫn còn nguyên. Hai bộ mã hóa riêng biệt được kết hợp trực tiếp tạo ra các ký tự đệm đi lạc làm phá vỡ bảng chữ cái giải mã. Đây là lý do tại sao một số hệ thống loại bỏ phần đệm trước khi nối: mã thông báo bao gồm ba phân đoạn Base64url được nối bằng dấu chấm không có phần đệm trong các phân đoạn, giúp việc ghép nối trở nên đơn giản. Nếu xây dựng giá trị Base64 từ các bộ phận, hãy xác minh xem mỗi bộ phận có được đệm và tách hoặc thêm phần đệm một cách nhất quán hay không trước bất kỳ thao tác nào.
Bộ mã hóa và giải mã Base64 áp dụng RFC 4648, yêu cầu đệm theo mặc định. Khi bạn nhập văn bản và yêu cầu đầu ra base64, công cụ sẽ tạo ra kết quả được đệm: dạng chuẩn. Nếu bạn thấy Base64 không có phần đệm và muốn giải mã nó, hãy kiểm tra xem bộ giải mã của bạn có chấp nhận phần đệm bị thiếu hay không. Công cụ này chấp nhận cả đầu vào có đệm và không có đệm và khôi phục chính xác các byte gốc. Để gỡ lỗi, việc đếm độ dài modulo bốn sẽ cho bạn biết liệu phần đệm có bị loại bỏ hay không và công thức cho biết phần đệm nào sẽ có.
Các lỗi thường gặp: cắt xén = như thể đó là khoảng trắng hoặc nối hai chuỗi có đệm - mỗi chuỗi làm hỏng bộ giải mã như thế nào
Base32 và Base16 (thập lục phân) có các quy tắc đệm khác nhau được xác định trong RFC 4648 phần 6 và 7. Base32 sử dụng = nhưng nhóm cuối cùng có thể là 2, 4, 5, 7 hoặc 8 ký tự tùy thuộc vào độ dài đầu vào theo modulo 5. Hệ thập lục phân không cần đệm; nó luôn ánh xạ một byte thành hai ký tự không có phần còn lại. MIME Gói Base64 chạm vào phần đệm: chuỗi được bọc cột 76 vẫn có phần đệm ở cuối, chỉ vài dòng sau đó.
Hiểu phần đệm cho Base64 là hiểu bố cục bit và độ dài đầu vào theo modulo ba; một khi bạn thấy số học, phần đệm sẽ trở thành một hệ quả trực tiếp chứ không phải là một quy tắc để ghi nhớ. Phần đệm có thể rút ra được, không phải phép thuật.
Điều này không bao gồm những gì - quy tắc đệm base32 và base16 và quy ước về độ dài dòng MIME
Với một chuỗi Base64 có độ dài bất kỳ, bạn có thể khôi phục dạng đệm chuẩn bằng cách chia số ký tự cho 4, lấy phần còn lại và thêm số dấu = tương ứng. Đây là lý do tại sao việc thiếu = có thể sửa được và tại sao các bộ giải mã nghiêm ngặt có thể tha thứ: phần đệm mang thông tin (nhánh nào trong ba trường hợp mà dữ liệu đầu vào của bạn rơi vào), nhưng thông tin đó có thể được tính toán chỉ từ độ dài.
Bộ mã hóa và giải mã Base64 hiển thị đầu ra có đệm ngay lập tức để bạn có thể so sánh các byte đã giải mã với văn bản gốc và xác minh xem chuyến đi khứ hồi có hoạt động không. Base64 và các mã hóa liên quan mở rộng nguyên tắc tập hợp lại các bit thành các độ rộng ký tự khác nhau. RFC 4648 chỉ định cả ba điều này và việc hiểu một điều sẽ khiến những điều khác trở nên đơn giản về mặt khái niệm. Thông tin chi tiết quan trọng là mã hóa hoàn toàn là thao tác bit: chọn kích thước bảng chữ cái, nhóm các bit cho phù hợp, tra cứu từng nhóm trong bảng.
Bài học rút ra: phần đệm có thể lấy được, do đó, dấu = bị thiếu có thể sửa được - cách bộ mã hóa & giải mã Base64 hiển thị cho bạn dạng chuẩn được đệm của bất kỳ văn bản nào bạn mã hóa
Giải mã ngược lại: tra cứu từng ký tự, trích xuất các bit, nhóm lại chúng, ghi byte. Ánh xạ hai chiều xác định này là lý do tại sao Base64 hoạt động đáng tin cậy trên tất cả các nền tảng và ngôn ngữ. Các lỗi trong mã hóa và giải mã thường bắt nguồn từ việc hiểu sai phần đệm hoặc sự khác biệt về bảng chữ cái. Nếu giải mã không thành công do lỗi đệm, hãy kiểm tra xem bộ giải mã có yêu cầu Base64 chuẩn (được đệm nghiêm ngặt) hay chấp nhận các biến thể hay không. Nếu không thành công do lỗi ký tự, hãy kiểm tra xem đầu vào có phải là base64url hay không và bộ giải mã mong đợi Base64 tiêu chuẩn.
Bộ mã hóa và giải mã Base64 chấp nhận cả bảng chữ cái và xác thực phần đệm một cách nhất quán, do đó, mọi ví dụ được tính toán bằng tay đều có thể được xác minh ngay lập tức. Kiểm tra mã hóa bằng cách giải mã lại là cách chắc chắn nhất để phát hiện lỗi trước khi chúng gây ra sự cố trong quá trình sản xuất.