Keine Ahnung, was du damit meinst - muss wohl etwas für Insider sein.
War auch nicht so bierernst gemeint, kann aber tatsächlich zu solchen Erscheinungen führen bzw. sie erklären.
Bei UTF-8 wird jedes Zeichen (oder jeder "code point", um bei den richtigen Begriffen zu bleiben) erst einmal in 8 Bit kodiert, solange das möglich ist und nur die Zeichen, die außerhalb des mit diesen 8 Bit darstellbaren Bereiches liegen, brauchen dann zwei bis vier Byte für ihre Kodierung (bei Binärdateien bleibt es also bei einer 1:1-Kodierung, weil ein Byte immer ein Byte ist).
Bei UTF-16 ist das im Prinzip genauso, nur werden hier für die "normale" Kodierung jedes "code points" schon 16 Bit verwendet (ungenutzte Bits sind dann eben 0) und damit ergibt sich tatsächlich (ungefähr) die doppelte Datenmenge für dasselbe Ausgangsmaterial. Da im HTTP-Protokoll auch unterschiedliche Kodierungen möglich sind (das nennt sich dann "
MIME" und wurde von älteren Protokollen u.a. auch an HTTP "vererbt"), kann so etwas tatsächlich vorkommen ... ob das hier allerdings wirklich die Ursache für eine "Verdopplung" des übertragenen Volumens ist, weiß ich (ohne Test) natürlich auch nicht.
Da die Kodierung von Inhalten für eine solche Übertragung auch noch von den "Angeboten" auf der Sender- und Empfängerseite abhängig ist (beide lassen verlauten, was sie verstehen würden und der Sender sucht dann i.d.R. irgendetwas Passendes aus), kann man das aber nicht mal verläßlich mit einer eigenen Box gegen irgendeinen beliebigen Server testen und müßte dafür tatsächlich noch wissen, was da in den Header-Entries bei der HTTP-Kommunikation zwischen Server und Client vereinbart wird ... es führt jetzt aber zu weit, das hier zu erklären, wie "Accept"-Header und die darin kodierten "Austauschformate" funktionieren.
Aber auch an anderen Stellen kennt man solche Effekte ... wer z.B. ein Foto per E-Mail versendet, wird auch feststellen, daß es dabei um 33% größer wird in der E-Mail, weil es (fast immer) in Base64-Kodierung gesendet wird und dabei für die Kodierung von jeweils 6 Bit in der Datei am Ende 8 Bit benötigt werden (also die erwähnten 33% "Aufschlag") - aus drei Byte in der Eingabedatei werden jeweils 4 Byte in der Base64-Kodierung.
Es wäre also (zumindest theoretisch) sogar denkbar, daß die Anzeige des doppelten Transfervolumens für eine Datei gar kein "echter Fehler" ist, sondern daß wirklich diese Datenmenge nach der Kodierung entstanden ist und übertragen wurde. Das würde dann den Fehler (so man ihn noch so bezeichnen mag) an eine andere Stelle (nämlich an die, wo die Wahl der Kodierung erfolgt) verlagern.
Nähere Einzelheiten, wie Du diese Verdopplung festgestellt hast, stehen ja nicht in diesem Thread ... und auch kein Link auf eine "vorherige Meldung".