Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tJRq5-0032z5-PF for pgsql-bugs@arkaria.postgresql.org; Fri, 06 Dec 2024 06:29:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tJRq3-00APtV-1U for pgsql-bugs@arkaria.postgresql.org; Fri, 06 Dec 2024 06:29:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tJRq2-00APtM-Ow for pgsql-bugs@lists.postgresql.org; Fri, 06 Dec 2024 06:29:19 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tJRq1-001JAM-4Z for pgsql-bugs@lists.postgresql.org; Fri, 06 Dec 2024 06:29:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=o6xfJNi0vltWZDqKMJUvmGHPq6JTaH50JF0TfL7KmEc=; b=X6xsHNlT2dO9bLgt7v4G95pheH 6K5PWQwLWAbTAOhUGtwOZRcdpCbumUkGJYxzhhdAPXnXqXA9Iq3nXsTHie+OMGePkuUD468uliNnt YThYMfNCAcqcpG1yNpigRIUVmKBpqbkNpsMSOJRDdg9ZQG7Lqi4pTM1TznyILT4ZTuvGkdefGLSNu FakO/pjly6E37Gs7WvCl6AXpTz4IvyTAX63fZra1Z2tLYPOGRpbZpZruc6ZonbhvkU8MJ8kVdBA1f cYf4X9U/j4uhKF4CJAuPcJxVTw58EDfwnLVcA8hJxiu6uQp4FMcTnjiv3+YVG6gX7v12/k6Am22cX hIXnl8pw==; Received: from 221x241x223x178.ap221.ftth.ucom.ne.jp ([221.241.223.178] helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1tJRpw-003sfY-0T; Fri, 06 Dec 2024 06:29:15 +0000 Date: Fri, 06 Dec 2024 15:29:01 +0900 (JST) Message-Id: <20241206.152901.833675745256351050.ishii@postgresql.org> To: tgl@sss.pgh.pa.us Cc: koichi.dbms@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows From: Tatsuo Ishii In-Reply-To: <2750622.1733463850@sss.pgh.pa.us> References: <2572359.1733424649@sss.pgh.pa.us> <20241206.142130.1661155698933375612.ishii@postgresql.org> <2750622.1733463850@sss.pgh.pa.us> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Tatsuo Ishii writes: >>> This might mean that it'd be okay to just skip the backslash-to-slash >>> conversion loops altogether if we think the encoding is Shift-JIS. > >> I suggest to not do so because majority of Shift-JIS users treat 0x5C >> as a backslash. They understand that a 0x5C means a backslash in >> Shift-JIS files if the files are for programming (source code) or for >> the technical documentations and so on. > > Sure, we can do it that way. I think the hard part is figuring > out whether Windows thinks the file names are in Shift-JIS. > Do you have any idea about finding that out? I am not familiar with Windows and have no idea, but from the original report: postgres=# \cd 'c:/work/09_環境構築' it seems the KANJI characters are shown properly even if a part of the KANJI characters include a backslash. This could indicate Windows thinks the file names are in Shift-JIS. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp