From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: fixing url-unhex-string for unicode/multi-byte charsets Date: Sun, 08 Nov 2020 17:07:35 +0200 Message-ID: <83sg9j6g5k.fsf@gnu.org> References: <20201106074742.jq3h4uujm7oce7af@E15-2016.optimum.net> <83wnyy9akw.fsf@gnu.org> <20201106102756.e2ctvpjruenatud5@E15-2016.optimum.net> <83pn4q8zdz.fsf@gnu.org> <20201106122846.unoizvad53blgncf@E15-2016.optimum.net> <83lffe8v92.fsf@gnu.org> <83eel68r2y.fsf@gnu.org> <20201108091216.xug4neeem7iuayhq@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4082"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Boruch Baum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 08 16:08:17 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kbmIi-0000xH-Ec for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Nov 2020 16:08:16 +0100 Original-Received: from localhost ([::1]:47390 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kbmIh-0003sN-FG for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Nov 2020 10:08:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kbmHz-0003SX-PN for emacs-devel@gnu.org; Sun, 08 Nov 2020 10:07:31 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50138) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kbmHy-00028p-UF; Sun, 08 Nov 2020 10:07:30 -0500 Original-Received: from [176.228.60.248] (port=4193 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kbmHy-0004Ia-6l; Sun, 08 Nov 2020 10:07:30 -0500 In-Reply-To: <20201108091216.xug4neeem7iuayhq@E15-2016.optimum.net> (message from Boruch Baum on Sun, 8 Nov 2020 04:12:16 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258903 Archived-At: > Date: Sun, 8 Nov 2020 04:12:16 -0500 > From: Boruch Baum > Cc: Stefan Monnier , 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.