今日は File, Dir, Pathname などのファイルパスの操作するメソッドでエンコーディングを意識した処理をするようにする修正がありました。
nobu:r34372 2012-01-25 11:32:06 +0900
File.expand_path や File.basename, File.dirname, File.join などなど、ファイルパスを扱う File、Dir のクラスメソッドや Pathname#sub_ext で文字列のエンコーディングを意識した処理をするようにしています。 [ruby-dev:45145] [Bug #5919]
主にパスの区切り文字(/ とか \)の探索や拡張子の検出で1文字ずつ辿るところが1バイトずつの処理になっていたのを、エンコーディングを意識して1文字ずつの処理にしたり、あとは途中にヌルバイトが存在する可能性があるのを考慮した(?)ループの停止条件などの変更です。
chompdirsep() などで path++ が残っているので区切り文字はシングルバイトであることは仮定されているようですね。Windows では UTF-16 だったような……と思って Rubyist Magazine - Ruby M17N の設計と実装のファイルパスのエンコーディングについて読むとRubyが利用しているANSI版APIは ANSI コードページまたは OEM コードページなるものに変換した文字列を返すとのこと。これらが実際にどんなエンコーディングなのかははっきりわかりませんでしたが……。
[追記]コメントで教えていただきました。1.9.3 以降は Win32 API の ANSI 版ではなくて Wide文字版を利用しているそうです。しかしシステムネイティブのエンコーディング(多分 UTF-16LE)から Encoding.default_external に変換して Ruby 内には入ってくるので default_external が ASCII-compatible エンコーディングなら大丈夫、ということでしょうか。[/追記]
svn:r34373 2012-01-25 11:32:12 +0900
version.h の日付更新。
nobu:r34374 2012-01-25 11:40:29 +0900
r34372 で rmext() に追加した拡張子の文字列のサイズが 0 だったらすぐに return するようにしています。
nobu:r34375 2012-01-25 13:27:45 +0900
File.basename で第2引数の拡張子の文字列が指定されていて、そのエンコーディングが第1引数と互換性がない時には一致しないので第2引数をなかったことにして処理するようにしています。つまり ASCII 文字じゃないような拡張子の場合はエンコーディングはそろえて渡しましょうということですね。
