Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAqLGLNt=dsuCG4sFRWpunMSaXCRmqScP=2FyWzftcdzOWy=qA@mail.gmail.com>
References: 
 <CAAqLGLN4mBmgMCyYKASY34JjP4z0cZvuj-fq5+iHzBm0qJ-Emg@mail.gmail.com>
	<CAOGo0VYeaoy3P8vE3VBjRzxboDsVFvN=g=j8gutEPeV-yMMatg@mail.gmail.com>
	<CAAqLGLOyN9m5omm-q5+a7qgu_bAHoBpBkQOxW-RM1M4zvc-enQ@mail.gmail.com>
	<4183552502473640450@unknownmsgid>
	<CAOGo0VbsA8OpzdSp-V_=yU2+wAdyjrk=StHAc1i2vQdD3sjY3g@mail.gmail.com>
	<-8624072539068019852@unknownmsgid>
	<CAE9L6G2iqWvS5eDrPkaCR2_-qdZsa1VXvBv+0h91o8c-xicB=A@mail.gmail.com>
	<CANrzj0kqt4qpRdurOxiSHx7Svckhw+V4QqSoBZDG4mzZKWjYXA@mail.gmail.com>
	<CAOGo0VaNF1n81gz6wU1A2YUAMub54w5zzf0UNvyX1Fj5UFz4mQ@mail.gmail.com>
	<CAE9L6G2+=MW6dpa6S6=qSmnLNbFb8Vt5q=HdFbDTNzsHTYCVpA@mail.gmail.com>
	<CAOGo0Vb_rPX6F=NtZJMwj6aYRnz2NGQRWMYL5aKa1uNiNQT6jQ@mail.gmail.com>
	<CAOGo0VaavoTBfMz_Z0TYX34UH5HeA0FqvhKkkaw1pBoJMGzDbQ@mail.gmail.com>
	<CAAqLGLNt=dsuCG4sFRWpunMSaXCRmqScP=2FyWzftcdzOWy=qA@mail.gmail.com>
Date: Wed, 20 Mar 2013 10:48:15 +0000
Message-ID: 
 <CAOGo0VZfmrXDHTfKw-rHKHmuoGdL30xGVxdk_dqCMaPrMpEHnA@mail.gmail.com>
Subject: Re: [fileupload] towards 1.3 release - feedbacks required
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 20 March 2013 08:26, Simone Tripodi <simonetripodi@apache.org> wrote:
> priceless!!!
>
>> 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?
>
> IMHO having such behaviour is acceptable, but if it doesn't cost you
> too much, having the behaviour described in Wikipedia[1] is a 'nice to
> have':

As far as I know, it already behaves as per the article, except I have
just noticed that RFC2045 requires invalid characters to be ignored.
That should be trivial to fix now that the code has been re-organised.

The article does not describe how to handle embedded PADs

> +-----------------------------------------------------------+
> Decoding Base64 with padding
> When decoding Base64 text, 4 characters are typically converted back
> to 3 bytes. The only exceptions are when padding characters exist. A
> single '=' indicates that the 4 characters will decode to only 2
> bytes, while 2 '='s indicates that the 4 characters will decode to
> only a single byte. This example illustrates:
> Encoded text ends with: YW55IGNhcm5hbCBwbGVhcw==   Block with 2 '='s
> decodes to 1 character:  any carnal pleas
> Encoded text ends with: YW55IGNhcm5hbCBwbGVhc3U=   Block with 1 '='
> decodes to 2 characters:  any carnal pleasu
> Encoded text ends with: YW55IGNhcm5hbCBwbGVhc3Vy   Block with 0 '='s
> decodes to 3 characters: any carnal pleasur
> +-----------------------------------------------------------+
>
> Thanks!
> -Simo
>
> [1] http://en.wikipedia.org/wiki/Base64
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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