Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

well that's mysterious - this script will work without any problems (put my base64encoded.txt into the scriptdir):
<?php
$fp = fopen ("base64encoded.txt", "r");
$str = fread ($fp, filesize ("base64encoded.txt"));
fclose ($fp);
echo base64_decode($str);
?>

but if you send the string via POST or GET, you'll get this output, where the text ist messed up (copy the content of base64encoded.txt and put it behind yourscript.php?vari= ):
<?php
echo base64_decode($_GET[vari]);
?>

What if you use urlencode($data) ? 

yes, we've already tried urlencoding as an alternative and urldecode works.
but there's still the base64_decode bug when you send the data via POST or GET.
as i mentioned before, it worked under php4 and the earlier php5 versions.

You must use urldecode() on the data you're sending through GET/POST.
No bug here.

ok, this time i took the string and used base64 encoding and then i urlencoded that base64 output. i sent this "double encoded" string to the server via POST/GET and there i used this script:
<?php
echo base64_decode(urldecode($_GET[vari]));
?>

and nothing changed. the first lines are ok but then the text is messed up.

(you might think, that the base64 encoding function on my client application does not work properly, but as i mentioned before i've already tested the output with other base64 decoder and they hat no problems)

Don't urldecode $_GET variables and keep in mind taht most servers have an URL lenght limit.