From: "NARUSE, Yui" Date: 2008-01-15T21:09:23+09:00 Subject: [ruby-dev:33123] Re: Binary String 成瀬です。 Hidetoshi NAGAI wrote: >> ソースをざっと見ただけなので間違っているかもしれませんが、本当にそうです >> か。tk_call_without_enc とかの binary 版を作れば解決したりしませんかね。 > > ダメだと思います. > > ソースをご覧になったのであればご承知とは思いますが, > tk_call_without_enc は,ascii のみと分かっているか, > あるいはすでに UTF-8 (または binary string) に変換済で > それ以上の変換が必要がない場合に使えるものです. > 結局はいずれかの段階で,Tk に渡すトークンごとに > どのように変換するかを決めてやる必要があります. > binary なのかを判断してやらねばなりません. あぁ、tk_call_without_enc は変換しないんですね。それでは、バイナリデータ を要求するメソッドでは tk_call_without_enc を使えば意図しない変換は行わ れないんじゃないですか? > Ruby 1.9 で,magic comment がなければ ASCII-8BIT になり > binary == ASCII-8BIT とするのであるならば, > これまで動いていた Ruby 1.8 のスクリプトに対しては > 次のようになると思います. > > (1) これまでと同様に動くようにするため, > Ruby 1.8 と同様に binary を明示する情報を付与する. > > せっかく encoding 情報を持つようになったのに, > それを利用しないという方法です. > でも,一般ユーザは ASCII-8BIT を binary として > 使おうとするかもしれません. > 似て異なる情報を持たせねばならないという > 気持ちの悪い状況ではあります. BINARY を定義したのにユーザーが ASCII-8BIT をバイナリとして用いるケース を想定していらっしゃいますか? > (2) Ruby 1.8 で動いていた Ruby/Tk のソースは > 文字化けしてしまうのというのを諦めてもらう. > > ソースの互換性を捨ててしまうという対応です. > 動かしたければ,適切な magic comment の付与が必要です. > このような互換性は捨ててしまうべきという意見もありそうですが, > 私は,不可能でない限りは互換性を極力維持したいと > 考える方ですので,心情としてはかなり辛い選択です. > > 不明時の encoding である ASCII-8BIT と区別できるような > binary encoding が存在しさえすれば互換性維持ができると思ってます. > そのために導入をお願いしてきたわけですが, > どうしても binary encoding を加えるつもりはないということであれば, > 非常に残念ですが上記の (2) を選択することにします. えーっと、まず、1.9 では Kernel#* がいくつか消えていたり、多重代入に変更 が入ったり、、、string[i] が 文字を返すようになったりといった非互換な変 更が大量に入っているので、既存のスクリプトが修正なしに Ruby 1.9 で動くと いうことはある程度の規模ならばまずあり得ないと思います。よって、1.8 向け のコードがそのまま動くというのはもとより諦めていただかねばなりません。 magic comment を定義しないことによる問題については定義してくださいの一言 です。magic comment が未定義なことに由来する不都合はユーザー側の責任で しょう。どうも、magic comment の意義を過小評価していらっしゃるようです が、magic comment なしで自動推測によってかろうじて動いていたコードは、別 の環境に持って行ったら化けるんですよ?そんなコードが許されるはずがない じゃないですか。 > というわけで,本当に最後の質問です. > binary encoding 導入,または ASCII-8BIT と UNKNOWN-8BIT の区別は > どうしてもダメですか? え、これで最後なんですか?まだ、永井さんはどこに問題があるのかを把握して いらっしゃらないように思われます。問題を把握できていない方の修正案ではそ の問題が本当に解決できるのかわかりませんし、わたしは binary encoding 導 入では問題の解決はできないと考えています。 田中さんも仰られていますが、「具体的な問題の例」言い換えればテストケース があると理解しやすいように思います。ある種の極限状態——ユーザからもTcl/Tk 自体からもデータを受け取り、そのデータはバイナリデータのこともテキスト データのこともあるというメソッドが存在し、さらに受け取るテキストデータが ASCII-8BIT のままである正当な理由があるケース——がもし存在するならば BINARY が必要な可能性がありますが、わたしはそういうケースは実際には存在 しないと考えています。反証があれば考えを改めさせていただきます。 とりあえず、 * locale 非対応→Ruby が対応すればいいだけ * magic comment がない→つけてください なので、これ以外ですかね。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA