[ruby-dev:33104] Re: Binary String

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

From: Tanaka Akira <[e-mail]>
Subject: [ruby-dev:33080] Re: Binary String
Date: Mon, 14 Jan 2008 00:33:41 +0900
Message-ID: <[e-mail]>
> そういうときはやはり具体的な問題に立ち帰るのがいいんじゃない
> でしょうか。問題の具体例を示してみるのはどうでしょう?

以下は「推測」とは別の話なので
一例になるのかよく分からない点もありますが，
tk で生成する binary (identity) 文字列は
どうやって識別可能にしておけばいいのでしょうか？

生成された文字列には Ruby のオブジェクトに変換するための処理を
適用した上で Ruby 側に渡してやる必要があります．
その際，Ruby 側での処理が楽になるように，
文字列はデフォルトの encoding で渡すようにしています．

通常の文字列であれば変換処理を適用すべきですが，
binary (identity) 文字列であればそのまま渡さねばなりません．
また，Ruby 側に渡した文字列は Tk 側を呼ぶ際に
そのまま使われる可能性があります．
binary (identity) 文字列であればもちろん加工なしに渡さねばなりません．

この変換処理の判定をすべてのケースについて記述しようとすると，
コードの量が極度に増えてしまう危険性が大きく，
新しい Tcl/Tk の機能/属性に対してもその度に対応作業が
必要になる可能性も高まるため，避ける必要があります．

この際，Ruby 側のデフォルトの encoding が 
ASCII-8BIT なりうるとすると，どうすべきなのでしょうか？
多分，「変換しなければいい」とおっしゃるのだろうとは思いますが，
Ruby と Tk との間で渡したり渡されたりの中で
区別できなくなっていることによるトラブル発生への心配を
どうしても拭いきれません．

> 一般に locale に従うという推測は正しいとは限りませんから、
> そのような推測を行うのはなるべく状況証拠があるときに限定すべ
> きです。状況証拠というのは、たとえば、端末から読み込んだデー
> タである、とかです。それだって正しいとは限りませんが、MIME
> でどこかから来たデータが locale に従うというよりはずいぶんと
> ありそうなことだと思います。このような状況証拠はデータを読み
> 込むところが一番良く知っていて、処理が進むとどんどん消えてい
> きます。
> 
> tk のような、データがどこから来たのかわからない部分で推測を
> 行うのは避けたほうがいいのではないでしょうか。

Tk が認識 or 保持しているデフォルトの encoding は
そのユーザの GUI 環境において普通の encoding であり，
通常はその encoding を使っているというように推測するのは
さほどおかしな事とは思えません．
Ruby の default_external が未定義の状態にある場合にのみ
(識別できるなら「未定義」の文字列に対してのみ) 
Tk のデフォルトを参照しようということですので，
問題はないと考えます．

> さて、tcl 8.5.0 の library/encoding/ をいくらか眺めてみまし
> た。間違っていたら指摘してください。
> 
> ASCII 互換で単一バイトなエンコーディングは ASCII-8BIT の
> replica として定義すればそれなりに動きます。
> この範疇にあるのは (Ruby や Oniguruma に定義があるものも含め
> て) 以下の通りです。
> ascii, cp437, cp737, cp775, cp850, cp852, cp855, cp857,
> cp860, cp861, cp862, cp863, cp864, cp865, cp866, cp869,
> cp874, cp1250, cp1251, cp1252, cp1253, cp1254, cp1255,
> cp1256, cp1257, cp1258, gb1988, iso8859-1, iso8859-2,
> iso8859-3, iso8859-4, iso8859-5, iso8859-6, iso8859-7,
> iso8859-8, iso8859-9, iso8859-10, iso8859-13, iso8859-14,
> iso8859-15, iso8859-16, jis0201, koi8-r, koi8-u,
> macCentEuro, macCroatian, macCyrillic, macGreek, macIceland,
> macJapan, macRoman, macRomania, macThai, macTurkish,
> macUkraine, tis-620

なぜ binary であることを示す identity が外されているのでしょうか？
generic/tclEncoding.c で initial encoding の筆頭で定義されています．

> 難しい救済に挑戦するよりは、定義しちゃったほうが、tk 以外で
> も幸せになれますし、いいのではないかと思います。

はい．
他の encoding の alias ではない形での identity も含めて
定義していただけるなら，幸せになれます．(^_^)
Tk 上で「binary である」と規定されている identity を，
Ruby 上で「binary であるとは限らない」とされている 
ASCII-8BIT の alias として定義されてしまうのは困ります．

# グリフが明らかに違うのに同じコードにされてしまった
# 日中の「骨」のように．(^_^)

> >  * 未定義と定義済とは区別できるべきではないのか？
> 
> さて。
> 
> 区別が可能だとして、区別するとどのくらい嬉しいことがあって、
> どのくらい厄介なことがあるのか、という問題になります。
     (snip)
> > 「binary の導入を」という希望は，
> > 未定義と定義済との区別がなされていないように見える現状に対し，
> > せめて「(未定義or定義済)と定義済」の区別ができるようにしてほしい
> > というものです．
> > 
> > ですので，例えば未定義 == dummy encoding であり，
> > それによって「未定義と定義済」の区別ができるのであれば
> > binary == ASCII-8BIT でも何ら不満はありません．
> 
> 文字列を受け取る側としては区別できるようにしてほしいのでしょ
> うが、文字列を生成する側はどうでしょうか。区別して生成し分け
> るのは簡単だと思いますか?

え〜っと，ASCII-8BIT 以外は「未定義」ではないのですよね？
スクリプトの encoding は明示するようにするのが基本で，
明示がなければ default_external とする (これは未決定？) のですよね？
で，default_external は encoding が決定できない場合のみに
ASCII-8BIT に設定され，その場合に encoding を指定せずに生成した
文字列のみが「未定義」となる (ASCII-8BIT を明示した文字列は「定義済」)
というように考えていたのですが，間違っていますか？

# 私がはっきりしていないばかりに，
# 二種類の対応策についての議論が明確に切り分けられずに進んでいて，
# 混乱した状態になってしまっているのかも．．．
-- 
                                       永井 秀利 （九工大 知能情報）
                                           [e-mail]