Tại sao kích thước email của tôi lớn hơn khoảng một phần ba so với kích thước của các tệp đính kèm?


111

Khi đính kèm dữ liệu vào email của mình, tôi nhận thấy Thunderbird tính toán tổng kích thước của email kết quả lớn hơn nhiều so với các tệp tôi đã đính kèm.

Đây là một ví dụ gần đây: hai hình ảnh, một ở mức 13 MB và một ở mức 3,6 MB nên có tổng số xấp xỉ 17 MB. Có bốn dòng văn bản. Thunderbird sau đó hỏi tôi có thực sự muốn gửi email với tổng kích thước 22MB không.

Sự khác biệt đó đến từ đâu? 5 MB văn bản nghe có vẻ hơi nhiều.


2
Lưu ý rằng điều này thường ảnh hưởng đến những thứ như kích thước tối đa. Nếu tôi không nhầm, thư Google thường cho phép email nhiều nhất là 25 MB, nhưng 25 MB được tính sau khi mã hóa, do đó bạn không thể gửi hình ảnh 25 MB bằng email, vì khi được mã hóa thì nó thực sự quá lớn.
Bakuriu

4
Nhận xét của @ Bakuriu cũng áp dụng cho máy chủ Outlook + Exchange. Tôi đề nghị rằng câu hỏi cơ bản thực sự là Tại sao các ứng dụng thư khách (thường - Tbird có vẻ tốt hơn so với triển vọng một lần nữa) chỉ báo cáo kích thước tệp cục bộ khi kích thước được mã hóa cơ sở 64 là vấn đề?
Chris H

@MarcksThomas Tôi không muốn tranh luận về sự hấp dẫn của việc có một nguồn kiến ​​thức bao gồm tất cả dễ dàng tìm kiếm chống lại tất cả các kiến ​​thức có thể dễ dàng tìm kiếm. Nhưng nó có cần thiết không? Tôi không nghĩ vậy. - Tôi không nghĩ rằng vấn đề không phải là hữu ích ở tất cả, tôi chỉ nghĩ rằng nó không đáp ứng các yêu cầu cơ bản để giữ cho trang web miễn phí của câu hỏi không cần thiết và làm cho nó khó khăn hơn để tìm những thứ thực sự quan trọng, đó không phải là trả lời bất cứ nơi nào khác. Đó là những gì chúng ta nên làm! - arc_lupus, vì tôi chỉ ẩn trên trang web này, thông thường, downvote của tôi chưa cout. Nhưng như nó là, nó đứng.
Alexander Kosubek

Câu trả lời:


214

Dữ liệu của bạn là 17 MiB. Có 1024 KiB trong một MiB. Có 1024 B trong một KiB. Có 8 bit trong một byte. Vì vậy, đó là 142.606.336 bit.

Mã hóa cơ sở 64 mã hóa cứ sáu bit dưới dạng một byte riêng biệt. Vì vậy, chúng ta cần khoảng 23.767.722 byte. Chia cho 1024 hai lần cho chúng ta 22,67 MiB. Vì vậy, đó là nơi 22 MiB đến từ.

Email là một công nghệ khá cũ và không giả sử đường ống sạch 8 bit.


79
Để giải mã dòng cuối cùng một chút: cơ sở 64 là cách mã hóa tệp đính kèm dưới dạng văn bản bằng cách sử dụng một bộ "ký tự an toàn được bảo đảm" có giới hạn sẽ không bị cắt xén bởi một số thiết bị trung gian, như az, AZ, 0-9
Yorik

64
Và, khi bạn hiểu toán học trong câu trả lời xuất sắc của David, bạn có thể nhân kích thước của các tệp đính kèm với 4/3 để có được kích thước của thư sẽ được gửi (cộng với văn bản thực tế).
Kent

12
Ngay cả khi email biết rằng nó có một ống 8 bit đầy đủ thì cũng phải mã hóa vì về cơ bản đó là một luồng văn bản - một số ký tự phục vụ các chức năng kiểm soát và do đó không được xảy ra trong dữ liệu của bạn. Điều đó đang được nói, có những kỹ thuật mã hóa tốt hơn nhưng chúng chưa được áp dụng.
Loren Pechtel

3
@LorenPechtel bạn có thể vui vẻ có một phần ứng dụng / octet-stream trong tin nhắn MIME. Tất cả bạn phải làm là chọn một ranh giới không xảy ra trong dữ liệu.
OrangeDog

8
những gì cơ sở thực sự làm, là sử dụng 4 byte cho mỗi 3 byte gốc. Trong khi điều này nghe có vẻ tương tự, nó rất quan trọng vì độ dài luôn là bội số của 4 và cũng vì không có lý do gì cho mức bit.
njzk2

50

Tại sao email lớn hơn?

Bởi vì dữ liệu được mã hóa trong base64đó mã hóa các nhóm có tối đa ba byte thành các nhóm gồm bốn ký tự ASCII có thể in được. Thông thường, các nhóm ký tự có thể in này sau đó được chia thành các dòng.

Kết quả là dữ liệu được mã hóa chỉ lớn hơn 1 lần so với kích thước của dữ liệu gốc.

Tại sao Base64 được sử dụng?

Email có một lịch sử lâu dài và ban đầu được thiết kế để mang văn bản. Chỉ các giá trị byte đại diện cho các ký tự có thể in ASCII mới có thể đi qua các hệ thống email khác nhau trên hành tinh.

Vì vậy, MIME đã chia ra hai sơ đồ để mã hóa dữ liệu khác dưới dạng văn bản ASCII - "có thể in được trích dẫn" được thiết kế cho phần lớn văn bản ASCII với một vài bit khác và "BASE64" cho dữ liệu nhị phân tùy ý.

Đã có các phần mở rộng cho giao thức SMTP để thử và loại bỏ các hạn chế này. Đầu tiên, 8BITMIME năm 1994, cho phép các giá trị octet cao hơn nhưng không may không xóa các giới hạn liên quan đến độ dài dòng và kết thúc dòng, do đó không phù hợp với dữ liệu nhị phân tùy ý; và sau đó là BINaryMIME vào năm 1995, cho phép chuyển các tin nhắn có chứa dữ liệu nhị phân tùy ý.

Tuy nhiên, các tiêu chuẩn này đã không được áp dụng rộng rãi. Một vấn đề là, điều gì xảy ra nếu một bước nhảy trong chuỗi thư hỗ trợ họ nhưng bước nhảy tiếp theo thì không? Sau đó, máy chủ thư không thể gửi thư theo nguyên trạng, nó phải từ chối nó dưới dạng không gửi được và bị trả lại (điều này không thể chấp nhận được đối với người dùng) hoặc chuyển đổi nó (yêu cầu thêm mã đáng kể trong máy chủ thư) . Chuyển đổi được thực hiện đặc biệt đau đớn bởi các quy tắc MIME liên quan đến việc không sử dụng mã hóa chuyển nội dung trên các loại nhiều phần.


1
Tôi tự hỏi tại sao yEnc, mặt khác, lại khá thành công ở Usenet khi thay thế UUE. Có thể bởi vì các nhóm tin nhị phân gây áp lực lớn hơn cho các ISP so với một email nhị phân không thường xuyên?
igorsk

2
@igorsk: cộng với Usenet / NN đã được trình bày và hiểu là mất mát, nơi bạn có thể xuất bản một bài viết và không phải tất cả người đăng ký trên tất cả các máy chủ sẽ nhất thiết phải nhận được nó. Có (và phần lớn vẫn còn) về việc trích dẫn trong phần tiếp theo 'đủ' của (các) bài viết trước rằng người theo dõi của bạn có thể hiểu được những người không nhận được bài viết trước đó . Ngược lại, hầu hết những người gửi email (không hút thuốc) mong đợi 'hệ thống' sẽ nhận được tin nhắn của họ đến (các) người nhận được đặt tên, mặc dù đôi khi sau nhiều giờ hoặc nhiều ngày; ngày nay mọi người phàn nàn về sự chậm trễ thậm chí ngắn.
dave_thndry_085
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.