From: Tanaka Akira Date: 2008-02-25T17:01:13+09:00 Subject: [ruby-dev:33933] Re: encdet.rb In article <20080222.230222.782383970824617455.kou@cozmixng.org>, Kouhei Sutou 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]