[IVS][安岡孝一氏] / “新しいIVDと互換漢字の人名用漢字 | yasuokaの日記 | スラッシュドット・ジャパン” http://t.co/hf8SUmy3
2012-03-05 09:27:16「Unicode文字列型が複数の内部表現をサポート」ってどういうこと?「Python 2系からの移植を容易にするため…Unicodeリテラルシンタックスも復活」これは良い。 http://t.co/LxkUP45x
2012-03-06 21:44:00PEP393 Flexible String Representation か。Pythonにしてはすげー頭悪いことしてる気がする http://t.co/fndkFh99
2012-03-06 23:03:57@nalsh ん? どうしてですか? UTF-8じゃないと面倒すぎるという意味でしょうか?
2012-03-07 10:35:51@knsmr HTTP絡みの操作する時に外部から来たバイト列と、コード由来のUnicode文字列が混ざって面倒+そもそも仕様決めるのが大変という。PHP6なんかはそれが理由で死んじゃったのだと思ってたり
2012-03-07 10:43:28@nalsh でも、日本のWebだと外部から来るバイト列はいまだにかなりShift_JISだったりもしませんか? ヨーロッパもアジアもUTF-8が完全制覇というには程遠いのでは?
2012-03-07 10:46:41@knsmr バイト列ならShift_JISでもUTF-8でもあんまり問題ないんですよ。例えばHTTP_REFERERとか識別子は同じバイト列になるので。でもUTF-16だとここで変換しないといけないので、req.params[b"HTTP_REFRER"]とかやらないといけなく
2012-03-07 10:52:42@nalsh SJISもUTF8もASCII上位互換だから、ASCIIはそのままでいいってことでしょうか? むむむ?
2012-03-07 11:00:29@knsmr はい。Rubyのその辺いじってて、内部UTF-16だと発狂するなぁと思いました。ASCII互換だけ相手してても仕様決めるのが悩ましかった
2012-03-07 11:01:43Webは一見文字列に見える、なにか謎のバイナリで通信してる無法の荒野だからな。まともな文字列のあつかいをしてる言語ほどWebでは死ぬ
2012-03-07 11:03:40@nalsh なるほど、そういえば、UTF-8がASCIIのスーパーセットでもあるというのって、あまりに当たり前で忘れていました。そういう意味ではShift_JISも偉かったのかも。内部UCS2は時代の必然と思ってましたが、確かに面倒かも
2012-03-07 11:04:49謎のバイナリを謎のバイナリのまま扱うすべを持っていないと頭がおかしくなって死ぬ。持っていても頭がおかしくなるのでるびいすとはあたまがおかしい
2012-03-07 11:04:53@knsmr @nalsh 内部UCS2は修羅の道ですよ。理論上は綺麗かもしれないけど、実践ではいいことなんにもない。
2012-03-07 11:06:27@yukihiro_matz @knsmr いやいや、Win32APIや.NET、Cocoaとやりとりしやすい、ICUを叩きやすいっていうメリットはあります。これに目が眩んだ人も多い
2012-03-07 11:07:17それがどうしたの?あほとはいえないとおもうが。UTF-8(Unicode)以前のISOでの2021アップワード互換上word単位は必須だったし。 QT @nalsh: ちなみに、最初に wide character なんてアホな考えを思いついたのは日本人のはずである
2012-03-07 11:10:44@hutai ISO 2021でなくISO 2022でしょうか。wide characterというかEUC用の拡張が入ったのはISO 2022の86年改正なので必須ということは無いです
2012-03-07 11:20:58@nalsh @yukihiro_matz なるほどー。Unicodeが描いた美しい“文字列オブジェクト”の世界ですね。ネットワーク上もDBもUTF-8が主流になって、結局インピーダンスミスマッチ的なことが起こってるんでしょうか
2012-03-07 11:23:36@nalsh 2022でしたっけ?わすれちゃったけど(ご免)。EUC(DEC code でもあるw。)から苦労してmbとのバランスは手探りで議論されたわけでね。 QT @nalsh: ISO 2021でなくISO 2022でしょうか。wide characterというかEUC用
2012-03-07 11:24:29@nalsh @yukihiro_matz しかし「バイト列」を扱っていれば済むという発想って、BiDiを持つ文化圏を考慮していないということもありませんか。そうか、プロトコルがASCIIだから話がややこしいのかしら
2012-03-07 11:25:54世の中、標準から離れてしまった、規格検討について批判を若いひとは簡単にするけど(wcとmb問題などね。)、当時は手探りであり、かつ、欧米ではまったく興味すらない世界だったのわ。これの一番の原因は、ちゃんとした論文/本を英語でかけないというジレンマね。 > @nalsh [X41]
2012-03-07 11:28:28@hutai 時系列的には、Σプロジェクト→EUC→DEC 漢字ですね。仰るとおり「マルチバイトのほうが正しかった」ってのはかなり後になってわかったことなので、後出しの話ではあります
2012-03-07 11:29:07@hutai EUCはΣプロジェクト絡みの日本での検討結果をAT&Tにフィードバックして、アメリカで作られたものなので、実は意外とやりとりがあったりしますよ
2012-03-07 11:30:22NO! これは絶対にいえる。1982のDECUS論文。DEC→EUC→UJISの順ですよ。 QT @nalsh: @hutai 時系列的には、Σプロジェクト→EUC→DEC 漢字ですね。仰るとおり「マルチバイトのほうが正しかった」ってのはかなり後になってわかったことなので、
2012-03-07 11:30:57