Warum ist die Größe meiner E-Mail um ein Drittel größer als die angehängte Datei?

10761
arc_lupus

Beim Anhängen von Daten an meine E-Mails fiel mir auf, dass Thunderbird die Gesamtgröße der resultierenden E-Mail um ein Vielfaches größer als die angehängten Dateien berechnet.

Hier ein aktuelles Beispiel: Zwei Bilder, eines mit 13 MB und eines mit 3,6 MB, sollten insgesamt etwa 17 MB betragen. Es gab vier Textzeilen. Thunderbird fragte mich dann, ob ich wirklich eine E-Mail mit einer Gesamtgröße von 22 MB senden wollte.

Woher kommt dieser Unterschied? 5 MB Text klingt nach etwas viel.

112
Beachten Sie, dass dies häufig Auswirkungen auf die maximale Größe hat. Wenn ich mich nicht irre, erlaubt Google Mail normalerweise eine E-Mail von höchstens 25 MB, aber die 25 MB werden nach der * Kodierung * berechnet. Sie können also kein 25 MB großes Bild mit einer E-Mail senden, da sie bei Kodierung tatsächlich zu groß wäre. Bakuriu vor 7 Jahren 2
Der Kommentar von @ Bakuriu gilt auch für Outlook + Exchange Server. Ich schlage vor, dass die zugrunde liegende Frage eigentlich ist * Warum geben E-Mail-Clients (oft - Tbird scheint wieder besser als Ausblick) nur die lokale Dateigröße an, wenn es sich um die base64-codierte Größe handelt? * Chris H vor 7 Jahren 4
@ MarcksThomas Ich möchte nicht gegen den Reiz einer einzigen leicht durchsuchbaren Wissensquelle argumentieren, wenn alles Wissen leicht durchsuchbar ist. Aber ist es notwendig? Ich glaube nicht - Ich denke nicht, dass die Frage überhaupt nicht nützlich ist, ich denke nur, dass sie nicht die Grundvoraussetzungen erfüllt, um die Site von unnötigen Fragen zu befreien und es schwieriger macht, das wirklich Wichtige zu finden, nämlich _is not_ anderswo geantwortet. Das sollten wir tun! - arc_lupus, da ich nur auf dieser Seite lauere, ist mein Downvote in der Regel noch nicht bekannt. Aber so wie es ist, steht es. Alexander Kosubek vor 7 Jahren 0
Siehe auch: http://superuser.com/questions/568506/how-much-larger-does-uuencode-make-binary-files glenneroo vor 7 Jahren 0

2 Antworten auf die Frage

214
David Schwartz

Ihre Daten waren 17 MiB. Es gibt 1024 KiB in einer MiB. Es gibt 1024 B in einem KiB. Ein Byte enthält 8 Bits. Das sind also 142.606.336 Bits.

Die Basis-64-Codierung codiert alle sechs Bits als separates Byte. Wir brauchen also 23.767.722 Bytes. Wenn Sie zweimal durch 1024 teilen, erhalten Sie 22,67 MiB. So kommt also der 22 MiB.

E-Mail ist eine ziemlich alte Technologie und geht nicht von einer sauberen 8-Bit-Pipe aus.

Um die letzte Zeile ein wenig zu entschlüsseln: Mit base-64 können Anhänge als Text mit einem begrenzten Satz "garantierter sicherer Zeichen" codiert werden, die von einigen Zwischengeräten wie az, AZ, 0-9 nicht beeinträchtigt werden Yorik vor 7 Jahren 79
Sobald Sie die mathematischen Daten in Davids hervorragender Antwort verstanden haben, können Sie die Größe der Anhänge mit 4/3 multiplizieren, um die Größe der zu sendenden E-Mail (plus den eigentlichen Text) zu erhalten. Kent vor 7 Jahren 64
Selbst wenn E-Mails wussten, dass es eine vollständige 8-Bit-Pipe hat, müsste eine Kodierung vorgenommen werden, da es sich im Wesentlichen um einen Textstrom handelt. Einige Zeichen dienen Steuerfunktionen und dürfen daher nicht in Ihren Daten vorkommen. Allerdings gibt es bessere Kodierungstechniken, die jedoch noch nicht übernommen wurden. Loren Pechtel vor 7 Jahren 12
@LorenPechtel können Sie einen Anwendungs ​​/ Octet-Stream-Teil in einer MIME-Nachricht haben. Sie müssen lediglich eine Grenze auswählen, die nicht in den Daten vorkommt. OrangeDog vor 7 Jahren 3
@Mehrdad Ich sagte, dass Sie beide recht haben: Copper. Das besagte, dass die Fehlerüberprüfung / -korrektur auf einer höheren Ebene als dem physischen Austausch von Bytes (was es ist) passiert, und Sie sagen, es sei eine niedrigere Ebene als die MIME-Codierung / Mail-Transfer-Format (was es ist). TripeHound vor 7 Jahren 0
Was base64 _actually_ tut, verwendet 4 Bytes für jeweils 3 ursprüngliche Bytes. Das klingt ähnlich, aber es ist wichtig, weil die Länge immer ein Vielfaches von 4 ist und weil es keinen Grund für die Bitebene gibt. njzk2 vor 7 Jahren 8
@Mehrdad Email verfügt nicht über eine binäre Darstellung, daher müssen binäre Daten als Text neu codiert werden (a la base64). jpaugh vor 7 Jahren 1
Wenn Sie "8BITMIME" senden können, können Sie im Prinzip eine Codierung verwenden, die viel effizienter ist als base64 mit 7,5 oder mehr Bits binärer Daten pro Byte (anstelle von 6 Bits). Sie können keine reinen Binärdateien senden, da es sich um gültigen Text handeln muss, aber Sie können die gleiche Effizienz erreichen. R.. vor 7 Jahren 0
Leider gibt es keinen Standard, der eine Kodierung definiert, die beliebige binäre Daten effizient als einen Datenstrom kodiert, der den Regeln von MIME "8bit" folgt. Es gibt * IS * eine SMTP-Erweiterung zum Übertragen von E-Mails, die unzulässige Binärdaten enthalten, aber es scheint nicht umfassend unterstützt zu werden. plugwash vor 7 Jahren 1
@ njzk2 Base64-codierte Daten sind immer ein ganzzahliges Vielfaches von 4 Byte, außer wenn dies nicht der Fall ist. Insbesondere ist die Endauffüllung in vielen Implementierungen optional. a CVn vor 7 Jahren 1
@ njzk2 https://tools.ietf.org/html/rfc4648#section-3.2 "Implementierungen ** MÜSSEN ** am Ende der codierten Daten ** die entsprechenden Aufzeichenzeichen enthalten **, sofern ** die in diesem Dokument genannten Spezifikationen nicht ausdrücklich etwas anderes angeben . " (Meine Betonung.) Nicht sicher, ob Internet-E-Mail das Fehlen von Auffüllvorgängen zulässt oder nicht zulässt. a CVn vor 7 Jahren 0
Es gibt immer noch keine "8-Bit-Clean-Pipe", ein SMTP-Server * interpretiert *, was über eine TCP-Verbindung an ihn gesendet wird, und sucht zumindest nach einer Endsequenz (Einzelpunkt oder Kontroll-D) für einen DATA-Befehl. Zumindest wird ein Escape-Protokoll benötigt, um alle gültigen derartigen Sequenzen aus den binären Daten herauszuhalten. rackandboneman vor 7 Jahren 0
@rackandbonemane Der CHUNKING / BINARYMIME-Standard löst dieses Problem, indem der Befehl BDAT eingeführt wird, der einen Längenkopf enthält. Die binären Nachrichtendaten müssen also nicht nach einer Endsequenz durchsucht werden. plugwash vor 7 Jahren 0
50
plugwash

Warum ist die E-Mail größer?

Denn die Daten werden verschlüsselt, base64wobei Gruppen von bis zu drei Bytes als Gruppen von vier druckbaren ASCII-Zeichen codiert werden. Normalerweise werden diese Gruppen von druckbaren Zeichen in Zeilen aufgeteilt.

Das Ergebnis ist, dass die kodierten Daten etwas mehr als das 1-Fache der Größe der Originaldaten sind.

Warum wird base64 verwendet?

E-Mail hat eine lange Geschichte und wurde ursprünglich für Text entwickelt. Nur Bytewerte, die druckbare ASCII-Zeichen darstellen, können die vielfältigen E-Mail-Systeme auf der Welt zuverlässig passieren.

Daher hat MIME zwei Schemata für die Kodierung anderer Daten als ASCII-Text unterteilt - "quoted-printable", der für meist ASCII-Text mit einigen anderen Bits entwickelt wurde, und "BASE64" für beliebige binäre Daten.

Das SMTP-Protokoll wurde erweitert, um diese Einschränkungen zu beseitigen. Erstens, 8BITMIME aus dem Jahr 1994, das höhere Oktettwerte zuließ, aber leider keine Begrenzungen in Bezug auf Leitungslängen und Leitungsenden aufnahm, war also nicht für beliebige binäre Daten geeignet. und dann BINARYMIME im Jahr 1995, mit dem Nachrichten mit beliebigen binären Daten übertragen werden konnten.

Diese Standards haben jedoch keine breite Akzeptanz erfahren. Ein Problem ist, was passiert, wenn ein Hop in der Mail-Kette sie unterstützt, der nächste Hop jedoch nicht? Der Mail-Server kann die E-Mail dann nicht im Ist-Zustand senden, er muss sie entweder als nicht zustellbar zurückweisen und ablehnen (was für die Benutzer wahrscheinlich nicht akzeptabel ist), oder sie konvertieren (was erheblichen zusätzlichen Code im Mail-Server erfordert). . Die Konvertierung wird besonders schmerzhaft durch MIME-Regeln hinsichtlich der Nichtverwendung von Content-Transfer-Kodierungen auf mehrteiligen Typen.

Ich frage mich, warum es yEnc im Usenet gelungen ist, UUE zu verdrängen. Möglicherweise, weil binäre Newsgroups ISPs viel stärker belasten als gelegentliche binäre E-Mails? igorsk vor 7 Jahren 1
@igorsk: plus Usenet / NN wurde als verlustbehaftet dargestellt und verstanden, wobei Sie einen Artikel veröffentlichen könnten und nicht alle Abonnenten auf allen Servern diesen unbedingt erhalten würden. Es gab (und bleibt größtenteils) Sitten, in einem Folgesatz "genug" der vorherigen Artikel zu zitieren, damit Ihr Follow-up von jemandem verstanden werden kann, der die vorherigen Artikel nicht erhielt. Im Gegensatz dazu erwarteten die meisten (Nicht-Spammer-) E-Mail-Absender, dass "das System" ihre Nachricht an die genannten Empfänger weiterleitete, obwohl dies manchmal nach Stunden oder Tagen der Fall war. Heute klagen die Leute sogar über kurze Verzögerungen. dave_thompson_085 vor 7 Jahren 2

Verwandte Probleme