W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

Re: File API: File's name property

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 4 Sep 2013 17:45:37 -0500
Message-ID: <CABirCh-poiV2tv+j3L8qS+E+BxR0Xeg73znUihoUvkP0mA73=Q@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Arun Ranganathan <arun@mozilla.com>, WebApps WG <public-webapps@w3.org>
On Tue, Sep 3, 2013 at 12:04 PM, Anne van Kesteren <annevk@annevk.nl>wrote:

> The problem is that once you put it through the URL parser it'll
> become "/". And I suspect given directory APIs and such it'll go
> through that layer at some point.
>

I don't follow.  Backslashes in filenames are escaped in URLs (
http://zewt.org/~glenn/test%5Cfile), like all the other things that require
escaping.

 Well, my suggestion was rawName and name (which would have loss of
> information), per the current zip archive API design.
>

Having a separate field is fine.  This is specific to ZIPs, so it feels
like it belongs in a ZipFile subclass, not File itself.  We definitely
wouldn't want raw bytes from filenames being filled in from user
filesystems (eg. Shift-JIS filenames in Linux), and Windows filenames
aren't even bytes (they're natively UTF-16).


> > By the way, in the current ZIP URL proposal, where would a File be
> created?
> > If you use XHR to access a file inside a ZIP URL then you'd just get a
> Blob,
> > right?
>
> There's an API too.
>

It might be better to wait until we have a filesystem API, then piggyback
on that...

-- 
Glenn Maynard
Received on Wednesday, 4 September 2013 22:46:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:13 UTC