That horse was already bothered and I had already used the binary FH c
+all and got the same results.
But I think I have pinpointed the exact location of the problem: it's
+in the encode_base64 code itself - on the last few lines:
sub encode_base64 ($) {
my $res = "";
my $eol = "\n";
pos($_[0]) = 0;
while ($_[0] =~ /(.{1,45})/gs) {
$res .= substr(pack("u", $1), 1);
chop($res);
}
$res =~ tr|` -_|AA-Za-z0-9+/|;
#!!! Here's where the different characters are created!!!!
# my $padding = (3 - length($_[0]) % 3) % 3;
# $res =~ s/.{$padding}$/"=" x $padding/e if $padding;
# if (length $eol) {
# $res =~ s/(.{1,76})/$1$eol/g;
# }
$res;
}
I have borrowed this code and don't know what it's trying to do - is i
+t a standard? Since I have no MIME access on my host, and I'm using U
+NIX - is it possible another encoding function exists, something like
+ uu?encode? Thanks again. Peter.
|