From: Martin Duerst <duerst@...>
Date: 2008-09-25T10:16:58+09:00
Subject: [ruby-dev:36542] Re: Encoding.default_internal    のためのパッチ

まつもとさん、成瀬さん、こんにちは。

成瀬さんと同感の点があります。下を見てください。

At 06:31 08/09/25, NARUSE, Yui wrote:
>成瀬です。
>
>Yukihiro Matsumoto wrote:
>> まつもと ゆきひろです
>> 
>> In message "Re: [ruby-dev:36517] Re: Encoding.default_internal のためのパッチ"
>>  on Wed, 24 Sep 2008 21:23:48 +0900, "NARUSE, Yui" <naruse@airemix.jp> writes:
>> 
>> |Martin Duerst wrote:
>> |> [ruby-core:18774] に Michael Selig から Encoding::default_internal
>> |> の提案がありました。
>> |
>> |まつもとさんに昼ごろ聞いたところ、まだ思案中のようです。
>> |
>> |結局 default_internal ってのは multi-locale を指向する
>> |Ruby からすると逆行する存在なので、難しいところではあります。
>> 
>> 今日一日考えて、導入することにしました。

ありがとうございました。

>> 以下のような仕様を考えています。
>> 
>> * default_internalはIOでinternalを指定しなかった場合のエンコー
>>   ディングである
>
>internal を指定しなかった場合、IO#internal_encoding は nil のままで
>いいでしょうか。
>
>> * これが指定されている時IOからの入力は(バイナリでない限り)、
>>   このエンコーディングを持つ(必要なら変換する)。
>>
>> * (重要)なにも指定しない場合のdefault_externalはlocale。
>>   default_internalは「UTF-8」。
>>
>> * 新設の-Lオプションを指定するとdefault_externalはlocale、
>>   default_internalは空になる。
>
>これはこのままだとまずいです。
>すべてが UTF-8 ならば言うまでも問題ありません。
>しかし、入力元・出力先・スクリプトのリテラルが全て例えば CP932 の場合、
>Ruby 1.9 では入力とリテラルを結合できません。

これは根本的な問題なのか、「-L を指定しない限り」なのか?
後者だと思いますが、成瀬さん、確認できますか。

>これが、Perl 等の場合はリテラルも変換してしまうので問題ないのですが、
>Ruby 1.9 では リテラルはそのままなので不一致が発生します。
>
>oneliner 等の簡単なスクリプトでリテラルをそのまま認識させたい場合に、
>-L 一つとはいえオプションが必要というのは煩雑ではないでしょうか。

そうですね。

>これの一つの解決策はリテラルも default_internal に変換してしまうことです。
>
>もう一つは default_internal の初期値を空にし、
>Unicoder 用のオプションを新設することです (幸い -U が空いています)。

これはいいアイディアだと思います。

>思うに、Ruby は日々の簡単なスクリプトに最適化されるべきです。
>なぜならば、そのような場合は書く絶対量、処理にかかる絶対時間が短いので、
>些細な違いのインパクトが大きいからです。
>
>例えば ruby -pe'1' < hoge.txt としたときに、
>無駄に変換が2回走るのはいかがなものかとか、

これはそれほどの問題ではないと思います。

>数行の書き捨てスクリプトでいちいち -L 指定しないといけないとか、
>数行に対しての " -L" なので、まぁそれなりにインパクトは。

そうですね。もう一つちょっと心配なのは 1.8 との互換性です。
-L の導入でその -L を付けるかどうかなどの作業が発生します。

>一方の Unicode は基本的に巨大な伽藍を築く際に真価を発揮するわけで、
>ごてごてとオプションをつけさせるのは悩み多き Unicoder には煩雑でしょうが、
>-U オプション一つならば問題ないんじゃないかあぁ。

そうですね。

>> * (未定)Dirなどが返すパス名はdefault_externalから
>>   default_internalへの変換が行われる。ただし、変換エラーが発
>>   生した場合、文字が化けるのは避けたい(バイナリで返すか)。
>>
>> 現在では基本Unicodeで構わないとは思いますが、パス名については
>> 変換に伴うデータロスでファイルが見つけられない事態を避けるこ
>> とを考えなければなりません。上では「未定」と書いていますが、
>> 「変換に失敗した時にはバイナリ」というのが現実的な対処ではな
>> いかと思います。
>
>毎回 roundtrip することを確認しますかねぇ。
>で、戻らなかったら元の encoding のまま返すとか。
>ASCII-8BIT をつけちゃうのは不便なんじゃないかと思います。

これは微妙な問題です。なぜなら変換できないのは結構少なく、
たまにしか起こらない問題こそ難しい問題はありません。


>> この結果、各種ライブラリは
>> 
>>  * 基本UTF-8を返せばよい、入力もUTF-8を期待
>>  * より親切なライブラリはdefault_internalで返す。入力は
>>    encodingを見て対処

ここはちょっと心配のところです。特に外国のプログラマは
「全部 UTF-8 でやってしまう」動向が強いでしょう。
それでいいという可能性もありますが、そうではない可能性も
あります。

>default_internal が空の場合は default_external で返すのですかね。

パッチを作ったときに、「default_internal が空なら default_external」
を返す機能の必要性を感じ始めました。

宜しくお願いします。    Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp