37
K.Takata @k_takata
「Unicode文字列型が複数の内部表現をサポート」ってどういうこと?「Python 2系からの移植を容易にするため…Unicodeリテラルシンタックスも復活」これは良い。 http://t.co/LxkUP45x
成瀬 @nalsh
PEP393 Flexible String Representation か。Pythonにしてはすげー頭悪いことしてる気がする http://t.co/fndkFh99
Ken Nishimura / 西村賢 @knsmr
HaskellやClojureと比べるとRubyとPythonは双子のよう。じゃあなぜ科学計算でPython、WebでRubyとなったかって、大阪でエレベーターは右に立ち、東京では左という程度の偶然ってことないかな。DHHが左に立ったのは全然偶然ではないけど
成瀬 @nalsh
@knsmr Webで内部UTF-16はダメなんじゃないかと思ってます
Ken Nishimura / 西村賢 @knsmr
この比較表を見ると、Rubyの簡潔さと一貫性が際立っているとと思うのだけど、やっぱりPythonとは双子じゃないかと思ったりする http://t.co/CqW9kIf3
Ken Nishimura / 西村賢 @knsmr
そうか、Pythonにはswitch caseがないのかー。これは象徴的だな。RailsのArray#forty_twoメソッドと真逆の発想という気が
Ken Nishimura / 西村賢 @knsmr
@nalsh ん? どうしてですか? UTF-8じゃないと面倒すぎるという意味でしょうか?
成瀬 @nalsh
@knsmr HTTP絡みの操作する時に外部から来たバイト列と、コード由来のUnicode文字列が混ざって面倒+そもそも仕様決めるのが大変という。PHP6なんかはそれが理由で死んじゃったのだと思ってたり
Ken Nishimura / 西村賢 @knsmr
@nalsh でも、日本のWebだと外部から来るバイト列はいまだにかなりShift_JISだったりもしませんか? ヨーロッパもアジアもUTF-8が完全制覇というには程遠いのでは?
成瀬 @nalsh
@knsmr バイト列ならShift_JISでもUTF-8でもあんまり問題ないんですよ。例えばHTTP_REFERERとか識別子は同じバイト列になるので。でもUTF-16だとここで変換しないといけないので、req.params[b"HTTP_REFRER"]とかやらないといけなく
Ken Nishimura / 西村賢 @knsmr
@nalsh SJISもUTF8もASCII上位互換だから、ASCIIはそのままでいいってことでしょうか? むむむ?
成瀬 @nalsh
@knsmr はい。Rubyのその辺いじってて、内部UTF-16だと発狂するなぁと思いました。ASCII互換だけ相手してても仕様決めるのが悩ましかった
KOSAKI Motohiro @kosaki55tea
Webは一見文字列に見える、なにか謎のバイナリで通信してる無法の荒野だからな。まともな文字列のあつかいをしてる言語ほどWebでは死ぬ
Ken Nishimura / 西村賢 @knsmr
@nalsh なるほど、そういえば、UTF-8がASCIIのスーパーセットでもあるというのって、あまりに当たり前で忘れていました。そういう意味ではShift_JISも偉かったのかも。内部UCS2は時代の必然と思ってましたが、確かに面倒かも
成瀬 @nalsh
謎のバイナリを謎のバイナリのまま扱うすべを持っていないと頭がおかしくなって死ぬ。持っていても頭がおかしくなるのでるびいすとはあたまがおかしい
Yukihiro Matsumoto @yukihiro_matz
@knsmr @nalsh 内部UCS2は修羅の道ですよ。理論上は綺麗かもしれないけど、実践ではいいことなんにもない。
成瀬 @nalsh
@yukihiro_matz @knsmr いやいや、Win32APIや.NET、Cocoaとやりとりしやすい、ICUを叩きやすいっていうメリットはあります。これに目が眩んだ人も多い
成瀬 @nalsh
ちなみに、最初に wide character なんてアホな考えを思いついたのは日本人のはずである
Yukihiro Matsumoto @yukihiro_matz
@nalsh @knsmr ああ、そこは見落としてました。そっち方面に住んでないから。でも、その先、外界との界面ではやはり修羅の道のような。
成瀬 @nalsh
@yukihiro_matz @knsmr 「外界」がファイルとかクリックとかGUIのフォームとかだと「界面」はフレームワーク内なので、問題はたぶん顕在化しないです。WebとかSocketとかネットワーク系だと顕在化して修羅の道ですね
成瀬 @nalsh
@hutai ISO 2021でなくISO 2022でしょうか。wide characterというかEUC用の拡張が入ったのはISO 2022の86年改正なので必須ということは無いです
Ken Nishimura / 西村賢 @knsmr
@nalsh @yukihiro_matz なるほどー。Unicodeが描いた美しい“文字列オブジェクト”の世界ですね。ネットワーク上もDBもUTF-8が主流になって、結局インピーダンスミスマッチ的なことが起こってるんでしょうか
Ken Nishimura / 西村賢 @knsmr
@nalsh @yukihiro_matz しかし「バイト列」を扱っていれば済むという発想って、BiDiを持つ文化圏を考慮していないということもありませんか。そうか、プロトコルがASCIIだから話がややこしいのかしら
成瀬 @nalsh
@hutai 時系列的には、Σプロジェクト→EUC→DEC 漢字ですね。仰るとおり「マルチバイトのほうが正しかった」ってのはかなり後になってわかったことなので、後出しの話ではあります
7594591200220899443 @shyouhei
@knsmr @nalsh @yukihiro_matz とはいえ私達の縦書き文化が考慮されたことなどありませんし。しょせん完全な対応を求めるのは無理なので、できるところまでやるしかないと思いますよ。
残りを読む(78)

コメント

Ken Nishimura / 西村賢 @knsmr 2012年3月7日
ニコニコのコメントがUCS4というツイートを追加
Koichiro Ohba @koichiroo 2012年3月7日
ちょっと足しました
成瀬 @nalsh 2012年3月7日
Python vs. Rubyの話は遡ると@nankyokujuseiの話に遡れて、そのきっかけは小崎さんで、さらにEric Wong、Rubyのチケットと遡ります。 https://twitter.com/#!/nankyokujusei/status/177185676595433472 https://twitter.com/#!/nankyokujusei/status/177178451462205440 https://twitter.com/#!/nankyokujusei/status/1
成瀬 @nalsh 2012年3月7日
で、よく見ると西村さんは内部コードの話はしていません。どこからそんな話が出てきたかというと、https://twitter.com/#!/k_takata/status/177011650535227393 https://twitter.com/#!/nalsh/status/177031771114835968 のあたりが念頭にありました
Koichiro Ohba @koichiroo 2012年3月8日
成瀬さんのコメントを反映しました。
Koichiro Ohba @koichiroo 2012年3月8日
Python vs Rubyは福井さんがまとめてくれたのでいいかなー
ログインして広告を非表示にする
ログインして広告を非表示にする