Re: address@hidden: [patch] url-hexify-string does not follow W3C spec]

[Thien-Thi Nguyen]

YAMAMOTO Mitsuharu <address@hidden> writes:

> This change breaks the following case:
> 
> (concat
>  "file://localhost"
>  (mapconcat 'url-hexify-string
>           (split-string
>            (encode-coding-string "/SOME/NONASCII/FILE/NAME"
>                                  (or file-name-coding-system
>                                      default-file-name-coding-system))
>            "/")
>           "/"))
> 
> Maybe suppress encoding with UTF-8 for unibyte strings?

if the result of this expression is to be used as a URI, then that means
the change exposes improper use of `url-hexify-string'; according to the
RFC (as i understand it) URIs require utf-8.

if we want `url-hexify-string' to handle "URI-like" transformations
(i.e., not strictly produce URI-conformant results), we can add an
optional arg MAKE-UNIBYTE that specifies a function to do the conversion
to unibyte.  in most cases, i guess that would be `string-as-unibyte',
but i don't know for sure.

so i suppose it comes down to the question: is this case supposed to
produce a valid URI?  if so, we should fix the call and not the called.

thi