[ruby-dev:33381] Re: Binary String

永井＠知能．九工大です．

# 研究室のサーバがいきなり完全にご臨終となり，
# 同時に外付け RAID も瀕死というとんでもない状況になってました．
# 外付けハードウェア RAID の再起動の試みを何度も繰り返した結果，
# RAID 0+1 を構成するディスクの 6 割を辛うじて認識し，
# 奇跡的にギリギリの片肺状態で稼働できてデータを救出できましたが，
# 卒論，修論の追い込み時期に危なくデータを失うところでした．(^_^;
# 復旧までにかなりの時間がかかったものの被害は最小限ですみましたが，
# 失った時間は痛いです．
# 皆様も油断なさりませんよう．(^_^)

From: "NARUSE, Yui" <[e-mail]>
Subject: [ruby-dev:33321] Re: Binary String
Date: Wed, 23 Jan 2008 20:58:19 +0900
Message-ID: <[e-mail]>
> うーん、$KCODE に依存していたらー、どうだろう。$KCODE を自分で定義したら
> 救えてしまうパターンと、どうしようもないパターンに二極化するような気はし
> ないでもないですが。

多分，どうしようもないパターンというのは 
UNDEFINED-8BIT のようなものでも救済できないんでしょうね．
$KCODE を自分で定義しても 1.9 のメソッドには機能してくれませんから，
役には立たない気がします．

# $KCODE を使うように，必要なメソッドをすべて wrap するというのは
# あまりにも労力が割に合わないので，当然考えてはおられませんよね？

> >> あとは、ライブラリにブロックを渡すなりしてライブラリ中で処理するか、オブ
> >> ジェクトを受け取ってから設定するかすれば。
> > 
> > え〜っと，それって「ライブラリ側に手を入れる」ってことですよね．
> > 上記の「ライブラリ側に手を入れられないことが前提ならば 」とは
> > 矛盾してしまいませんか．(^_^;
> 
> いえ、[ruby-dev:33269] の例の念頭に置いているので手を入れていません。

ライブラリが元々ブロックを受け取ることができる仕様になってなければ
どうしようもないように思えるのですが．．．
ライブラリ「内」でそうした対応を行わせるためには，
そのライブラリに手を入れるしかないですよね．
私がまた何か勘違いしているのでしょうか？

> > > > また，UNDEFINED-8BIT で返されたならば，
> > > > 他の encoding の場合と違って Ruby 1.9 としての処理の結果の
> > > > 必然として得られたものではないということが分かります．
> > > > それが分かれば好きなように料理することができます．
> > > 
> > > encoding 非対応のライブラリが返してきた時点で必然の結果得られたものでは
> > > ないことが分かります。
> > > 
> > ライブラリ上で作られた (生の？) string と，
> > ライブラリからさらに nkf などを通じて処理された結果の string が
> > 同じように混ざって返されてもですか？
> 
> いまいち想定されている状況が分からないのですが、とりあえず nkf は
> encoding 対応なのはいいのかな。で、その時点で encoding がつくのであとは
> よしなになはずなんですが、そこに他の ascii only でない ASCII-8BIT の文字
> 列を結合させようとすると困りますが、この場合は例外だしてしまうのでちょっ
> と違うような。

ごめんなさい．nkf は単なる例なのでさして重要ではありません．
1.8 由来のライブラリ内部で nkf などの別の文字列処理ライブラリなり
組み込みメソッドなりを呼び出す際，
その 1.8 由来のライブラリは encoding なんてものを知りませんから
何らかの encoding を仮定 or 想定して文字列を生成し，処理を依頼します．
このとき encoding が指定されてはいないし，
magic comment なんかも入っていませんから，
ASCII-8BIT で文字列が生成される可能性が高いのですよね？

現状の nkf は encoding 対応なわけですが，
仮定として 1.8 版の nkf (1.8 的に動作するものと 
1.9 のメソッドを利用するもの) のようなものと 
1.9 版の nkf のようなものとの場合で考えてみます
(別に nkf でなくてもいいですし，名前が混乱の元になるかもしれませんが，
 話の流れ上なんとなくということで)．
「メインスクリプト ⇔ 1.8 由来のライブラリ ⇔ nkf 」
というように利用されている状況です．
なお，「1.8 由来のライブラリ」ですから，
そのライブラリは nkf のようなものが上記のどのタイプかは知りませんし，
1.8 的に動作するものだと考えて作られているはずです．
で，この「1.8 由来のライブラリ」は「そのまま使う」ということで，
1.9 対応のような修正の手を入れないものとします．

1.8 版で 1.8 的に動作するもの (encoding を利用するような 
1.9 のメソッドや C の関数は利用していない) の場合は，
encoding なんてものは知りませんから，
encoding 設定を無視して処理するでしょう．
そのため，問題なく処理結果を返してくれると思います．
ただ，String オブジェクトの生成は 1.9 ですから 
1.9 のルールに従って encoding が与えられ，
nkf のようなものの戻値の encoding は，
多分 ASCII-8BIT になるのですよね？
このケースでは，1.8 由来のライブラリ上では
すべて ASCII-8BIT で扱うことになり，
ASCII-8BIT でメインスクリプトに返すと思われます．
メインスクリプトは 1.9 前提ですので，
ライブラリの想定 encoding に合わせて
戻ってきた文字列に対して force_encoding すれば
確かになんとか対処できるでしょう．

次に 1.8 版で 1.9 のメソッドを利用するものについてです．
このケースでも nkf のようなものは 1.9 を想定して書かれたわけでは
ないため，magic comment は存在しません．
このとき，1.8 由来のライブラリで生成されて 
ASCII-8BIT とされた文字列が nkf のようなものに
渡される場合を考えます．
メソッドが受け取る引数に依存する点もありますが，結果は
 (1) 例外発生
 (2) 適切に処理されて適切な encoding が与えられたものが返る
 (3) たまたま適切に処理はされたが encoding は ASCII-8BIT で返る
     (ASCII-8BIT はライブラリが想定している encoding ではない)
 (4) 例外は生じないが，ASCII-8BIT のまま (不適切に？) 処理され，
     何らかの encoding (ASCII-8BIT?) で返る
というところでしょうか．
1.8 由来のライブラリは，適切に処理できた場合の encoding を
知っているでしょうから，その想定に従った処理を行うはずです．
ただし「1.8 由来」ですから，戻値に force_encoding などは
するはずもありません．
1.8 由来のライブラリで生成された文字列は ASCII-8BIT ですから，
上記 (2) の場合，処理によっては encoding 不整合でこけます．
こけなければ適切な encoding を持った結果を返せそうです．
上記 (3) の場合は，処理によっては不適切な結果となるかもしれません．
戻値の encoding は多分 ASCII-8BIT となるでしょう．
上記 (4) の場合は，何を返すことになるかわかりません．(^_^;

最後に 1.9 版の nkf のようなものを利用するケースです．
1.8 由来のライブラリで生成された ASCII-8BIT 文字列が渡される場合，
1.9 版の nkf のようなものはその encoding を信じて処理を行うはずです．
ですが，1.8 由来のライブラリが想定している encoding は
ASCII-8BIT ではありませんから，結果は，
 (1) 例外発生
 (2) 例外は生じないが，ASCII-8BIT のまま (不適切に？) 処理され，
     何らかの encoding (ASCII-8BIT?) で返る
というところかもしれません．
「たまたまうまく」ということが絶対にないとは言い切れませんが．

なお，メインスクリプトはほとんどの場合で
戻値として期待する encoding を知っているでしょうから，
正しく処理された結果が返されさえすれば，
force_encoding で適切に設定してやることは可能でしょう．
ですが，不適切な結果が返されてしまうとどうしようもありません．

見落としがありそうな気もしていますが，
UNDEFINED-8BIT + default_undefind なら
上記のすべてをかなりの確率で救済できそうな気がします．

1.8 版で 1.8 的に動作するもののケースでは，
戻値は UNDEFINED-8BIT となり，
無理に force_encoding しなくても default_undefind として
処理を多分正常に継続できます．

1.8 版で 1.9 のメソッドを利用するもののケースも
1.9 版の nkf のようなものを利用するケースも，
問題はいずれも適切な encoding を与えることができずに
ASCII-8BIT として処理しているところにありますから，
encoding が default_undefind となることで
高い確率で適切に処理できるようになると思われます．
1.8 由来のライブラリで生成されたままで未処理のものは
UNDEFINED-8BIT で返ってくるでしょうし，
ASCII-8BIT なら何らかの処理上の必然でそうなったはずです．
戻値をそのまま以降の処理に回しても，
UNDEFINED-8BIT は default_undefined として処理されるため，
何ら問題なく処理できると考えます．
もちろん，UNDEFINED-8BIT を受け取ったメインスクリプトは
force_encoding した方がいいとは思います．
-- 
                                       永井 秀利 （九工大 知能情報）
                                           [e-mail]