mshibata

2008年2月11日2016年9月6日

2008-02-11

一部の人には発表する前に見つかってしまいましたが、一年以上前にテストを始めて、しかも半年近く止まったままだった掲示板を復活、正式に公開することにしました（トップページからリンクを張った）。ここを読んでいる人は雑談の感想でも書いてやってください。まだいくつかいじるところがありますが、あとは動かしながら手を入れていくことにしました。おかしなところに気づいたらご指摘ください。

テスト中に覗いていた人はブラウザのキャッシュを一旦空にしたほうがいいかもしれません。一時期へんなヘッダを吐いていたので。

掲示板にはウェブ・フィード (RSS) が付きました。RSS アプリケーションについては疎いので、フィードに入れてあるデータの内容や形式についてもご意見いただければ。

一段落したらソースを公開する予定です。

CGI のテストをしていてキーッ！となったこと

その一、Firefox は RSS 1.0 の description 要素を、二重に解釈してマークアップしたコンテンツとして表示する。つまり、

&lt;a href="http://example.com"&gt;サンプル&lt;/a&gt;

上のようなテキストを（これはマークアップですらないことに注目）、

サンプル

のように表示する。そもそもこれは規格を逸脱しているし、こういうことをやるために content:encoding があるんじゃないの？　掲示板の投稿データはテキストなので、はじめは description にテキストとして配信しようとしていたのですが、この実装を見て仕方なく content:encoding に入れることに。content:encoding あんまり好きじゃないんですけど。Mozilla の中の人は仕様にうるさいものとばかり思ってたら、基本的なところでなぜこんなだらしない実装にしてあるんだろう。

その二、email.Utils モジュールの parsedate 関数はタイムゾーン指定を見ていない。

>>> from email.Utils import parsedate
>>> parsedate('Wed, 06 Feb 2008 01:30:15 GMT')
(2008, 2, 6, 1, 30, 15, 0, 1, -1)
>>> parsedate('Wed, 06 Feb 2008 10:30:15 +0900')
(2008, 2, 6, 10, 30, 15, 0, 1, -1)

このふたつはどちらも同じ時刻なんですが、タイムゾーンの指定を無視して時刻の数字しか見てない。そうならそうとドキュメントに書いておいてほしかった……。formatdate と可逆だとばかり思ってたので、更新時刻の処理がどうしても合わなくて数時間悩んだよ。

2008年2月8日2016年9月6日

2008-02-08

雑談。

文字セットはブラックホールだ。

Python の文字コードサポートが整っているのは、Guido がヨーロッパ人だからなんだろうか。

以下うろおぼえにもとづく戯言。

ヨーロッパでは、ASCII の 128 文字に、アクセント記号付きアルファベットや各種記号などを加えた、8 ビット 256 文字の 1 バイト固定の文字コードを使っているのですが、困ったことに後半 128 文字の割り当てが規格によってばらばらで、しかもなまじ 1 バイト固定長のため、バイトの並び具合からの文字コードの推測が非現実的であるという問題があるそうで。ある意味これは Shift_JIS / ISO-2022-JP / EUC-JP の自動判別がそれなりの精度で効く日本語よりも深刻なわけです。だから、文字コードについてはアメリカ人がほんとにほんとにわかってないのだけ突出してるという状況なのかも。しかし影響力は大きいのでまたこれが。

で、ヨーロッパの事情からすると 8 ビット 256 マスのテーブルの「どこにどの文字が入っているか」という問題のとらえ方なので、「文字セット」という言い方がされるんじゃないかと思う。W3C の HTTP でも Content-Type: text/html; charset=iso-8859-1 ですよね。しかし日本語の文字コード事情からすると、文字集合（どの文字をどう並べた表を使うか）は JIS X 0208 なりなんなりで決まっていて、そのバイト表現（符号化方式）が違っているというのが問題になってくる。だから用語としては encoding のほうがしっくりくる（自分は）。encoding のほうが「文字の区点番号」と、その「区点番号のバイト表現」とを抽象化してるから、より一般的な概念じゃないかな。charset だとそこがまだ未分化な感じがする（文字の番号が即そのままバイト値）。

プログラムの変数名なんかは、encoding で統一してます。

Python では、

encode: 抽象的な概念としての「文字列」 → 具体的なバイト列表現; 例: u'いろは'.encode('shift_jis')
decode: 抽象的な概念としての「文字列」 ← 具体的なバイト列表現; 例: '¥x82¥xa2¥x82¥xeb¥x82¥xcd'.decode('shift_jis')

というレイヤーがはっきりしてる（言うまでもないけど、矢印の左側が unicode オブジェクトで、右側が str オブジェクトということになる）ので、「文字コードを意識したプログラミング」がやりやすい。

しかしどうも世のなかには「文字コードを意識しないプログラミング」をしている時に問題がもっとも起きにくいのが文字コード処理に優れたプログラミング言語であると考える方々もいるようで。

……などとえらそうなことを書いてたら、掲示板をテストしていて気づいたことを書く時間がなくなってしまった。