Without seeing the code that produced the files and tries to decode them back, we can't help you much. Sounds like a missing binmode somewhere.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Thanks for your reply.

Actually we have legacy PERL application which encodes(using base64) the file content and puts data into the DB.

Now we have written a script to download & decode those attachment from that DB.

Below is the code we are using for this:

Read more... (8 kB)

That was tough to wade through, you should put code in-between <code>...</code> tags. But basically, I see this

my $filePath1 = "/tools/busapps/LAMP/dev/APP/htdocs/APP/APP_Attachment
+s/2016/LGop.pdf";
open (my $upload_filehandle,'<',$filePath1);
binmode $upload_filehandle;
my $filecontents;
{ local $/ = undef;
$filecontents = <$upload_filehandle>;
} 
my $fContent = decode_base64( $filecontents );
[download]

and unless your file naming conventions are strange, a pdf file is not base64 encoded.

What you need to do is first identify and isolate a file that is failing to decode. Move it off to the side and then write a very small script that just opens that problem file and tries to decode_base64 it. More than likely, you'll find the problem is with the actual file (it's not base64 encoded) and not the decode_base64 routine.

-derby

If this is running under Windows, extra bytes are probably being added when you write your decoded binary data from the $fContent variable to OFILE. If this is the case, you could fix it by adding the line binmode OFILE; immediately after lines which begin with open ( OFILE,...