[ruby-dev:36534] Re: Encoding.default_internal のためのパッチ

成瀬です。

Yukihiro Matsumoto wrote:
> まつもと ゆきひろです
> 
> In message "Re: [ruby-dev:36517] Re: Encoding.default_internal のためのパッチ"
>  on Wed, 24 Sep 2008 21:23:48 +0900, "NARUSE, Yui" <[e-mail]> 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 では入力とリテラルを結合できません。
これが、Perl 等の場合はリテラルも変換してしまうので問題ないのですが、
Ruby 1.9 では リテラルはそのままなので不一致が発生します。

oneliner 等の簡単なスクリプトでリテラルをそのまま認識させたい場合に、
-L 一つとはいえオプションが必要というのは煩雑ではないでしょうか。

これの一つの解決策はリテラルも default_internal に変換してしまうことです。

もう一つは default_internal の初期値を空にし、
Unicoder 用のオプションを新設することです (幸い -U が空いています)。

思うに、Ruby は日々の簡単なスクリプトに最適化されるべきです。
なぜならば、そのような場合は書く絶対量、処理にかかる絶対時間が短いので、
些細な違いのインパクトが大きいからです。

例えば ruby -pe'1' < hoge.txt としたときに、
無駄に変換が2回走るのはいかがなものかとか、
数行の書き捨てスクリプトでいちいち -L 指定しないといけないとか、
数行に対しての " -L" なので、まぁそれなりにインパクトは。

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

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

毎回 roundtrip することを確認しますかねぇ。
で、戻らなかったら元の encoding のまま返すとか。
ASCII-8BIT をつけちゃうのは不便なんじゃないかと思います。

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

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

> これにともない、UTF-{16,32}対応はencから外した方がよいかもし
> れないと思うようになりました。これらはUTF-8とは符号化方式の
> 違いしかありません。まったくデータロスなしに変換できる以上、
> 対応するメリットは大きくなく、混乱のデメリット(たとえばCSVラ
> イブラリがUTF-16対応に苦労した)の方が大きそうです。

んー、彼の場合はそれこそ UTF-8 に変換して内部で処理して、
UTF-{16,32} で返せばいいだけだと思ったのですが。
続きはうささんの方に。

-- 
NARUSE, Yui  <[e-mail]>