Trackback

今日の「やっぱイジメたいです．とことんまで．」(2003-09-02)

今の実装では受ける時はcharsetパラメタ無視してUconvやNKFの推測におまかせだけど，ちゃんとcharset見るようにした方がいいかも．どちらにしろ，MTからTrackback受けるにはUconv必須ってことになりそう．ただでさえ高い敷居がもっと高くなっちゃうね． 以下，オレ個人の意見であって，tDiary Projectとしての意見ではありません． 今回の件で思ったんだけどTrackbackってやっぱMTのモノなんだね． 座談会でこの件について議論した人達もみんなMTユーザみたい．まぁもともとMTから発生したモノなんだから，MTのモノだと言っても間違いじゃないんだけろうけど，今やTrackbackに対応してるblogや日記CGIって他にいくつもあるのにねぇ． っつーかどうして「blog座談会」なのに ...

文字コードをUTF-8にしようといいだしたのはワタシなのですが、

1. そもそも異なるBlogシステムや海外のサイト等にTrackback Ping する際、相手のサイトの文字コードが何か、日本語対応パッチがあたってるかなどを考慮するのは激しくメンドウ。「文字化けして迷惑かけたらヤだな。。」とか考えながらPingするのも本末転倒。なのでTrackback の仕様自体で、文字コードを指定するのか、UTF-8の1本にするのかどっちかがいい。

2.HTTP POST で XML 返しといういまの REST な仕様下では、文字コードをパラメータ指定するのはあんまりキレイじゃない(Content-Type: text/xml で xml encoding="" にいれるならまだしも) ←とはいえこれは趣味の問題なのであまり大した理由にはならない

3.海外のサイトやすべてのツールに、charsetを読んで自サイトのエンコーディングに変換してもらうよう、 iconv 等をくみこんでもらうのは仕様としてオーバースペックではないか。というより1つの言語で複数のエンコーディングが存在するという状況を「UTF-8でいいじゃん」な国の人達に説得するのは大変 ;-)

大体このあたりを根拠にして、おくる方は UTF-8 きめうちがいいとおもったわけです。とはいえ一度提案した仕様である charset=utf-8 をパラメタにつけるというのもmilanoのパッチではのこっているとおもいます。

もちろん受け側がUTF-8 を解釈できなければならないという負担は増えるわけですが、EUC-JP <=> Shift_JIS のエンコーディング変換できるルーチンがあるぐらいなら UTF-8 もフツーできるんじゃないの？とかおもうのはスペックとして間違いですかねえ。。。

あと座談会の件ですがわたしともう一人とおる。さんはMTの他に Blosxom も使用してます。(Shibuya.pm も Blosxom でできています) というかわたしはこのBlogをはやくMTから脱却したい ;-) (移行の手間かんがえてひよってます)

座談会の内容についてもMTに特化した話はほとんど出てなかったですよ。むしろ、tDiary やはてなダイアリー、関心空間の話とか、なつみかんアンテナとかの話もしたような気がします。。 :-) 編集でどうなるかわかりませんが。

UPDATE 09/02 10:28
ただのにっき

そのためには、デコードのヒントになるcharsetは、きちんと指定できるようになっていなくてはいけない。元の発想が相手に迷惑かけたくないというのであればなおのこと、charsetは指定すべきである。「外国の作者に説明するのが大変」なんてのは、これを拒否する理由にはならない。

今日の「やっぱイジメたいです」

Ruby1.6系だと，Uconvというライブラリを持ってこないとUTF-8を使えないんですよね．その分ちと敷居は高いんではないかな．ということでこの部分は

3.海外のサイトやすべてのツールに、charsetを読んで自サイトのエンコーディングに変換してもらうよう、 iconv 等をくみこんでもらうのは仕様としてオーバースペックではないか。

ここと矛盾しているような… Ruby1.8系にはiconvが標準で付いてくるので，もっとRuby1.8が普及すればtDiary側の問題はなくなると思いますが．

作者に説明するのが大変、ってのは本来の理由ではないのはおっしゃる通りです。ちょっと言い訳じみてますね。すいません。

ただ、Ping先に迷惑かけたくないから charset をおくれ、ってのは微妙に自分の認識とずれますね。迷惑かけたくないから、とりあえずUTF-8でおくろう、というのが今の自分の意識です。ASCII な人たちに、charset からの文字変換パッチ実装しろ、っていうのと、UTF-8に移行しろ、っていうのはだいぶ負担が違うかなと。(そうでもないか。。)

素のMTやBlosxomは、Trackbackの文字コードがどうこうなんて気にしちゃいないので、受けとったものをそのまま格納して表示、です。他の海外製Blogツールも、調べてませんがそういう実装のものはおおいとおもいます。という状況でも、

「変換ツールをくみこまなくても、Trackback を UTf-8 でおくり、相手Blogの文字コードがUTF-8なら、文字化けしない」

というのはわかっているわけで。そういう「現状」があって一番現実的だし、かつ、charsetを指定するより実装が難しくなることはないのは、TrackbackをUTF-8限定にしてしまうことなんじゃないかな、という認識です。

もちろん、すべてのツールの作者がこのSpecを理解して、charsetパラメタからの変換をコアにくみこんでくれればそれでも全然かまいません。問題なのは、すでに実装があるということなのかもしれませんね。。。(新しく仕様をつくるなら、最初からこの問題を考慮してつくりますから)

複数の言語のPingを受けとっても、同一ページに混在させるときにはUTF-8等のUnicodeにおこさないといけないわけで、UTF-8強制の方が実装が楽(というか、実装すらしなくてもユーザの設定 = Blog のエンコーディングをUTF-8にする)で回避できる方が現実的なんじゃないかな、というだけのことですね。

UPDATE: 09/02 10:54

ちょっと考えなおしましたが、やはりたださん、きたさんがおっしゃるような、「UTF-8をはけない、読めない環境への/からのTrackback」 については、考慮がやっぱり必要ですね。

UTF-8を扱えるツール(A)は、

* 送信はUTF-8 とし、charset=utf-8 をつけて送信
* 受信時は charset をみて判断。なければ UTF-8 と判断(または自動判別も可)

UTF-8を扱えないツール(B)は、

* 送信はcharset=euc-jp などをつけて送信
* 受信はcharsetをみて、変換できなければ捨てる、ゲタなどの処理

そもそも国際化を考えていないツール(C)は、

* 送信はcharsetをつけず、Blogエンコーディングのまま送信
* 受信はそのまま格納して表示

こうなると、

* A → A: ○
* A → B: △
* A → C: ○ (C が UTF-8 なら)
* B → A: ○
* B → B: ○
* B → C: ×
* C → A: ○ (C が UTF-8 や latin-1 なら)
* C → B: ×
* C → C: △ (C同士が同じエンコーディングなら)

となるのでかなり改善しそうです。