• 今までHTTP GETとしてタイトルの取得に失敗した場合、そのURLの登録ができなかったのですが、その縛りを無効にしました（HTTPSのページで取得失敗する例が多すぎたんで）。
• 投稿フォームでジャンルの区切りとして全角の「｜」が入力された場合、自動的に半角の「|」に読み替えるようにしました。全角半角気にせずに縦棒で区切っちゃってください。

どこともしれない方向を向いて言い訳。

もともとWikiParserクラスを作ったのは、

• 自分で今まで作ったWikiParser（複数）は、DOM（風のオブジェクト群）を介して展開するというごつい設計になっていて、メンテナンスがうざかった（というか拡張していく過程で細かいバグが取りきれなかった）
• PEARのText_Wikiをのぞいてみたけど（ちゃんとは読んでいない）、こちらの設計も俺が作ったのと似ていてジェネリックすぎてごつい感じに見えた
• もっとシンプルな（テキスト操作レベルでの）Wikiパーサーの方が扱いやすくていいなー。RandomNote/PHPのパーサーなんか見通しがよさそう。これをベースに汎用的なものにしよう

って感じなんでText_Wikiベースじゃないんですよ。

うーん不正アクセス禁止法で有罪判決かー。ひとまず現時点では、あの程度の（パラメータを平文レベルで書き換える（しかもブルートフォースアタックでもなく）だけで破ることができるセキュリティ、というか、単にセキュリティに関する無頓着さ）を突破することは、不正アクセス禁止法に触れるという判断なわけね。

俺は、「高木浩光＠自宅の日記 - 不正アクセス禁止法 私はこう考える」に書かれている、

どこかに線引きをして、ここまでは法律による保護もあるが、ここからは保護されないので、最低限の安全対策として（ファイル丸出し同様に）必ず実施しなくてはならないこととして、倫理を形成していくしかないのではなかろうか。

における線引きの手前、「最低限の安全対策として開発・運営者側が実施しなければならないこと」の方に含めた方がいいと思うんだけどなー。

少なくとも、いかにもセキュリティ的にやばそうなサイト（ソースコード）等を見つけたときに、その危険度をある程度は実際に試して測ってもいいと思う。というか、そのくらい自己防衛の一環としてやらせて欲しい。もちろん「ある程度」の範囲は常識的な範囲であるべきだと思うけど（この件ではoffice氏はその範囲を逸脱したとは思う）。

試してみただけで不正アクセス禁止法に触れる、と言われてしまうとリスクを測ることもできないままに、そのサイトを使うか使わないかを判断しなければならないし、またやばそうだと思ってもそれを（具体的な根拠がないから）誰かに告げることもできない。いつか致命的な何かが起きないことを祈りながら、そのまま放置するしかなくなる。

そういう危険性を未然に回避するためには、それまでoffice氏が行ってきた、やばそうなサイトに対して実際にやばいのかどうかを試し、問題があった場合は修正するように通知するという活動は、非常に有用だったと思っている。現時点でも、既知のセキュリティ的な問題を抱えたサイトは、世の中にまだまだたくさんあるはずだ。asahi.comの記事にあるように、セキュリティに興味がある人（善人・悪人問わず）には既知の問題でも、「アクセスはプログラムの脆弱（ぜいじゃく）性を利用したもので、管理者は想定もしていなかった」りするわけだし。

実際俺も昔office氏に、textmaniaのエラーメッセージのサニタイズ不足でXSSが可能だった点を指摘されて直したことがある。それ以来セキュリティ対策に関してはすごく意識するようになった。この件については、例の本にoffice氏の活動に対する謝辞として入れてある。office氏に対する応援のつもりだったんだけど、ひとまずは有罪判決が出ちゃったのか。不正アクセス禁止法に関しては無罪という線を願っていたんだけどな。

なんでもPHPで書いてみよう計画挫折。curlを使っても、HTTP_RequestやHTTP_Clientを使っても、不満を解消しきれない（HTTPSでアクセスできないサイトがある。タイムアウトが効かない。マルチスレッド対応できない）のに嫌気が差して、blogmapのクローリングプロセスの一部（主に巡回処理部分）をPerl（LWP::Parallel::RobotUA）で書き直しちゃったよ。すげー速くなったっぽい。主にタイムアウト処理がきちんと行われるようになったのが理由で、純粋な処理速度の問題ではないんだけど。

やっぱりなんでもPHPで書くのはあきらめた方がいいんだろうなー。単純なスクリプトならばいいけど、ちょっと凝るとすぐにつまらない問題・制限に行き当たるんだよな。でもWebアプリはPHPで書くのが（環境設定や速度や自前のライブラリの都合上）一番楽だし、そうなるとシェルスクリプトでもある程度は同じライブラリを使いたくなるしなー。CPANのPHPとか、pecl/perlとかに手を出してみようかなー。でも色物臭いしなー。

mylistのリンク元記録をはじめました。メモの固定URLに対するHTTP_REFERERのみを記録します（具体的にはdateパラメータがある呼び出しのみを記録しています）。また呼び出し回数は記録しません（何回呼び出されても1回のみ記録されます）。1470.net内のREFERERは記録対象から除外しています。

現在のところ、各ユーザーの設定フォームの下に最近一週間分の元が表示されています（tDiary風のリンク元表示に対応するかどうか検討中です）。それに伴い、設定フォームの呼び出しリンク文字列を「設定」から「管理」に変更しました。

と思ったけど

やっぱり固定リンク以外へのREFERERも記録するようにしました。

なんかSpider.NETを名乗るクローラーが、MMやらblogmapやらのすべてのURLを延々とたどり続けていて、何万ページたどってもやめる気がなさそうなんで、IPアドレス範囲で丸ごとdenyした。これは何者なんだろう？

WikiParserをJavaScriptに移植してみようかと思ったら、preg_replace_callback相当の正規表現（Perlで言うと/eg）が見あたらない。っつーか、ないんだよね？

しょうがないんで、こんな感じで動かしてみたんだけど、なんとも不格好な感じ。もうちょいいい書き方ないかなー。

function replace(str)
{
str = str.replace(/(123)/g, "' + callback('$1') + '");
str = str.replace(/'/g, "\\'");
str = str.replace(/\\' \+ callback\(\\'(.+?)\\'\) \+ \\'/g, "' + callback('$1') + '");
str = eval("'" + str + "'");
return str;
}
function callback(str)
{
str = eval(str) + 100;
return str;
}
test = "sdga123lkjdgas1234fasdfas";
alert(test);
result = replace(test);
alert(result);

ちなみにテンポラリの式をわざと対象のstrに含まされると誤動作するけど、大して危険性もないだろうということで放置。

正解は

malaさんからきれいな解答を教えてもらいました。

function replace(str)
{
str = str.replace(/123/g, callback);
return str;
}
function callback(str)
{
str = eval(str) + 100;
return str;
}
test = "sdga123lkjdgas1234fasdfas";
alert(test);
result = replace(test);
alert(result);

これでOK。replaceの第2パラメータに関数を渡すと、その関数のパラメータとして、lastMatch（というかマッチした全体）、$1、$2、……が渡されて呼ばれる模様。で、その関数の戻り値として置換結果文字列を返してやればいい。

str = str.replace(/(123)/g, callback($1));

とか

str = str.replace(/(123)/g, callback(RegExp.$1));

なんて表現は試してみたんだけどなー。

ちなみに後者の表現だと、RegExp.$1はここの/123/gではなく、その前に評価された正規表現の結果の$1を受け取っちゃうんで、微妙に惜しい結果になった。

主な変更点としては、

• プラグインとして、従来の関数型プラグインに加え、プラグインクラスに対応。
• プラグインクラスでは、同一プラグイン内でのデータの保持、イベントコールバックによるパーサーからの呼び出し、に対応。要は、footnote（注釈）プラグインみたいなことができるようにした
• パースしている元テキストへのアクセス手段を用意。それに伴いフィルタに対応。フィルタ（プラグインのイベントコールバックの実装と同様）を利用することで、パース処理実行時の元テキストへの加工処理が可能になる。要は、tdview.phpとtdiary_categoryプラグインみたいに、カテゴリ記法に対して前処理でリンクを張ったりできるようにした。
• いくつかのバグをフィックス。

一応現状の基本仕様でフィックスさせつつ、細かいメソッド名とかをもうちょいいじる予定。プラグイン連携のためのメソッドもいくつか追加するかも。

今日ようやく実物を見ることができました。『はじめに』にも書きましたが、主にホビープログラマーが趣味としてプログラミングを楽しむためのネタとして、Webアプリおよびblogツール関連技術の仕組み・使い方を実例（PHP 4）と共に紹介する、という感じのものです。

『自分で作るblogツール（PHP編）サポートエントリー』 の方でいろいろフォローしていきます（最後かなりばたばたしたんで、細かい間違いがたくさんありそう）。よろしくお願いします。

花粉がさらにひどいことになっている気がする。薬を飲んでいても目を洗っても我慢の限界を超えることが多い。補助に鼻炎薬とか飲んだ方がいいかなー。