From: "NARUSE, Yui" Date: 2008-09-26T00:29:09+09:00 Subject: [ruby-dev:36576] Re: Encoding.default_internal のためのパッチ 成瀬です。 Martin Duerst wrote: >> しかし、入力元・出力先・スクリプトのリテラルが全て例えば CP932 の場合、 >> Ruby 1.9 では入力とリテラルを結合できません。 > > これは根本的な問題なのか、「-L を指定しない限り」なのか? > 後者だと思いますが、成瀬さん、確認できますか。 -L か -E CP932 を指定しない限り、ですね。 ただ、Windows 環境でさっと書いたときに、これにはまったとき、 -L を指定するって解放にどうやってたどり着くんでしょうね。 # スクリプトは UTF-8 で書くこと推奨でしょうか >> 思うに、Ruby は日々の簡単なスクリプトに最適化されるべきです。 >> なぜならば、そのような場合は書く絶対量、処理にかかる絶対時間が短いので、 >> 些細な違いのインパクトが大きいからです。 >> >> 例えば ruby -pe'1' < hoge.txt としたときに、 >> 無駄に変換が2回走るのはいかがなものかとか、 > > これはそれほどの問題ではないと思います。 うささんの例だと正規表現マッチと同じだけの時間変換にかかってしまっているわけで、 結構な例で問題になるんじゃないでしょうか。 >> 数行の書き捨てスクリプトでいちいち -L 指定しないといけないとか、 >> 数行に対しての " -L" なので、まぁそれなりにインパクトは。 > > そうですね。もう一つちょっと心配なのは 1.8 との互換性です。 > -L の導入でその -L を付けるかどうかなどの作業が発生します。 わたしは芸風的に互換性のことは言いづらいので、この指摘は助かります。 >>> この結果、各種ライブラリは >>> >>> * 基本UTF-8を返せばよい、入力もUTF-8を期待 >>> * より親切なライブラリはdefault_internalで返す。入力は >>> encodingを見て対処 > > ここはちょっと心配のところです。特に外国のプログラマは > 「全部 UTF-8 でやってしまう」動向が強いでしょう。 > それでいいという可能性もありますが、そうではない可能性も > あります。 ここは強く懸念する点の一つで、ここまで UTF-8 を強く推奨してしまうと、 なんで他の encoding に対応しないといけないの？とか、 そもそもなんで他の encoding に対応する必要があったの? という問いに答えづらくなります。 >> default_internal が空の場合は default_external で返すのですかね。 > > パッチを作ったときに、「default_internal が空なら default_external」 > を返す機能の必要性を感じ始めました。 なかださんが指摘なさってますが、単純にやると難しかったりします。 -- NARUSE, Yui