MIME::Base64 bugs?

MIME::Base64 bugs?

am 05.06.2007 10:21:22 von sonet.all

The MIME::Base64 will convert \n to \r\n.

$a="1234\n4567\n";
$a=encode_base64($a,0);
print decode_base64($a);

The result is 1234\r\n4567\r\n.

Re: MIME::Base64 bugs?

am 05.06.2007 11:41:59 von Sisyphus

"sonet" wrote in message
news:f436e2$f6u$1@netnews.hinet.net...
> The MIME::Base64 will convert \n to \r\n.
>
> $a="1234\n4567\n";
> $a=encode_base64($a,0);
> print decode_base64($a);
>
> The result is 1234\r\n4567\r\n.
>

Can't reproduce that on any of my Win32 builds of perl, or on linux:

A copy'n'paste from Windows:
-----------------------------
C:\pscrpt>type try.pl
use warnings;
use MIME::Base64;

$a="1234\n4567\n";
$a=encode_base64($a,0);
$z = decode_base64($a);

print "\\r => ", ord("\r"), "\n";
print "\\n => ", ord("\n"), "\n";

for(0..length($z) - 1) {
print ord(substr($z, $_, 1)), " ";
}
C:\pscrpt>perl try.pl
\r => 13
\n => 10
49 50 51 52 10 52 53 54 55 10
C:\pscrpt>
-----------------------------

And the same script produces the same output on linux for me.

Cheers,
Rob

Re: MIME::Base64 bugs?

am 05.06.2007 12:57:23 von Gunnar Hjalmarsson

sonet wrote:
> The MIME::Base64 will convert \n to \r\n.
>
> $a="1234\n4567\n";
> $a=encode_base64($a,0);
> print decode_base64($a);
>
> The result is 1234\r\n4567\r\n.

How did you come to that conclusion?

Could it possibly be that your observation has something to do with
http://perldoc.perl.org/perlport.html#Newlines ?

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Re: MIME::Base64 bugs?

am 16.06.2007 15:04:33 von Marcus Beranek

sonet wrote:

> The MIME::Base64 will convert \n to \r\n.
>
> $a="1234\n4567\n";
> $a=encode_base64($a,0);
> print decode_base64($a);
>
> The result is 1234\r\n4567\r\n.

Maybe this is caused by the following: the microsoft implementation of stdio
converts the "\n" to a "\r\n" automaticly on input/output. so you can have
a "\n" in memory throughout your whole perl-script, but upon printing or
writing to file it gets converted ...

But i'm not quite sure about this, maybe there are also different flavours
of stdio, which behave differently, i don't know.

HTH,
Marcus

--
-mb-

Re: MIME::Base64 bugs?

am 18.06.2007 13:17:11 von lio

On Jun 5, 2:21 pm, "sonet" wrote:
> The MIME::Base64 will convert \n to \r\n.
>
> $a="1234\n4567\n";
> $a=encode_base64($a,0);
> print decode_base64($a);
>
> The result is 1234\r\n4567\r\n.

Look for http://www.ietf.org/rfc/rfc2045.txt [Page 25]

Care must be taken to use the proper octets for line breaks if
base64
encoding is applied directly to text material that has not been
converted to canonical form. In particular, text line breaks must
be
converted into CRLF sequences prior to base64 encoding. The
important thing to note is that this may be done directly by the
encoder rather than in a prior canonicalization step in some
implementations.

This RFC requirement.

Regards, LIOL

Re: MIME::Base64 bugs?

am 23.06.2007 21:37:24 von hjp-usenet2

On 2007-06-18 11:17, liol wrote:
> On Jun 5, 2:21 pm, "sonet" wrote:
>> The MIME::Base64 will convert \n to \r\n.
>>
>> $a="1234\n4567\n";
>> $a=encode_base64($a,0);
>> print decode_base64($a);
>>
>> The result is 1234\r\n4567\r\n.

Not on my system (perl, v5.8.8 built for i486-linux-gnu-thread-multi,
MIME::Base64 3.07). Are you using Windows?


> Look for http://www.ietf.org/rfc/rfc2045.txt [Page 25]
>
> Care must be taken to use the proper octets for line breaks if
> base64 encoding is applied directly to text material that has not
> been converted to canonical form. In particular, text line breaks
> must be converted into CRLF sequences prior to base64 encoding.
> The important thing to note is that this may be done directly by
> the encoder rather than in a prior canonicalization step in some
> implementations.
>
> This RFC requirement.

For "text material that has not been converted to canonical form", yes.
But base64 is most often used to represent non-text material, such as
images, PDFs, word documents, viruses, etc.

But MIME::Base64 has no way of knowing if the string it is passed is
text material, so it should leave canonicalization to the caller (and it
does, AFAICT).

hp

--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"