Forum CM: Dlaczego nie powinno sie pakowac plikow

Igor [ Centurion ]

O sorry, nie wszystko sie skopiowalo. Oto calosc: Why you should not zip PBEM files? Because it makes them bigger. To understand the issue, you have to know that practically all email transportation on the internet is done in ASCII form, not binary form. The protocol SMTP, which is used for all normal email transportation on the internet requires it, and the protocols pop3 and imap which often deliver the mails to the enduser aren't any better. The PBEM file as generated by Combat Mission is an ASCII file. The actual data that CMBO uses is binary, but for your convenience it wraps it into ASCII. The data before being converted to ASCII is already compressed (in fact it is encrypted and then compressed), so what your really have is binary CMBO data which is first compressed and then made into ASCII. If you zip such a CMBO move, it gets smaller: size filename 990023 nordic-cbg-rwolf056.txt* 749052 nordic-cbg-rwolf056.zip That's nice, it saves 25% - while resting on your harddrive that is. However, if you actually mail the zipfile, your mailer is converting it to ASCII again. A zipfile is not ASCII, it is binary, that means any value a byte can have mixed freely. The usual email protocols don't allow real binary to be transported since they are too braindead to tell the extend of the file then, among other protocol weaknesses. So your mailer ensures that everything is ASCII. Everything - if it isn't ASCII to start from, it converts it to ASCII, without mentioning it to you and the reader's mailer converts it back, again it goes without saying. That means the original CMBO file is transported as-is, but the zipfile is converted first. So what does the conversion to ASCII look like? There are two methods in common use - uuencode and base64. Base64 is a little more efficient so it is in use in most mailers today. Still, although base64 does the best job it can, it operational requirements are pretty limited. It has to wrap everything in the few "real" ASCII chars (not counting umlauts and stuff) and it inserts newlines to make it look like a real formatted text. So what is the size for uuencode (*.uue) and base64 (*.base64)? 990023 nordic-cbg-rwolf056.txt 749052 nordic-cbg-rwolf056.zip 1026480 nordic-cbg-rwolf056.zip.base64 1032068 nordic-cbg-rwolf056.zip.uue As you can see, the ASCII conversion did not only eat up the zip advantage, it made things worse. And that is natural. The original CMBO file is already a compressed file before it was turned into text, and compressing a compressed (or encrypted) file again will make it bigger (unless the first compressor was exceptionally braindead). The zipping of the original file could do some compression because it squeezed out the ASCII wrapper of the CMBO file, but when you later add a new ASCII wrapper for email transportation, you get the overhead that is natural when compressing already compressed files. You gained nothing from first compressing an ASCII wrapper or to re-wrap later, and on top of gaining nothing there you have two compression overheads and uneliminated traces of the first ASCII wrapper which you don't even use anymore.

Rami [ Chor��y ]

Co zreszta nie do konca jest prawda - po prostu coponiektore programy pocztowe potrafia zle wklejak tekstowe attachmenty, i wtedy jest spory problem....

JOY [ Generaďż˝ ]

Ja jak narazie nie miałem żadnych problemów z pakowanymi plikami więc chyba zależy jak leży :)