Ok... here are a couple oddities.

I dont have all the Technical information on Base64... but here is what
I do know. When a string is Base64 encoded, (3 - (length($string) % 3))
characters are tacked on the end as equal signs ("="). So for instance
"1234" would be encoded as "MTIzNAoxCg==". And "123" would have no "="
like "MTIzCjEK".  And just to continue the thought process "12345" would
encode like "MTIzNDUKMQo=". 

So... here is where the trick comes in... when the string is DECODED,
should those "=" be turned into NULLS or should they not exist at all.
My inital thought would be not to exist at all, however, PHP turns them
into nulls. I have not had a chance to test it with IE, but nulls in the
output stream of a web page that is given to Netscape make it rather
upset and it tends to omit portions of the received data, alltho, when
telneted to port 80 one can see the data actually is there.

So....

echo base64_decode(base64_encode("123")); 

Works fine in a browser, but....

echo base64_decode(base64_encode("1234"));

causes portions of the output to not be displayed.


I tried to use regular expressions to remove any nulls from the end of
the string, but that gave errors in ereg_replace.... see code:


$null = chr(0);
$decodedtext = ereg_replace($null."$","",$decodedtext);



causes an error:

Warning: REG_EMPTY: empty (sub)expression in
/usr/local/apache/share/htdocs/djl/base64.php3 on line 11



In attemping to work around this problem... I found another glitch of
sorts. If I simply strip the "=" off the end of the encoded string
before decoding it, IT STILL DECODES PROPERLY. This should not happen.
It is not that any data becomes lost, it is just simply not proper for
base64 encoding.

I continued research a little more and found that four NULLS encodes to
"AAAAAA==". In PHP, if this string we decoded I would have a string of 6
NULLS, which is not the original data.


Thanks,
Daniel