cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Slicing files on iOS and Android
Date Tue, 08 Jan 2013 14:05:56 GMT
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 <agrieve@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 <gibson.becky@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 <braden@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message