Re: File API: File's name property

On Thu, Aug 29, 2013 at 10:51 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> On Thu, Aug 29, 2013 at 4:46 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > All constructing a File does is give a name (and date) to a Blob.  It
> > doesn't create an association to an on-disk file, and shouldn't be
> > restricted to filenames the local platform's filesystem can represent.
>
> Yes, but it can be submitted to a server so it has to be transformed
> at some point. It seems way better to do the transformation early so
> what you see in client-side JavaScript is similar to what you'd see in
> Node.js.
>

It's transformed from a UTF-16 DOMString to the encoding of the protocol
it's being transferred over, just like any other DOMString being sent over
a non-UTF-16 protocol.

> URL parsing does lots of weird things that shouldn't be spread to the rest
> > of the platform.  File.name and URL parsing are completely different
> things,
> > and filenames on non-Windows systems can contain backslashes.
>
> All the more reason to do something with it to prevent down-level bugs.
>

We shouldn't prevent people in Linux from seeing their filenames because
those filenames wouldn't be valid on Windows.  That would require much more
than just backslashes--you'd need to prevent all characters and strings
that aren't valid in Windows, such as "COM0".

Even having non-ASCII filenames will cause problems for Windows users,
since many Windows applications can only access filenames which are a
subset of the user's locale (it takes extra work to use Unicode filenames
in Windows).

-- 
Glenn Maynard