西村賢さんのPython内部文字コードの話題から端を発するUnicodeの話

K.Takata @k_takata

「Unicode文字列型が複数の内部表現をサポート」ってどういうこと？「Python 2系からの移植を容易にするため…Unicodeリテラルシンタックスも復活」これは良い。 http://t.co/LxkUP45x

成瀬 @nalsh

PEP393 Flexible String Representation か。Pythonにしてはすげー頭悪いことしてる気がする http://t.co/fndkFh99

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

HaskellやClojureと比べるとRubyとPythonは双子のよう。じゃあなぜ科学計算でPython、WebでRubyとなったかって、大阪でエレベーターは右に立ち、東京では左という程度の偶然ってことないかな。DHHが左に立ったのは全然偶然ではないけど

成瀬 @nalsh

@knsmr Webで内部UTF-16はダメなんじゃないかと思ってます

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

この比較表を見ると、Rubyの簡潔さと一貫性が際立っているとと思うのだけど、やっぱりPythonとは双子じゃないかと思ったりする http://t.co/CqW9kIf3

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

そうか、Pythonにはswitch caseがないのかー。これは象徴的だな。RailsのArray#forty_twoメソッドと真逆の発想という気が

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

@nalsh ん？ どうしてですか？ UTF-8じゃないと面倒すぎるという意味でしょうか？

成瀬 @nalsh

@knsmr HTTP絡みの操作する時に外部から来たバイト列と、コード由来のUnicode文字列が混ざって面倒+そもそも仕様決めるのが大変という。PHP6なんかはそれが理由で死んじゃったのだと思ってたり

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

@nalsh でも、日本のWebだと外部から来るバイト列はいまだにかなりShift_JISだったりもしませんか？ ヨーロッパもアジアもUTF-8が完全制覇というには程遠いのでは？

成瀬 @nalsh

@knsmr バイト列ならShift_JISでもUTF-8でもあんまり問題ないんですよ。例えばHTTP_REFERERとか識別子は同じバイト列になるので。でもUTF-16だとここで変換しないといけないので、req.params[b"HTTP_REFRER"]とかやらないといけなく

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

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

成瀬 @nalsh

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

小崎 資広 (KOSAKI Motohiro) @kosaki55tea

Webは一見文字列に見える、なにか謎のバイナリで通信してる無法の荒野だからな。まともな文字列のあつかいをしてる言語ほどWebでは死ぬ

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

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

成瀬 @nalsh

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

Yukihiro Matz @yukihiro_matz

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

成瀬 @nalsh

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

成瀬 @nalsh

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

Yukihiro Matz @yukihiro_matz

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

成瀬 @nalsh

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

成瀬 @nalsh

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

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

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

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

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

成瀬 @nalsh

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

7594591200220899443 @shyouhei

@knsmr @nalsh @yukihiro_matz とはいえ私達の縦書き文化が考慮されたことなどありませんし。しょせん完全な対応を求めるのは無理なので、できるところまでやるしかないと思いますよ。