BioRubyからPython/JavaScriptそして文字列/バイナリーへのRubyistの論議

@yukihiro_matz @kakutani @knsmr @nalsh さん達がBioRuby Ruby Python JavaScript Unicode 文字列 バイナリーについてとても興味深い面白い話をされていたので、そのまま埋もれるのはもったいないと思ったのでまとめました。
11
西村 賢🐠Coral Capital / Ken Nishimura @knsmr

@nalsh SJISもUTF8もASCII上位互換だから、ASCIIはそのままでいいってことでしょうか? むむむ?

2012-03-07 11:00:29
成瀬 @nalsh

@knsmr はい。Rubyのその辺いじってて、内部UTF-16だと発狂するなぁと思いました。ASCII互換だけ相手してても仕様決めるのが悩ましかった

2012-03-07 11:01:43
西村 賢🐠Coral Capital / Ken Nishimura @knsmr

@nalsh なるほど、そういえば、UTF-8がASCIIのスーパーセットでもあるというのって、あまりに当たり前で忘れていました。そういう意味ではShift_JISも偉かったのかも。内部UCS2は時代の必然と思ってましたが、確かに面倒かも

2012-03-07 11:04:49
Yukihiro Matzmotto @yukihiro_matz

@knsmr @nalsh 内部UCS2は修羅の道ですよ。理論上は綺麗かもしれないけど、実践ではいいことなんにもない。

2012-03-07 11:06:27
成瀬 @nalsh

謎のバイナリを謎のバイナリのまま扱うすべを持っていないと頭がおかしくなって死ぬ。持っていても頭がおかしくなるのでるびいすとはあたまがおかしい

2012-03-07 11:04:53
Yukihiro Matzmotto @yukihiro_matz

@nalsh @knsmr ああ、そこは見落としてました。そっち方面に住んでないから。でも、その先、外界との界面ではやはり修羅の道のような。

2012-03-07 11:09:23
成瀬 @nalsh

@yukihiro_matz @knsmr いやいや、Win32APIや.NET、Cocoaとやりとりしやすい、ICUを叩きやすいっていうメリットはあります。これに目が眩んだ人も多い

2012-03-07 11:07:17
成瀬 @nalsh

ちなみに、最初に wide character なんてアホな考えを思いついたのは日本人のはずである

2012-03-07 11:08:28
Yukihiro Matzmotto @yukihiro_matz

@nalsh @knsmr ああ、そこは見落としてました。そっち方面に住んでないから。でも、その先、外界との界面ではやはり修羅の道のような。

2012-03-07 11:09:23
成瀬 @nalsh

@yukihiro_matz @knsmr 「外界」がファイルとかクリックとかGUIのフォームとかだと「界面」はフレームワーク内なので、問題はたぶん顕在化しないです。WebとかSocketとかネットワーク系だと顕在化して修羅の道ですね

2012-03-07 11:14:29
成瀬 @nalsh

@hutai ISO 2021でなくISO 2022でしょうか。wide characterというかEUC用の拡張が入ったのはISO 2022の86年改正なので必須ということは無いです

2012-03-07 11:20:58
西村 賢🐠Coral Capital / Ken Nishimura @knsmr

@nalsh @yukihiro_matz なるほどー。Unicodeが描いた美しい“文字列オブジェクト”の世界ですね。ネットワーク上もDBもUTF-8が主流になって、結局インピーダンスミスマッチ的なことが起こってるんでしょうか

2012-03-07 11:23:36
西村 賢🐠Coral Capital / Ken Nishimura @knsmr

@nalsh @yukihiro_matz しかし「バイト列」を扱っていれば済むという発想って、BiDiを持つ文化圏を考慮していないということもありませんか。そうか、プロトコルがASCIIだから話がややこしいのかしら

2012-03-07 11:25:54
成瀬 @nalsh

@hutai 時系列的には、Σプロジェクト→EUC→DEC 漢字ですね。仰るとおり「マルチバイトのほうが正しかった」ってのはかなり後になってわかったことなので、後出しの話ではあります

2012-03-07 11:29:07
成瀬 @nalsh

@hutai EUCはΣプロジェクト絡みの日本での検討結果をAT&Tにフィードバックして、アメリカで作られたものなので、実は意外とやりとりがあったりしますよ

2012-03-07 11:30:22
成瀬 @nalsh

@hutai む、それわたしが知っている日本語UNIXシステム諮問委員会→AT&T→UJIS/EUCの流れと別の流れっぽいですね。ちょっと調べてみます

2012-03-07 11:34:28
Yukihiro Matzmotto @yukihiro_matz

@knsmr @nalsh BiDiについては以前考えたことはあるのですが、文字の並びの方向は表示層に属するので、プログラミング言語の文字列としては必要な情報ではないだろうというのが結論でした。縦書き文化からの類推で、実際にBiDi言語を使う人は違う意見があるのかもしれませんが

2012-03-07 11:35:13
西村 賢🐠Coral Capital / Ken Nishimura @knsmr

@shyouhei UTF-8によってマルチバイトは一級市民に加えてもらったからオレたちはもうそれ以上(BiDiとか文字がくっつくとか、、、よく知りませんが)は知らんという態度なのだとしたら、過去の問題が再現してるような気がしたのでした

2012-03-07 11:39:52
成瀬 @nalsh

@hutai なるほど。当時の資料あったら頂けませんか?昔JAEや日本語UNIXシステム諮問委員会までは調べたんですが、UNIXシステム日本語機能提案書やJAE2のマニュアルは手に入れたんですが、JAE1やそれ以前まで遡れなかったんです http://t.co/2YLzHwSK

2012-03-07 11:41:21
成瀬 @nalsh

@knsmr @shyouhei BiDiや縦書きはRuby M17Nより上のレイヤの仕事だと思っています。「文字がくっつく」は異体字セレクタや結合文字列の話ですかね、こちらはString#each_glyphとかそういうのが必要かなぁと考えてるんですがユースケース待ち

2012-03-07 11:44:15
成瀬 @nalsh

@hutai なるほど。DECUS論文集は国会図書館にあるようなので見てみます

2012-03-07 11:53:10
Yukihiro Matzmotto @yukihiro_matz

@kakutani どうせgithubにあるのだから、がんがんpull requestを出すとか。あとはメンテナの負荷軽減対策が必要だろうけど。

2012-03-07 12:44:37
Yukihiro Matzmotto @yukihiro_matz

たとえば素人の私でもPILやNumPyをRubyに移植することくらいはやればできると思う。が、そこから先、機能拡張したりするのは難しい。最初の一歩を踏めば、続きをやる人が名乗りでると思う?

2012-03-07 12:54:54
成瀬 @nalsh

@yukihiro_matz Rubyアサシンで懸賞金かけるといいんじゃないですかね。それで稼ごうと思ったら安いけど、自分用に作るついでに金ももらえるなら儲けものくらいの額で。そういう人が作ったら続きもやってくれるだろうと

2012-03-07 12:57:29
成瀬 @nalsh

@hutai BMPで収まればまだよかったんですけどねぇ。あとWeb業界的にはそもそもASCII互換じゃないといろいろつらいなぁというのが最近の知見ですね

2012-03-07 13:18:00