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
