From: Tanaka Akira Date: 2008-03-03T17:29:27+09:00 Subject: [ruby-dev:33975] Re: encdet.rb In article <20080226.204332.1007194564549993975.kou@cozmixng.org>, Kouhei Sutou writes: > 収束しない気もするのでとりあえずまとめておきます。 > （誰か助けて） 介入する人はいないみたいですねぇ。 > 須藤: openするところまで含むとファイル以外に使えないからIOに > エンコーディングを検出・設定する > API（io.detect_encoding!）を追加して、openとは独立 > に使えるAPIがいい。でも、使うときはreadする前とか > に呼んでね、という注意が必要。 そういう API が存在してはならないとは考えていません。 私が第一に欲しいものはそれではありませんが。 > 私は"/"が細分化とかグループ化とか具体化されている、というよ > うなイメージがあるので、net/httpはネットワーク関係のHTTPとい > う風に思い、憤りは感じませんでした。ディレクトリの区切りが > "/"なのに影響を受けているのかもしれません。 net/http は net の下にいくつもあるので憤りは感じません。 憤りを感じるのは test/unit です。 > XxxYyyというモジュールはxxxyyy.rbというファイル名にするとい > う習慣のことを言いたかったのでした。 ふむ。だからといって XxxYyy というモジュールを xxx/yyy.rb と いうファイル名にするのはかなり慣習に反しますから、xxx-yyy.rb にするか、XxxYyy というモジュール名はつけるべきではないとい うように解釈できます。 そして、xxx-yyy.rb は現在のところモジュール名はあまり関係な い形でしか使われていないので、これまた慣習に反します。 ということは、結局、XxxYyy というモジュール名をつけることに 反対していると解釈できるのですが、あってますか? >> 問題はそもそも分類すべきかどうかというところだと思います。 > > 私は「エンコーディング関連の機能」の「検出機能」という風に考 > えてしまうんでよね。たとえ、今は「エンコーディング関連の機能」 > が一つしかなくても。 私は、不要な分類は避けたいと思っています。 分類すると名前が長くなって使いにくくなりますし、私の思考は不 要な分類に憤りを感じるようにできているようです。 もちろん、必要な分類は必要であり、憤りも感じませんが、今回の はいまのところ必要であるかどうかははっきりしません。 RAA や freshmeat や sourceforge や CPAN でしばらくエンコーディ ングまわりのライブラリを検索してみた結果としては、エンコーディ ングに直接関連するライブラリとしては変換・推測・修復あたりが ありがちなようです。もうちょっと広げると言語推測、行末検出あ たりが入ってくるかもしれません。(言語推測はエンコーディング 推測と密接に関連していますが。) さらに広げるとローマ字かな変 換とか大文字小文字変換とかが入ってきますが、このへんになると エンコーディングは単なる道具で、エンコーディング関連の機能と はいえないような気もします。 私の印象としてはそんなに広がらなそうで、分類の必要性はあまり 感ていません。ただ、Unicode なシステムではエンコーディングに 関する処理が外界とのやりとりのところに集中するのが当然で、変 換が基本になるのも容易に想像できるわけですが、Ruby では外界 とのやりとりのところに集中しない (ようにも書ける) ので、なに か違う種類の機能が必要とされることもあり得るのかもしれません。 分類の必要性に関する決断を遅らせる方法としては Encoding.detection_open とかにして encoding.rb にするという 方法がありますが、私の感覚からするとちょっと長いんですよねぇ。 > ひとつ具体例をあげると、SF.netにHTML（全部がXHTMLというわけで > はないですが）をアップロードする時にSF.netのロゴを入れるとき > に使うことがあります。（SF.netにアップロードするHTMLには > SF.netのロゴを入れなきゃいけないので。） わかったうえでやりたければやればいいんじゃないでしょうか。 > chdirする前にfile.detect_encoding!（仮）してね、というのでは > 弱いでしょうか？ そういう注意が不要な API をデザイン可能なのに、なぜわざわざ ユーザが問題に注意しなければならない API を好むのでしょう? > StringIOやTempfileなどIOっぽいファイル以外のものにも使いたく > ない？と言いたかっただけでした。 具体例はどんなのがあるんでしょう? StringIO や Tempfile についてエンコーディングをどう扱うのが 正しいかということを考えると、それらの内容を生成したやりかた を考えてエンコーディングを得るのが正しいように思えます。 それではうまくない、という例にはどんなのがありますか? > やはり、EncDet.openがそれほどたくさん使われるものなのかがわか > りません。 > > 今のところ、具体例としてRDocでのRubyスクリプトの読み込み、と > いうのがでていますが、それ以外の場合で使われることは多いので > しょうか？というのも、スクリプトを読み込むことはそんなにない > のではないかと思っているからです。PythonやEmacsで編集するファ > イルでmagic commentを使っているのはわかるのですが、それらの > ファイルを読み込むことが多いのかがわかりません。 テキストを処理する、というのは充分に多いように思います。 たとえば、RD のプリプロセッサを書いたとして、プリプロセッサ が RD で記述されたテキストを読むときに、日本語を扱いたいとす れば、エンコーディングをどうにかする必要があります。テキスト を Emacs で編集するとすれば、今回のようなライブラリがあれば、 エディタとプリプロセッサでエンコーディング指定を共用できます。 RD にかぎらず、プレインテキストに近いフォーマットであればど れも同じ事情が成り立つでしょう。 設定ファイルもそうです。最近は YAML が多いような気がしますが、 自前のパーザを持っているアプリケーションも少なくはないでしょ う。設定ファイルの中に日本語を入れたいとすればエンコーディン グをどうにかしなければならず、今回のようなライブラリが役に立 ちます。 > また、CERN httpd形式はよく使われているのか、そしてそれを利用 > したファイルを読み込むことは多いのかというのもわかりません。 こちらはいまのところあまり普及しているとは思いません。 しかし、どんなファイルにでもエンコーディングをつけられるとい う良い性質を持っており、また、エンコーディング以外の情報も入 れられるため、いろいろと便利なんじゃないかと考えています。 > そういう場面が多いのであれば名前を短くしたいという欲求はわか > らなくもないです。ただ、私の経験ではそんなにないんじゃないか > なぁという感じです。 不思議なんですが、日本語を含んだテキストを扱うとき、どうやっ てエンコーディングを処置しているんですか? と、思って Rabbit の README.ja をみてみると、--encoding オプ ションか自動検出のようですね。自動検出がうまくいくのであれば、 必要性を感じないのかなぁ。自動検出はうまくいかないけれど、毎 回 --encoding オプションを指定するのは面倒、というときに役に 立つんですが。 >> EncDet.make_magic_comment("euc-jp") が >> "-*- coding: euc-jp -*-" を返すとか。 > > うーん、使いやすいでしょうか。 > もし、今後XMLをサポートした場合は↑の形式は使えませんよね。 > 検出はmagic comment以外も頑張るけど、出力はmagic commentのみ > サポートというのでもいいでしょうけど、出力もライブラリがうま > い具合に頑張ってほしい気がします。（やるなら） EncDet.make_xml_decl も作ることは出来ます。 ただ、なんにしろ入力は magic comment でも BOM でもどれかひと つの形式で検出できればそれにするというものなのに対し、出力は どの形式にするかユーザが指定する必要があります。どう頑張って も、形式の情報を提供しなくてもいいようにはならないでしょうね。 -- [田中 哲][たなか あきら][Tanaka Akira]