[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: [MD:7103] Bug? of unix-to-dos-filename and dos-to-unix-filename



藤井です。

From: MIYOSHI Masanori <miyoshi@xxxxxxxxxxx>
Subject: Re: [MD:7103] Bug? of unix-to-dos-filename and dos-to-unix-filename
Date: Sat, 13 May 2006 10:44:02 +0900
> >>>>> [meadow-develop : No.7307] にて
> >>>>> himiさんは書きました:
> > > ちなみに、今回気付いたのは、mw32-sh-get-file-info が動かないなぁ?
> > > からです。これは、'C' レベルで unix_to_dos_filename() を call し
> > > ているから救えない。
> 
> > normalize_filename()は、Windows の国際化APIを使ってファイルを見分けているから
> > unix-to-dos-filenameや、dos-to-unix-filenameでnormalize_filename前に
> > ENCODE_FILE と DECODE_FILEをすればよいはずです。
> 
> なるほど。
> normalize_filename() の前後で ENCODE_FILE と DECODE_FILE を実行す
> るように修正しました(r4076)。

これはまずいです。

dostounix-filename, unixtodos-filename 現状、encode された文字列と、
encode されていない文字列の双方が渡される可能性があります。

expand-file-name は encode せずに渡すので、ENCODE/DECODE_FILE を実行す
る修正が有効になります。

その一方で、map_w32_filename はすでに呼び出し元で encode された文字列を
unixtodos_filename に渡しています。つまり、今回の修正によって
map_w32_filename を実行すると内部でデコードされてしまうことになります。

ですので、map_w32_filename を呼び出している側の関数はデコードされた文字
列をファイル操作 API に渡してしまいます。その結果、日本語を含むファイル
を殆ど扱えなくなってしまいます。ticket:300 の原因もこれです。

応急処置として map_w32_filename の unixtodos_filename の呼び出しを
normalize_filename にかえて余計なデコードが行われないようにしました。
(r4081)

最終的には[MD:7121]に書いたように unixtodos/dostounix_filename で呼び出
し元の文字コードが内部コードかシステムのコードかに統一しないといけない
のだと思います。

From: "M.Fujii" <boochang@xxxxxxxxxxxx>
Subject: Re: [MD:7103] Bug? of unix-to-dos-filename and dos-to-unix-filename
Date: Wed, 28 Dec 2005 06:48:02 +0900 (JST)
> From: Kyotaro HORIGUCHI <horiguti@xxxxxxxxxxx>
> Subject: Re: [MD:7103] Bug? of unix-to-dos-filename and dos-to-unix-filename
> Date: Wed, 28 Dec 2005 01:42:01 +0900 (JST)
> >  これは normalize_filename が受け取る文字列が常に Emacs 内部コード
> > で表現されているという前提ですね. 微妙...と思ってたら実例が..
> 
> 確認してみると、そんな前提は全く成り立っていなっていないことがわかった
> ので、修正を元に戻しました。すみません。
> 
> 問題を解決するには normalize_filename が受けとる文字列が、内部コードか
> システムのコードのいずれかに統一されるように呼び出し側のコードを整理す
> る必要がありそうです。

--
藤井 正行 / Masayuki FUJII