ジャストシステムのATOKを購入しました。最新版となる「ATOK 2012 for Windows」は、2月10日の発売でした。

　このATOK、今年で誕生30周年だそうです。PC-9801で出ていた「一太郎」の頃から使っているので、かれこれ四半世紀は使っていることになります。

　途中、MS-IMEなども使ってみましたが、やはり98（キューハチ）世代の職人は、ATOKから離れられません。0xF9C7

　秋葉原の某店では、通常版のパッケージ製品が7,980円で売られていますが、PCパーツと一緒に買うと、なぜか3,990円になるとのことで、買うつもりは無かったのですが、買ってしまいました。
（現在、ATOK 2006を使っていて、「Ultimate Tera Storage Machine」も新しくなったので、この機会に購入することにしました）

　ぷららのblogサービス「Broach」のあまりの重さと対応の遅さに業を煮やし、工房blogを移設した訳ですが、

　これまでにも、多くの利用者の皆さんから、「登録記事のバックアップ機能（エクスポート機能）」の追加要望が出されていますが、Broachスタッフ側は、いっこうに動いている気配が見えません。要望に応えるつもりは、まったく無いようです。
（私の記憶が確かならば、かなり以前に「今後の追加機能（予定）」として書かれていたように思いますが、いまでは跡形もなく消されています）

＃まぁ、これだけグダグダな管理運営体制なので、エクスポート機能をリリースした途端、多くの利用者が他社に流出してしまうので、そんなリスクは冒せないのだと思いますが。0xF9D1

　工房blogを移設するまでにBroachに登録した記事は、700エントリを越えています。

　これまでしこしことマニュアルで移植していたのですが、半年以上経った現在、まだ100エントリほどしか完了していません。

　遅々として進まないのは、BroachからMT（Movable Type）へ移植するにあたっては、いろいろと越えなければならないステップ（後述）があり、これに手間取っていたためです。

　「やらぬなら、作ってしまえ、エクスポート機能」ということで、PHPのスクリプトをゴリゴリ書いて、作ってしまいました。0xF9F8

　若干マニュアルなところが残っていますが、ほぼオートマティックに移植することができます。

　動作としては、左側の枠にBroachの記事（HTML）をコピー＆ペーストし、実行ボタンを押すと、XHTML Validなものに整形・変換してくれます。

　同時に、HTMLの中からBroachにアップロードしたアイテム（画像など）を抽出し、MTのアイテムとして自動的に登録してくれます。

　その際、Broachでは、アイテムの名称（ファイル名）を勝手にシリアルなものに変換してしまいますが、Broachにアップロードした時のオリジナルの名称に戻してから、MTに登録してくれます。

（以下、詳細略）

　いや～、ぷららさんのお陰で、PHPによるSQLサーバ連携のよい勉強ができました。（もちろん、アイロニーな意味ですけど）0xF9D1

　これで、BroachからMTへの移植が進むかと思います。最終的には、Broachを解約します。

　またも、Webサーバ内部の改造です。

　工房では、工房にアップされているすべての画像への直リンクを禁止しています。

　具体的には、「.htaccess」に、以下のように記述しています。

　「Referer」の値をチェックして、Refererがセットされていない場合（＝直リンクされている場合）、または工房のドメイン以外の場合（＝自分のページに勝手に表示している場合）には、アクセスさせないようにしています。

＃こうすると、セキュリティーソフトを入れていて、Refererを出力しないような設定をしている場合には、画像が表示されなくなってしまいますが、まぁ、そういうヒトは、そういうヒトということで。

　ただし、その一方で、Googleなどの画像検索クローラーがやってきた場合には、アクセスさせたい訳です。

　上記のように、ホスト名を指定して許可すればいいのですが、Googleのようなクローラーであっても、ホスト名が得られず、IPアドレスしか分からない場合があります。

　このような場合、そのIPアドレス毎に許可してやればいい訳ですが、クローラーのIPアドレスは、アクセスの度にコロコロ変わることがほとんどです。

　そこで、クローラーのIPアドレスを含むサブネット全体を、丸ごと許可してやることにします。

＃ちょうど、スパム対策の逆の手法ですね。

　では、どのようにクローラーのIPアドレスを取得するかというと、.htaccessに、以下のように設定します。

　これは、HTTPのステータスコードに基づき、クライアントエラーが発生した場合には、“error.phpを呼び出す”という設定になります。

　1行目は、エラーコード403（Forbidden）で、リソースへのアクセスを拒否された場合に、2行目は、エラーコード404（Not Found）で、リソースが見つからなかった場合に、それぞれerror.phpを呼び出すことになります。

　これを受けて、error.phpでは、以下のようなHTMLを出力します。

　あたかも、Apacheとまったく同じ挙動をするように偽装していますが、実は、裏ではしっかりアクセスログを取っています。

　以下、そのソース（一部）です。

　このスクリプトによって集められたIPアドレスを逆引きし、Googleなどのクローラーであった場合には、そのサブネットを得て、アクセス許可リストに追加していきます。

　逆に、直リンクしたり、自分のページに勝手に表示したりしている場合には、アクセス拒否リストに追加していきます。

　また、ある一定時間以内に、ある一定回数以上のアクセスがあった場合には、Webサーバへのアタックと見なして、アクセス拒否リストに追加したりできます。

　実際のエラーログの一部です。

　IPアドレスを逆引きすると、Googleが取得したサブネットからのアクセスであることが分かります。

　これらより、.haccessには、上記のように設定しました。

　このように、HTTPのステータスコードを取り込み、エラーログを解析することにより、「クローラーには優しく、不届きなヤカラには厳しい」対処を取ることができます。

　藤本壱さんが開発された、「ブログに記事を書いたことをFacebookに投稿するプラグイン」を導入し、改造してみましたので、ご紹介します。

　オリジナルのプラグインの導入方法は、こちらまたはこちら（小粋空間さん）をご覧ください。

　このプラグインは非常に有効で、MovableTypeにブログの記事（またはウェブページ）を投稿すると、自動的にFacebookのウォールにアップしてくれます。

　自動投稿されたイメージは、上記のようになります。

　とても便利なプラグインなのですが、Facebookに投稿される画像は、プラグインの設定時に指定した、固定的なものとなります。

　記事の内容によっては、その記事に関連する画像を設定して、ウォールにアップしたい場合があります。

　ということで、さっそく改造してみました。0xF9F8

　ファイルを所定のフォルダにアップし、最初に管理画面にアクセスすると、上記のようなメッセージが表示されるので、「アップグレード開始」を押下します。

　アップグレード（データベースの設定変更）が正常に終了すると、上記のようなメッセージが表示されます。

　ブログ記事の新規編集画面を開くと、右下に、上記のような項目が追加されています。サムネイル画像のURLを設定できるようになっています。

　サムネイル画像の初期値は、プラグインの設定時に指定したものが、そのまま入っています。

　過去に投稿した記事についても、編集画面を開き、「Facebookに公開」のチェックボックスを入れて再投稿すれば、その時点でウォールにアップしてくれます。

　改造後のイメージは、上記のようになります。

　記事に応じて画像を変えることで、一目でその記事の内容を推定することができ、訴求力をアップすることができます。

　以下、改造のポイントです。

　まずは、「config.yaml」の変更点です。

　サムネイル画像のURLを格納するフィールドを、「fb_thumbnail」とします。

　このフィールドを、ブログの記事（mt_entry）毎に紐付けるため、上記、4行目のように宣言します。

　ここで、fb_thumbnailには、「meta」という属性を設定しています。

　これは、過去のすべての記事（mt_entry）にfb_thumbnailを確保するのではなく、プラグインを導入した以降に投稿した記事（または、必要に応じて編集した過去の記事）に対してのみ、fb_thumbnailを確保するようにするためです。
（内部的には、「mt_entry_meta」にfb_thumbnailが追加されます）

　つづいて、「Plugin.pm」の変更点（一部）です。

　記事の編集画面で呼び出される関数（edit_entry）です。

　サムネイル画像のURLを設定するため、<input>タグを追加しています。

　ブログ記事を新規編集する場合には、変数「$fb_thumbnail」に、プラグインの設定時に指定した値を代入し、これをデフォルト値としています。

　過去に投稿した記事を編集する場合には、デフォルト値は同じですが、mt_entryのmetaフィールド「fb_thumbnail」に値が格納されていた場合（＝過去に編集した際に設定していた場合）には、$fb_thumbnailにその値を代入しています。

　今回は<input>タグを使って、サムネイル画像のURLを直接設定するようにしましたが、同じ編集画面内の「ブログ記事アイテム」から、その記事に紐付けられた画像をドラッグ＆ドロップできるようにすれば、もう少し便利になるかと思います。

　が、とりあえずは、基本機能の実装ということで・・・。0xF9C7

　これまで、MTと連携する外部関数は、いくつか書いてきましたが、MTのプラグインを作成するのは、初めての挑戦でした。著名な藤本壱さんが書かれたソースを解析してみて、とても勉強になりました。

　効果テキメンでした。0xF9F8

　前回、スパム認定されたIPアドレスを含むサブネット全体を、丸ごと「完全遮断」するという強硬手段に出た訳ですが・・・、

　上記は、ここ1ヶ月半ほどのスパムコメント数の推移です。

　規制を掛ける前は、最大で1日8件、平均で1日4.3件のスパムコメントが付いていましたが、スパム認定されたIPを規制することで、1日平均2.6件にまで落とすことができました。

　さらに、スパム認定されたIPアドレスを含むサブネット全体を規制することで、1日平均0.2件（ここ数日は0件）にまで落とすことができました。

　してやったり、という感じです。

　これだけ効果が大きいものとは、当初は思いも寄りませんでした。しかも、そのほとんどが中国（cn）からのアクセスなので、実効上、なんら問題はありません。

　ついでに、PHPも、さらなる改善を図りました。

　前回のスクリプトを書いている途中に気付いたのですが、IPアドレスを解決する際に、わざわざAPNICのWebサーバに聞きに行かなくても、自分のサーバでwhoisコマンドを実行してその結果を得れば、HTTPプロトコルによるオーバーヘッドを無くせるので、レスポンスの改善を図ることができます。

　ということで、さっそく改良しました。以下、そのソース（一部）です。

　「ip2cidr()」は、IPv4形式のIPアドレス（開始アドレスと終了アドレス）から、ネットアドレスとサブネットマスクを生成する関数で、PHPの電子マニュアルに載っていたもの、そのままです。

　「GetNetMask()」が、今回のポイントとなる関数で、IPアドレスからネットアドレス等の関連情報を取得するものです。

　「exec()」関数でwhoisコマンドを実行し、結果をバッファに入れます。バッファを検索し、「inetnum」という文字列があれば、IPv4形式のIPアドレス（開始アドレスと終了アドレス）を取得します。

　あわせて、「country」という文字列があれば、国籍を取得します。

　なお、IPアドレスによっては、「inetnum」がwhoisサーバのデータベースに載っていない場合があるため、その場合には、例外処理をしています。