[Base64] Codereview request for 8006315 8006530 AND 8006295

Xueming Shen xueming.shen at oracle.com
Fri Feb 1 16:55:58 UTC 2013


Hi,

For 8006295 it appears the more reasonable approach is to continue throw IOE
but document this behavior clearly at the wrap(is) API. So the change is 
joined
with these two.

8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream 
which throws unspecified IOException on attempt to decode invalid Base64 
byte stream

http://cr.openjdk.java.net/~sherman/8006295_8006315_8006530/webrev/

Thanks!
-Sherman

On 1/31/13 11:37 PM, Xueming Shen wrote:
> Hi,
>
> This is the webrev for
>
> 8006530: Base64.getMimeDecoder().decode() throws exception for 
> non-base64 character after adding =
> 8006315: Base64.Decoder decoding methods are not consistent in 
> treating non-padded data
>
> http://cr.openjdk.java.net/~sherman/8006315_8006530/webrev
>
> The change is to
>
> (1) explicitly specify line feed is not added to the end of mime 
> encoded output (no surprise)
>
> (2) mime decoder now ignores any non-base64 character after padding = 
> (same as it
> ignores those non-base64 character within the data (mime base64 spec). 
> Convenient
> for use case like a padding \n at the end of any input data from the 
> file and, as suggested
> from real base64 use case.
>
> (3) explicitly specify padding character at the end of the base64 
> encoded data is
> optional when DECODING (encoder always adds padding character = when 
> necessary).
> The "decoding" part of the RFC really does not make it a MUST, so be 
> liberal.
>
> (4) update the decoder inputstream to behave the same way other 
> decoders do, to
> accept AA and AAA same as AA== AAA=.
>
> Please help review.
>
> -Sherman




More information about the core-libs-dev mailing list