From: "遊楽庵" <yu_raku_an@...>
Date: 2008-01-15T09:50:59+09:00
Subject: [ruby-dev:33109] Re: Binary String

遊楽庵です。

あの、前にも出してスルーされちゃった話で恐縮ですが…

> 変換していないのにトラブルが発生する理由がわかりません。そのようなトラブ
> ルが発生するケースとは、ビットマップデータをテキストボックスに突っ込むよ
> うな事態が起きてるってことですよね？
というご発言から考えて、成瀬さんは「Stringは必ず文字列である」とお考えの
ようですが、私は必ずしもそうではなくもっと広い概念で「文字列ではない
Stringも存在する」と思っています。
蒸し返してすみませんけど、そういう「文字列でないString」のための
「正しい」encodingとしての「binary」(でも「identity」でもいいですけど)を
用意することは考えられないでしょうか。

NARUSE, Yui さんは書きました:
> 成瀬です。
> 
> Hidetoshi NAGAI wrote:
>> From: Tanaka Akira <akr@fsij.org>
>> Subject: [ruby-dev:33080] Re: Binary String
>> Date: Mon, 14 Jan 2008 00:33:41 +0900
>> Message-ID: <87ejclkaeh.fsf@fsij.org>
>>> そういうときはやはり具体的な問題に立ち帰るのがいいんじゃない
>>> でしょうか。問題の具体例を示してみるのはどうでしょう?
>> 以下は「推測」とは別の話なので
>> 一例になるのかよく分からない点もありますが，
>> tk で生成する binary (identity) 文字列は
>> どうやって識別可能にしておけばいいのでしょうか？
> 
> で、本当に binary が識別可能じゃないとだめなの？ってのが疑問ですね。
> 
>> 生成された文字列には Ruby のオブジェクトに変換するための処理を
>> 適用した上で Ruby 側に渡してやる必要があります．
>> その際，Ruby 側での処理が楽になるように，
>> 文字列はデフォルトの encoding で渡すようにしています．
> 
> default_external が、tcl/tk を呼び出すスクリプトの内部エンコーディングと
> 等しいとは限らない気がします。スクリプトを書く人が CSI に作ってくれてい
> るならば綺麗に動くのでしょうが、実際は default_external は Windows-31J
> で 内部は UTF-8 とかこれからは多そうな気が。まぁ、蛇足ですが。
> 
>> 通常の文字列であれば変換処理を適用すべきですが，
>> binary (identity) 文字列であればそのまま渡さねばなりません．
>> また，Ruby 側に渡した文字列は Tk 側を呼ぶ際に
>> そのまま使われる可能性があります．
>> binary (identity) 文字列であればもちろん加工なしに渡さねばなりません．
>>
>> この変換処理の判定をすべてのケースについて記述しようとすると，
>> コードの量が極度に増えてしまう危険性が大きく，
>> 新しい Tcl/Tk の機能/属性に対してもその度に対応作業が
>> 必要になる可能性も高まるため，避ける必要があります．
> 
> ソースをざっと見ただけなので間違っているかもしれませんが、本当にそうです
> か。tk_call_without_enc とかの binary 版を作れば解決したりしませんかね。
> 
>> この際，Ruby 側のデフォルトの encoding が 
>> ASCII-8BIT なりうるとすると，どうすべきなのでしょうか？
>> 多分，「変換しなければいい」とおっしゃるのだろうとは思いますが，
>> Ruby と Tk との間で渡したり渡されたりの中で
>> 区別できなくなっていることによるトラブル発生への心配を
>> どうしても拭いきれません．
> 
> 変換していないのにトラブルが発生する理由がわかりません。そのようなトラブ
> ルが発生するケースとは、ビットマップデータをテキストボックスに突っ込むよ
> うな事態が起きてるってことですよね？
> 
>> Tk が認識 or 保持しているデフォルトの encoding は
>> そのユーザの GUI 環境において普通の encoding であり，
>> 通常はその encoding を使っているというように推測するのは
>> さほどおかしな事とは思えません．
>> Ruby の default_external が未定義の状態にある場合にのみ
>> (識別できるなら「未定義」の文字列に対してのみ) 
>> Tk のデフォルトを参照しようということですので，
>> 問題はないと考えます．
> 
> * 最近は locale に関わらず内部 Unicode なのでは
> * locale_charmap がとれない場合は US-ASCII になった [ruby-dev:33078]
> * ASCII-8BIT が返ってくる場合は、Ruby の知らない encoding のみ
> * Tcl/Tk が知っていて Ruby が知らないのは KOI8-U のみ
> 
> KOI8-UはKOI8とKOI8-Rどちらのreplicaにすればわからなかったので保留してい
> ましたが、Wikipediaにどっちとも違うと載っていたので適当にいじってそのう
> ち対応させます。
> 
>> なぜ binary であることを示す identity が外されているのでしょうか？
>> generic/tclEncoding.c で initial encoding の筆頭で定義されています．
> 
> default_external の文脈ですから、文字列に対する encoding のことでしょう。
> 
>>> 難しい救済に挑戦するよりは、定義しちゃったほうが、tk 以外で
>>> も幸せになれますし、いいのではないかと思います。
>> はい．
>> 他の encoding の alias ではない形での identity も含めて
>> 定義していただけるなら，幸せになれます．(^_^)
>> Tk 上で「binary である」と規定されている identity を，
>> Ruby 上で「binary であるとは限らない」とされている 
>> ASCII-8BIT の alias として定義されてしまうのは困ります．
> 
> この「定義」って CP936 と CP949 のことでは。で、これはもう Ruby 側で対応
> しました。
> 
>> # グリフが明らかに違うのに同じコードにされてしまった
>> # 日中の「骨」のように．(^_^)
> 
> 一応解説。Unicode という存在の解釈の仕方はいろいろあるのですが、その一つ
> として、Internationalization のためのものではなく、Globalization のため
> のものであると。つまり、日本語の文字列と中国語の文字列が同時に一つの文章
> には混在しないので、グリフが違っても問題ないのですよ。なので、Unicode を
> 使うときは言語情報も付加させないとだめですよというお話です。もしそれが問
> 題だと思うのならばグリフが同じでも中国語の文字と日本語の文字は別にするべ
> きで（厳密な同定が事実上困難だとか他の異体字との兼ね合いだとかグリフが同
> じでも意味が違えば違う字だろうとか、んじゃ意味が同じとは何かとか）、それ
> は ISO 2022 だとか ISO 10646 原案のような方向になりますな。
> 
>> え〜っと，ASCII-8BIT 以外は「未定義」ではないのですよね？
> 
> 定義しないと振られませんね。
> 
>> スクリプトの encoding は明示するようにするのが基本で，
>> 明示がなければ default_external とする (これは未決定？) のですよね？
> 
> 違います、magic comment の指定されていないスクリプトの文字列リテラルのエ
> ンコーディングは ASCII-8BIT です。
> 
>> で，default_external は encoding が決定できない場合のみに
>> ASCII-8BIT に設定され，
> 
> 前述のとおり、Rubyが知らない encoding が来た場合のみになりました。
> 
>> その場合に encoding を指定せずに生成した
>> 文字列のみが「未定義」となる (ASCII-8BIT を明示した文字列は「定義済」)
>> というように考えていたのですが，間違っていますか？
> 
> 生成がどこで行われているかは大きな問題です。外部からの入力、文字列リテラ
> ルが大きなものでしょうが、他に Integer#chr とか Array#pack だとか。
> 
>> # 私がはっきりしていないばかりに，
>> # 二種類の対応策についての議論が明確に切り分けられずに進んでいて，
>> # 混乱した状態になってしまっているのかも．．．
> 
> 端的にいえば、問題がどこにあるのか把握なさってないのではないのでしょう
> か。問題が変換についてだけなら、ソースを見た感じ、
> * バイナリデータな string を受けるときはメソッドを変える
> * 変換してほしくない文字列は UTF-8 にしてしまう (なんか hack ぽいけど)
> * ASCII-8BIT は変換しない (Ruby 側で予め encoding を設定してもらう)
> のどれかで解決するでしょう。
> 
> 逆に永井さんのおっしゃるアプローチで BINARY を新たに定義したとしても、バ
> イナリを期待するメソッドに外から ASCII-8BIT でデータををつっこまれれば自
> 動変換がかかって終了ですし、そこを突破しても BINARY と ASCII-8BIT の　
> string の結合を試みた時点で死にます。
> 
> 遠回りに見えるかもしれませんが、encoding を正しく設定してもらうのが実際
> は一番の近道だと思いますよ。こちらのアプローチで気をつけるのは常に Ruby
> の対応文字コード (ここでの「対応」は名前を知ってさえいればそれで足りる)
> が Tcl/Tk を内包するようにすることだけですし。
> 

--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/