Re: File API: File's name property

On Wed, Sep 4, 2013 at 11:45 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

If the raw input to the URL parser includes a backslash, it'll be
treated as a forward slash. I am not really expecting people to use
encodeURI or such utilities.


>> 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.

Is it? There's no other file systems where the file names are
effectively byte sequences? If that's the case, maybe that's fine.


> We definitely wouldn't
> want raw bytes from filenames being filled in from user filesystems (eg.
> Shift-JIS filenames in Linux),

The question is whether you can have something random without
associated encoding. If there's an encoding it's easy to put lipstick
on a pig.


> and Windows filenames aren't even bytes
> (they're natively UTF-16).

Right, that would end up as a utf-8 byte sequence in File.rawName and
File.name would do the right thing with that.


>> There's an API too.
>
> It might be better to wait until we have a filesystem API, then piggyback on
> that...

Yeah, I wondered about that. It depends on whether we want to expose
directories or just treat a zip archive as an ordered map of
path/resource pairs.


-- 
http://annevankesteren.nl/

Received on Friday, 6 September 2013 15:42:48 UTC