Adam Polselli ≫ Archivesにも、過去の写真と対応するカラースキームがのっているのですが、眺めていると、こんな色がこの写真ではこんなに使われているのだなー、と意外に思うことがあります。

私がラフをあげようとしたら、絶対に浮くか統一感が無くなってアウトになりそうな配色でも、写真で見るときっちり落ち着いて見えたり。なじませ方や調和のさせ方とか、写真は色々教えてくれそうです。

このサイト自体も、お手本にしたいサイトです。色合いはもちろん、分割比とかスペースのとり方とか。ありがたや。しかし日本語もAdam Polselli's 2005 Color Forecastくらい、きれいに組んでレンダリングしてくれないですかね…ブラウザ様('A`)

日本語は均等組みもできやしない…。http://www.crymson.co.jp/ir/さんなんかは、すごくきれいに文字組みされててびっくりです。

このサイトもフォントサイズやら文字送りやら色々試して現在に落ち着いたのですが…なんかドタバタした感じはぬぐえず。

そういえばMorisawaのGlyphGateはどうなったんでしょ。サーバあたり150万円以上という価格がネックなのか、トンと話を聞かなくなりました。

サンプルページを見ると、きれいにはきれいなのですが、慣れというものがあるからか、全て文字画像に見えてきてなんか気持ち悪い('A`)
それに、どこがテキストとして選択できるのかも良く分からんですし…あれ、でも、MacOSXで見れば、OTFフォント指定すれば似たように表示されるんだから、やっぱり慣れなのかな。

それか、SEOとかユーザビリティが注目されてきたときにサイト製作とか趣味でやり始めたので、「文字画像は悪！文字画像＝悪！」という声が無意識に刷り込まれているのか…。

こんな感じで表示されます。一番上は、何らかの熊ですか、これは。右側のキャプションはこれはどうやって作っているんでしょう。
CBSとかPBS側がもともとこういうものを持っているのかな。にしても、バラエティとかだとそんなかっちり出ないだろうし…。音声からこんなに正確に引っ張り出せるとも思えないです。なんなんでしょか。

しかし、正式版になるとAltaVista - Video Searchみたいになるんでしょうか。そうすると今後、もしGoogleが一般のVideoも扱うようになるなら、プライベートなものは、きっちりGoogleスパイダーから守っておかないと、気が付いたら流出みたいなことになりそうです。スターウォーズ少年みたいに。

こうして検索技術が発展して、日に日にWebの見通しが良くなっていくと、かえってパーソナルなサービスが増えていきそうな気がします。特に回線が細くてWebが一般的じゃなかった時代は、単純にWebサイト作って静かにやってれば、良きにつけ悪いにつけ、身内にしか知られないもんでした。鬱蒼とした森の中で頭にネクタイ巻いて裸踊りしても、めったに見つからないわけです。

けど、こうやって検索の精度や、Gooの最新ニュース検索みたいに、即時性が上昇していけば、どんどん見晴らしが良くなって、ちょっと妙なことしても誰かに見つかるようになってしまいます。安心して裸でタコ踊りしてたのに、うぉい気が付いたらハゲ山になって丸見えじゃん。みたいな。

そうすると、仲間内だけで安心できるようなパーソナルなサービスとか、同じ趣味同士でグループを作るような内向的コミュニティサービスが増えていきそうな予感が。

そんなことを考えつつ、花粉を呪う日々です。今年は地獄かも知れぬ…

現在の収益を表示したり、自販機の総売上が出たり。詳しくはリンク先を見てもらえれば早いと思われます。

しかし、ホントにこんな方法で操作するものなんでしょうかね…。嫌がおうにも道端で自販機のボタンをポチポチ押しながらメンテしてたら、とっくにばれてそうな気が。システムみたいなものが入ったのが最近とは言え、何か微妙です。

成功したとか、動いたとか一本を60ドルにしてきたとか、報告はチラホラ見るのですがどんなものでしょう。BoingBoingでは出展はAnarchist's Cookbookじゃねぇのかぃ、等と言っていたりもするので、そんな有名なら天下のコカ=コーラが放置するのも妙な感じです。

PLA Forumというところではコメントがぐいぐい伸びてます。

何か、"ランプが真ん中で光ったらもう一本！"を、目押しで会得しようとしていた小学校の友達T君を思い出した今日この頃。

ちなみに、子供の頃は、ジュース一本も大金だったから、妙に自動販売機に対して畏敬の念みたいなものが今でもあります。ジュース一本でビックリマンが3つ買えるし。カードダスは5枚ですよ。えぇえぇ。ジュース5本でミニ四駆変えます。そんな世代です。

お風呂のない家に住んでた時、銭湯通いだった訳ですが、集に一回だけ母親が買ってくれるコーヒー牛乳が美味でした。

しかし決して忘れないのは、好奇心で風呂屋のオンボロマッサージチェアを試した時。大人用のセッティングだから、めっさ痛かったです。ありゃ子供はやるもんじゃない、R指定だ('A`)

ColorPic

紹介されているのは、まずカラーピッカーのColorPic。今まで他のカラーピッカーを使っていてそれなりに満足していたのですが、こっちもなかなか。

まず、基本的なカラーをピックする機能はもちろん一通り網羅。拡大率も変えられる、画面下の拡大鏡で対象に合わせて、Ctrl+Gでピックします。一度に複数の色をピックできます。デフォルトで16個と十分。また、ここでこのソフトのよさげなポイントの一つがあらわになるのですが、ショートカット完備で、慣れればかなりサクサクと色が取れます。

起動して取りたい色のところに持っていって「Ctrl+G」
さらに、上のパレットは、ファンクションキーにそれぞれ対応していますので、F2を押せば、ワンタッチで2つ目のスペースに移動できます。そこでまた「Ctrl+G」でピック…そしてF3…Ctrl+G…F4…Ctrl+G…

こうして好きなだけ色をとった後、ファンクションキーでカラーを選んで、Ctrl+Cを押せば、カラーコードをクリップボードにコピーできます。これはかなり楽そう。特にキーボード派には良いのでは。

MWSnap

続いてのMWSnapは、いわゆるスクリーンキャプチャ。BMP, JPG, TIFF, PNG GIFで保存できたりするのがよさげ。しかし、標準のスクリーンキャプチャの、ボタン一発の楽さもすてがたし。結局すぐにPhotoshopにペーストしてトリミングしてしまうので('A`)

TopStyle"Lite"

つづいて、http://www.bradsoft.com/topstyle/の、フリーの方のTopStyle"Lite"。こいつは以前から使っていましたが、リアルタイムにスタイルを表示してくれるので便利です。ただ、日本語に対応していないこと、そしてCSSを書き換えるたびに、下のプレビューウィンドウが一番上に戻ってしまうことがかなり個人的に面倒です。いちいちさっき見ていたスタイルまでスクロールしないといけないという罠。これが改善されれば悪くなさげ。特にピクセル単位での調整やら微妙なカラー調整に良いと思います。

Web Developer Extension

そして、FireFoxとMozillaの拡張ツールバーWeb Developer Extension

こいつは文句なしに便利です。ツールバーから画像の非表示をしたり、スタイルの非表示をしたり、画像サイズを表示したり、JavaScript切ったり、おまけに一発でValidateに持っていってくれたりで、Webサイトを作っていて追加のツールバーに抵抗がない人には是非お勧めです。ちなみに後発類似品でWeb Accessibility Toolbarもあります。こっちはIE用。

最後のひとつは、accessify.comの、Accessibility Toolbox 。これは、アクセシビリティに優れたFormを自動的に作ってくれるもののようです。お腹がえらく痛いので未使用('A`)

寝る前に牛乳をパック半分のみ干したのが良くなかったのだろうか…。週明けの忙しいときにやる気が右肩下がりです。

おや？と思ってカラーピッカーで取ってみると、やっぱり違う。何だ何だと思っていると、不意に右下のプルダウンメニューに目が。

「Protanopy (1 % of men)」

いつの間にかデフォルトの「Normal Vision」から変えてしまっていたようです。
しかしこれはどういう意味だろうか…というわけで調べてみると、以下のような意味でした。

Protanopyとはいわゆる「赤色が見えない」状態
Deuteranopyとはいわゆる「赤色が見えない」状態
Tritanopyとはいわゆる「赤色が見えない」状態
Protanomalyは、「赤色の見え方がおかしい」状態
Deuteranomalyは、「緑色の見え方がおかしい」状態
Tritanomalyは、「青色の見え方がおかしい」状態
Full colorblindnessはいわゆる「全色盲」で、
Atypical monochromatismは世界が「モノトーンに見える」ということらしいです。
　＃参照：http://www.drallanpanzer.com/color_vision_diagnosis.htm

つまりこのカラージェネレータは、なんと、色盲の人達の見え方をシミュレートしてくれるものなのです。

いじっていて、こんな風に見えるのかと言う驚きと共に、ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0を不意に読み返したりと、いいきっかけになりました。自分にとっては、視覚で示されると下手な文章より説得力が大きいようです。

また、Vischeck: VischeckImageでは、手持ちの画像をアップロードして、色盲の人の見え方をシミュレートすることが出来ます。こちらもどうぞ。また、色盲の人にもわかるバリアフリープレゼンテーション法にある、神奈川県の 『色使いのガイドライン（PDF版）』も良い感じだと思います。

【追記】
大変ありがたいコメントを頂きました。誤訳を指摘していただきました。多謝多謝です。
誠に勝手ながら、有用な情報ですので、転載させていただきます。ご了承下さいませ。

---------------------------------------------------
凄く惜しい翻訳です。
全ては「色覚異常者の見え方」です。
日本には、赤緑色覚異常の第１色覚異常と第２色覚異常と青黄色覚異常と言います。
色覚異常を分けた「中波長領域＝色弱（弱め）〜色盲」が下記のようになります。

Protanopyとは「赤色色盲」
Deuteranopyとは「緑色色盲」
Tritanopyとは「青色色盲」
Protanomalyとは「赤色色弱（弱め）」
Deuteranomalyは、「緑色色弱（弱め）」
Tritanomalyは、「青色色弱（弱め）」
Full colorblindnessとは「全色盲（モノクロ）」
Atypical monochromatismとは「単色色盲（単色明度・モノトーン）」
です。
参考：色覚異常（色盲・色弱）http://www.wakaba-hp.or.jp/eye/eyesick_f/eyesick_13.html
参考：Wikipedia（色覚異常）　http://ja.wikipedia.org/wiki/%E8%89%B2%E8%A6%9A%E7%95%B0%E5%B8%B8

---------------------------------------------------

例えば、メールソフトやら何やらで一般的な、2カラムのデザインのことを、ここではOverview Plus Detailと称しています。一つのカラムは「概観・概要」で、もう一つは「詳細」というわけです。つまりはこのデザインを使っている理由は

The user has the large structure in front of them at all times, while being able to peer into the small details at will

ということを実現するため、と言う訳です。あくまで、詳細と概要を同時にユーザーが把握できるようにすることを狙った結果の2カラムだと。

言われてみれば当たり前のことですが、もし自分がUIを設計していて、何故この2カラムデザインを採用したのか？と聞かれたときに、サクっとこの様な回答が出せるかと言うとあまり自信が無い('A`)

言葉にしようとすると難しい。昔人に言われた「自分がデザインした要素全部、何でそれをそこにそうやって配置したのか説明できなきゃダメだ」という言葉を、不意に思い出して軽く冷や汗をかいてしまった自分。センスのある人は直感的に適切なものを選ぶのでしょうが…。

「様々な制約（使用される媒体のスペックとか、使うユーザー層とか）」の中で、ユーザーに「ある機能・便利さを提供するため」に、適切と思われるUIを設計する。という正当な流れをきちんと踏襲せねば。
UIデザインだけにとどまらず往々にして、放っておけば当初の思想から離れていってしまうものですし。伝統行事や慣習がよさげな例です。伝統行事には、果たして、何らかの形で思想なりが残っていたとしても、それが現在の常識で正当に理解できるのか、また、言葉で語ることの出来ない要素が多すぎる、という障害もありますので、一概に一緒には出来ませんが。

名前

MIME-tools

構文

MIME形式のメッセージを分析して、指定したディレクトリにMIMEコンポーネントを出力するという基本的なコードをいくつか書きます。

use MIME::Parser;
###パーサを作り、オプションをいくつか設定する。
my $parser = new MIME::Parser; $parser->output_under("$ENV{HOME}/mimemail");

### パースして入力
$entity = $parser->parse(\*STDIN) or die "parse failed\n";

### トップレベルのエンティティをチラッと見る。
$entity->dump_skeleton;

続いて、3つのパートを含んだMIME形式のメッセージを組み上げて、さらにそれを送信するコードを書きます。

use MIME::Entity;

###トップレベルの要素を作り、メールのヘッダーをセットする。
$top = MIME::Entity->build(Type =>"multipart/mixed",
From => "me\@myhost.com",
To => "you\@yourhost.com",
Subject => "Hello, nurse!");

### パート1　単純なテキスト
$top->attach(Path=>"./testin/short.txt");

### パート2: GIF画像
$top->attach(Path => "./docs/mime-sm.gif",
Type => "image/gif",
Encoding => "base64");

### パート3 いくつかの一般的な文書
$top->attach(Data=>$message);

### 送るぞ
open MAIL, "| /usr/lib/sendmail -t -oi -oem" or die "open: $!";
$top->print(\*MAIL);
close MAIL;

MIME::Toolsの各ページを見れば、もっと色々スクリプトの例が載っています。

記述

MIME::ToolsはPerl5のコレクションです。

これは、シングルパートないしマルチパート（ネストしている場合もある）のMIMEメッセージを分析したり、デコードしたり、生成する為のモジュールです。
（そうだよ少年、これは気味でもGIF画像を添付したメールを遅れるってことだよ。）

必要条件

MIME::Toolsを使うには、システムに以下の物が必要です。

File::Path
File::Spec
IPC::Open2 (オプション)
IO::Scalar, ... from the IO-stringy distribution
MIME::Base64
MIME::QuotedPrint
Net::SMTP
Mail::Internet, ... from the MailTools distribution.

これらの必須モジュールが入っているかどうか、また、そのバージョンがいくつなのかは、お手持ちのシステムのMalefile.PL等をご覧下さい。

クイックツアー

クラスの概観

一般的に直接扱うであろうクラスの概観はこんな感じです。

    (START HERE)            results() .-----------------.
          \                 .-------->| MIME::          |
           .-----------.   /          | Parser::Results |
           | MIME::    |--'           `-----------------'
           | Parser    |--.           .-----------------.
           `-----------'   \ filer()  | MIME::          |
              | parse()     `-------->| Parser::Filer   |
              | gives you             `-----------------'
              | a...                                  | output_path() 
              |                                       | determines
              |                                       | path() of...
              |    head()       .--------.            |
              |    returns...   | MIME:: | get()      |
              V       .-------->| Head   | etc...     |
           .--------./          `--------'            |
     .---> | MIME:: |                                 |
     `-----| Entity |           .--------.            |
   parts() `--------'\          | MIME:: |           /
   returns            `-------->| Body   |<---------'
   sub-entities    bodyhandle() `--------'
   (if any)        returns...       | open()
                                    | returns...
                                    |
                                    V
                                .--------. read()
                                | IO::   | getline()
                                | Handle | print()
                                `--------' etc...

図解すると、こういう感じで構文を解析しているのです。

"Parser"はMIMEストリームを解析します。

ParserはMIME::のインスタンスです。
これをファイルハンドルの様に、入力ストリームに持っていくことで、そのメッセージを解析できます。
解析が成功裏に終われば、MIMEエンティティが返されます。

解析されたメッセージは、エンティティとして表現されます。

エンティティとは、Mail::Internetのサブクラスである、MIME:Entity:のインスタンスです。
エンティティは、Content-typeやsenderやsubjectline等のメッセージヘッダーの情報を持っています。

エンティティの"body"部分は、メッセージデータの場所を知っています。

そのメッセージデータを読み書きするために、"open"することが出来ます。そうすることで入出力のハンドル（ I/O handle ）を持ってくることができるのです。

"body"を開いて、入出力ハンドル（ I/O handle ）を得て、メッセージデータを読み書きできます。

このハンドルは、IO::と基本的には同じです。ハンドルとファイルハンドル……これはどんなクラスでもありうるものです。それが、小さくて、基礎となっているデータソースへの標準的な読み書きの手順をサポートしている限りは。

2つのパートを含んでいる典型的なマルチパートのメッセージ（グリーティングメッセージとGIF画像）は、MIME::Entityのツリーになっています。それぞれのパーツもそれぞれMIME::Headを持っています。こんな感じに。

    .--------.
    | MIME:: | Content-type: multipart/mixed
    | Entity | Subject: Happy Samhaine!
    `--------'
         |
         `----.
        parts |
              |   .--------.
              |---| MIME:: | Content-type: text/plain; charset=us-ascii
              |   | Entity | Content-transfer-encoding: 7bit
              |   `--------'
              |   .--------.
              |---| MIME:: | Content-type: image/gif
                  | Entity | Content-transfer-encoding: base64
                  `--------' Content-disposition: inline;
                               filename="hs.gif"

メッセージの構文解析

まずはMIME::Parserインスタンスを作り、どこに抽出したファイルを置くかや、ファイルの命名ルールなどのパラメータを決めるところから解析は始まります。

そのインスタンスを、MIMEメッセージが待っている、読み取り可能なファイルハンドルに持って行きます。それが上手くいくと、Mail:Internetのサブクラスである、MIME::Entityを得ることが出来ます。これは以下のものを内に持っています。

• MIMEのヘッダーのデータを持っているMIME::Head。これはMIME::Headerのサブクラスです。
• メッセージの本文の場所を知っているMIME::Body。あなたは、これを"open"して読み取りることができます。データへのファイルハンドルをくれるのです。これはファイルハンドルと同様のオブジェクトです。そして、IO::Handleインターフェイスのサブクラスである限りどんなクラスでもあり売ります。

もし元のメッセージデータがマルチパートだったら、MIME::Entityオブジェクトは、空ではない"parts"のリストを持っています。それはそれぞれMIME::Entityを持っています（それはさらにネスとしてるかもしれません）。

内部では、パーサ(MIME::Parser)は、必要なときはMIME::Decorderインスタンスに、エンコードされたデータをデコードさせます。MIME::Decorderはbase64等のサポートしているエンコーディングから、デコード可能なインスタンスへのマッピングをします。このマッピングはnewやexperimentメソッドで変更を加えることが出来ます。また、それ自体でデコーダとして使うことが出来ます。

メッセージを組み上げる

メッセージの組み上げは、全てMIME::Entityを通じて行います。シングルパートのメッセージなら、MIME::Entity/buildコンストラクタで簡単に作ることが出来ます。

マルチパートのメッセージなら、まず MIME::Entity::build()メソッドトップレベルのマルチパートを作ります。そして MIME::Entity::attach() でパーツをくっつけていきます。
　 ※注意：私たちが「メールと添付したGIF画像」と思っているものは、実際は2つのパートを含むマルチパートメッセージです。一つ目はテキスト、2つ目はGIF画像です。

MIMEエンティティを作っているとき、二つの重要な情報を与えてあげないといけません。 content type と content transfer encodingです。これは直接にファイルのタイプを決めます。例えば、 HTML file なら text/htmlです。もう一つの、 encodingは、しかしながらトリッキーです。例えば、7bit-compliantなHTMLもあれば、非常に長くて、信頼性を得るために quoted-printableで送られないとまずいものもあります。

メールを送る

MIME::EntityはMail::Internetを継承していますので、それを使ってメールを送ることが出来ます。例えば

$entity->smtpsend;

エンコードとデコードのサポート

MIME::Decorderクラスは同様にエンコードすることもできます。これは、MIME::Entityを出力するときに行われます。全てのスタンダードなエンコードがサポートされています（詳細に関してはをMIME入門書をご覧下さい）

    Encoding:        | Normally used when message contents are:
    -------------------------------------------------------------------
    7bit             | 7-bit data with under 1000 chars/line, or multipart.
    8bit             | 8-bit data with under 1000 chars/line.
    binary           | 8-bit data with some long lines (or no line breaks).
    quoted-printable | Text files with some 8-bit chars (e.g., Latin-1 text).
    base64           | Binary files.

あなたが与えられた文書に対して、どのエンコーディングを選ぶかは、主に（１）あなたが文書の内容（テキストなのかバイナリなのかとか）について何を知っているか、（２）7ビット通信を行うインターネットでの電子メール送受信において、信頼できるメッセージを必要とするか、次第です。

一般的には、 quoted-printable で base64 なものだけが、保障できる信頼性のある送受信データです。他の三つ、まず no-encodingはただ単にデータを送ります。そのデータが1000行未満の7ビットASCIIであり、マルチパート境界でコンフリクトを起こしていない限りにおいて、信頼できます。

私は、 content-type と encodingを。ファイルパスから自動的に推定できるように作ったつもりですが、問題もあるようです…少なくともMail::capは…。

メッセージのロギング

MIME::Toolsは様々な外部からの入力を扱う、複雑なツールキットです。ロギングは、裏で本当なにがおこなわれているかを知る助けになります。MIME::Tools自身で記録しているメッセージがいくつかあります。

Debug Messages

STDERRに直接、 "MIME-tools :debug "という接頭辞をつけて出力します。あなたがDebuggingするように設定しない限り、ログは出力されません。

 

Warning messages

異例の事態になったときに、標準のPerlがwarn()で出すものと同じメカニズムで記録されます。 $^Wが真で、MIME::Toolsがquietに設定されていなければ記録されます。

Error Messages

何かが失敗したときに、標準のPerlがwarn()で出すものと同じメカニズムで記録されます。 $^Wが真で、MIME::Toolsがquietに設定されていなければ記録されます。

Usage messages

上の”典型的な”ものとは違って、データ処理や使い方の警告です。あまり良くない使い方や怪しげな呼び出しを開発者に警告します。$^Wが真で、MIME::Toolsがquietに設定されていなければ記録されます。

MIME::Parser（ないし内部のヘルパークラス）が上記のようなメッセージを伝えたいとき、上の様な関数が呼び出される前に、即座にMIME::Parser::Resultオブジェクトが呼び出されます。つまり、各Parserはそれぞれ独自にトレースログを持っているということです。

ツールキットを設定する

debugging

デバッグのオンオフを設定します。デフォルトはオフです。 （例　：　MIME::Tools->debugging(1);　)

quiet

warningとerrorメッセージの報告をオンオフします。デフォルトはオンです。 （例　：　 MIME::Tools->quiet(1); )

version

MIME::Toolsのバージョンを返します。（例　：　 print MIME::Tools->version, "\n"; 　)

THINGS YOU SHOULD DO

(省略)

THINGS I DO THAT YOU SHOULD KNOW ABOUT

(省略)

MIME入門書

MIMEを解析しなければいけないけれど、詳しいことが良く分からない…大丈夫です。

用語集

ここにあるのは、RFC-1521に適合した専門用語についての定義です。それぞれは同等のMIMEモジュールを携えています…。

atattchment

"atattchment"マルチパートに関して、一般に広まっている俗語です。「これが前に約束してた画像だよ」みたいなメッセージは、これには含まれません。システム上は、単なるトップレベルのエンティティの下にあるMIME:Entityです。恐らく、partsの中の一つになっています。

body

エンティティの"body"とは、ヘッダーと、実際のいわゆる”メッセージ”を含む部分です。例えば、GIF画像の添付書類があるなら、そのGIFファイルのbodyは、 base64によってコード化されたGIFファイルそれ自体です。bodyはMIME::Bodyインスタンスによってあらわされます。bodyhandle()メソッドを使って実際のメール本文を得ることが出来ます。

body parts

マルチパートのエンティティのパートの一つなので、"body parts"はまた、bodyとheaderを持ちます。なのでこれで"bodyのbody"というということの意味が分かりますね。bodyはエンティティとほぼ同義です。もちろん、MIME::Entityインスタンスです。

entity

エンティティは、メッセージ部分か、body partsのどちらかを意味しています。すべてのエンティティにはheaderとbodyがあります。エンティティはMIME::Entityで表されます。
エンティティからheader(MIME::Header)とbody（MIME::Body）を得るメソッドがあります。

header

MIMEメッセージの一番上にあるものです。これは "Content-type", "Content-transfer-encoding",などを含んでいます。全てのMIMEエンティティはMIME::Headerで表されるヘッダーを持っています。headメソッドで、エンティティからMIME::Headerを得ることが出来ます。

message

一般的に、messageはネットワークで伝達されている、完全に（ないしトップレベルが）テキストであるものを意味します。
現在、"messages"をきちんと明白に定義するパッケージは、MIME::にはありません。messageとは、ファイルやファイルハンドルから読まれうるデータのストリームです。あなたは、MIME::Parserで返されたMME::Entityを、messageの全てであるとして扱えます。

Content-types

これは、通常どんな形式のデータがMIMEメッセージとして示されるかを、 majortype/minortype と言う感じで記述したものです。主要なものは以下の様になっています。より包括的なリストは、RFC-2046で見つけることが出来るかもしれません。

application

他のカテゴリーにはまらないデータで、特にアプリケーションで処理されるもの。

audio

オーディオ。

image

グラフィックスデータ。

message

通常のメッセージ、メールまたはMIMEメッセージ 。

multipart

他のメッセージを含むメッセージ 。

text

人が読むことになっている、文のデータ。

video

ビデオかビデオ+オーディオデータ。

Content transfer encodings

これは、メッセージのbodyが安全な転送のためにどのようにパッケージされるかということです。主要な5つのMIMEエンコーディングが以下に挙げられています。より包括的なリストは、RFC-2046で見つけることが出来るかもしれません。

7bit

コード化が全く行われません。 このラベルは8ビットの文字は一切無いことを主張し、改行コードを含んだ文字数が1000を超えないことを主張しています。

8bit

コード化は全く行われません。このラベルは8ビットの文字があるかもしれないことを主張し、改行コードを含んだ文字数が1000を超えないことを主張しています。

binary

コード化は全く行われません。このラベルは8ビットの文字があるかもしれないことを主張し、改行コードを含んだ文字数が1000を超えるやもしれないことを主張しています。まずメールゲートウェイを通り抜けられることは無いでしょう。

base64

スタンダードなエンコーディング。(それは任意の2進のデータを7ビットのドメインにマッピングします)。 非ASCII文字を含むメッセージ(例えば、ラテン語-1、ラテン語-2、またはいかなる他の8ビットのアルファベットも)をコード化することの役に立ちます。

quoted-printable

スタンダードなエンコーディング。(それは任意のline-orientedのデータを7ビットのドメインにマッピングします)。非ASCII文字を含むメッセージ(例えば、ラテン語-1、ラテン語-2、またはいかなる他の8ビットのアルファベットも)をコード化することの役に立ちます。

MT - Movable Type

概要にはMTクラスは、MT関連ライブラリーの上位のクラスです。このライブラリは全てのリビルド作業をします。他のMTの機能はMT::AppとかMT::App::CMS等を使います。とあります。また、MT関連のモジュールを使用する場合は、まずはこのモジュールで対象のMTを読み込むのが普通な予感。

で、インスタンスを作成。この時自動的にカレントディレクトリからmt.cfgを探して設定を読み込みます。もしmt.cfgがデフォルトと違うところにある場合は、Configでディレクトリを指定します。これで、$mtというMTインスタンスを通じて、対象のブログを操作することが出来るようになります。

つづいてリビルド関連。

こんな感じにすると、$blog_idに対応するブログを(IDはMTの管理画面で確認)リビルドし、コールバックでサブルーチンを呼び出します。この場合は、何番目の記事が現在リビルド中なのか出力されるはず。

また、どのアーカイブをリビルドするかとか、インデックステンプレートをリビルドするかどうか等オプションがあるようです。

ArchiveType　:　リビルドしたいアーカイブタイプを指定。
NoIndexes　:　インデックステンプレートをリビルドするか。
Limit　:　リビルドを最後のNUMエントリーにしぼることができる。
Offset　:　MTのタグと同じで、最後のNUM個をリビルドしないことができる。

リビルドはエントリー単位で行うことも出来ます。この辺は MT::Entry で。テンプレートのリビルドもMT::Templateで。ちなみに、どちらもそれぞれのオブジェクトを引数に取って、$mt->rebuild_entry( %args )
とか$mt->rebuild_indexes( %args )とかすればOKそうです。

また、他にも色々あります。
text filterとか。プラグイン作るときに出てきたグローバルフィルターとか絡みだろうか。しかし結構シンプルにまとまっていてなんかワクワクしますな。今のうちにワクワクしておこう。どうせそのうち土ツボに嵌まるだろうし。

MT::Entry - Movable Type entry record

MT::Entryは、MTドキュメントのMT::EntryのDESCRIPTIONによると、これを通じてエントリーの本文とさらに作者やカテゴリーなどのメタデータを操作できるもののようです。MT::Entryは、MT::Objectのサブクラスなので、基本的な部分はMT::Objectから継承しています。なので、まずはMT::Objectを見てみることに。

MT::Objectは、MTが蓄積しているデータをあらわすクラスらしい（何かうまく日本語に出来ない）普通はそれはRDBに置いてある。SQLとか。BerkleyDBとか。MTは基本的にはデータがどのようなメカニズムで、技術で蓄積されているかについては全く関知せず、そこにどんな名前（？）のデータが入っているかだけ知っているようです。

んで、実際のデータ蓄積メカニズムは、MT::ObjectDriver 次第だそうで。
このように独立させていることで、色々なデータベースに対応できているそうな。

このMT::Objectをベースにして、いくつか独自のメソッドやらを付け加えたのがMT::Entry。なので、MT::Entryに載ってないメソッドとかがあったら、MT::Objectにさかのぼって調べればよさげ。スーパークラスって奴ですか。MT::Objectについてはそれ以上今回は突っ込まない予定。突っ込む前にクラスとか復習しないと玉砕必至('A`)

エントリーを投稿する場合

と言うわけでMT::Entryに戻ります。エントリー投稿までのサンプルスクリプトはこんな感じで書かれています。
　＃コードはMT::EntryのSYNOPSISから引用

その他にもMT::Entryには色々とメソッドがあるようですな。多いのは、既存のエントリーから情報を引っ張ってきたり、編集したりすることだと思うので、ちょっとその辺りをついでに探ってみたいと思います。

エントリーから色々読み出してくる場合

まずは、さっき作ったようなMT::Entryインスタンスを読み込んできます。loadメソッドを使います。まずは基本形。

この中で、CLASSはここではMT::Entryです。\%termsは、この場合EntryIDを入れれば、エントリー単品が対象になります。BlogIDを入れると、エントリーのリストが返ってきます。

\%argumentsは、様々なオプション（direction => "ascend|descend"　、limit => "N"等など。MT::ObjectのLoading an existing object or objects辺りを参照）

なので例えばブログのタイトル一覧を10件出力するには

と言う感じでエントリーを読み込んで、作成日時で (sort => 'created_on')、降順 (direction => 'descend')に。10件分のタイトルを出力できます。このあたりはTechknow Movable Type: Movable Type Perl API Hacks その1 - MT API の基礎にしっかり載っていました。ありがたや。ちなみにMTインスタンスは、明示的にConfigでmt.cfgの場所を指定しておいたほうがよさげです。

また、例えばオブジェクト（エントリー）の数を数えるにはこんな感じ。

他にもありそうですが、今回はこんな感じで。ちなみにこのMT::Objectのloadメソッドはエントリーから情報を読み出すほかにも、MT::BlogやMT::TemplateやMT::Author等のインスタンスといった、MT::Objectを上位のクラスに持つものから情報を引き出せます。

MT::Imageは、$img->scale(%arg)くらいなので、まぁなんとかなるかな、と言う感じでパス。というわけでようやくモジュール終わり('A`)

連休中に終わると思った自分が馬鹿だった…。

しかし250cc単気筒。250ccオフロード車では最大のパワーがあるとは言えなかなか高速巡航は疲れます。慣らし中で（出発時わずか走行500km強）あまりスロットルを開けられなかったせいもあると思いますが。
　　#右は小田原サービスエリア

しかしドンドンドンドンという…低速から中速でのエンジンが力強く地面を蹴ってる感じが、かなり自分は好きです。

さて、何はともあれ箱根の入り口小田原に到着。しかし、小田原厚木道路を走っていたときから感じてたんですが、明らかにどんどんどんどん寒くなってる。標高が上がってるからか分かりませんが、日があたっている場所はいいんですが、日陰が凄く寒い。箱根は標高1000mは楽に越える場所が多いので、なかなか不安です。一応かなりウェアは着込んできたんですが、なんせ初めてで。思わずホッカイロを買い込んでしまった('A`)

さてしかし。ひとたび箱根に入ってしまえば快晴という恵まれた天候と景色のおかげで気持ちいいこといいこと。年末ということで結構混んでるかと思ったのですが、癒すいてる空いてる。左の写真は3枚ともターンパイクの頂上にある、大観山付近。しかし山の天気は変わりやすい、って奴なんでしょうか。大観山で写真を撮っていたら、雪がちらほら。そんなに寒くないし何より空は晴れてます。しかし椿ラインに下るまで、SAで休んでいるときも延々と降ってました。なぜ？時差？

箱根の峠道は走る人達がたくさんいると覚悟していたので、免許取り立てとしては正直ありがたかったです('A`)
箱根ターンパイクは対向車含めて大観山まででせいぜい３台くらいで。バイクにいたっては、大観山で止まっていたハーレーの人とゼファーの人だけでした。芦ノ湖付近まで下ると、ビッグスクータとか結構いるんですけどね。

さて、そんなこんなで雪降る大観山を後にして、ワインディングのメッカらしい椿ラインに入ります。（道が分からなくて、間違ってターンパイク戻ったり箱根新道方面に出ようとしたりしたのは秘密）ここは春には椿がきれいなので、椿ラインという名前らしい。

しかし走ってみるとひたすらワインディングなので、もし春に来ても椿を見ている暇はなさそう。走るのは確かに楽しいです。かなり。ここでも全然バイク会わなかった。途中の休憩所みたいなところに何台か止まっていただけでした。車もやっぱり3台くらい。ただ何台か道の途中に止めて写真を撮っていたりします。これが怖い…何せカーブ出口にいきなりワンボックスが鎮座してたりするわけです。せめて見通しのいいところに止めて('A`)

さて、こんな感じで一通り楽しんだ頃にはすでに16時過ぎくらい。実は昼飯もまだだし、チェックイン予定時刻も迫っているので、途中の箱根の道の駅で軽くうどんを食べて、小涌谷の宿に向かいました。何より寒くなってきたし。

珍しく迷わずに宿に到着したころにはもう日が落ちかけで寒かった…。しかもアップダウンの激しい峠道が続いてなかなか人間にもバイクにもきつい。というか現地の軽トラがえらい飛ばす飛ばす。なんか追い回されてるみたいな気がしてつられて飛ばして疲れました。

宿に着いたらすぐにそばの小涌園ユネッサンで温泉三昧。軽くビールを入れてさくっと睡眠。ちなみに素泊まりなので夕食はコンビニonz

だって、ユネッサンのレストラン劇混みで入れそうに無い…。いや、煮込みハンバーグおいしかったですよ、えぇえぇ。っていうか強羅のコンビニに行くまでにえらい迷ったし。強羅ってアップダウンが凄いです。セカンドギアでエンジンブレーキひたすらかけて下ってたんで、結構うるさかっただろうなぁ。ごめんなさい。

ちなみにKDDI EZナビウォークを結構使いました。コンビニ探すのにもネ。パケット代やら追従性を考えるとカーナビ的にはきついです。それから、起動までえらい時間がかかる上に、スリープさせておいたりできないので、結構イライラします、当たり前ですが、ガーミンのGPSとかには全然かないません。ただ、迷ったときに現在地を確認するには結構よさげ。座標付きの地図とメモ用紙と併用すると幸せになれると思います。

2日目

ぐっすり寝て、ホテルで朝食を取ったら即チェックアウトしてバイクにまたがります。まずは目指すは大涌谷。ここはいわゆる温泉地。硫黄が吹き出すわ溶岩みたいなのが転がってるわな愉快な場所です。

そばに近づくと硫黄の匂いがぐわっと。朝方ですが結構人はいました。スピーカーから流れる大涌谷の説明テープは、なぜかドラゴンボールの悟空の声、と言うか野沢雅子だった。金がかかっている。箱根。変なところに。

ぐるっと回って駐車場にバイクを止めるまもなく前方には噴煙が…。もくもくどころか何か凄いです、これ。こんなにもくもくしてるとは。そして、ここぞとばかりにそこらじゅうで売ってる温泉タマゴを食べようと思ったのですが、これが8個単位でしか売ってない…一人でそんなに食べたらえらいことになりそうだ。

時間が立つにつれて人も増えてきたので撤退。ルートは全く決めていなかったので、その前に次なる目的地とルートを決める。時間に余裕があるので山中湖経由で帰ることに決定。途中にある仙石原に向かう。行き当たりばったりの旅に、小回りの効くバイクは最適だと。個人的には思います。

仙石原はなんというか、ススキの海です。突然目の前が開けたかと思うと目の前に肌色の海が。何かと思った…。ミステリーサークルがきれいに作られそうな感じです。緩やかに山のほうまで道が続いていて、ずんずん上がっていったのですが、途中から獣道になってきたので撤退。それを見て後ろから来た人たちも身を翻して撤退。……自分は毒見役か。しかし上から見下ろすススキ畑はかなり気持ちいです。是非是非。

さて、ここから山中湖までしばらく北上して山中湖に出ます。正直ここからはきつかったです。富士山の西側に来たくらいから、どんどんどんどん寒くなる寒くなる…天気もふるわず震えながら峠を下っていました。山中湖半が一番厳しかったです。標高は1000キロくらいであまり箱根と変わらないのに全然違う。

ほうとうを食べようと思っていたのに、もはや降りる気もしない。とにかく暖かいところに行こうと思って、急いで道志みちへ入りました。もう寒くて写真取ってる余裕ナシ。とかく山中湖半は風通しが最高にいいので、湖の上で冷えた風がビュンビュン吹き付けてきます。こいつのまえじゃホカロンもただの粉。

道志のワインディングを下っていると、それほど標高は変わってないのにあったかくなっていく…日もだんだん差してきました。途中の道の駅で休憩。ようやっと撮影する気になって一枚。ここには結構バイクがいました。自分が来たときに入れ替わりにDucatiが数台。駐輪場に写真のCB400SFとカワサキの大型（わからん）が2台。自分が買えるときに入れ替わりでDT230と何かが一台。

道の駅でトン汁をすすり、何とか体温を回復。そのまま道志道を下っていると、完全に晴れ。何か山中湖周辺だけおかしかったような。富士山付近は次から気をつけないとまずいですな('A`)

そしてそのまま道志を下り、途中で県道76号、山北藤野線にはいります。相模湖に向かうためです。

しかし、この76号がひたすらにブラインドブラインドブラインド…かなりのカーブにミラーが付いてる有様です。車の数が少なかったからいいですが、カーブのたびに何か飛び出してくるんじゃないかとハラハラ。

この辺は自転車や一般人も通るので、エンジンの音がしなくても要注意でした。景色は割と開けてきれいですが、気にしてる余裕は少なくとも自分には無かった…。そして相模湖に到着、あとは甲州を通って東京に帰りました。

甲州と吉祥寺が馬鹿混みでえらい疲れましたが…あまりに動かなくて、井の頭でついに歩道を押し歩いたし。。一泊ツーリングは朝から走れるので楽しいです。早くあったかくならんかなー。 全走行距離350kmでした。

ではでは、最後まで読んでいただいて、長々とありがとうございました(^-^)

最初に、読み込みモジュールやら定数宣言。POP3サーバの情報はconstantで定数にしておきます。この辺はお好みで。

そして、

さっそく分からんです…"[]"はいったい何だ。

…気分転換にコンビニに行ってきて再開です。
cpanのMIME::WordDecoderドキュメントのを見ると、こういうコードがありました。

このコードについての、cpanドキュメントから引用すると、MIME::WordDecoderはA MIME::WordDecoder consists, fundamentally, of a hash which maps a character set name (US-ASCII, ISO-8859-1, etc.) to a subroutine .だそうです。

つまり、MIME::WordDecoderインスタンスを作る際に、そのインスタンスを使ってMIMEデコードする際、各Charsetごと、に処理させるサブルーチンを設定しておく必要がある模様。そして、KEEPやらWARNやらDIEはすでに定義されたサブルーチンで

KEEP 全てそのままスルーする.
IGNORE 特に警告を出さないまま消して、無かったことにする
WARN 警告を出しつつ消して、無かったことにする。
DIE 文字セットを扱えませんというエラーを発する・

となっているようです。
&keep7biは、このCPANドキュメントのサンプル内で定義しているサブルーチンです。
つまりこの場合、
「US-ASCIIはそのまま変換なし」
「ISO-8859-1（US-ASCII にラテン1拡張を加えたもの）は&keep7biサブルーチンで処理」
「ISO-8859-2（US-ASCII にラテン1拡張といくつかの記号を加えたもの）は&keep7biサブルーチンで処理」
「Big5(いわゆる中国語とか)は警告を出しつつ消して、無かったことにする。」
「その他はエラーを出す」

という意味のようです。すると、

って云うのは、とにかく全てjcodeでsjisに変換しろということではなかろうか…と判断。
　　＃ちなみにJcodeについてはJcode - Japanese Charset Handler参照

[]は分かりません…。無名ハッシュへのリファレンスって解釈でいいのだろうか。でも、cpanの方だと、{}になっている。分からん。保留。

とりあえずこの部分は、MIME変換のデフォルトを「jcodeでsjisに変換」に設定した、という部分だと思います('A`)

ログインとヘッダの処理

続いて。

ここは、Net::POP3の基本的な奴で、出力先を"pop3"ディレクトリにして、POP3サーバに接続して、ログインしてメールのリストを取得するところ。前回このあたりは探ったトコです。Moblog設置ドキュメンタリー[その1]：：[7korobi8oki.com]

続いてのforeachブロックは、

MIME::Parserでパースされたメールデータは、MIME::Entityクラスになって、様々なMIMEクラスのメソッドで、情報を取り出したり入れたりと操作できるようになります。
なので、続いてヘッダの情報を取り出すのに、めんどくさい正規表現などを使うのではなく、MIME::Entity::headrメソッドを使うだけで、事が済むようになります。モジュール万歳。
こうして、ヘッダを$oHeadに代入。

ちなみに、この結果$oHeadは、MIME::Headerインスタンスになっています。MIME周りのクラス郡は、それぞれ適切なクラスとして生成されるようになっています。MIME-toolsのドキュメントに図解が載っています。

MIME::HeaderインスタンスであるoHeadからは、getメソッドで簡単にヘッダ情報が取り出せます。
なので、From、To、Subjectのヘッダ情報を取り出し、各変数に代入。

この時点では日本語になっていないので、MIME::WordDecoder::unmimeメソッドで日本語に。
unmimeメソッドはデフォルトに設定したMIME変換を適用するメソッドです。デフォルトの変換とは、さっき設定したjcodeの奴です。

メールデータ→MIME変換→日本語変換、という三段階が日本語などのマルチバイトには必要みたいです。

MIME::Toolsに含まれる、ParserとかHeadとかBodyとかEntity等が上手く連携して出来てるのね…。
これで、ヘッダはOK。

本文の処理

続いて本文。このスクリプトでは、PrnContサブルーチンで処理。

引数を２つ取る。一つ目の$oEnt は先ほどMIME::Parserでパースされたデータですな。２つ目は、マルチパートかシングルパートかのフラグか。指定が無ければ自動的に0が入る。ちなみに先ほど$oEntからheaderメソッドでMIME::Headerオブジェクトを作りましたが、別にそれで元のMIME::Entityである$oEntからヘッダ情報が消えたわけではないです。コピーのコピーみたいな感じでしょうか。

さて、MIME::ParserでパースされたデータはMIME::Entityインスタンスなので、MIME::Entityのメソッドが使えます。MIME::Entity::is_multipartメソッドで、データがマルチパートかどうか判別できますので、これを利用します。

SinglePartの場合

シングルパートだったら、以下のようにしてから、jcodeでshift-jisにする。

$oEnt->bodyhandleメソッドは、MIME::Entityインスタンスから、いわゆる本文部分をMIME::Bodyとして引っ張り出せるものです。
単純にやるなら"$bodyh = $ent->bodyhandle;"などとやれば左辺に代入されます。
そいでそれをMIME::BODY::as_stringメソッドを使って、文字として取り出します。
これでメールのの本文が、日本語として取り出せました。

このあたりのメソッド群は、cpanのドキュメントの色んな所を見なきゃいかんです('A`)。MIME::BodyのとこやMIME::Parserのとこや、MIME::WordDecoderのとこやらMIME::Headerのところやら。

MultiPartの場合

つづいてマルチパートです。
マルチパートは、階層構造になっている場合があるので、その時の為に、再帰処理をします。
そしてそうでない、ないしそうでなくなった場合、改めてマルチパートの種類を確認します。

具体的には。MIME::Entityのpartsメソッドで各パートにアクセスし、mime_typeメソッドで種類を確認。

っていうところ。これが
1)text/plain　だったら、シングルパートと同じ処理

2)text/html　だったら、やっぱり同じ処理。

3)そのほかだったら、pathメソッドでローカルに保存。返り値のパスを表示。
　　＃メソッドについてはsearch.cpan.org: MIME::Body

というわけで、マルチパートの添付ファイルの処理もするようです。
以上で一応MIME-toolsでメールの受信をする[河馬屋二千年堂さん]のソース読みの完了となります。何とか、読めた…のだろうか。ものすごく不安だ…。

しかし読み返してみると、あっちにいったりこっちにいったりで読みづらい。自分の普段の会話そっくりだ。

まずmoblogはどんなもんかと調べると、伊藤譲一氏によると、moblogはmail2entryというもので成り立っているらしい。Aron Atkins氏作成らしいですが、この記事からダウンロードできます。

Joi Ito's Web: mail2entry moblog code update

これが、基本的にサーバに入れて動かすもの。我が家のVineに入れられないこともないのでしょうが、そこにたどり着くまでに自分のスキルではどえらく時間がかかりそうなのでナシ…。インストールされた方も結構おられるので、将来のためにメモメモ。
　＃Bell's Memorandum: mail2entry
　＃matsubokkuri: mail2entry

さて、どうしたものかと検索していると、どうやらWEB-YATAIさんの方で、cgi版が出ている模様。さっそくこれを使わせてもらうことに。

とは言っても、そのまま使っていてもいつまでたってもヘボのままなので、それだけはどうしても嫌なのでソースも読んでいく事に。教材ですなー。

何ていうかみんなゴリゴリ書ける人のブログばっかりだから、たまにゃこういったショボいのもいいのでは…検索すると凄い人たちばっかりだもんよ('A`)ｷｶﾞﾋｹﾙ

ちなみに自分のスキルは、C言語をやろうと発奮するも『明解C言語』と『ポインタ完全制覇』をやってなんか満足してコードも書かずにいて振り出しに戻り、その後、もう一度発奮してPerlやろうと、O'REILLYの『初めてのPerl』『プログラミングPerl』をなんとか消化した程度です。

Moduleとかの知識は『Blog Hacks』読みながら得たものくらいです。
未来検索の結果を正規表現やらでRSSにしてパースして、Javascriptにしてサイトに表示する位が限界です。さらに、サーバは基本的な操作位しか出来ない。はてさて、どこまでやる気が持つか…('A`)

とりあえずスタート

ひとまず先ほどのWEB-YATAIさんからソースをダウンロード。
印刷して斜め読みした感じでは、対象のPOPサーバにあるメールをModuleで定期的に取得して、それをパース。さらにそれを目標のMTにエントリーとしてPOSTする、というもののようです（本当に読みながら書いているので違うかも）

使うModuleが結構あります。Net::POP3;　MIME::Parser;　MIME::WordDecoder;　Image::Size;　Jcode;　CGI　File::Copy;　MT;　MT::Entry;　MT::Blog;　MT::Image;、と10個以上です。
この中で良く分からんものをまずは調べておくことにします。

Net::POP3

とりあえず POP3がPost Office Protocol 3だと今初めて知った('A`)
perldocがNet::POP3 - POP3(Post Office Protocol 3)クライアントクラス (RFC1939)にあるので、とりあえず問題なさげ。簡単なサンプルはモジュールを使って POP3 クライアントを作ってみようにあります。しかしこんな簡単にCGIからPOPとかいじれるのね…もっと、こう、なんか凄いことになっているイメージが。0と1がたくさん出てくるんですよ、えぇえぇ。

しかし、モジュールの概要を調べる前に、ひとまずPOP3そのものについて知っておかないと、痒いところに手が届かない感じで気持ち悪くて仕方ないです。

なので、調べてみる。とりあえずNet::POP3のソースを見てみるも、イマイチどうやってPOP3サーバと通信してるのか分からない（と言うかModuleのソースがよく理解できない。Classとか完全に忘れている）さかのぼってNet::Netrcを見てもよう分からんですわ。

そんなこんなで、モチベーションが急激に右肩下がりですが気を取り直してPOP3サーバの仕組みから探ってみることに。

すると、@ITに魅力的な記事が。さすが。その記事とは、インターネット･プロトコル連載のPOP3の回。
　＃ラスト・ワン・ホップ プロトコル「POP3」
　
図1の動作模式図は分かりやすい…POP3もFTPやらHTTPやらと同じで、コマンドのやり取りで成り立ってるのか…。つまり、これを実装すればCGIでPOP3クライアントが出来る、と。大まかな動作の流れが分かったので、これで何とか吸収できそうな予感。

さて、モジュールのメソッドなどは、具体的にはこんな感じのようです。

コマンド名とメソッド名が大体同じで助かるところです。なんとかOK。

しかしPOP3だけでずいぶん時間を食いました。
でも、仕組みがそれなりに理解できたのでさっぱりさっぱり。
土台がどうなってるのか分からないまま上に家を建てるのが、どうにも気持ち悪い性質でして。＠ITのプロトコル連載には、他にもHTTPやらMIME、SMTP、FTPもあります。読まねば。何はともあれ＠ITの中の人に感謝。

MIME::Parser

さて、続いてMIME::Parserです。何と言うか、すぐに＠ITのさっきのMIMEのところを読むべきか…。

読みました。分かりやすい。
　＃しかし、何か目的もなしに読むと頭に入らない罠。

MIME::Parserは日本語ドキュメントがないので原文。
search.cpan.org: MIME::Parser - experimental class for parsing MIME streams

しかし、何気に今MIME::Parserで検索すると九割五分以上moblogの記事がひっかかる。

MIME::Parserは、MIME::Toolsのサブクラスみたいです（送信とかするにはそっちが必要。）
#MIME-Toolsの概要はsearch.cpan.org: MIME-toolsから。以下も同。

MIME::Parserは、メールデータをMIME::Entityクラスに変換し、様々なメソッドを通じて操作できるようにするために存在するようです。こいつを通せば、とても扱いやすくなり、メールのヘッダ情報とか本文とかがメソッド一発で簡単に取り出せるようになります。凄い。

入力のバリエーションとパースはこんな感じ。RSSを作るのに使った、XML::Parserに似ていてちょっと安心。同じパーサーだから当たり前か('A`)

続いて、パースしたものをどこのディレクトリに展開するかとかどういう名前をつけるかとかそういったセッティングが必要らしい。

そしてエラー処理について。

後オプションとか色々ありましたが、MIME:Parserはこんな感じなのだろうか。イマイチピンときてない。だがとりあえずNet::POP3;　MIME::Parser;と最後にMIME::WordDecoder;で、ひとまとまりな気がするのでMIME::WordDecoderを見てから悩むことにしますか…('A`)

MIME::WordDecoder

Cpanのドキュメントはsearch.cpan.org: MIME::WordDecoder - decode RFC-1522 encoded words to a local representationから。
これも、さっきのMIME::Toolsのサブクラス。MIME::Wordの方に実例があった。
　＃IME::Words - deal with RFC-1522 encoded words

たとえば下のようなものがあって、

こいつにWord::Decorderをかますとこうなるらしい

…Subjectの中の人は大変だ('A`)
ギャル文字どころじゃないぞ。変換されてるところがあったり無かったり。readは駄目でcoolは素通しなのかよ。

ひとまずメソッドとしては

みたいにするらしい。配列に入れるのは、返り値が @decoded_enc[0]が[DATA]で、@decoded_enc[1]が[CAHRSET]だからだそうだ。

うーむ。まとめると、NET::POP3でPOP3サーバに接続してメールデータを得て、それをMIME::ParserでパースしてMIME::Entityにする。そしてMIME::WordDecoderで各文字コードにデコード、という感じなのかな…。うぅむ。

なんか文字コードとMIME変換とマルチバイトと、そのあたりの変換がかなりの勢いでごっちゃになっているような気がします。その辺が一番の混乱のもとのような。

そんな感じで机に突っ伏していたら河馬屋二千年堂さんに、ActivePerlでメールを受けるという記事が。シンプルにこういたモジュールを使った、POP3へのアクセススクリプトが載っていました。

ありがたやありがたや…やっぱりサンプルはありがたいですな…。というわけで、まず先にこっちのソースを読みながらmoblogへの基礎固めをする予定です。

次回はMoblog設置ドキュメンタリー[その2]：：[7korobi8oki.com]です。

しかし、Google 検索: MIMEは凄いな。

どうやら、半田ごてやら電子部品を駆使して、PCから電化製品をいじれるようにしてしまおうという、かなりハードウェアよりの内容の予感。

というわけで、ひとまず目次を見てみると「１）自動的につくライト」「３）ペットを遠くから監視する」あたりは、商品としてもあった気がするので、別に何てことはないですな。I See Petとか昔話題になったような。
しかし「１１）キーレスでOKな家」「１３）セキュリティシステムを作る」とか、個人で出来るものなのか出来んのか微妙なものが他には並んでおります。
　　＃目次部分のPDF

ちなみに「６）ホームシアターをコントロール」は、サンプルによると40ドルの費用で出来るそうです。お手tごろな値段で出来ることも目標の一つだとか…内容は自分には見てもさっぱり分からんです。oreilly.com -- Online Catalog: Hardware Hacking Projects for Geeksなんかを買った人にはオススメな感じでしょうか。
　　＃6章のサンプルPDF

一応日本のアマゾンでも買えるみたいですね。
　　＃Amazon.co.jp： 洋書: Home Hacking Projects For Geeks (Hacks)

しかし、O'REILLYのHACKSシリーズは最近凄い勢いで出版されています。何気にhacks.oreilly.comが出来てるし。Mind HacksやらTiVo Hacksやら、凄まじい。

そのうち神田川俊郎氏辺りが、Ryori Hacksとか出すかもしれない。あるいはRetoruto Hacks.とか。ちょっと工夫でこのなんとやら。

身近なHacks
　・抜けたビールに塩を入れると、ちょっとだけ泡が復活する
　・ティーバッグに使用済みの油を染み込ませた奴を使うと水垢が良く落ちる
　・ハチミツを入れておくと、カレーが次の日になっても固まらない

…って、伊東家の食卓ってもしやHacking番組だったのか。

ReadMeによると、とりあえずサーバがbackgroundtaskを許してくれているかチェックしろとの事。方法としては、
まずmt-testbg.cgiを走らせろとのこと。ブラックリストの自動アップデートに必要だとか。しかし、サーバを探しても無いし手元にも無い、日本語版にはどうやら入っていない模様。というわけで米国本家からフルバージョンを落としなおして、そこから使ってみる。

走らせて見ると

If you see only one number below, or if you see two and they match, you should add the line
BackgroundTasks 0
to the file mt.cfg.
-------------------
[20921]
[20919]

とのこと。数字（これはプロセスID？）は二個出ているし、同じ番号でもないので、backgroundtaskはOKってことでいいのかな？とりあえず、mt-cfgのBackgroundTasks を1にしてみる。

続いてReadme通りにpluginsディレクトリ内にBlacklistというディレクトリを作って中身を放り込んでみる。

この時、imageディレクトリの中身はMTの既存のimageディレクトリに放り込み、pluginの中身はpluginにそのまま放り込まないと、イニシャライズでエラーが出ます（ひっかかった）。mt-blacklist-styles.css and mt-blacklist.jsはMTのトップディレクトに入れます。パーミッションは全て755でOK。
　　#作者は、データベースにいくつかテーブルを加えるので念のために
　　#バックアップを取ることを推奨しています。今回は出来たてブログなので無視。

そしてmt-bl-load.cgiを走らせると、無事イニシャライズ完了に。後はmt-blacklist.cgiを走らせれば管理画面に行きます。使い終わったmt-blacklist.cgiは消去すべし。

後はMaster Switchをオンにして、左のメニューからconfigureを選びます。

「 Scan incoming comments 」「Scan incoming TrackBack pings 」「Auto-update from the Master Blacklist」はそのまんまだと思われます。「Use MT-Blacklist notifications」は恐らくスパム相手にMT-Blacklistの存在を知らせるコメントなりを送るかどうかの設定ではないかと。

「Denial/Moderation Preference Override」は、個々の設定を無視して、全てのコメントを十把一絡に拒否するか、全部自分で可否を判断する（モデレートする）かに出来るということらしい。後はそのまんま、かと。

現在 2580 のブラックリストが登録されているらしいです。頼もしいですな。ADD ITEMから自分で追加も出来るのでどうぞ。その際はBlacklist Data Typesに書式などが載ってます。

うーむ、一つのプラグインだけでこんなに時間が。
そして、他のプラグインも、ひとまず現在は必要なさそうです。
結局、当初の目的であるサイドバーの寂しさは変わってない。

"KoalaRainbow"は、ブログ記事をグラフで表すもの。
"XSearch/Plus"は、デフォルトのものよりかなり強力な検索を提供してくれるみたいです。
"MultiBlog"は、多分ミラーサイトを作るのに使うのでは。
"Markdown"はValidなXMLを吐いてくれる様にしてくれるもの。でも結構デフォルトでValidになるので見送り。"Notifier"は名前からしていらなそうなので、一応見送り。

ちなみに画像は、発禁になったスノボビデオ「Blacklist」