Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã Base64
Tại sao tệp đính kèm email là Base64: MIME, 7-bit vận chuyển và 76-cột
· Lý lịch
base64 mã hóa
Email được tạo cho văn bản 7-bit ASCII và các tệp đính kèm phải vừa với văn bản đó. Bài đăng này theo dõi cách MIME áp dụng Base64, tại sao các dòng được gói bằng 76 ký tự và điều đó có ý nghĩa gì đối với kích thước và việc gỡ lỗi.
Tệp đính kèm đến bị hỏng thông qua rơ-le cũ — vấn đề 8-bit mà MIME được phát minh để giải quyết
Email được thiết kế vào những năm 1970 và 1980 chỉ dành cho văn bản 7-bit ASCII. SMTP, giao thức mang email, yêu cầu mỗi dòng có tối đa 998 ký tự 7-bit ASCII (ký tự 0-127). Gửi tệp nhị phân như PDF hoặc hình ảnh trực tiếp qua SMTP sẽ không thành công: byte 128-255 sẽ bị hỏng hoặc bị từ chối bởi máy chủ thư và chuyển tiếp cũ. Tệp đính kèm cần mã hóa. MIME (Tiện ích mở rộng thư Internet đa năng, RFC 2045) đã giải quyết vấn đề này bằng cách xác định các giá trị tiêu đề Mã hóa chuyển nội dung, bao gồm base64, biểu thị bất kỳ chuỗi byte nào dưới dạng văn bản 7-bit ASCII.
MIME cung cấp một số lựa chọn Mã hóa chuyển nội dung: 7bit (không mã hóa, chỉ dành cho ASCII an toàn), 8bit (dành cho máy chủ hỗ trợ 8 byte bit, không phổ biến), có thể in được trích dẫn (chỉ mã hóa các byte không an toàn, giữ cho ASCII có thể đọc được) và base64 (mã hóa mọi thứ, tối đa hóa khả năng tương thích). Base64 được chọn cho các tệp đính kèm nhị phân vì nó đơn giản, được tiêu chuẩn hóa và đảm bảo an toàn trên mọi hệ thống thư, bất kể cũ hay nghiêm ngặt chỉ 7-bit. Sự đánh đổi là kích thước: Base64 lớn hơn khoảng một phần ba so với byte ban đầu.
Vấn đề vận chuyển Base64 giải quyết - biểu diễn các byte tùy ý bằng các ký tự có thể in được
3 KB PDF trở thành khoảng 4 KB văn bản Base64. Giới hạn dòng 76 ký tự xuất phát từ RFC 2045.
SMTP cho phép các dòng có tối đa 998 ký tự nhưng hệ thống thư cũ hơn và một số bộ lọc thư rác từ chối các dòng dài. RFC 2045 chỉ định rằng các dòng MIME Base64 không được vượt quá 76 ký tự (cộng với phần cuối dòng CRLF), do đó, máy chủ thư sẽ không bao giờ phá vỡ quá trình truyền tải. Giới hạn không phải là điều kỳ diệu; đó là sự thỏa hiệp mang tính lịch sử giữa khả năng đọc (76 ký tự phù hợp với hầu hết các thiết bị đầu cuối những năm 1980), khả năng tương thích với các hệ thống cũ và tránh bị phát hiện là mẫu thư rác hoặc vi-rút.
Các lựa chọn đầu ra hiển thị trong công cụ này - phần đệm chuẩn và gói ký tự 76 tùy chọn
Các hệ thống thư hiện đại thường hỗ trợ các dòng dài hơn nhưng việc mã hóa thành các dòng có 76 ký tự đảm bảo tệp đính kèm sẽ đến được ngay cả người nhận lâu đời nhất. Sau RFC 2045 được xác định MIME Base64, RFC 4288 (loại phương tiện) và RFC 2183 (Bố trí nội dung) đã thêm các cách tiêu chuẩn hóa vào nhãn tệp đính kèm. Thư có tệp đính kèm PDF bao gồm tiêu đề Content-Transfer-Encoding: base64, tiêu đề Content-Type: application/pdf và PDF byte được mã hóa dưới dạng Base64 với các dòng 76 ký tự. Trình đọc thư giải mã các dòng bằng cách loại bỏ các ngắt dòng (CRLF ký tự) rồi giải mã Base64 để khôi phục các byte gốc.
Giải mã tệp đính kèm MIME Base64 yêu cầu bỏ qua khoảng trắng. RFC cho biết: bộ giải mã phải bỏ qua ngắt dòng (ký tự CR và LF) trong khi giải mã. Đây là lý do tại sao bộ giải mã Base64 chấp nhận khoảng trắng là thiết thực; hầu hết thư MIME thực sẽ có ngắt dòng. Một số bộ giải mã rất nghiêm ngặt và từ chối khoảng trắng (phù hợp với các ngữ cảnh như JWT, trong đó không nên có dấu ngắt dòng), trong khi một số khác lại nhẹ nhàng và bỏ qua khoảng trắng (phù hợp với MIME).
Tùy chọn ký tự 76 trong thực tế — cách bộ mã hóa chèn và bộ giải mã bỏ qua ngắt dòng
Công cụ mã hóa & giải mã Base64 có thể xử lý cả hai: nó chấp nhận tệp đính kèm được dán nhiều dòng và bỏ qua các ngắt dòng trong khi giải mã. Tác động kích thước có thể dự đoán được. Gói RFC 2045 base64 thêm một CRLF (2 bytes) cho mỗi 76 ký tự đầu ra. Đối với tệp 10 KB, Base64 có khoảng 13.3 KB, cộng với CRLF mỗi 76 ký tự: tổng cộng khoảng 13.5 KB. Chi phí chung là khoảng một phần ba byte.
Giới hạn kích thước email thường được nêu cho kích thước được mã hóa chứ không phải kích thước tệp gốc; máy chủ thư có giới hạn 25 MB nghĩa là 25 MB thư được mã hóa chứ không phải 25 MB tệp đính kèm. Việc tính toán kích thước tệp gốc yêu cầu chia cho 1.33 (hay chính xác hơn là cho 4 chia cho 3). Mã hóa có thể in được trích dẫn là một giải pháp thay thế giữ cho ASCII có thể in không thay đổi và chỉ mã hóa các byte 128-255 và một vài ký tự đặc biệt.
Ví dụ hoạt động: đọc nguồn tin nhắn thô - tìm phần Base64 và giải mã một tệp đính kèm văn bản nhỏ
Tệp văn bản có hầu hết ASCII vẫn có thể đọc được nếu bạn mở nguồn thư thô. Base64 làm xáo trộn mọi thứ, ngay cả văn bản ASCII đơn giản. Có thể in được trích dẫn hiếm khi được sử dụng cho các tệp nhị phân (nó sẽ rất kém hiệu quả đối với PDF) nhưng đôi khi được sử dụng cho văn bản. Trình đọc thư chọn mã hóa dựa trên loại tệp đính kèm; trình duyệt thường không hỏi người dùng nên áp dụng mã hóa nào.
Nội dung Base64 của thư email chỉ là các byte chứ không phải là một tệp riêng biệt. Khi bạn nhìn thấy tệp đính kèm trong trình đọc thư, trình đọc đó đã giải mã Base64 và đang hiển thị tệp gốc.
Chi phí kích thước trong thực tế - thêm khoảng một phần ba byte và tại sao giới hạn kích thước thư được nêu cho kích thước được mã hóa
Nếu bạn xem nguồn thư thô (một tùy chọn trong hầu hết các ứng dụng thư), bạn sẽ thấy tiêu đề MIME và nội dung được mã hóa Base64. Công cụ mã hóa & giải mã Base64 có thể giúp bạn giải mã thủ công một đoạn nguồn tin nhắn; sao chép phần Base64, xóa ngắt dòng và dán vào công cụ.
Nhiều tệp đính kèm trong tin nhắn MIME sử dụng ranh giới nhiều phần. Mỗi phần có các tiêu đề riêng (Loại nội dung, Mã hóa chuyển nội dung) và nội dung riêng. Phiên bản thay thế văn bản thuần túy của thư xuất hiện dưới dạng một phần và mỗi phần đính kèm sẽ xuất hiện dưới dạng một phần khác. Chuỗi ranh giới ngăn cách các phần; nó được chọn để không xuất hiện trong bất kỳ nội dung nào của phần đó. Trình đọc thư sẽ xây dựng lại thư bằng cách phân tích các ranh giới và giải mã từng phần theo tiêu đề Mã hóa-Truyền-Nội dung của nó.
Điều này không bao gồm những gì — tiêu đề từ được mã hóa, S/MIME và phần mở rộng 8BITMIME chuyên sâu
RFC 2045 mã hóa base64 ngày nay không phổ biến. Một số hệ thống thư hỗ trợ truyền tải 8-bit và không còn yêu cầu base64 nữa. Một số hệ thống sử dụng tên mã hóa khác nhau hoặc thêm tiêu đề tùy chỉnh. Nhưng base64 với dòng 76 ký tự vẫn là lựa chọn tương thích nhất cho các tệp đính kèm phải tiếp cận mọi hệ thống thư, ở bất kỳ đâu. Khi bạn đính kèm tệp bằng ứng dụng thư, ứng dụng khách thường tự động chọn base64 cho tệp nhị phân, xử lý việc ngắt dòng và thêm tiêu đề MIME.
Hiểu cơ chế này sẽ giúp bạn gỡ lỗi khi phần đính kèm có vẻ bị hỏng hoặc khi bạn đang làm việc thủ công với nguồn thư. Việc xây dựng hoặc phân tích cú pháp thư email gửi đi yêu cầu hiểu cấu trúc MIME. Thư viện phải xử lý việc mã hóa, ngắt dòng và tiêu đề; bạn thường không xây dựng MIME theo cách thủ công. Nhưng nếu bạn đang phân tích cú pháp nguồn thư thô (gỡ lỗi sự cố gửi hoặc trích xuất tệp đính kèm theo chương trình), thì việc biết rằng Mã hóa chuyển nội dung: base64 có nghĩa là phần nội dung sau đây được bao bọc bởi ký tự 76 base64 cho phép bạn áp dụng bộ giải mã phù hợp.
Bài học rút ra: Base64 là lớp tương thích của email — cách bộ mã hóa và giải mã Base64 cho phép bạn đọc cục bộ một phần văn bản nhỏ từ một tin nhắn thô
Bản thân base64 là tiêu chuẩn RFC 4648; tiêu đề gói và MIME dành riêng cho email. Tệp đính kèm email là base64 vì email được xây dựng cho văn bản thuần túy và base64 là lớp tương thích đơn giản, phổ biến nhất để gửi dữ liệu nhị phân thông qua giao thức chỉ có văn bản. Giới hạn dòng 76 ký tự là một yếu tố lịch sử của các thiết bị đầu cuối và mạng chậm những năm 1980, nhưng nó vẫn tồn tại như một tiêu chuẩn cho khả năng tương thích.
Hiểu lịch sử này sẽ giải thích tại sao MIME tồn tại, tại sao có nhiều tùy chọn mã hóa và tại sao base64 vẫn là mặc định cho tệp đính kèm ngay cả khi các hệ thống thư hiện đại có thể hỗ trợ trực tiếp nhị phân. Bộ mã hóa và giải mã Base64 cho phép bạn làm việc thủ công với phần thân MIME để xác minh hoặc gỡ lỗi mã hóa.