Base64 und EOLs

[hotti]

moin,

kleine Verständnisfrage zu

q(...In der Regel wird spätestens nach jeweils 76 ausgegebenen Zeichen, das entspricht 57 codierten Bytes, ein Zeilenumbruch eingefügt, ...)

Das habe ich mal so umgesetzt indem ich mein temporäres Handle in Häppchen zu 57 Bytes auslese und die codierten Bytes dann aneinanderhänge, das Perl-Modul MIME::Base64 macht dann im Default nach 76 resultierenden Bytes den Zeilenumbruch (so wie das im Wiki steht und das funktioniert einwandfrei).

Was mich ein bischen stutzig macht, ist die Zahl 57, die ist zwar durch 3 teilbar aber nicht durch 6 und auch nicht durch 8. Wobei: Base64 macht eine Umgruppierung von 3*8 nach 4*6. Wie passt die 57 da rein???

Hotti

[Der Martin]

Hallo,

q(...In der Regel wird spätestens nach jeweils 76 ausgegebenen Zeichen, das entspricht 57 codierten Bytes, ein Zeilenumbruch eingefügt, ...)

ich wollte erst protestieren und sagen, ich kriege 59 raus. Aber du hast recht, es sind 57.

Was mich ein bischen stutzig macht, ist die Zahl 57, die ist zwar durch 3 teilbar aber nicht durch 6 und auch nicht durch 8.

Warum sollte sie durch 6 oder 8 teilbar sein? Sie sollte nur durch 3 teilbar sein, weil je drei Bytes zu vier Zeichen umcodiert werden. AFAIK müssen aber die Zeilenumbrüche in einem base64-Stream nicht einmal unbedingt mit Byte- oder Bytegruppengrenzen zusammenfallen, auch wenn das natürlich vorteilhaft ist. Wobei das bei den von dir angenommenen 57 Bytes sogar passt.

Wobei: Base64 macht eine Umgruppierung von 3*8 nach 4*6. Wie passt die 57 da rein???

57 * 4/3 = 76   - qed ;-)

Ciao,
 Martin

[hotti]

hi Martin,

ein Licht geht auf in Oppenheim ;)

Warum sollte sie durch 6 oder 8 teilbar sein? Sie sollte nur durch 3 teilbar sein, weil je drei Bytes zu vier Zeichen umcodiert werden.

Grad eben mal mutig getestet:

  
while(read $handle, my $buffer, 3){  
  $b64 .= encode_base64($buffer);  
}  

das ist zwar Blödsinn

JVBE
Ri0x
LjIK
MyAw
...
kommt raus, aber es funktioniert!!!

AFAIK müssen aber die Zeilenumbrüche in einem base64-Stream nicht einmal unbedingt mit Byte- oder Bytegruppengrenzen zusammenfallen,

stimmt. Die EOLs könnten auch wegfallen.

auch wenn das natürlich vorteilhaft ist.

Hmm, für wen ist das ein Vorteil? Ist 57/76 eine Empfehlung, wenn ja, von wem ;)

Viele Grüße,
Hotti

[Der Martin]

Hallo,

AFAIK müssen aber die Zeilenumbrüche in einem base64-Stream nicht einmal unbedingt mit Byte- oder Bytegruppengrenzen zusammenfallen,
stimmt. Die EOLs könnten auch wegfallen.
auch wenn das natürlich vorteilhaft ist.
Hmm, für wen ist das ein Vorteil?

das Zusammenhalten der Dreier/Vierergruppen ist -wenn es denn vorgeschrieben ist- ein Vorteil für faule Programmierer. ;-)

Die Einhaltung einer maximalen Zeilenlänge ist dann ein Vorteil, wenn man die base64-Wurst per e-Mail verschicken möchte. Hier gilt zwar gemäß RFC 2822 eine maximale Zeilenlänge von 998 Zeichen (zzgl. CR/LF, also 1000 Zeichen "brutto"), aber es gilt immer noch die historisch gewachsene Empfehlung, die Zeilen nicht länger als 80 Zeichen zu machen.

Ciao,
 Martin

[hotti]

hi Martin,

das Zusammenhalten der Dreier/Vierergruppen ist -wenn es denn vorgeschrieben ist- ein Vorteil für faule Programmierer. ;-)

Davon ist +100%ig auszugehen!!!

Die Einhaltung einer maximalen Zeilenlänge ist dann ein Vorteil, wenn man die base64-Wurst per e-Mail verschicken möchte. Hier gilt zwar gemäß RFC 2822 eine maximale Zeilenlänge von 998 Zeichen (zzgl. CR/LF, also 1000 Zeichen "brutto"), aber es gilt immer noch die historisch gewachsene Empfehlung, die Zeilen nicht länger als 80 Zeichen zu machen.

Ahhhh, alles klar jetzt ;)

Nun verstehe ich auch, warum in MIME::Base64::encode($bin, $eol) das $eol im Default ein Zeilenumbruch ist, weil faule Programmierer nämlich dann read $handle, my $buffer, 57; notieren können und erhalten RFC-gerechte (empfehlungsgemäße) Maildateien.

Danke Dir!!!
Schönen Sonntag,
Horst Sonnenschein