DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FASTER?

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9931

Base64 decoder chokes on a whitespace: FASTER?

m.redington@ucl.ac.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Base64 decoder chokes on a  |Base64 decoder chokes on a
                   |whitespace: FIXED?          |whitespace: FASTER?



------- Additional Comments From m.redington@ucl.ac.uk  2003-01-26 22:36 -------
Attached is another patch for Base64.java, for folding the data in the encode()
method.

This one allocates a little extra space to hold separators, and then inserts the
separators on the fly. It relies on CHUNK_SIZE % 4 == 0, which is true for the
recommended RFC value (76).

The only real issue I can see is that if your last block is padded, and is
exactly 76 chars long, you won't get a newline on the end of it. This should be
easy to fix given the patch.

It was marginally faster on the tests, but the advantage should get bigger as
the size of the input increases (adds one equality test every four bytes of
input, but saves a lot of array copying).

I also had a look at decode. Whitespace could be stripped out in the body of
this, probably more efficiently, as Daniel suggested, but I can't see any
elegant way to manage this offhand.