マスタカの ChangeLog メモ / 2008-02

■ Mew + Namazu (mew-nmz.el) [Mew]

「To: に masutaka at example.com を含む」または「ほげほげ」が含まれたメールを検索。

to=masutaka at example.com or ほげほげ

「To: に masutaka at example.com を含む」かつ「ほげほげ」が含まれたメールを検索。

to=masutaka at example.com and ほげほげ

cc=masutaka at example.com を使う場合は ~/Namazu/mknmz-inc.pl の $SEARCH_FIELD を修正
して、インデックスを作り直す必要がある。他にもパラメータを追加したほうが良いかもしれない。
mew-dist 28132 参照のこと。

インデックス作り直しに関連した話題をもう一つ。
Namazu-2.0.17 以降であれば `--decode-base64' が使える。メリットは以下の
とおり。こちらも mew-dist 28132 参照のこと。

・日本語のメールなんだけど、UTF-8 + Base64(Q も可) なものも検索できる。
・添付された MS-Word などの中身も検索できる。

■ メール本文に ISO-2022-JP を利用することになった背景 [電子メール]

mew-dist 355 (古い...) から一部抜粋。

仕様では通常、シンタックスとセマンティクスを定義します。
RFC822 では、ヘッダのセマンティクスもボディのセマンティクスも ASCII と
定めています。ASCII とは、0-127 の範囲を ASCII 表にある文字として解釈
するというセマンティクスです。ただ、RFC822 の執筆当時 Dave が気が付い
ていた犯しやすいシンタックス上の問題点(単一の CR など)は明確に排除しま
した。
日本で本文に ISO-2022-JP を入れたのは、シンタックス上は問題ありません
が、セマンティクスを破っています。ASCII 文字列中に ESC シーケンスが現
れても、それは単なる ESC シーケンスですから、日本語として取り扱われま
せん。また、ヨーロッパでは、本文に 0-255 までを許し、これを Latin-1 と
解釈することにしました。これはシンタックスもセマンティックスも破ってい
ます。しかし、所詮、日本で ISO-2022-JP を利用しようとした背景は、ヨー
ロッパが 8bit 領域を使っていたからにほかなりません。日本でも EUC Japan
を標準に選ぶ可能性はあったということです。

シンタックスは「構文」、セマンティクスは「データの意味」のことらしい。へぇ〜。
Gartner Column：第11回 そもそも「セマンティクス」とは何だろう？が参考になるかも。

追記20090405:
関連する話題があったので、貼り付けておきますね。

(URL: 日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か - スラッシュドット・ジャパン)

個人的には ISO-2022-JP で表現できない内容なら、Unicode で送るのはまっ
たく問題ないと思います。ただ上の記事にあるように、本文に 8bit 目を
使うのはシンタックスを破ることになるので、base64 符号化は必須です。

Shift-JIS や EUC-JP を base64 符号化せずに送るのは 8bit 目を使って
いるので論外ですが、じゃあ Shift-JIS+base64 や EUC-JP+base64 なら良
いの？と言われるとこれも NO です。ISO-2022-JP で送れば素直なプレー
ンテキストになるのに、無駄な符号化をしているので。

■ PIXUS 560i [未分類]

アマゾンのレビューを一気読み

プリンタなんてこのくらい小さいもので良かったんだよなあ。今のは大きすぎ。
でも使わないから、買い直すほどでもないよなあ。大きすぎる上に詰まっ
て使えなくなってしまったから、とっても邪魔。安く修理できたら売りたい。