blog nullpage@my.opera.com

　どうやら最新の Opera では Opera 9.27 とはあれこれ異なる事が有って、以前使っていた設定がそのまま利用できないケースがあるように思う。そして、Opera Mail のフィルタ抽出条件にもそれが有る様に思う。フィルタを使うと 9.5x の軽快さが失われるので、当初は利用していたフィルタの殆どを削除してしまったのだが、RSSフィードが増えるとどうしてもまた使いたくなってしまう。

　以前、9.27 で試していた日本語メッセージの抽出だが、あれからメッセージの文字コードに加えて(代えて)全てのヘッダに「 =iso-2002-jp?」が含まれる事を条件にする事で良好な結果が得られる事が判ったのだが、これは 9.5x (RC2)では全く効果がない (なぜかヘッダにこの文字列を含まないいくつかの英文のメッセージが抽出された) 事が判った。

　これは良い方に解釈すると、比較時に生データではなく、エンコードを考慮した比較が行われるように改良されたと想像する事ができるが、実際はまだ良く判らない。仮にこれが事実だとすると、ヘッダだけではなくメッセージ全体でこの改良が有効になっている可能性もあるので、例えば文字コードで区別する場合にも Unicode だけを考慮すれば済むようになっているかも知れないのでチェックしてみる必要が有りそうだ。

　ところで、9.27 のメッセージを Opera 9.5x に移行する作業は以前書いたように Opera 自身にやらせたわけだが、これは注意事項に有るような少々のメッセージの重複が有る程度で、それ以外は殆ど完璧にできたように思っていたが、その後更に詳細にチェックしてみると、メールアカウント毎のフィルタビューに納まっていないPOPメッセージがかなりある事に気が付いた。これは変換の際に起きたのか、9.27 の時点で既にあったものか今はもう調べる事はできない (バックアップは有るがかなり面倒) のだが、とりあえず、すぐに判るものだけは手動で本来のビューへ移動させておいた。これらを入れ子のフィルタビューに自動的に振り分けるのは Opera Mail ではかなり面倒なのだ。

　その他に気が付いたのはヘッダ情報が失われていてフィルタリングできないRSSフィードメッセージがいくつか見つかった事。不要なメッセージだったので削除したが、どこでどうしてこんな事に鳴ったのか全く判らない。

　最後に、「ごみ箱のメールを削除するとメールサーバからも削除されるという重要な仕様変更」についてだが、これを実行すると、迷惑メールを削除した後に、メールパネルの下部に「サーバからメッセージを削除しています…」のようなメッセージが表示され、何件かのメッセージが削除されている様子が伺えたのだが、実際に適切なメッセージが削除されたのかどうかやや不安が残って気持のいいものでは無い。例えば、複数のPCで同じPOPアカウントをアクセスしている場合や、他のメールクライアントを併用している場合に、既にサーバにないメッセージをゴミ箱から削除する事もあるし、サーバからは既に削除しているが、クライアント側のローカルのメッセージは削除したくないと言ったことが有り得る。もちろん、ゴミ箱にあるPOPメールメッセージのうち、サーバにあるメッセージだけをゴミ箱を空にした時に削除してくれれば何も問題ないので心配する必要はないのだが…。

※先ほど nPOPuk でPOPサーバを確認したが、特に問題は無い様に見える (重要なメールが殆ど無いので何が有ってもそう見えてしまうのだが…)。

　大したネタじゃないのに何この長いタイトルは…。入りきらなくてえらい苦労した。でも、これで海外からのアクセスが増えるんだよね。また、「また騙されてわけのわからん日本語のブログ開いちゃったよ…」って人が増えると…。

　えーと、このブログではおそらく Opera Mail に関する愚痴が一番ネタとしては多いと思うんだけど、実は今回もそれ。で、世の中 既にOperaだったら9.51に鳴ってるのは承知しているし、それも既にインストールはしてあるのだけど (9.51RC3) 、まだ全然自分のOperaじゃないので、このネタも相も変わらず 愛用中の Opera9.27 を対象にしてる。とはいえ、今まで試した印象ではこのネタは 9.51 になっても引き続き有効だとは思う。

　前置き長いので本題へ。ちと前に Opera Mail で日本語メッセージを抽出するには? みたいなネタを書いたんだけど、そして、正規表現がどうなってるのか判らんと。というか、正規表現は公式ドキュメントにも書かれていて、先日もここでちょっと書いたように、「Ecma Script や Perl に準拠している (らしい)」ってとこまでは判っているだけど、それでも対象となる文書が複数の文字コードで構成される場合にはどのような扱いになるのか判らん…て事と、行とかヘッダとかのパーツの扱いがどうなってるのかも判らん…というところで終わらしてたので、今回この最初の判らんについてちょいとだけ試してみたのでメモしておく事にしたという訳。本題でも前置きが長い。

　で、今回試したのは、前述したように日本語メッセージの抽出のネタ。例えば、前回の投稿では (確認して無いので不確かだけど…) 正規表現のメッセージ全体検索で 「[あ-ん]+」 という条件にすれば大抵日本語ならひらがなが混ざっているって事で抽出できるんじゃないか…でもうまくいかんなぁ…。みたいな内容だったと思うけど、これは要点をまとめるとこんな感じになると思う。

　上のネタの要点

• Opera Mail で扱うメッセージは多くの文字コードが使われている。
  
• 日本語だけに限定しても 例えば SJIS,EUC,JIS,Unicode (UTF-8 UTF-16 etc.) のようにかなり乱立している。
  
• ひとつのメッセージにも各種ヘッダ、本文、添付ファイル(マルチパート)と多数の部分が有り、それぞれに別のコードが存在し得る。
  
• 上記のような特性のメッセージをひとつの条件で抽出する方法はあれこれあるが Opera Mail フィルタではどうやっているのだろう?
  

　と、思いつく範囲で書くと上記のようになると思う。今回はこれら全部の要素をひっくるめて試すのはあまりにも面倒臭いので、ひとつのメッセージにはひとつの部分しかなく、かつ、ひとつのメッセージにはひとつの文字コードしかない。という風に単純化して考えて試す事にしてみた。それに加えて抽出するメッセージはとりあえず (概ね) 日本語だけになるようにする方法という事にしてみた。それともうひとつ。対象メッセージはニュースフィード (RSSフィード)メッセージに限定した (メールはあんまし来ないからチェックできないし…)。

　ここで重要なのは、上記の要点の中の最後のひとつ、つまり、いろんな文字コードがある中で Opera Mail は与えられた抽出条件をどのように処理するのか…って事が一番問題になってくる。この手の方法でパッと思いつく方法を次にあげてみる事にする。

　上のネタの方法

1. メッセージはひとつのコードしかないと決めつける。伝統を重んじるからコードは全て7bit。日本語はJISに決ってる。他は知らん。
   
2. メッセージはひとつのコードしかないと決めつける。CP/M時代から日本語コードの決定番はSJISに決ってる。他は知らん。
   
3. 日本語何それ? コンピュータはASCII (ANSI)コードで十分。8bitは許すにしても他は知らん。(ここまでややネタ)
   
4. メッセージのコードに従って与えられた抽出条件 (正規表現) を変換して対処する。 やや面倒臭いけどこれくらい当然でしょ。
   
5. メッセージをひとつのコードに変換して与えられた抽出条件を適用して処理する。 時代は Unicode でしょ。javascript/DOMもコレ。
   

　さて、Opera Mail はどの方法を採用したか? さっそく試してみる。が、その前に、前述したように「[あ-ん]+」は通用しなかったんだよなぁ…。て事は駄目な方からチェックした方がイイ? いや、単に正規表現に日本語が使えないだけかもしれない。それなら数値を使えばいいやんか…。

Search count=1
Search Field= メッセージ全体
Search Text= [\u3000-\u3eff]+

　コレ、内部 unicode 統一って事が前提な…。時代の先端を行くOperaならやっぱこれでしょ…。

・結果→

　それなりにうまく抽出するようだが、あまりにも数が少ない。Operaネタが目立つな。やはり駄目。おそらくunicode (utf-8)なメッセージだけ抽出したのだろう。

　という訳で結局駄目な方からチェックする事にした。駄目な方ってのは、上記リストの 3) に近いかな? でも正規表現は確かなものという前提で。つまり、乱立している日本語の文字コードを全て抽出条件として与えてしまおうって事です。

Search count=4
Search Field=メッセージ全体
Search Text=[\u3000-\u3eff]+
Search Option 2=または
Search Text 2=([\x81-\x9f\xe0-\xef][\x40-\x7e\x80-\xfc])\1+
Search Field 2=メッセージ全体
Search Option 3=または
Search Text 3=([\xa1-\xfe])\1+
Search Field 3=メッセージ全体
Search Option 4=または
Search Text 4=\e(\(I|\$[@B]|\$\(D|&\e\$B)([\x21-\x7e])\2+\e\([BJ]
Search Field 4=メッセージ全体

　これはかなりいい加減だけど、unicodeのCJK領域 または SHIFT-JIS領域 または、EUC領域 または、JIS領域っていう風にすべて並行してチェックするようにした。ていうか、コード判定無い (つまり駄目なやり方) という前提でこうしたわけで…。

・結果→

　これはなかなか行けた。Opera Mail での日本語メッセージの抽出方法という意味ではうまく行ったと言っても良いと思う (JISコードの正規表現にはひとつもヒットしなかったけど間違ってるかな?)。でも、例えば 海外の何かしらのコードのメッセージがたまたまどれかに合致する事も有る訳で、そうしたらそれは素通りしてしまう事になる。実際にロシア語のメッセージが多少漏れて抽出されるのが確認できた。それで、最悪なのは、Opera Mail がメッセージのコードを見てそれに応じた条件を適用してくれない事がハッキリした事。当然、前のテストで統一した内部コードに変換している訳ではない事もハッキリしている訳で。そう言う意味じゃあ良いトコひとつもなしの最低って事になるね。ただ、救いは正規表現がちゃんと使えていそうって事くらいかな?

・総評

　これ、たぶん Opera9.51 でも変化は無いと思うんだけどどうなんだろ? それは置いておくとして、やっぱりなんとかして欲しいとおもうなぁ…。なんとかするとしたらどこをどうしたらいいだろうか?

• 部分毎の文字コードでそれ専用に変換した抽出条件を適用する
  　コレ、ハッキリ言って大変だと思う。文字コードがらみでメールの構造を考えるとメチャメチャ複雑だし。与えられた条件を相応しいものに変換といわれても固有の文字だと困る場合も有るだろう (そういうのもそれなりの対処法はあるだろうが…)。
  
• 内部コードを unicode に統一する。
  　コレ、一番いいように見えるけど、ニュースフィードはともかく、メールではそうは行かないだろうなぁ。抽出時に一時的に uniocodeに変換するという事も考えられるけど、面倒かもしれない。ただ、メッセージからDOMを作ってしまうという方法なら (XMLではないが…)、別のご利益も有るかもしれない。
  
• 正規表現を高度にする。unicode regexp ってのがあるけど、更にそれよりも進んだ大抵の文字コードや字種をクラスとして扱えるような正規表現を使う事ができれば他をいじる必要はなくなると思うが、そんな正規表現は少なくとも俺は知らん。
  

---

　その他にまだチェックしたいのは正規表現の「^」や「$」がどんな風に扱われるのかって事。例えば、メッセージ全体とか言ったら各ヘッダの先頭と末尾に一致するのか、とか、本文の改行に一致するのかとか…。これはおいおいチェックしてみる必要が有るかも?

　最後に感想だけど、仮に上記のような方法でそれなりに完全といえる抽出ができるようになったとしても、こんなんじゃあ素人は使えんと俺は思うね。あと、これとはまた全然別の話なんだけど、高速検索用にインデックス作成を動かすのに拘る理由がおれは良く判らんのよな…。この手のフィルタは予め用意しておけば、新着メッセージは到着する度に逐次抽出できる訳だし、バックグラウンドで勝手にCPUリソースを食らう処理をする必要も無いと思うんだよな。そうでなくて既存のメッセージアーカイブから抽出するにしても、プログレスメータなりを出してその間待たされた方が裏でコソコソされるよかナンボもマシだと思うんだよ。特に Opera Mailのようなメッセージマネージャだと、アドレスバーで文字を入力する度にサジェストが出るようなあれこれ凝った芸当を見せる最近のブラウザの流行とも無縁だと思うしね…。

※今後の未定なんだけど、mail ディレクトリにある lexicon.dat ファイルを眺めながら Opera Mail のインデックス作成時の語彙の抽出についてあれこれ愚痴るネタも考え中。以前の考察はやや的外れだった感じが有ったし。でも難しいな。このネタは俺の手には終えないと思う。あと、眺めたのはOpera9.27 だし。

　デフォルトの3時間毎の更新にして一晩放置してみた結果…。いまのところインデックスの乱れは見当らないが、フィルタの問題はどうやら9.5でも改善されていないようだ。

　まず問題なのは…英文だけの条件のフィルタに無関係な (殆ど日本語の) メッセージが混ざってくる事。とりあえずその余計なメッセージを選択して全てのヘッダ表示 (ニュースフィードではソースが表示される模様) して、更にCTRL+Fで抽出条件の英文を検索してみる事にした。すると…確かに有った。これはベース64エンコードかな? この中に偶然その英文が確かに含まれている…。生テキストから条件抽出とは…これはこれで便利な事も有るのだろうが要らん事すんなよ…。これをどうやって対処しろというのだ?

　そういえばこんな事も有った。Unicodeがらみのメッセージを抽出するために条件に「UTF」を含ませたのだが…これはエンコード指定で使われているのだ…。これは例えば抽出条件を「メッセージ全体」ではなく「件名」とか「メッセージ本文」にすればいいかというとそうでもないようである。マルチパートのメッセージの生テキストにはこの手の情報があちこちに含まれている。あれこれ複雑な条件にすれば対処できないくもないのかもしれないが、仮に可能と市手もどれだけの労力をが必要になるか判らない。

　そういえばOpera9.5ではフィルタからメッセージを削除してもビューだけが削除されるだけになってしまっている。この理由については理解しているつもりだが、ニュースフィード(RSS)の場合はメッセージ自体を削除したい事も有る。この場合はどうすればよいのか? これは単にデフォルトの削除ボタンやDELキーに「メッセージの削除= Delete」から「ビューから削除= Cut」のアクションが使われるようになっただけなのか、それともアクション自体の動作が変わったのか良く判らない (ショートカットの設定を見た限りではアクションの動作が変っているように見えるが…なぜそんな事を?)。ともかくデフォルトの状態ではフィルタビューからは元のメッセージを削除する事はできないようであった (Delete mail というアクションが有るがこれを使えば良いのだろうか?)。

　もうひとつ、フィルタ抽出条件の「正規表現」だが、ためしにこんな事をやってみた。俺がフィードしているたくさんのニュースフィードの大半が日本語以外である。だが、俺は日本語しか読めない。それでも海外のニュースフィードには面白い情報があるので流し読みしているのだが、気分的に日本語以外は見たくない事もある。そんな時のために日本語のみのメッセージを抽出するフィルタを作ってみる事にしたのだ。まずヘッダ情報に手掛かりが無いか確かめてみたが、エンコードがutf-8ではそれは無理なようであった。また、エンコード情報が取得出来なかったか何かの理由だろうか? 外国語のメッセージにSJISエンコード情報が吹かされているメッセージも有った。と言う事でこれはもうメッセージ本文で仕様されている文字のコードで判定するしかない。ともかく試しに ウェブページにおける javascript の正規表現の要領で全ての文字コードが unicode になっているものとして 「[\u3000-\u3fff]+」のような条件を登録してみた。だがこれは無駄であった。全く抽出されない。冒頭でも書いたように生テキストが対象になっているからだろうか…。と言う事はエンコードを意識しなければならないのか? 良く判らないがこれは難問である。次により単純に「[あ-ん]+」で試してみた。が、これでもやはり全く抽出されない。さらに単純な「。」を試してみると確かに日本語のメッセージが抽出できるようである。しかし残念ながら日本語以外のメッセージもたくさん抽出されるのであった。まだフィルタの (正規表現の) ル ールは闇の中だ。