On Tue, Sep 3, 2013 at 11:31 AM, Arun Ranganathan <a...@mozilla.com> wrote:
> And, restrict separators such as "/" and "\". > I thought we just agreed that "\" is a platform-specific thing that File.name shouldn't restrict. "/" is a directory separator on just about every platform, but "\" can appear in filenames on many systems. On Tue, Sep 3, 2013 at 11:28 AM, Anne van Kesteren <ann...@annevk.nl>wrote: > ByteString doesn't work. A byte sequence might. If the platform does > file names in Unicode it would be converted to bytes using utf-8. > I don't know what API is being suggested that would keep File.name acting like a String, but also allow containing arbitrary bytes. I could imagine one (an object that holds bytes, stringifies assuming UTF-8 and converts from strings assuming UTF-8), but that's pretty ugly... On Tue, Sep 3, 2013 at 11:42 AM, Anne van Kesteren <ann...@annevk.nl>wrote: > That doesn't solve the problem I mentioned earlier for arbitrary file > names coming out of zip archives. And then your data model is not > bytes, but Unicode scalar values. We could of course accept > information loss of some kind in the conversion process between zip > archive resources and File objects and require developers to keep > track of that if they care. > If you want to retain the original bytes of the filename somewhere, it seems like it should go somewhere other than File.name. For example, a subclass of File, ZipFile, could contain a ByteString filenameBytes with the original filename. I wonder when you'd need that info, though. 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? -- Glenn Maynard