[ruby-dev:33321] Re: Binary String

成瀬です。

Hidetoshi NAGAI wrote:
>> 一義的にはライブラリ側を 1.9 対応させるのがベストなわけですが、ライブラ
>> リ側に手を入れられないことが前提ならば [ruby-dev:33269] のように 途中で
>> force_encoding したり、オブジェクトを受け取ってから force_encoding すれ
>> ばいいでしょう。1.8 非対応なのはわかっているのだから、使う側が
>> force_encoding すればいいよね、と。
> 
> いえ，返されてしまった後ではすでに手遅れかもしれないです．
> 1.8 では $KCODE とかもありましたから，そうした情報に基づいて
> 内部で何らかの処理を行っているかもしれません．
> しかしそうした処理を 1.9 で実行したときには 
> 1.9 のメソッドが使われてしまうわけで，
> 返されてからの force_encoding では間に合いません．

うーん、$KCODE に依存していたらー、どうだろう。$KCODE を自分で定義したら
救えてしまうパターンと、どうしようもないパターンに二極化するような気はし
ないでもないですが。


>> 若干ここの仮定がおかしいように思います。その「手の届かないライブラリ内
>> 部」はすべて encoding 非対応なので、encoding が設定されている必要はない
>> でしょう。encoding が必要になるのは手が届くところまで来てからですから、
>> そこで設定してあればよのです。
> 
> では十分とは思えないです．
> 
> 「ではそういうライブラリは諦めてください」が 
> Ruby 1.9 なのかもしれませんが．．．

うーん、あまりそういうライブラリって多くないと思いますけどねぇ。

> # これまでは， Ruby って，ある程度のいい加減さを許容する
> # 鷹揚さがあるように (魅力のひとつとして) 感じてましたが，
> # 1.9 (の encoding) ではそれを許さない雰囲気がありますね．
> # まぁ，これは本当に「感情的」なものですが．(^_^)

まぁ、encoding ってのは交換用ですからね。
そのまま表示するだけだったらてきとーでいいんですが。

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

いえ、[ruby-dev:33269] の例の念頭に置いているので手を入れていません。

>> encoding 非対応のライブラリが返してきた時点で必然の結果得られたものでは
>> ないことが分かります。
> 
> ライブラリ上で作られた (生の？) string と，
> ライブラリからさらに nkf などを通じて処理された結果の string が
> 同じように混ざって返されてもですか？

いまいち想定されている状況が分からないのですが、とりあえず nkf は
encoding 対応なのはいいのかな。で、その時点で encoding がつくのであとは
よしなになはずなんですが、そこに他の ascii only でない ASCII-8BIT の文字
列を結合させようとすると困りますが、この場合は例外だしてしまうのでちょっ
と違うような。

もっとも、ascii only でない ASCII-8BIT な文字列を結合させてしまうような
ケースはあまりないんじゃないかなぁ・・・。C言語のライブラリがかんでる場
合くらいでしょうか。

> 成瀬さんは比較的低レベルで活用される基本ライブラリのようなものを
> イメージされているのかもしれません．
> そのようなものであれば，結果を受け取ってから force_encoding でも
> 確かに十分であるケースが多そうです．

まぁ、わたしが低レベルよりなのは否定しませんが、

> 私の場合はそうした基本ライブラリを組み合わせて使っているような
> 高レベルのライブラリを想定していました．
> そうしたものでは冒頭のように force_encoding が間に合わないケースが
> しばしば発生するのではないかと考えます．

いくら組みあわせても ASCII-8BIT で処理し続けている限り、基本的には変化し
ないんじゃないかなぁと思っているのですが、実際はそうでもないのかなぁ。
nkf や iconv で変換をかませても、最終的に戻ってくる文字列のあるべき
encoding がわかるならばそれをセットするだけじゃないかなと。で、あるべき
encoding がわからないケースってのが想像付きません。

> 「なら実際にそういうものを用意してみろ」，
> 「具体例を出さないからわからない」と言われて
> きちんと提出できないところがダメなんでしょうけど．．．
> 
> # たとえ出せたとしても，
> # 「1.9 は 1.8 との互換性維持を前提としていないんだから，
> #   そういうケースは諦めましょう」
> # と言われて終りにされそうな気がするのは気のせいでしょうか．．．

C言語のライブラリが、自分で Ruby レベルでファイルを開いてロケールエン
コーディングの文字列を持ってきて、これに C 言語レベルで自分で作った
ascii only でない ASCII-8BIT 文字列と結合させようとして例外だして死ぬ、
あたりはありえそうですかねぇ。

>> ただ、本当に必要かというと、今のところ必要に見える場面はどれも別のよりい
>> い解決策が存在しているようです。なので、実は必要ないのではないかと。
> 
> これまで維持するように注意を払ってきた互換性を
> 主義に反して捨てる覚悟をした者に対して，
> それさえも「よりいい解決策」とさらっと流してしまうのは
> ちょいと残酷ではないかと．(^_^)
>
> 1.8 との継続性に対する重みの捉え方が根本的に違ってて，
> 空回りしてしまってるのかなぁ．．．

いやー、だって、今 String はバイト列じゃなくなったんですよ、互換なわけな
いじゃないですか。

ってのは言いすぎだとしても、わたしは Windows 3.1 -> Windows 95 くらいの
変更が行われていると思っていますし、Ruby より先に Unicode 化した Perl で
ライブラリに軒並み utf8 対応の変更が入ったのも見ていますから、その辺の感
覚は違うかもしれません。

そもそも 1.8 でも文字絡みの部分はちょくちょく変更入ってますからねぇ。nkf
が 1.7 から 2.0 になったりとか。

-- 
NARUSE, Yui  <[e-mail]>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA