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? [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Base64 decoder chokes on a |Base64 decoder chokes on a |whitespace: FIXED? |whitespace: FASTER? ------- Additional Comments From [EMAIL PROTECTED] 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
