On Tue, Sep 3, 2013 at 12:04 PM, Anne van Kesteren <ann...@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