[ruby-list:44887] Re: Dir.entriesのエンコーディング (was Re: Ruby 1.9のARGVのエンコーディング)

成瀬です。

U.Nakamura wrote:
>> 実装コストはあまり気にしてなくて、むしろ UI ですかね。
>> Dir.entries(path, :encoding=>"UTF-8") でもまぁいいのかなぁ。
> 
> Dir.entriesだけを取ってみるならば、こうするのがいけない理由が
> 思いつきません。
> # が、Dir.globなどに考えを広げるとちょっと悩ましい

この手の引数や戻り値の encoding を指定する必要があるものは数ありまして、
それらを考慮に入れるとちょっと慎重な方がいいかなぁと思っています。

open をハッシュに対応させるパッチとかも手元にはあるんですが、
これも名前的な意味で保留していたりします。

>> って、いつもの引数文字列のエンコーディングで指定ですか？
>> 内部実装向けの hack としては簡潔で素晴らしいとは思うのですが、
>> 一般ユーザ向けにはいかがなものかなぁと。
> 
> 実は成瀬さんの言う「force_encoding」がそういう話なんじゃない
> かと思ったりもしてました。
> 成瀬さんはこの方式にはあまり賛成でない、と。

普通に EUC-JP のパスを渡すと EUC-JP で帰ってくる、とかならいいと思うのですが、

[ruby-list:44864]の例(localeがutf-8でファイルエントリがeuc-jp)で、

  files = Dir.entries(eucpath.force_encoding('utf-8'))

で UTF-8 なファイルパスの配列が手に入る〜とかだといかがなものか、と。

つまるところ、この手の hack のバッドノウハウ化を恐れています。

> つまり、戻ってくる文字列は実際のエンコーディング(rubyは知って
> るかもしれないし知らないかもしれない)と関わりなく、常にlocale
> のエンコーディングが設定されているということですか。
> その場合、localeのエンコーディングでは不正となるバイト列が返
> されたら何が起きるんでしょう?
> 勝手にASCII-8BITになる? それとも例外?

不正なバイト列である locale のエンコーディング文字列という想定でした。
というのも、Windows ではファイルシステムが返すパスのエンコーディングは、
常に valid な文字列だったと思いますが、
UNIX 系ですと不正な文字列が返ってくる場合もありうるからです。

# そういう場合には例外を出すべきという主張もあり得ますが、
# valid_encoding? でよいのではないかと

> Dir.entriesの場合、話に出てくるエンコーディングは3つありえて、
>   (1) 引数であるパス指定のエンコーディング
>   (2) 実際のファイルシステム上のエントリのエンコーディング
>   (3) 結果配列内の各文字列のエンコーディング
> 
> 以上の考察から、私の提案はこうです。
> 
>   * (3)は(1)と同一とみなして適宜変換する

US-ASCII 時の例外を入れればだいたい大丈夫そうなんですが、
これは少し考えてみます。

>   * (2)のデフォルトはlocale(rubyが知っている場合はもちろんそ
>     れを使う)とし、別途オプション引数等で指定可能とする

「rubyが知っている場合はもちろんそれを使う」ということは、
Encoding.filesystem_encoding のような、
locale がデフォルトの別の変数または定数が必要ですよね。

>   * もし(1)と異なるエンコーディングで(3)が欲しいという特殊な
>     事態があれば、それはスクリプト作者が(1)をどうにかする

ここで先述の force_encoding を用いたテクニックを使わせるのには抵抗があります。

>   * (1)がUS-ASCIIでかつ(2)がいわゆるASCII互換でない場合、locale
>     またはオプション引数で指定されたエンコーディングを(3)に用
>     いる

ここの「ASCII互換でない」とは 7bit only ではないということですよね。
つまり、ファイルシステムのエンコーディングをそのまま渡すと。

-- 
NARUSE, Yui  <[e-mail]>