Attachment in OL:mac wesentlich größer als unter OL für Windos

klickman

Aktives Mitglied
Thread Starter
Dabei seit
31.05.2010
Beiträge
1.262
Reaktionspunkte
218
Hallo Kollegen,

eine ähnliche Frage hatte ich seinerzeit schon in diesem Thread gestellt: https://www.macuser.de/forum/thema/...hments-immer-groesser-als-im-Finder-angezeigt
Dieses Mal handelt es sich um ein anders Phänomen, nämlich dass Attachments in Outlook für Windows (egal welche Version) eine wesentlich geringere Dateigröße aufweisen als in Outlook für/am Mac. Davon ist jeder Dateityp betroffen. Beispiel: Ein Bekannter schict mir eine .wmv-Datei, die auf seinem Rechner in OL 2007 8 MB aufweist, auf meinem Rechner zeigt mir Outlook (14.3.8 - war aber unter früheren Versionen gleich) 11 MB. Weiteres Beispielt: Eine simple .ppt-Datei, nur mit Text und wenigen Bildern gefüllt, hat am Mac eine etwa 1,5fache Größe als am Windowsrechner. Wie kommts?

EDIT: Vielleicht liest ein Moderator mit und korrigiert bitte meinen Tippfehler im Titel: "Windos" zu "Windows". ;)
 
1. Wie groß werden denn die angehängten Objekte nach Lösen des Anhangs von der Email im Eigenschaften- (Explorer) bzw. im Informationen-Fenster (Finder) in Byte angezeigt?
Nur diese ist repräsentativ, denn…

2a. MB vs MiB?
10.000.000 B = 10 MB = aber schon nur 9,54 MiB
10.240.000 B = 10,24 MB = 9,77 MiB

2b. Unterschiedliche Größe durch unterschiedliche Blockgröße auf der Platte?

2c. Wo liest du welche Werte ab?
Falls im Emailer: Weißt du, ob der jeweilige Emailer die Größe des in der Email kodierten Anhangs (Sendegröße der Email) oder die Größe des gelösten Anhangs ausweist?

Wenn ich aus Mail oder aus Outlook sende, ist die im Finder angezeigte Summe der Größen der Bilder auch kleiner, als die zu sendende Email (im Beispiel außer den Bildern nur ein paar Byte Text des Headers; sonst kein weiterer Text).

6,7MB an Daten im Finder machen eine Email mit denselben Werten in Mail (links) und in Outlook (rechts) von 8,5MB:
Emailgroesze.jpg OL2011-Groesze.jpg

3. Das Anzeigeverhalten ist also Mac-intern hüben wie drüben gleich. Eine plattformspezifische Abweichung hat also vrsl. Ursachen außerhalb der Anwendungssoftwares.
 
Zuletzt bearbeitet:
Hallo fa66,

vorweg danke für deine Antwort.

Den Punkt 1 beantworte ich wie folgt:
Foto 1 zeigt das Infofenster einer ".ppt"-Beispieldatei auf dem Schreibtisch meines MBP, also noch nicht als Attachment hinzugefügt:
attachment.php



Foto 2 zeigt diese Datei als Attachment vor dem Versenden in einer Mail von Outlook:mac (Zuwachs 2 MB!):
attachment.php


Foto 3 zeigt sie als Attachment im Posteingang von MS Outlook 2003 auf einem Windows XP-Notebook:
attachment.php


Foto 4 zeigt die Eigenschaften der Datei auf dem Desktop dieses XP-Notebooks, also herausgelöst aus der empfangenen Mail:
attachment.php


Ad 2b: Keine Ahnung, die Festplatte des XP-Rechners ist mit NTFS und Standardblockgröße formatiert, mein MBP mit "Mac OS Extended (Journaled)".

Ad 2c: Siehe Bilder.
Nein, ich weiß leider nicht, woher der jeweilige Mailclient die Datengröße bezieht.

Ad 3: Hier besteht für mich nach wie vor das Rätsel, dass Dateien im Finder kleiner angezeigt werden, als als Attachment in einer Mail von Outlook:mac. Das war seinerzeit der Grund meines, in meinem 1. Beitrag verlinkten Themas.
Mein Pferdefuß ist die Tatsache, dass ich oft Unterlagen (.ppt´s, .docx´s) an Auftraggeber schicken muss, deren Mailserver lediglich max. 5 MB an Datengröße per Mail zulässt. Vom XP-Rechner aus war das niemals ein Problem, da die Dateigrößen, bzw. deren Summe, sowohl im Dateiexplorer, als auch in der zu sendenden Mail annähernd gleich angezeigt wurden und somit recht verlässlich waren. Somit wurden diese von der 5 MB-Einschränkung des empfangenden Mailservers nicht blockiert. Eine dieser Dateien von "seinerzeit" wächst auf meinem MBP auf eine, die 5 MB übersteigende Dateigröße an und kann nun nicht mehr an den betreffenden Mailserver gesendet werden - gleiche, unveränderte Datei, bloß anderer Mailclient und andere Plattform.
 

Anhänge

  • Foto 4.jpg
    Foto 4.jpg
    5,4 KB · Aufrufe: 89
  • Foto 3.jpg
    Foto 3.jpg
    2,5 KB · Aufrufe: 90
  • Foto 2.jpg
    Foto 2.jpg
    3,8 KB · Aufrufe: 95
  • Foto 1.jpg
    Foto 1.jpg
    14,6 KB · Aufrufe: 87
Δ[SUB](Foto1, Foto2)[/SUB] ist der Größenzuwachs in der Email als kodiertes Attachment. Das Kodieren des Anhangs zwecks Einbau in den Emaildatenstrom bläht den Anhang auf.

Δ[SUB](Foto1, Foto4)[/SUB] ist die offenbar die Differenz zwischen MB und MiB, wobei MacOSX (seit 10.6 durchgängig) SI-Präfixe ausschließlich dezimal verwendet und auch dezimal meint, wohingegen Windows zwar klassisch MB schreibt, ab MiB meint.

Foto3 scheint eine arg grobe Rundung des in Foto4 angezeigten MiB-Wertes zu zeigen (also auf Basis der unkodierten Größe des Anhangs.

Daher ist die Größenangabe in Byte die einzig relevante (Δ[SUB](Foto1, Foto4)[/SUB]=0B) für die Dateigröße des Anhangs nach Abschluss der Übertragung und zum Verwenden der (hier) PPT am Ziel.

Bei Größenbegrenzungen beim Sender oder Empfänger musst du doch bereits klären, ob die (s.o.) vielleicht fahrlässig MB schreiben, aber MiB meinen, um die tatsächlich mögliche Größe – notfalls durch Umrechnen – ermitteln zu können. Im Postfach landet immer erstmal die kodierte Datei als Teil der Email.

5MB (oder MiB?) sind in der heutigen Zeit schon arg klein bemessen. Andererseits gibt’s ja auch andere Übertragungsmöglichkeiten. Angefangen beim guten alten FTP; oder über aktuelle Wolkendienste wie Tropfkasten et al.

Übrigens: MSO2007~2013-formatige Dateien sind ZIP-Container und sollten bei gleichem Inhalt in der Tendenz kleinere Dateiengrößen als das ältere 97~2004er Format liefern.
 
Danke fa66, du erhellst wieder mal ein paar meiner Gedankengänge. Bei all der Verwirrung über unterschiedliche Größenangaben fiel mir nicht auf, dass die Byteangaben von Foto 1 und Foto 4 ident sind.

Ob mein Auftraggeber MB oder MiB meint, werde ich aus Gründen die ich hier nicht anführen kann, kaum in Erfahrung bringen können. Meine direkten Ansprechpartner haben 0 Ahnung von solchen Feinheiten (ich bis vor kurzem auch nicht ;) ) und bis die sich diese Auskunft von deren IT geholt haben... Egal. 5 MB sind in der Tat antiquiert. (Ob MB oder MiB, es würde aufgrund der Größe mancher zu versendenden Dateien keinen Unterschied machen.) Erst heute bekam ich nach einem Versuch via, wie du sie nennst, "Tropfenkiste" ;) die Info, dass es damit auch klappt. Also ist zumindest das Problem "per Mail" vom Tisch.

Deinen letzten Hinweis finde ich übrigens sehr interessant. Das wär doch eine feine Option für ein größeres office:mac 2011-Update. Ok, ich hör auch schon wieder auf mit den Fantastareien, es gibt ja bereits 365...
 
… Deinen letzten Hinweis finde ich übrigens sehr interessant. Das wär doch eine feine Option für ein größeres office:mac 2011-Update …
:kopfkratz: 2011 liegt doch zwischen 2007 und 2013.
Oder anders: die XML-basierenden Dateien sind auch unter MSO2008 und MSO2011 ZIP-Container.
Oder um was geht deine letzte Bemerkung?
 
Oder anders: die XML-basierenden Dateien sind auch unter MSO2008 und MSO2011 ZIP-Container.
Ich hatte dies lediglich auf Officeversionen für die Windowsplattform bezogen.
Es entsteht der Eindruck, dass der Zip-Container keinen guten Job macht, wenn alleine die Codierung für den Einbau in den Mail-Datenstrom eine Datei derart aufbläht, wie Foto 1 zeigt, doch die "Zippung" keine stärkere Verringerung der Größe schafft.
Wie auch immer, wir müssen es wohl so hinnehmen.
 
Ich glaube, das "Aufblähen" beim Einbau in die Mail hat absolut nichts mit irgendwelchen Zip-Programmen zu tun (und Container machen eh keine Jobs, die sind einfach da). Ziemlich jedes Dateiformat nimmt an Umfang zu, wenn man es per Mail verschickt.
 
Naja, da verlustfrei komprimiert wird, und Bilder meist schon in komprimierenden Formaten vorliegen, bringt das allein nur, wie geschrieben, in der Tendenz etwas. Wenn etwa eine hundertseitige Bleiwüste mal als .doc und mal als .docx gesichert wird.
;)
Hat aber mit der Emailsache selber nichts zu tun. Bestenfalls mit der Frage, von welcher Ausgangsgröße her der Anhang dann an die Email rankodiert wird. Größer wird’s immer.
 
Zurück
Oben Unten