漢字コードの歴史

なんでやねんDTP/おぢん @works014

[IVS][安岡孝一氏] / “新しいIVDと互換漢字の人名用漢字 | yasuokaの日記 | スラッシュドット・ジャパン” http://t.co/hf8SUmy3

K.Takata @k_takata

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

成瀬 @nalsh

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

成瀬 @nalsh

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

西村 賢🐠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 なんてアホな考えを思いついたのは日本人のはずである

森崎正人 @hutai

それがどうしたの？あほとはいえないとおもうが。UTF-8（Unicode)以前のISOでの2021アップワード互換上word単位は必須だったし。 QT @nalsh: ちなみに、最初に wide character なんてアホな考えを思いついたのは日本人のはずである

成瀬 @nalsh

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

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

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

森崎正人 @hutai

@nalsh 2022でしたっけ？わすれちゃったけど(ご免）。EUC(DEC code でもあるｗ。）から苦労してｍｂとのバランスは手探りで議論されたわけでね。 QT @nalsh: ISO 2021でなくISO 2022でしょうか。wide characterというかEUC用

西村 賢🐠Coral Capital / Ken Nishimura @knsmr

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

森崎正人 @hutai

世の中、標準から離れてしまった、規格検討について批判を若いひとは簡単にするけど(wcとmb問題などね。）、当時は手探りであり、かつ、欧米ではまったく興味すらない世界だったのわ。これの一番の原因は、ちゃんとした論文／本を英語でかけないというジレンマね。 > @nalsh [X41]

成瀬 @nalsh

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

成瀬 @nalsh

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

森崎正人 @hutai

NO! これは絶対にいえる。1982のDECUS論文。DEC→EUC→UJISの順ですよ。 QT @nalsh: @hutai 時系列的には、Σプロジェクト→EUC→DEC 漢字ですね。仰るとおり「マルチバイトのほうが正しかった」ってのはかなり後になってわかったことなので、