I use Free Pascal for programming a small utility for two quite busy
Mac OS X mail server (Postfix|CRM114|ANOMY|Cyrus) which prepares and
preselects incoming mails (filtering or leraning) for the statistical
mail filter CRM114.
Today, I managed to use the fcl base64 classes for decoding
respective parts of the piped through e-mails. However, it took me
some time to get it to work, and I have still some doubts if the
base64 decoding class is stable enough for unattended operation on a
busy mail server.
Possibly somebody has more experience with the fcl base64 classes
than I have, and hopefully can destroy my doubts.
Base64 encoded parts of e-mails usually include line breaks (LF at
Mac OS X Server) every 76 characters. When I write these LF into the
TMemoryStream which is passed to TBase64DecodingStream, then the
decoder freezes during the read beyond the first line break. If I
pass through CRLF or only CR instead of LF then it freezes also - it
seems that the decoder is caught into an endless loop. The obvious
workaround is not to write the line breaks into the TMemoryStream.
Actually, I check whether the input char belongs to the base64
character set before it is written to the TMemoryStream - also CR/LF
is filtered out by this way.
if ch in ['A'..'Z', 'a'..'z', '0'..'9', '+', '/', '='] then
My question here is, whether this catches every malformed base64
code, so that the decoder does not freeze.
Another problem was, that TBase64DecodingStream.EOF() does not
indicate properly the end of the decoded stream. Instead, I was
forced to use the "try read() except on EStreamError" sequence for
the eof indication.
My question here is, whether this works in any case. Again, I am a
little bit afraid, that the decoder might be caught into an endless
On Wednesday 02 November 2005 22:06, Dr. Rolf Jansen wrote:
> Today, I managed to use the fcl base64 classes for decoding
> respective parts of the piped through e-mails. However, it took me
> some time to get it to work, and I have still some doubts if the
> base64 decoding class is stable enough for unattended operation on a
> busy mail server.
Sort of the same problem struck me yesterday, too, but with streams
which are perfectly valid containing only base64-chars.
// somehow the current implementation of base64 decoding stream is
// broken, it sometimes raise StreamReadError instead of decoding
// the values correctly (if you feed $000102...7A7B7C into it,
// it stops just before decoding $7C, or try feeding a constant
// stream of $7D into it, it will stop after the first byte
Because I need this for XML-RPC server/client stuff, and thus I need the
HTTP-capabilities of it anyway, I (temporarily?) switched to Synapse's
SynaCode unit. AFAICS it doesn't have any problems with invalid base64
chars, it simply ignores them. Lukas, correct me if I'm wrong.
Currently I can't neither file a bug report nor check the current svn if
it's fixed already, because I don't have access to any of
*.freepascal.org. :-( Someone's blocking me and I haven't figured out
why and who yet.