On Fri, 13 May 2011, Simon Pieters wrote:
>
> We're making this change in Opera (we'll ignore "space characters" in
> atob).
I've updated the spec accordingly. Let me know if this causes any
problems.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.
On Thu, 12 May 2011 00:13:37 +0200, Ian Hickson wrote:
On Fri, 4 Feb 2011, Jorge wrote:
Wrt to the note "some base64 encoders add newlines or other whitespace
to their output. atob() throws an exception if its input contains
characters other than +/=0-9A-Za-z, so other characters need to be
r
On Fri, 4 Feb 2011, Jorge wrote:
>
> Wrt to the note "some base64 encoders add newlines or other whitespace
> to their output. atob() throws an exception if its input contains
> characters other than +/=0-9A-Za-z, so other characters need to be
> removed before atob() is used for decoding" in
On 06/02/2011, at 07:56, Joshua Bell wrote:
> On Sat, Feb 5, 2011 at 6:37 PM, Joshua Cranmer wrote:
>> On 02/05/2011 08:29 PM, Jonas Sicking wrote:
>>
>>> So my first question is, can someone give examples of sources of
>>> base64 data which contains whitespace?
>>>
>> The best guess I have is ba
On Sat, Feb 5, 2011 at 6:37 PM, Joshua Cranmer wrote:
> On 02/05/2011 08:29 PM, Jonas Sicking wrote:
>
>> So my first question is, can someone give examples of sources of
>> base64 data which contains whitespace?
>>
> The best guess I have is base64-encoding MIME parts, which would be
> hardwrappe
On 02/05/2011 08:29 PM, Jonas Sicking wrote:
So my first question is, can someone give examples of sources of
base64 data which contains whitespace?
The best guess I have is base64-encoding MIME parts, which would be
hardwrapped every 70-80 characters or so.
--
Beware of bugs in the above code
On Sat, Feb 5, 2011 at 4:29 PM, Aryeh Gregor wrote:
> On Fri, Feb 4, 2011 at 6:59 PM, Simon Pieters wrote:
>> Is the compat problem for not throwing for whitespace or for not throwing
>> for other garbage? If it's for other garbage, we could allow whitespace but
>> throw for other garbage. (The b
On Fri, Feb 4, 2011 at 6:59 PM, Simon Pieters wrote:
> Is the compat problem for not throwing for whitespace or for not throwing
> for other garbage? If it's for other garbage, we could allow whitespace but
> throw for other garbage. (The bugs I can find in our database with a quick
> search is ab
On Fri, 04 Feb 2011 19:54:56 +0100, Aryeh Gregor
wrote:
On Fri, Feb 4, 2011 at 1:19 PM, Jorge wrote:
On the other hand, it will be so forever
Correct, it will be.
unless the spec says *not* to throw but to skip over instead, so that
in a few years the cleanup can be ~safely skipped.
On 04/02/2011, at 19:54, Aryeh Gregor wrote:
> On Fri, Feb 4, 2011 at 1:19 PM, Jorge wrote:
>
>> unless the spec says *not* to throw but to skip over instead, so that in a
>> few years the cleanup can be ~safely skipped.
>
> Nope. The spec isn't going to change browser behavior here if there
>
On Fri, Feb 4, 2011 at 1:19 PM, Jorge wrote:
> On the other hand, it will be so forever
Correct, it will be.
> unless the spec says *not* to throw but to skip over instead, so that in a
> few years the cleanup can be ~safely skipped.
Nope. The spec isn't going to change browser behavior here
On 04/02/2011, at 18:58, Jonas Sicking wrote:
> On Fri, Feb 4, 2011 at 8:37 AM, Jorge wrote:
>> Hi,
>>
>> Wrt to the note "some base64 encoders add newlines or other whitespace to
>> their output. atob() throws an exception if its input contains characters
>> other than +/=0-9A-Za-z, so other c
On 04/02/2011, at 17:49, Boris Zbarsky wrote:
> On 2/4/11 11:37 AM, Jorge wrote:
>> Wrt to the note "some base64 encoders add newlines or other whitespace to
>> their output. atob() throws an exception if its input contains characters
>> other than +/=0-9A-Za-z, so other characters need to be rem
On Fri, Feb 4, 2011 at 8:37 AM, Jorge wrote:
> Hi,
>
> Wrt to the note "some base64 encoders add newlines or other whitespace to
> their output. atob() throws an exception if its input contains characters
> other than +/=0-9A-Za-z, so other characters need to be removed before atob()
> is used
On Fri, Feb 4, 2011 at 11:49 AM, Boris Zbarsky wrote:
> The problem is that at least some current browsers (which ones?) throw. So
> you wouldn't be able to rely on the non-throwing behavior anyway :(
Everyone except Opera throws on invalid characters in atob() input,
and IIRC, I was told b
On 2/4/11 11:37 AM, Jorge wrote:
Wrt to the note "some base64 encoders add newlines or other whitespace to their
output. atob() throws an exception if its input contains characters other than
+/=0-9A-Za-z, so other characters need to be removed before atob() is used for
decoding" in http://ary
Hi,
Wrt to the note "some base64 encoders add newlines or other whitespace to their
output. atob() throws an exception if its input contains characters other than
+/=0-9A-Za-z, so other characters need to be removed before atob() is used for
decoding" in http://aryeh.name/spec/base64.html , I t
On Wed, 25 Aug 2010, Boris Zbarsky wrote:
> On 8/25/10 9:37 PM, Boris Zbarsky wrote:
> > Note that this issue means that using atob or btoa for dealing with
> > this is a huge pain if non-ASCII chars are involved, since those take
> > and return byte arrays masquerading as JS strings, not actual
On Fri, Jan 7, 2011 at 12:38 PM, Boris Zbarsky wrote:
> In that case, I would prefer that the character and length constraints just
> be explicitly specified. Specifying them via an unreadable regexp is
> hostile not just to implementors but to the users of the spec too.
I've updated the spec an
On Fri, Jan 7, 2011 at 9:27 AM, Aryeh Gregor
> wrote:
> On Fri, Jan 7, 2011 at 12:01 AM, Boris Zbarsky wrote:
>
>
> > Note that it's not that uncommon to use atob on things that came from
> other
> > base64-producing tools, not just from btoa. Not sure whether that
> matters
> > here.
>
> I don
On 1/7/11 12:27 PM, Aryeh Gregor wrote:
1) If the input string contains any 16-bit units whose value is greater
than 0xff, throw INVALID_CHARACTER_ERR.
This seems redundant with step 4 below.
It's not, because after this step the input JS string is converted into
a byte buffer by dropping t
On Fri, Jan 7, 2011 at 12:01 AM, Boris Zbarsky wrote:
> For what it's worth, Firefox's behavior for atob (based on reading the
> source code, sorta) is the following (ignoring various exceptions on
> allocation failures and the like):
>
> 1) If the input string contains any 16-bit units whose val
On 1/6/11 3:25 PM, Aryeh Gregor wrote:
Browsers disagreed about how to handle input to atob() that can't be
produced by btoa(). Firefox mostly throws exceptions, WebKit is
slightly more lenient, and Opera doesn't throw exceptions at all.
gsnedders told me Opera's behavior caused site compat prob
I've written a provisional spec for window.atob() and window.btoa():
http://aryeh.name/spec/base64.html
These are functions supported by all browsers except IE, which do
base64 encoding and decoding. I also wrote a fairly complete test
suite, at:
http://dvcs.w3.org/hg/html/raw-file/tip/tests/su
24 matches
Mail list logo
