On 20 March 2013 14:42, Gary Gregory <garydgreg...@gmail.com> wrote: > On Wed, Mar 20, 2013 at 10:25 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 20/03/2013 01:09, sebb wrote: >> > I think QPD(ecode) is now OK; it handles lowercase hex and rejects >> > invalid characters. >> > >> > Base64Decode handles valid input OK, and rejects some invalid input, >> > but could perhaps do with tweaking to handle PAD characters better. >> > At present it treats an embedded PAD as the end of input (as per >> > Codec) but maybe it would be better to only allow 1 or 2 PADs at the >> > end? >> >> FYI >> >> Tomcat opted to bypass these Base64 issues but the solution requires >> Java 6 or later. >> >> http://svn.apache.org/viewvc?view=revision&revision=r1458726 >> > > Good one! I like the simplicity of that solution, I wonder if that will > work for [fileupload].
The Java 6 method DatatypeConverter.parseBase64Binary(String) generates a byte array, rather than writing to an OutputStream, but that would be easy to fix. Testing shows that it ignores trailing chars if they are not a multiple of 4. Also it handles concatenated input, provided that the padding is in the correct place (char 3 and/or 4). It's not so hot on some invalid input - I managed to get java.lang.ArrayIndexOutOfBoundsException: 5 when I tried experimenting with padding in different places. If we do decide to use the method, we should probably catch AOOBE and turn it into an IOException. If we do not want to go with Java 6 and that method, we should probably treat concatenated encodings the same way it does. But of course we won't emulate the crash! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
