Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows
От | Tatsuo Ishii |
---|---|
Тема | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |
Дата | |
Msg-id | 20241206.154248.1191531539866262856.ishii@postgresql.org обсуждение исходный текст |
Ответ на | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows
|
Список | pgsql-bugs |
> I don't believe the theory that the fault lies there. If the flex > rules were taking the backslash-embedded-in-a-shift-JIS-character > as a backslash, they would think it is the start of a new backslash > command, with the result being that the filename argument gets > truncated there. That doesn't match the reported symptoms: we > see more of the filename than that echoed back in the error message. > So I think the filename is getting through that part just fine, > and then we're messing it up in canonicalize_path or adjacent > processing. I have looked into canonicalize_path() and found this: #ifdef WIN32 /* * The Windows command processor will accept suitably quoted paths with * forward slashes, but barfs badly with mixed forward and back slashes. */ for (p = path; *p; p++) { if (*p == '\\') *p = '/'; } Here "path" is the filename encoded in Shift-JIS I think. It seems canonicalize_path() unconditionaly replaces a backslash with a slash. For me this seems to break any Shift-JIS KANJI characters that a backslash in the second byte. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
В списке pgsql-bugs по дате отправления: