commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace
Date Sat, 28 Sep 2002 08:45:36 GMT
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





------- Additional Comments From vnesek@yahoo.com  2002-09-28 08:45 -------
Well MIME RFC is a governing standard for most base64 implementations:

http://www.faqs.org/rfcs/rfc2045.html

On a page 27 the recomend folding at 76th column and ignoring
newlines. That would be enough for interoperability with Python's
xmlrpclib. However for max interoperability I think all 
whitespace should be silently ignored ( \t\r\n) (tabs and spaces
can be inserted by XML formatters at a begining of line) 
and exception should be throwed if character outside base64 chars
and whitespace is found.

Current impl (I haven't checked CVS recently) decodes base64 encoded
binary with newlines at 76th column into a slightly larger and 
distinctly different binary without raising any exceptions. I find it
some how unusable so I've replaced it with oreilly's base64 decored

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message