On Wed, Sep 4, 2013 at 11:45 PM, Glenn Maynard <[email protected]> wrote: > On Tue, Sep 3, 2013 at 12:04 PM, Anne van Kesteren <[email protected]> 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/
