Re: fixing url-unhex-string for unicode/multi-byte charsets

[Eli Zaretskii]

> Date: Sun, 8 Nov 2020 04:12:16 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> > > [ BTW, I wouldn't be surprised to hear that the Freedesktop spec
> > >   documents that the file names in the Trash should use utf-8, in which
> > >   case the code should hard-code utf-8 rather than use
> > >   `file-name-coding-system` ;-)  ]
> >
> > If the trash spec says it must be UTF-8, then yes, TRT is to use that
> > unconditionally.
> 
> The FreeDesktop.org Trash specification[1] says about the trash restore
> PATH:
> 
>    "The value type for this key is “string”; it SHOULD store the file
>    name as the sequence of bytes produced by the file system, with
>    characters escaped as in URLs (as defined by RFC 2396, section 2)."
> 
> The RFC says (section 2.1):
> 
>    "... there is currently no provision within the generic URI syntax to
>    accomplish this identification ... It is expected that a systematic
>    treatment of character encoding within URI will be developed as a
>    future modification of this specification."

This means the Trash uses the same byte sequence as stored in the
filesystem, without imposing any encoding restrictions.  In which case
decoding with this:

   (or file-name-coding-system default-file-name-coding-system)

will produce the expected results.

Please note that in general you should be able to use the (unibyte)
string produced by url-unhex-string directly, without decoding it.  It
will work just fine if you pass it to APIs that expect file names, the
only disadvantage is that the file name will not be human-readable.
Depending on the application, this may or may not be a problem.