Slicing files on iOS and Android

[Braden Shepherdson <br...@chromium.org>]

I've recently been implementing support for Blob.slice() for FileReader
files (sort of). With real native File and Blob objects, they actually hold
the binary data. Cordova File objects are just records passed to
FileReaders. Regardless, the API for File.slice() is identical: it takes a
start and optional end position, and returns a new File. Asking FileReader
to fetch that new file will return just the specified segment of the file.

Some examples are in order. Suppose the file we're reading contains the
text:
"All that is gold does not glitter, not all those who wander are lost."
Then
f.slice(4, 8) would result in "that"
f.slice(9) would be "is gold does not glitter, not all those who wander are
lost."
f.slice(-5, -1) would be "lost"

This is implemented on Android and iOS for both reading text and reading
data URLs. It's straightforward to implement on other platforms, and I
encourage maintainers of other platforms to add this.

I'll be updating the docs tomorrow, including the following quirk on iOS.


That quirk is that iOS encodes the response to readAsText using %-escapes,
so that spaces become %20 and so on. This breaks a handful of spec tests
including mine. It seems very puzzling, since a quick test with that
encoding removed shows that all the specs are now passing. I didn't commit
that, I just wanted to see if the bridge code would die horribly or
something. This has been in the codebase as far back as Github's history
goes (the name change to Cordova), so I was unable to discover the original
reason for it.

Shaz, Andrew, any idea what's going on here? Is this a relic of an old
bridge that can be removed? I'm not sure whether this is a breaking change
for iOS, since Android and presumably other platforms do not do this.

Braden

Re: Slicing files on iOS and Android

[Simon MacDonald <si...@gmail.com>]

Great, that will be a very useful addition to the File API.

Simon Mac Donald
http://hi.im/simonmacdonald


On Mon, Jan 7, 2013 at 6:30 PM, Braden Shepherdson <br...@chromium.org> wrote:
> I've recently been implementing support for Blob.slice() for FileReader
> files (sort of). With real native File and Blob objects, they actually hold
> the binary data. Cordova File objects are just records passed to
> FileReaders. Regardless, the API for File.slice() is identical: it takes a
> start and optional end position, and returns a new File. Asking FileReader
> to fetch that new file will return just the specified segment of the file.
>
> Some examples are in order. Suppose the file we're reading contains the
> text:
> "All that is gold does not glitter, not all those who wander are lost."
> Then
> f.slice(4, 8) would result in "that"
> f.slice(9) would be "is gold does not glitter, not all those who wander are
> lost."
> f.slice(-5, -1) would be "lost"
>
> This is implemented on Android and iOS for both reading text and reading
> data URLs. It's straightforward to implement on other platforms, and I
> encourage maintainers of other platforms to add this.
>
> I'll be updating the docs tomorrow, including the following quirk on iOS.
>
>
> That quirk is that iOS encodes the response to readAsText using %-escapes,
> so that spaces become %20 and so on. This breaks a handful of spec tests
> including mine. It seems very puzzling, since a quick test with that
> encoding removed shows that all the specs are now passing. I didn't commit
> that, I just wanted to see if the bridge code would die horribly or
> something. This has been in the codebase as far back as Github's history
> goes (the name change to Cordova), so I was unable to discover the original
> reason for it.
>
> Shaz, Andrew, any idea what's going on here? Is this a relic of an old
> bridge that can be removed? I'm not sure whether this is a breaking change
> for iOS, since Android and presumably other platforms do not do this.
>
> Braden

Re: Slicing files on iOS and Android

[Becky Gibson <gi...@gmail.com>]

FYI - the W3C versions of the File API's was done back in April of 2011.
Inquiring minds can see the history in my repo:
https://github.com/becka11y/phonegap-iphone/blob/master/PhoneGapLib/Classes/File.m




On Thu, Jan 10, 2013 at 12:12 PM, Becky Gibson <gi...@gmail.com>wrote:

> I put this in when we implemented the File APIs as it was the only way
> that I could get international /multi-byte characters to be supported.
> The implementation was way before iOS 5 so maybe the embedded browser or
> iOS internals have changed.
>
> -becky
>
>
>
> On Thu, Jan 10, 2013 at 11:26 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> Yes, that's one of the tests in mobile-spec, and it works fine without the
>> escaping.
>>
>>
>> On Thu, Jan 10, 2013 at 11:24 AM, Marcel Kinard <cm...@gmail.com>
>> wrote:
>>
>> > Can it pass non-ascii / multi-byte characters correctly without the
>> > escaping?
>> >
>> >
>> > On 1/10/2013 10:55 AM, Braden Shepherdson wrote:
>> >
>> >> Becky, do you know why this escaping was originally put in place? From
>> our
>> >> investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop
>> it,
>> >> and the iOS-specific readAsText implementation.
>> >>
>> >> If no one can remember why it was there (its existence predates the
>> >> porting
>> >> to Apache repos, so I can't see the commit that added it) and it seems
>> to
>> >> pass all the tests, then I vote to remove this extra complexity.
>> >>
>> >> Braden
>> >>
>> >>
>> >
>>
>
>

Re: Slicing files on iOS and Android

[Becky Gibson <gi...@gmail.com>]

I put this in when we implemented the File APIs as it was the only way that
I could get international /multi-byte characters to be supported.   The
implementation was way before iOS 5 so maybe the embedded browser or iOS
internals have changed.

-becky



On Thu, Jan 10, 2013 at 11:26 AM, Braden Shepherdson <br...@chromium.org>wrote:

> Yes, that's one of the tests in mobile-spec, and it works fine without the
> escaping.
>
>
> On Thu, Jan 10, 2013 at 11:24 AM, Marcel Kinard <cm...@gmail.com>
> wrote:
>
> > Can it pass non-ascii / multi-byte characters correctly without the
> > escaping?
> >
> >
> > On 1/10/2013 10:55 AM, Braden Shepherdson wrote:
> >
> >> Becky, do you know why this escaping was originally put in place? From
> our
> >> investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop
> it,
> >> and the iOS-specific readAsText implementation.
> >>
> >> If no one can remember why it was there (its existence predates the
> >> porting
> >> to Apache repos, so I can't see the commit that added it) and it seems
> to
> >> pass all the tests, then I vote to remove this extra complexity.
> >>
> >> Braden
> >>
> >>
> >
>

Re: Slicing files on iOS and Android

[Braden Shepherdson <br...@chromium.org>]

Yes, that's one of the tests in mobile-spec, and it works fine without the
escaping.


On Thu, Jan 10, 2013 at 11:24 AM, Marcel Kinard <cm...@gmail.com> wrote:

> Can it pass non-ascii / multi-byte characters correctly without the
> escaping?
>
>
> On 1/10/2013 10:55 AM, Braden Shepherdson wrote:
>
>> Becky, do you know why this escaping was originally put in place? From our
>> investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop it,
>> and the iOS-specific readAsText implementation.
>>
>> If no one can remember why it was there (its existence predates the
>> porting
>> to Apache repos, so I can't see the commit that added it) and it seems to
>> pass all the tests, then I vote to remove this extra complexity.
>>
>> Braden
>>
>>
>

Re: Slicing files on iOS and Android

[Marcel Kinard <cm...@gmail.com>]

Can it pass non-ascii / multi-byte characters correctly without the 
escaping?

On 1/10/2013 10:55 AM, Braden Shepherdson wrote:
> Becky, do you know why this escaping was originally put in place? From our
> investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop it,
> and the iOS-specific readAsText implementation.
>
> If no one can remember why it was there (its existence predates the porting
> to Apache repos, so I can't see the commit that added it) and it seems to
> pass all the tests, then I vote to remove this extra complexity.
>
> Braden
>

Re: Slicing files on iOS and Android

[Braden Shepherdson <br...@chromium.org>]

Becky, do you know why this escaping was originally put in place? From our
investigations it is unnecessary on iOS 5.0, 5.1 and 6, so we can drop it,
and the iOS-specific readAsText implementation.

If no one can remember why it was there (its existence predates the porting
to Apache repos, so I can't see the commit that added it) and it seems to
pass all the tests, then I vote to remove this extra complexity.

Braden


On Tue, Jan 8, 2013 at 10:21 AM, Braden Shepherdson <br...@chromium.org>wrote:

> Okay, Andrew and I investigated this a bit more this morning and found
> that I was getting some broken results.
>
> I can't reproduce the broken tests due to escaping, I suspect I had an old
> version that wasn't merging in the iOS version of FileReader.
>
> However, we continue to see that at least on 6.0 (downloading the 5.0
> simulator to check) on the default bridge, removing the encoding and
> decoding works fine, including for international characters. I'll follow up
> with the results on 5.0, and maybe experiment with other bridge modes too.
> Possibly this is an old workaround for a bug in iOS versions we no longer
> support.
>
> Braden
>
>
> On Tue, Jan 8, 2013 at 9:05 AM, Braden Shepherdson <br...@chromium.org>wrote:
>
>> Um, what Becky describes is exactly the opposite of what I saw. The test
>> for international characters was failing before I removed the encoding
>> because the percent-encoded string did not match the unencoded expectation.
>> When I removed the encoding from the native code, then all the tests
>> including that one started passing.
>>
>> I edited the common js implementation of readAsFile to handle the
>> slicing, and that's working. I didn't think to check for platform-specific
>> implementations. Now that I'm looking at that implementation, I'm wondering
>> why it isn't being used, since then the decoding should be working and the
>> slicing should be broken, but I've never seen that test result.
>>
>> Braden
>>
>>
>> On Mon, Jan 7, 2013 at 8:39 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>
>>> Right, what Becky said.
>>>
>>> It might be worth looking into having the iOS bridge take care of
>>> international characters directly instead of special-casing the
>>> FileReader.
>>> We should be able to escape characters using \uXXXX instead of percent
>>> escaping them. If you're interested in looking into this, let me know.
>>> Otherwise I'll look into it.
>>>
>>>
>>> On Mon, Jan 7, 2013 at 8:16 PM, Becky Gibson <gi...@gmail.com>
>>> wrote:
>>>
>>> > The reason for encoding on iOS was to support international characters.
>>> >  The response from read as text is decoded in the iOS specific version
>>> of
>>> > readAsText at
>>> >
>>> https://github.com/apache/cordova-js/blob/master/lib/ios/plugin/ios/FileReader.jsline65.  I wouldn't suspect that the all of the mobilespec file tests
>>> > would pass with the encoding removed since there are tests to check for
>>> > extended characters?
>>> >
>>> > Becky
>>> >
>>> > Sent from my iPad
>>> >
>>> > On Jan 7, 2013, at 6:30 PM, Braden Shepherdson <br...@chromium.org>
>>> > wrote:
>>> >
>>> > > I've recently been implementing support for Blob.slice() for
>>> FileReader
>>> > > files (sort of). With real native File and Blob objects, they
>>> actually
>>> > hold
>>> > > the binary data. Cordova File objects are just records passed to
>>> > > FileReaders. Regardless, the API for File.slice() is identical: it
>>> takes
>>> > a
>>> > > start and optional end position, and returns a new File. Asking
>>> > FileReader
>>> > > to fetch that new file will return just the specified segment of the
>>> > file.
>>> > >
>>> > > Some examples are in order. Suppose the file we're reading contains
>>> the
>>> > > text:
>>> > > "All that is gold does not glitter, not all those who wander are
>>> lost."
>>> > > Then
>>> > > f.slice(4, 8) would result in "that"
>>> > > f.slice(9) would be "is gold does not glitter, not all those who
>>> wander
>>> > are
>>> > > lost."
>>> > > f.slice(-5, -1) would be "lost"
>>> > >
>>> > > This is implemented on Android and iOS for both reading text and
>>> reading
>>> > > data URLs. It's straightforward to implement on other platforms, and
>>> I
>>> > > encourage maintainers of other platforms to add this.
>>> > >
>>> > > I'll be updating the docs tomorrow, including the following quirk on
>>> iOS.
>>> > >
>>> > >
>>> > > That quirk is that iOS encodes the response to readAsText using
>>> > %-escapes,
>>> > > so that spaces become %20 and so on. This breaks a handful of spec
>>> tests
>>> > > including mine. It seems very puzzling, since a quick test with that
>>> > > encoding removed shows that all the specs are now passing. I didn't
>>> > commit
>>> > > that, I just wanted to see if the bridge code would die horribly or
>>> > > something. This has been in the codebase as far back as Github's
>>> history
>>> > > goes (the name change to Cordova), so I was unable to discover the
>>> > original
>>> > > reason for it.
>>> > >
>>> > > Shaz, Andrew, any idea what's going on here? Is this a relic of an
>>> old
>>> > > bridge that can be removed? I'm not sure whether this is a breaking
>>> > change
>>> > > for iOS, since Android and presumably other platforms do not do this.
>>> > >
>>> > > Braden
>>> >
>>>
>>
>>
>

Re: Slicing files on iOS and Android

[Braden Shepherdson <br...@chromium.org>]

Okay, Andrew and I investigated this a bit more this morning and found that
I was getting some broken results.

I can't reproduce the broken tests due to escaping, I suspect I had an old
version that wasn't merging in the iOS version of FileReader.

However, we continue to see that at least on 6.0 (downloading the 5.0
simulator to check) on the default bridge, removing the encoding and
decoding works fine, including for international characters. I'll follow up
with the results on 5.0, and maybe experiment with other bridge modes too.
Possibly this is an old workaround for a bug in iOS versions we no longer
support.

Braden


On Tue, Jan 8, 2013 at 9:05 AM, Braden Shepherdson <br...@chromium.org>wrote:

> Um, what Becky describes is exactly the opposite of what I saw. The test
> for international characters was failing before I removed the encoding
> because the percent-encoded string did not match the unencoded expectation.
> When I removed the encoding from the native code, then all the tests
> including that one started passing.
>
> I edited the common js implementation of readAsFile to handle the slicing,
> and that's working. I didn't think to check for platform-specific
> implementations. Now that I'm looking at that implementation, I'm wondering
> why it isn't being used, since then the decoding should be working and the
> slicing should be broken, but I've never seen that test result.
>
> Braden
>
>
> On Mon, Jan 7, 2013 at 8:39 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> Right, what Becky said.
>>
>> It might be worth looking into having the iOS bridge take care of
>> international characters directly instead of special-casing the
>> FileReader.
>> We should be able to escape characters using \uXXXX instead of percent
>> escaping them. If you're interested in looking into this, let me know.
>> Otherwise I'll look into it.
>>
>>
>> On Mon, Jan 7, 2013 at 8:16 PM, Becky Gibson <gi...@gmail.com>
>> wrote:
>>
>> > The reason for encoding on iOS was to support international characters.
>> >  The response from read as text is decoded in the iOS specific version
>> of
>> > readAsText at
>> >
>> https://github.com/apache/cordova-js/blob/master/lib/ios/plugin/ios/FileReader.jsline65.  I wouldn't suspect that the all of the mobilespec file tests
>> > would pass with the encoding removed since there are tests to check for
>> > extended characters?
>> >
>> > Becky
>> >
>> > Sent from my iPad
>> >
>> > On Jan 7, 2013, at 6:30 PM, Braden Shepherdson <br...@chromium.org>
>> > wrote:
>> >
>> > > I've recently been implementing support for Blob.slice() for
>> FileReader
>> > > files (sort of). With real native File and Blob objects, they actually
>> > hold
>> > > the binary data. Cordova File objects are just records passed to
>> > > FileReaders. Regardless, the API for File.slice() is identical: it
>> takes
>> > a
>> > > start and optional end position, and returns a new File. Asking
>> > FileReader
>> > > to fetch that new file will return just the specified segment of the
>> > file.
>> > >
>> > > Some examples are in order. Suppose the file we're reading contains
>> the
>> > > text:
>> > > "All that is gold does not glitter, not all those who wander are
>> lost."
>> > > Then
>> > > f.slice(4, 8) would result in "that"
>> > > f.slice(9) would be "is gold does not glitter, not all those who
>> wander
>> > are
>> > > lost."
>> > > f.slice(-5, -1) would be "lost"
>> > >
>> > > This is implemented on Android and iOS for both reading text and
>> reading
>> > > data URLs. It's straightforward to implement on other platforms, and I
>> > > encourage maintainers of other platforms to add this.
>> > >
>> > > I'll be updating the docs tomorrow, including the following quirk on
>> iOS.
>> > >
>> > >
>> > > That quirk is that iOS encodes the response to readAsText using
>> > %-escapes,
>> > > so that spaces become %20 and so on. This breaks a handful of spec
>> tests
>> > > including mine. It seems very puzzling, since a quick test with that
>> > > encoding removed shows that all the specs are now passing. I didn't
>> > commit
>> > > that, I just wanted to see if the bridge code would die horribly or
>> > > something. This has been in the codebase as far back as Github's
>> history
>> > > goes (the name change to Cordova), so I was unable to discover the
>> > original
>> > > reason for it.
>> > >
>> > > Shaz, Andrew, any idea what's going on here? Is this a relic of an old
>> > > bridge that can be removed? I'm not sure whether this is a breaking
>> > change
>> > > for iOS, since Android and presumably other platforms do not do this.
>> > >
>> > > Braden
>> >
>>
>
>

Re: Slicing files on iOS and Android

[Braden Shepherdson <br...@chromium.org>]

Um, what Becky describes is exactly the opposite of what I saw. The test
for international characters was failing before I removed the encoding
because the percent-encoded string did not match the unencoded expectation.
When I removed the encoding from the native code, then all the tests
including that one started passing.

I edited the common js implementation of readAsFile to handle the slicing,
and that's working. I didn't think to check for platform-specific
implementations. Now that I'm looking at that implementation, I'm wondering
why it isn't being used, since then the decoding should be working and the
slicing should be broken, but I've never seen that test result.

Braden


On Mon, Jan 7, 2013 at 8:39 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Right, what Becky said.
>
> It might be worth looking into having the iOS bridge take care of
> international characters directly instead of special-casing the FileReader.
> We should be able to escape characters using \uXXXX instead of percent
> escaping them. If you're interested in looking into this, let me know.
> Otherwise I'll look into it.
>
>
> On Mon, Jan 7, 2013 at 8:16 PM, Becky Gibson <gi...@gmail.com>
> wrote:
>
> > The reason for encoding on iOS was to support international characters.
> >  The response from read as text is decoded in the iOS specific version of
> > readAsText at
> >
> https://github.com/apache/cordova-js/blob/master/lib/ios/plugin/ios/FileReader.jsline65.  I wouldn't suspect that the all of the mobilespec file tests
> > would pass with the encoding removed since there are tests to check for
> > extended characters?
> >
> > Becky
> >
> > Sent from my iPad
> >
> > On Jan 7, 2013, at 6:30 PM, Braden Shepherdson <br...@chromium.org>
> > wrote:
> >
> > > I've recently been implementing support for Blob.slice() for FileReader
> > > files (sort of). With real native File and Blob objects, they actually
> > hold
> > > the binary data. Cordova File objects are just records passed to
> > > FileReaders. Regardless, the API for File.slice() is identical: it
> takes
> > a
> > > start and optional end position, and returns a new File. Asking
> > FileReader
> > > to fetch that new file will return just the specified segment of the
> > file.
> > >
> > > Some examples are in order. Suppose the file we're reading contains the
> > > text:
> > > "All that is gold does not glitter, not all those who wander are lost."
> > > Then
> > > f.slice(4, 8) would result in "that"
> > > f.slice(9) would be "is gold does not glitter, not all those who wander
> > are
> > > lost."
> > > f.slice(-5, -1) would be "lost"
> > >
> > > This is implemented on Android and iOS for both reading text and
> reading
> > > data URLs. It's straightforward to implement on other platforms, and I
> > > encourage maintainers of other platforms to add this.
> > >
> > > I'll be updating the docs tomorrow, including the following quirk on
> iOS.
> > >
> > >
> > > That quirk is that iOS encodes the response to readAsText using
> > %-escapes,
> > > so that spaces become %20 and so on. This breaks a handful of spec
> tests
> > > including mine. It seems very puzzling, since a quick test with that
> > > encoding removed shows that all the specs are now passing. I didn't
> > commit
> > > that, I just wanted to see if the bridge code would die horribly or
> > > something. This has been in the codebase as far back as Github's
> history
> > > goes (the name change to Cordova), so I was unable to discover the
> > original
> > > reason for it.
> > >
> > > Shaz, Andrew, any idea what's going on here? Is this a relic of an old
> > > bridge that can be removed? I'm not sure whether this is a breaking
> > change
> > > for iOS, since Android and presumably other platforms do not do this.
> > >
> > > Braden
> >
>

Re: Slicing files on iOS and Android

[Andrew Grieve <ag...@chromium.org>]

Right, what Becky said.

It might be worth looking into having the iOS bridge take care of
international characters directly instead of special-casing the FileReader.
We should be able to escape characters using \uXXXX instead of percent
escaping them. If you're interested in looking into this, let me know.
Otherwise I'll look into it.


On Mon, Jan 7, 2013 at 8:16 PM, Becky Gibson <gi...@gmail.com> wrote:

> The reason for encoding on iOS was to support international characters.
>  The response from read as text is decoded in the iOS specific version of
> readAsText at
> https://github.com/apache/cordova-js/blob/master/lib/ios/plugin/ios/FileReader.jsline 65.  I wouldn't suspect that the all of the mobilespec file tests
> would pass with the encoding removed since there are tests to check for
> extended characters?
>
> Becky
>
> Sent from my iPad
>
> On Jan 7, 2013, at 6:30 PM, Braden Shepherdson <br...@chromium.org>
> wrote:
>
> > I've recently been implementing support for Blob.slice() for FileReader
> > files (sort of). With real native File and Blob objects, they actually
> hold
> > the binary data. Cordova File objects are just records passed to
> > FileReaders. Regardless, the API for File.slice() is identical: it takes
> a
> > start and optional end position, and returns a new File. Asking
> FileReader
> > to fetch that new file will return just the specified segment of the
> file.
> >
> > Some examples are in order. Suppose the file we're reading contains the
> > text:
> > "All that is gold does not glitter, not all those who wander are lost."
> > Then
> > f.slice(4, 8) would result in "that"
> > f.slice(9) would be "is gold does not glitter, not all those who wander
> are
> > lost."
> > f.slice(-5, -1) would be "lost"
> >
> > This is implemented on Android and iOS for both reading text and reading
> > data URLs. It's straightforward to implement on other platforms, and I
> > encourage maintainers of other platforms to add this.
> >
> > I'll be updating the docs tomorrow, including the following quirk on iOS.
> >
> >
> > That quirk is that iOS encodes the response to readAsText using
> %-escapes,
> > so that spaces become %20 and so on. This breaks a handful of spec tests
> > including mine. It seems very puzzling, since a quick test with that
> > encoding removed shows that all the specs are now passing. I didn't
> commit
> > that, I just wanted to see if the bridge code would die horribly or
> > something. This has been in the codebase as far back as Github's history
> > goes (the name change to Cordova), so I was unable to discover the
> original
> > reason for it.
> >
> > Shaz, Andrew, any idea what's going on here? Is this a relic of an old
> > bridge that can be removed? I'm not sure whether this is a breaking
> change
> > for iOS, since Android and presumably other platforms do not do this.
> >
> > Braden
>

Re: Slicing files on iOS and Android

[Becky Gibson <gi...@gmail.com>]

The reason for encoding on iOS was to support international characters.  The response from read as text is decoded in the iOS specific version of readAsText at  https://github.com/apache/cordova-js/blob/master/lib/ios/plugin/ios/FileReader.js line 65.  I wouldn't suspect that the all of the mobilespec file tests would pass with the encoding removed since there are tests to check for extended characters?

Becky

Sent from my iPad

On Jan 7, 2013, at 6:30 PM, Braden Shepherdson <br...@chromium.org> wrote:

> I've recently been implementing support for Blob.slice() for FileReader
> files (sort of). With real native File and Blob objects, they actually hold
> the binary data. Cordova File objects are just records passed to
> FileReaders. Regardless, the API for File.slice() is identical: it takes a
> start and optional end position, and returns a new File. Asking FileReader
> to fetch that new file will return just the specified segment of the file.
> 
> Some examples are in order. Suppose the file we're reading contains the
> text:
> "All that is gold does not glitter, not all those who wander are lost."
> Then
> f.slice(4, 8) would result in "that"
> f.slice(9) would be "is gold does not glitter, not all those who wander are
> lost."
> f.slice(-5, -1) would be "lost"
> 
> This is implemented on Android and iOS for both reading text and reading
> data URLs. It's straightforward to implement on other platforms, and I
> encourage maintainers of other platforms to add this.
> 
> I'll be updating the docs tomorrow, including the following quirk on iOS.
> 
> 
> That quirk is that iOS encodes the response to readAsText using %-escapes,
> so that spaces become %20 and so on. This breaks a handful of spec tests
> including mine. It seems very puzzling, since a quick test with that
> encoding removed shows that all the specs are now passing. I didn't commit
> that, I just wanted to see if the bridge code would die horribly or
> something. This has been in the codebase as far back as Github's history
> goes (the name change to Cordova), so I was unable to discover the original
> reason for it.
> 
> Shaz, Andrew, any idea what's going on here? Is this a relic of an old
> bridge that can be removed? I'm not sure whether this is a breaking change
> for iOS, since Android and presumably other platforms do not do this.
> 
> Braden