nDiki : WikiPage

WikiEngine によって提供される誰でも編集できるWebページのこと。 WikiForumの各ページ。

一般にページには、

• 「ページタイトル」...検索ページへのリンク
• ページの内容
• 「編集」リンク
• 前回の編集との差分表示ページへのリンク

等が含まれている。

WiKicker Wiki NaneyOrgWiki HTML URI WikiName キャッシュ URL Perl 日本語 BracketName データベース ファイル名 ロック WRN メモリ InterWiki DiKicker インストール Memcached PageName WRI エラー 自動リンク HTTP RecentChanges IndexPage JavaScript RWRN Web ブラウザ

■ [ WiKicker ] RCSファイルのリビジョン間引き

以前からWikiPageの編集で「連続する追記はチェックインしない」というオプションを検討している。 実装の前に「既存のRCSファイル中の連続する追記を間引く」というツール(rthin)を作って効果を検証してみた(どこかに転がってそうユーティリティだが見つけられないのでPerlで実装)。

• rlog で '+x -0' なリビジョンが連続した場合は削除対象に
• rcs -o で削除
• メジャーリビジョン番号変更の境目では間引かない
• ブランチは考慮して実装していない

で現在の NaneyOrgWiki で間引いてみたところ 9.5MB の RCSファイルらが 9.0MB になった。 容量的には劇的に減る訳ではないな。 リビジョン数が減るのは精神的に良いが。

これなら無理に WiKicker に実装しなくてもいいかも。 rthin をたまに走らせるだけで充分のようだ(実際にはロックを考慮しなければならないけれど)。

• [ WiKicker ] リビジョンが追加されていかない (2003-04-22)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• [ WiKicker ] 久しぶりにメンテナンス (2004-04-02)
• [ WiKicker ] 続L10N改善と、ページ名リスト処理の高速化 (2004-05-29)
• www.naney.org サーバ断続的にダウン (2006-04-30)

■ [ WiKicker ] 続L10N改善と、ページ名リスト処理の高速化

L10Nの改善の方はひき続き。 これで ja系以外の Accept-Language リクエストヘッダがきた場合は、日本語が混ざらないはず。

それからまた NaneyOrgWiki のレスポンスが悪くなりがちだったので、高速化のためのコード見直し。 現在 WikiPage 数 1151 で、ページ名リストにからんだ処理が遅くなってきているようなので重点的にチェック。

• HierarchicalWikiPage への参照解決の高速化 -> suffix マッチに rindex を使っていたところを substr を使うように修正。
• 1ページ1ファイルで保存しているDBからページ名リストを取得する部分の高速化 -> ディレクトリ上のファイル一覧を取得し各ファイル名をページ名に毎回デコードしていたのだが、これをやめて index ファイルを作っておくように変更。

• WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• WiKicker における PageName 最長文字数 (2006-06-10)
• WiKicker 0.34 リリース - 添付機能のコードを追加 (2006-06-11)
• [ WiKicker ] If-Modified-Since: 関連作業ほぼ済 (2003-09-19)

■ [ WiKicker ] キャッシュまわりにバグ

Memcached まわりをいじったので、キャッシュ具合をテストしていたら変な現象が。 WikiPage が表示されるべきところに、検索結果が表示されている。 あれ?

@ ページの内容が表示されるところに検索結果が

WiKicker では WikiPage のレンダリング結果も検索結果もキャッシュしているが、それぞれ別のキャッシュキーになるようにしている (WiKickerのバージョンを $V とすると、'$V:h:ページ名' と '$V:s:検索語')ので混ざるはずがないんだけれどな。 キャッシュしているデータの形式も違うし。

最初は Memcached まわりのアップデートで不具合がでたのかと思ったが、戻しても変わらない。ということは、ずっと以前からこの問題が発生していたのか。 やば。 設定でニックネームを設定している(cookie に保存している)と、その Web ブラウザに対してはキャッシュ機能が働かないようになっているので発見が遅れてしまった。

で結局コードをチェックしてみたら「WikiPage 表示と検索結果表示の View クラスを同じにしていたため、検索結果のレンダリングが WikiPage レンダリング結果と同じ領域にキャッシュされる」という風になってしまっていた。 ということで誰かがページ名で検索するとそれがキャッシュされてしまい、ページを読もうとしてもキャッシュ破棄されるまで検索結果が表示されてしまうというひどい状況になっていたと。

修正。

@ キャッシュキーのバグ

Memcached の出力をチェックしていたら、たまにエラーが起きていることを確認。 Memcached のプロトコルをチェックしたら、キーには制御文字と空白は使えないとある。 Cache::Memcached を見たらキーはそのまま through するだけ。 ということでページ名に空白が含まれている場合などの時には、まずい事になっていたようだ。 こちらは、キーを自前でエンコーディング(ページデータベースファイル名の作成に使っている base64 の亜種)するように修正。

• [ Perl ] Memcached を使ってみる (2004-01-12)
• [ WiKicker ] WikiPage のHTMLレンダリング結果のキ... (2004-02-14)
• [ WiKicker ] Memcached を使った検索結果のキャッシング (2004-01-15)
• [ WiKicker ] SpeedyCGI 対応するも…… (2003-11-09)
• [ WiKicker ] 古くても検索キャッシュを返す (2004-01-20)

■ [ WiKicker ] Acceptor とか ロックとか

HTMLレンダリングなどは WikiPage の構文木に対する Visitor パターンで行っている。

かなりの回数呼ばれるダブルディスパッチ部分、現在は accept の中で 'visit_クラス名' を呼ぶようにしている。 Acceptor クラスの accept メソッドでインスタンスのクラス名を取得してディスパッチしているのだがもったいない。

各サブクラスで明示的に accept をオーバライドするのが面倒なのでそうしていたのだが、今回は Acceptor モジュールを use した時にそのパッケージに accept 定義を作ってしまうように修正してみた。

@ ロックの方

アクセスが連続的にある時はDBに対して共有ロックがかかり続けるため、書き込みのための排他ロックがなかなか取得できない。 現在はDB全体でロックしているのだが、そろそろ「ページ名リスト」と「各ページ」を別にロックするようにした方がいいかもしれない。

• [ WiKicker ] hell mode - HTMLタグ付けブロックの導入 (2005-09-13)
• [ WiKicker ] form/list の paragraph から... (2003-05-03)
• [ WiKicker ] 憧れのサイドバー (2004-01-23)
• [ WiKicker ] If-Modified-Since: 関連作業ほぼ済 (2003-09-19)
• WiKicker 0.27 リリース (2005-10-05)

■ Linux Feed Reader Liferea

RSS巡回用に入れてみる。

とりあえず NaneyOrgWiki とはてなアンテナのRSSを登録。 これだけだとあまり良さがわからないな。 記事自体がRSSに含まれていれば、それなりに面白いのかもしれないが。

WiKicker では description に WikiPage 上部の数行を概要として出力しているのだが、ここはページの変更部分をのせた方が良いのかもしれない。

• [ WiKicker ] textarea ビヨーン (2004-02-04)
• [ WiKicker ] If-Modified-Since: (2003-09-18)
• [ WiKicker ] 続L10N改善と、ページ名リスト処理の高速化 (2004-05-29)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• mixiに登録 (2004-11-19)

■ WiKicker に Flickr 関連機能追加

WiKicker / DiKicker で Flickr 上の画像ファイルを貼れるように WRN scheme を追加。 Flickr では

 画像ファイルURL:
    http://photos番号.flickr.com/画像ID_文字列(_サイズ).jpg
 画像ページURL:
   http://www.flickr.com/photos/アカウントエイリアス/画像ID/

となるようだ。画像サーバ名と文字列部分の割り当ては推測できないので、画像ファイルURLは直接指定する他ないか。 後はアカウントエイリアスを指定すれば2つのURLが生成できる。 幸いアカウントエイリアスは : を含まない ([a-zA-Z0-9_-]+?)。

以上から WikiPage の中では

  [[flickr:アカウントエイリアス:画像ファイルURL]]

のように指定できるようしてみた。 www.flickr.com はレスポンスが悪いのだが画像サーバ自体のレスポンスは良いようで、試しに nDiki に貼ってみたが特に問題はないようだ。

@ 画像からのリンク

WiKicker では YukiWiki を真似て WikiPage に貼ったインライン画像はその画像のURLにリンクするようにしていたのだが、今回やめることにした。

Flickr や ASIN リンクのようにリンク先が決定できる時のみリンクにするようにする。 以前から、バナーを貼る時などのために「画像URLとリンク先URLの両方」を指定できるようにしたいのだが、いい記法が思い浮かばないのでいままでずっと実装しないままになっている。 何かうまいWRIを考えたい。

• Flickr に登録 (2005-02-08)
• Flickr + nDiki (2005-02-11)
• WiKicker 0.25 リリース - Win32 対応は動作未確認 (2005-05-07)
• WiKicker / DiKicker の AutomaticLink 長... (2007-03-01)
• DiKicker の出力する HTML コードを小さく (2006-10-05)

■ Windows 上での Apache 2.0.53 では PATH_INFO が シフト JIS に

WiKicker の Windows 上での動作確認の続き。 WiKicker のPPM パッケージを作成して ActivePerl 5.8.6.811 上にインストール。 依存するモジュールで、ActivePerl に入っていないものは以下の通り。

• Algorithm::Diff
• Jcode
• Log::Log4perl
• Time::Zone (TimeDate)

既に手元で PPM パッケージ化済みなので、これもインストールしておく。

後は RCS をパスの通っているディレクトリに入れてタイムゾーンを設定。

 TZ=JST-9

で CGI プログラムとして実行。 お、表示できた。 書き込みはと。

エラー。

予想していたけれど、sendmail に依存していたところ。 sendmail が見つからない場合はメールの送信をスキップするように修正。

これでうまく動くかなと思ったら、日本語名のページを作るとうまく表示できない問題を発見。

@ PATH_INFO がシフト JIS で渡される

WiKicker では UTF-8 文字列をURIエスケープして WikiPage のURLを生成している。 このURIにアクセスされると WiKicker は、PATH_INFO から WikiName を取り出す。 この文字列がシフト JIS になってしまっている。

Windows がファイル名に使用する charset にあわせて、Apache が変換してしまっているようだ。 調べてみると他の WikiEngine でも同様の問題にあっているという記事が見つかった。

将来の 2.0 系でパッチが取り込まれて修正されるとか、そうでないとか。

現状どうするかなぁ。 WiKicker 側でシフト JIS から UTF-8 に戻すというのもできない事はないけれど、あまりやりたくはないな。 いったんシフト JIS を介しているという時点で、シフト JIS に無い文字の扱いに関する問題をかかえてしまっているし(Apache が)。

対策案:

• Apache 1.x 系を使う (まだ未確認だが、こちらだと勝手に変換されないらしい)
• WiKicker に PATH_INFO を使わないオプションをつける(URI Query Component は勝手に変換されない)
• WiKicker 側でシフト JIS から UTF-8 に変換する

• WiKicker における PageName 最長文字数 (2006-06-10)
• WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
• PATH_INFO のかわりに REQUEST_URI と SCRIPT_... (2005-04-15)
• [ Perl ] Log::Log4perlのはまりどころ (2004-03-02)

■ [ WiKicker ] Storable 永続化データの互換性

fkimura 氏から WiKicker の障害レポートをいただいた。 Perl v5.8.6 へ移行した環境で WiKicker 0.26 を試してみたところエラーになってしまうとのこと。

 "Error
 action: do_read: Byte order is not compatible at blib/lib/Storable.pm
 (autosplit into blib/lib/auto/Storable/thaw.al) line 366,
 at /usr/local/lib/perl5/site_perl/5.8.6/WiKicker/DB/File.pm line 161
 at /usr/local/lib/perl5/site_perl/5.8.6/WiKicker/CGI/AbstractController.pm line 93"

(FreeBSD 4.11-RELEASE-p9)

Storable がエラーを吐いている。 Storable データ形式に互換性のない環境 (Perl and/or Storable) 変化があったようだ。

例えば Storable のマニュアルによれば 64bit integer をサポートするように構築された Perl v5.6.0 や v5.6.1 で Storable 2.02 以前を使って書き出したデータを他の環境で読み出すと 'Byte order is not compatible' エラーが出るとある。

確認したところ前のバージョンは Perl v5.6.2 だそうなので、もしかしたら上記の非互換性にあたってしまったのかもしれない (FreeBSD の Perl って 64bit integer サポートでビルドされるようになっている?)。

@ WiKicker での対応方法

WiKicker で使用している Perl のアップグレードで上記問題にあたった場合、一番簡単な方法は Storable で書き出しているページ情報ファイルを一旦全部消してしまうという方法。

WiKicker のデータベースディレクトリ (wikicker.database.directory プロパティで指定しているディレクトリ)の下の、info/basic/* を全て消してしまう(一応バックアップとしてコピーした方が良い)。

この場合、各ページの「最終更新時刻、最終更新者名、要約文」が消えてしまうが、これらの消えてしまった情報は次にページを更新した時に最新の情報で上書きされる。

WikiPage そのものおよび古いリビジョンは影響がなく全て残っているので、通常の運用ではまあ許容できる範囲の対処方法か。

情報ファイルを消したくない場合は、コンバートする必要があるけれど古い Storable データを読み出せる環境で export して、新しい形式で書き直す必要があるので作業する人にとってもちょっと面倒かもしれない。いや、新しい Storable ならば $Storable::interwork_56_64bit あたりを使えば両方をきりかえて読めそうであるので、新しい環境だけあればいいのかな。

• [ Perl ] Memcached を使ってみる (2004-01-12)
• SQLite とか DbUnit とか (2005-05-23)
• [ WiKicker ] キャッシュまわりにバグ (2004-06-05)
• [ WiKicker ] SpeedyCGI 対応するも…… (2003-11-09)
• テスト。More。 (2005-03-13)

■ [ WiKicker ] hell mode - HTMLタグ付けブロックの導入

WiKicker では、直接 WikiPage にHTMLタグを記述して表示に反映させる機能を提供していない。

@ HTMLタグ付けを許すのは嫌だ

HTMLタグ付けを許すと

• 入力ミスによるトラブル
  • HTMLタグ付けブロックの閉じ忘れ
  • 文法的に正しくないHTMLの入力
• 悪意ある入力によるトラブル

が起きやすくなるし、ページのソースの単純さが大きく失われてしまう。 レンダリングしてHTMLにした時に、正しいHTMLを出力されることを保証することが困難になるとともに、HTML以外へのレンダリング/コンバートもかなり難しくなる。

この機能を導入すると、Wiki の良さの半分(あるいはもうちょっと沢山か、もうちょっと少なめ)が失われてしまう。

@ でも

とはいえ欲しいという声があることも事実。 オープンな WikiForum では全くお勧めできないが、閉じたユーザグループの中ではまぁ必要悪なのかもしれぬ。

また正直ちょっとした表現を追加したい時に、WiKicker 用のプラグインを書くのも面倒だというのは確かにある。

WiKicker では開始・終了マーカによる複数行にまたがるブロックを表すための文法は(閉じ忘れを避けるため)意図的に排除してある。 このため、複数行にわけて書きたいような長いデータを扱うような拡張も導入しにくい。

ちょっと手抜きして「生HTML書けちゃえば」という誘惑はなくはない。

@ 大人の事情

ということでまあ自分に言い訳をしつつ、標準ではオフというかたちで HTMLタグ付けブロックを導入することにした。 スイッチは hell mode とかにしたい (今回は syntax.html というプロパティ名にしたけれど)。

記法は単純に、

 normal wiki syntax text...
 <html>
 html tagged text...
 ...
 </html>
 normal wiki syntax text...

のように行頭が <html> である行から、行頭が </html>である行までをHTMLタグ付けブロックとすることに。 このため、<html>ではじまる段落が書けなくなるという小さな非互換が発生するが、いたしかたない。

@ サニタイズ

HTMLタグを直接使えるようにするとはいえ、全てを許してしまうのはあまりに危険で非人道的すぎる。 有効なHTMLタグや属性は限定的であるべきだ。

このあたりの処理は面倒だが、幸いにしてCPANにモジュールがある。 今回は HTML::Scrubber を使うことにした。 HTML::Parserを使って parse し、指定したルールに従ってサニタイズしてくれる。

ちょっと使ってみた範囲では日本語(UTF-8、UTF8 フラグなし)でも問題ないようだし、文法的に正しくなくてもきちんとサニタイズできているようだ。

ということで、これを採用することに。

どの要素・属性を許すかはまだきちんと決めかねる。 当面は様子をみながら、調整していく予定。 サニタイザは設置者が置き換えられるようにプラガブルにしておかねばならないな。

• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• [ WiKicker ] form/list の paragraph から... (2003-05-03)
• Wikiの文法の標準化 (2004-02-10)
• 無制限 HTML タグ付けブロックを使って nDiki に Google ... (2007-08-23)

■ [ WiKicker ] destination anchor を打てるように

WiKicker には終点アンカー(HTML だと name and/or id属性付きA要素)をページ中に書く機能がない。

• 直観的ではない。この機能を知らない人が WikiPage を編集しようしたときに、ソーステキスト中にこれがあるのはよろしくない。HTMLを知っている人なら問題ないかもしれないが、そうでない人にはわかりにくい。
• アンカー名の一意性の保証が面倒
• 終点アンカーを書いて、他からご丁寧にリンクしても Wiki の正確上誰かが編集してすぐ無くなっちゃうかもしれない (そういってしまえばページそのものもそうであるが)。

等の(自分なりの)正当な理由で追加していなかったのだが、まぁ必要になったのであっさり追加することにした。 アンカーテキストに WiKicker のインライン要素を書けるようにするかどうか迷ったが、HTMLでレンダリングする際にA要素のネストを避けたりするのが大変なので書けない仕様にすることにした。

 [[anchor:anchor_name]]
 or
 [[anchor:anchor_name][anchor_text]]

という表記 (WRN scheme)を追加。 アンカー名の一意性の保証はまだ未実装。 やっぱやらんといかんかな。

• [ WiKicker ] form/list の paragraph から... (2003-05-03)
• [ WiKicker ] 憧れのサイドバー (2004-01-23)
• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• [ WiKicker ] If-Modified-Since: 関連作業ほぼ済 (2003-09-19)

■ skkinput がよく落ちるので uim-skk に乗り換え

メインのノート PC (Debian GNU/Linux sid)では XIMサーバとして skkinput を使っているのだが Firefox で入力をしていると、Firefox を道連れによく落ちてしまう。 何かの登録のためにフォーム入力していたり、WikiPage の編集をしているときに落ちてしまうとかなり辛い。

ということで遅ればせながら uim を試してみることにした。

@ インストール

ほぼ「Japanese - Debian GNU/Linux スレッドテンプレ」の通りに設定。

SKK用の辞書などは既にはいっているので

 apt-get install uim uim-skk

として uim 関連のファイルをインストール。

~/.xinitrc の skkinput 関連の部分をコメントアウトして、

 if type uim-xim &> /dev/null ; then
   uim-xim &
 fi
 XMODIFIERS=@im=uim ; export XMODIFIERS
 GTK_IM_MODULE=uim ; export GTK_IM_MODULE
 UIM_IM_ENGINE=skk ; export UIM_IM_ENGINE

を追記。

これで Firefox でも問題なく uim-skk で日本語入力ができた。

@ ツールバー

Window Manager 用システムトレイとして docker を使っているので、uim-toolbar-gtk-systray を使う。

 uim-toolbar-gtk-systray &

@ Emacs 用に設定を変更

初期状態だと C-j でも uim-skk がオンになる。 これだと Emacs を使っている時によろしくない。

uim-skk の方は Shift-space でトグルすればよいので、uim-pref-gtk 上の 「SKKキー設定1」の「モード遷移 - [SKK]オン」から Control-j を外しておいた。

@ 追記

@ Java アプリケーションでの入力。

J2SE (1.5.0_04) 上で日本語入力ができないのに気がつく。

~/.Xdefaults に

 *inputMethod: uim

を追加して入力できるように対応 (2005年9月24日追記)

• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• CUPS で Debian から EPSON カラーレーザプリンタへ印刷 ... (2006-01-04)
• Mozex を使って Firefox 1.5.0.1 の textarea... (2006-02-18)
• Iceweasel 2.0 (Firefox 2.0) にほぼ無事移行終了 (2006-11-27)
• 要日本語コンソール環境整備 (2006-08-24)