[ruby-dev:33933] Re: encdet.rb

In article <[e-mail]>,
  Kouhei Sutou <[e-mail]> writes:

> たぶん、田中さんは普段、"#{モジュール名.doncase}.rb"なので最
> 初にそれを試して、失敗して、それで戸惑ったということなんだと
> 想像しています。

よくわかりません。ここでいうモジュール名が "Test::Unit" だと
すると downcase すると test::unit で、test::unit.rb があるだ
ろうとは思いませんし、require 'test::unit' と書こうとも思い
ません。それはあまりに慣習から離れすぎています。ですから、
"#{モジュール名.doncase}.rb" で表現したかったのはそれではな
いと思うのですが、それがなんなのかというのがわかりません。

> でも、net/httpじゃなくてnethttpだったら戸惑わないとかいうもの
> でもなくて、普段使わないライブラリだから戸惑ったというのもあ
> るような気がします。

最初だけではなく、require を書くたびに、なぜ必要性もないのに
"/" が必要にしてあるのか憤りを感じたので、普段使わないから、
というだけでは説明できません。

> 私はXXXYYYだとXXXとYYYの切れめが分かりづらいのでそこで少し戸
> 惑うことがあります。（特にWEBrickのやつ。）なので、私は密か
> に"#{モジュール名.doncase}.rb"普及を拒みたいと思っています。

最初に述べたように、"#{モジュール名.doncase}.rb" がなにを示
しているのかよくわからないので、なんともいえません。

なお、WEBrick については、私は基本的に require 'webrick' す
ることにしています。

> なので、たぶん、XXX-YYY.rbになるなら文句は言わなくなる気がし
> ます。（encには反対すると思いますが。）

ハイフンを使っているのは open-uri と resolv-replace ですが、
どちらも主な使用法ではモジュールを使わないんですよねぇ。
どちらも私が作ったものですが。

> なんだと思います。そして、私の好みはXXX/YYY or XXX-YYYで田中
> さんのはXXXYYYなんだと思います。

open-uri などの例を考えていただければわかると思うのですが、
私が XXXYYY でないものを選ぶことはあります。

問題はそもそも分類すべきかどうかというところだと思います。

> どうしましょう。
> エンコーディング関係の別の機能を考えるのがいいのかしら。

将来的に、似た機能や関連する機能を設置する場所に困らないよう
にしたいとは思いますので、具体例があればぜひ考えたいと思いま
す。

機能をエンコーディング関係一般にまで増やしてしまって
encoding.rb というのは可能かなぁ。

> それはわかるのですが、コメント形式がないフォーマットには
> magic commentを追加しにくいのではないかと思います。例えば、
> CSVはどうでしょう。

はい。コメント形式がないのは難しいですね。
CERN httpd の形式はそういうときでも使えますが。

> UTF-16 LE/BEも受け付けるので利用したくなるかもしれません。
> YAMLパーサ使えよ、と言われればまぁそうなんですが。

あぁ、たしかに YAML は UTF-16 も仕様にはいっていますね。記憶
違いをしてました。

ただ、そうにしても YAML の仕様どおりの動作を求めるなら YAML
パーザを使うのが筋で、適当に検出するというのはちょっと乱暴で
すよね。

その適当さがいいのだ、という場合にはいいでしょうが。

> XMLファイルを開いてgsubするとか、grepしたいとかいう場合もあ
> る気がします。

えーと、その適当さがいいのだ、という (以下略)

> chdirがよくわかないのですが、openしたあとでもFile#pathでどう
> にかならないものでしょうか？

File#path が相対パスな場合、chdir されてしまうと、指している
場所が変わってしまいます。

> まさにそのとおりで、私はよくコマンドの結果を入れるのに使いま
> す。そのとき、入力値がプログラムで生成したことももちろんある
> のですが、どこかから持ってきたものを入力してコマンドに通して
> からその結果をプログラムで使うということもあります。そのとき
> はプログラムでの最初の入力がコマンドからの出力なのでエンコー
> ディングを検出したくなると思います。
>
> また、もし、自分でエンコーディングが分かっている場合でも自分
> でエンコーディングを指定するよりは自動でやってくれた方が楽な
> ので使いたくなると思います。

検出したくなるのはわかるのですが、状況がうまくイメージできま
せん。

現在提案中のは magic comment と BOM しか扱いませんから、コマ
ンドが magic comment か BOM を生成するときにしか使えません。

私の経験からいうと、コマンドが出力に magic comment や BOM を
つけるというのは少なくとも Unix ではあまりないのではないかと
思います。

そうすると、いくつかの可能性が考えられます。

* 私が知らないだけで、出力に magic comment や BOM をつけるコ
  マンドがある

* magic comment と BOM 以外の検出方法を追加する (guess とか)

* コマンドの入力に magic comment や BOM があって、それが出力
  に残っている (sed とか? grep だと消えてしまいそう)

想定されているのはどんな状況なんでしょうか?

> であれば、やっぱりopenの第二引数で指定できるくらいの使いやす
> さまで頑張って欲しいです。

私はそうしたいとは思っていません。
そういう提案に反対はしませんが。

> たぶん、私は、Detect.openと動詞がつながるのがなんか嫌なんだ
> と思います。

なるほど。

> コメントの書き方がフォーマットによって違うので難しい気がしま
> す。

えぇ、ですから、生成するのは magic comment の部分だけで、コ
メントは呼出側がどうにかすることになるでしょう。

例えば、(名前はともかくとして)
EncDet.make_magic_comment("euc-jp") が 
"-*- coding: euc-jp -*-" を返すとか。

> エンコーディングを推測する機能や検証する機能は組み込みでしたっ
> け。

String#valid_encoding? は組み込みです。

NKF.guess みたいな推測は組み込みではありませんね。

guess をつけるという案はあるかもしれませんが、これを言語独立
に実装することは現実的か、という問題があります。言語をパラメー
タとかメソッド名の一部にするという手はありますが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]