From ###@###.### Tue Aug 22 08:30 PDT 1995
X-Mailer: exmh version 1.6.2 7/18/95
To: ###@###.### (Chuck McManis)
Subject: Re: Possible bug in Base64decoder
Mime-Version: 1.0
Date: Tue, 22 Aug 1995 17:28:27 +0200
From: Per Danvind <###@###.###>

Hi again.

I think I know where the problem is, with BASE64Decoder anyway :)

I read the RFC1521 where base64 is defined to have lines of up to 76 encoded
characters (== 76*6 bits), which means 57 unencoded 8-bit characters. I guess
this means that any line length up to this value is a valid base64 encoding.

Since the decodeLineSuffix() method just discards any characters up to the
newline, setting the line length to 48 encoded bytes (== 64 6-bit characters)
as the bytesPerLine() method in BASE64Decoder does, could easily cause problems
when other encoders use other line lengths.

As an emergency hack, just to allow longer lines than 48 bytes, I added the
decoding functionality to the decodeLineSuffix too. Bad solution, but a quick
one... so now I can at least decode Exmh's 72 encoded character lines.

I guess that fixing the problem more definitely will mean changes to
CharacterDecoder, at least to take some feedback from the decodeAtom() method.
I was thinking that perhaps bytesPerLine() could give 57 and then decodeAtom()
would tell if it reached a newline before that...

Anyway, keep up the nice work!

--
Per Danvind

/------------------------------------------\\
| Address: Vänortsvägen 7:86 |
| 977 54 Luleå |
| Sweden |
| |
| Phone: +46 920 15934 |
| |
| WWW: http://jota.sm.luth.se/~d91-pdd |
\\------------------------------------------/