Hi Jason,
Jeffrey, the issue with the base64 stuff is that when the size of the decoded output is determined, no accounting is made for possible pad characters, and for some reason +1 is added to the size always.
I agree with your analysis, no C code port was done I was just looking at the description of the Algorithm from RFC 2045, this seem to be
just a bug.
The other problem requires a peek to the end of the incoming buffer to see if the last, or the second to the last character is the pad character. Here's how you could do this in the Xerces code:
int numPadChars = 0;
if ( base64Data[numberQuadruple-2] == PAD ) { numPadChars = 2; } else if ( base64Data[numberQuadruple-1] == PAD ) { numPadChars = 1; }
decodedData = new byte[ numberQuadruple*3 - numPadChars ];
Yes, this seems reasonable.
I say just remove the comment. ;)
Yes, you are right. At some point thought of adding the check code but decided not to. I forgot to remove the comment.
Hopefully I'll check the code tonight or tomorrow into CVS after I runit through some tests.
Thanks,
Jeffrey Rodriguez
_________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com
