nDiki : PageName

WiKicker 実装

URI まわりと、DB まわりの実装すすめる。UTF-8 PageName をファイル名にマッピングするのに base64 を使おうと思ったら、符号化される文字に '/' が含まれているのか。 '.' に置き換えた変形 base64 にすればいいかな。

[ WiKicker ] 自動InterWiki

一昨日実装した、 複数のキーワード集合による、AutomaticLinkモジュールを WiKicker CGI プログラムから使えるようにしてみた。

ローカルにおいておいたキーワードリストファイルを読み込み AutomaticLink 処理(WikiForum 内で AutomaticLink でマッチしていない部分文字列に対して)。 マッチした場合は InterWiki を使ってURIに変換しリンク化する。

あわせてIndexPage.txtでWiKicker WikiForum 内の PageName を取得できるようにした。

これで例えば、2つの WiKicker WikiForum が cron で互いの IndexPage.txt を定期的に取得し、AutomaticLink するようにすれば、相補的に連携する事ができるようになる(ただし AutomaticLink のみ。WikiName や BracketName は依然としてその WikiForum 内のみ)。

AutomaticLink でのリンク先は(指定した)任意の InterWiki で定義できるので、あるキーワード集合について Google の検索結果ページや「はてなダイアリーキーワード」への自動リンクも実現可能(はてなダイアリーキーワード自動リンクAPIはキーワードリストではなく正規表現を返してくるので、元に戻す必要有り。またあれだけ巨大なキーワードリストだと毎回 AutomaticLink のために、trie 再生成するのも辛いのでもう一工夫必要)。

[ Perl ] Devel::SmallProf

行毎のプロファイリングを実現する Perl モジュール。 メジャーどころの Devel::DProf がサブルーチン毎なのに対して、こちらはより細かい粒度で実行回数などを計数できる。

WiKicker だと、PageName <-> FileName の部分がページ数が増えるに従って気になりだしたな。 PageName リストファイルとか作ってそれを読み書きするのとどちらが速いだろうか。

AWStats 6.0

www.naney.org のアクセスログをローカルにもってきて統計解析をするのに、今回は analog ではなく AWStats を使うことに。

以前 www.naney.org に入れてみた時より、随分使いやすくなった感じ。

セットアップ

Debian パッケージを入れた後、awstats.naney.org というバーチャルドメインをローカルのApacheに用意(/var/www/awstats.naney.org)。

 Alias /icon/ "/usr/share/awstats/icon/"

も設定に追加しておく。

ファイルレイアウト:

 /var/www/awstats.naney.org/
  |
  +-- .htaccess
  |
  +-- awstats.conf  <-- 作成
  |
  +-- awstats.pl    <-- コピーしてきて一部修正
  |
  +-- cache         <-- DNSキャッシュ用 (まだ未使用)
  |
  +-- data          <-- データを保存
  |
  +-- plugins       <-- プラグイン
       |
       +-- wikicker.pm <-- /wiki/(.*).html を $1 で表示するプラグイン(自作)

awstats.pl はパッケージのものをコピー。DecodeEncodedString の中で Jcode.pm を使って文字列を UTF-8 に変換するように修正。

ローカル用なのであまり気にせず DocumentRoot の下にもりっとファイルを置いておく。

awstats.conf はこんな感じ。

 LogFile="/path/to/downloaded-log/access.log"
 LogType=W
 LogFormat=1
 LogSeparator=" "
 DNSLookup=2
 DirData="./data"
 SiteDomain="www.naney.org"
 HostAliases="localhost"
 DNSStaticCacheFile="cache/dnscache.txt"
 DNSLastUpdateCacheFile="cache/dnscachelastupdate.txt"
 URLWithQuery=1
 URLReferrerWithQuery=1
 LevelForWormsDetection=2
 ShowWormsStats=1
 LoadPlugin="wikicker"
 ValidHTTPCodes="200 304 -"

ValidHTTPCodes の '-' というのは、本来不要。自前のSSIで似非 Combined Log を生成する際に '-' を出力する事があるので追加。

日本語もきちんと出るしいい感じ。 指定した月ではなく、指定した日のログを見れるといいのだが設定すればできるようにならないかな。

analog と違ってプラグインが使えるのが良い。 Perlスクリプトだから、その気になれば簡単に awstats.pl 自体を変更する事もできるし。

今回は ShowInfoURL 用プラグインを書いて、/wiki 以下のURLの際は unescape して PageName を表示するようにしてみた。

その他いろいろ遊べそう。

最後がピリオド(.)で終わるファイル名をつけられない

Windows で「最後がピリオド(.)で終わるファイル名」を新規作成する。 最後のピリオド(ドット)が無くなる。

……。

8.3形式の名残なのか? Explorer 上で作成しても、プログラム(Perlスクリプト)から作成しても駄目。

環境は Windows XP Home Edition SP2 + NTFS。 Windows 2000 + NTFS でも同様。

WiKicker

これは WiKicker のテストをしていて気がついた。 WiKicker では「PageName の base64 を生成し 『/』 を 『.』 で置き換えたもの」をファイル名にしている。 例えば UTF-8 で「タ」は

 44K/

となるので、ファイル名は 「44K.」となる。 で最後の文字が消えてしまうので、デコードするとおかしくなると。

これを機会に Windows 環境でのエンコーディングは RFC3548 「4. Base 64 Encoding with URL and Filename Safe Alphabet」を使うように変更するか。

本当は全てこれに変更したいのだけれど、すでに動いている WikiForum の事を考えると移行は難しいかも。

Punycode はファイル名用エンコーディングには向かない

WiKicker の Win32 用ファイル名エンコーディングとして使えないかなと考えていた、 Punycode を試してみる。 実装としては IDNA::Punycode Perl モジュールを使用。

• 空白は空白のまま
• / は / のまま
• アルファベットは大文字小文字を維持したまま

という点で PageName をファイル名にエンコードするのには向いていないことがわかった。 「エンコード後の文字列が短い」「コードが小さい」等の特長があるらしいので、期待していたのでちょっと残念。

WiKicker における PageName 最長文字数

WiKicker では PageName を エンコードした文字列を URI に埋め込んだり、サーバで保存する際のファイル名にしたりしている。 このため、PageName の最長文字数はそれらの最長文字数に依存しているはずである。

今まで確認を後回しにしていたのだが、新しい機能の追加の際に確認しておく必要があるので調査してみた。

WiKicker の実装

WiKicker の実装がらみとして最長を決める要素としては

• PageName の UTF-8 表現を URI エスケープしてページ URI に含めている。→ URI、HTTP、HTML、Web サーバ、Web ブラウザの実装による最長の制約
• PageName を base64 にエンコードしてファイル名にしている。→ ファイルシステムのファイル名、パス名の最長の制約

がある。

各仕様等による制約

• HTTP では URI の長さには制限なし (RFC2616 3.2.1)
• Web サーバは Request-URI が長いと 414 Request-URI Too Long を返す (RFC2616 10.4.15)。Apache は LimitRequestLine ディレクティブにより、URI を含むリクエスト行のサイズを制限することができる(配布時には 8190)。
• Internet Explorer が扱える URL の長さは 2083文字。
• ext2 はファイル名は 255文字まで(増やすこともできる)。
• 手元の Linux 2.6.15 で試したところ、パス名は 4095文字まで。

WiKicker で問題が出ない PageName 最長文字数

上記の中ではファイル名による制約が一番大きい。

WiKicker 内部でファイル名として base64 (の亜種) でエンコードしたものを使っているので、元の文字列はは最長 189バイトまでなければならない。base64 だと3バイトで4文字になるため、189バイトで 252文字となる。

WiKicker ではここでさらにファイル名に ',v'、'-lock' をつける事があるので、実際には元の文字列は最長 186 バイトまでとなる。

PageName が 186 バイトまでだとすると、URL エスケープしたとして558バイト。 WikiEngine のスクリプトの URL や他のパラメータとあわせても、これぐらいなら大丈夫のはずである。

ということで WiKicker では Linux 上だと通常 PageName は 186 バイトが最長と言ってよさそうだ。 日本語の文字はだいたい UTF-8 で3バイトになるので、62 文字までということになる。

そのうち、WiKicker に制約チェックを入れることにしよう。 そのうち。

ケータイ用にプライベート Wiki を設置

パケ・ホーダイを契約してから、MovaTwitter・RTM・モバイル Gmail などで携帯電話を活用するようになった。そんななか、決定打がないのが、ノートアプリケーション。電車の中などの隙間時間に、この nDiki の 下書きなどはケータイでできるようにしたい。

Google ドキュメントが使えればいいが、前年ながらまだiモードでは使えない。 メールベースでやる手もあるが、メモには良いものの再編集を繰り返したいようなものに難がある。

ということで自前でプライベート Wiki を立てそこに書き込んでみることにした。

iモードから WiKicker

使う WikiEngine はいつも通り自作の WiKicker。

書き込んだテキスト内のキーワードを nDiki へ自動リンクさせることができるので、パーソナルナレッジベースとして自分にとっては一番便利。書式も同じなので、Wiki に書いた下書きを、そのまま nDiki で使える。

肝心のケータイからの書き込みだが Ajax 等凝った技術を使っていないおかげで、問題なく FOMA 端末(D703i)からiモードで読み書きできた。WiKicker は UTF-8 でページを出力しているが、網側か端末側の処理かは知らないが今のところ問題なし。

なお認証は簡単に Basic 認証で済ますことにした。 安全とは言えないがそれほど重要なデータを置くわけではないしいいかな。 cookie は必要ないし WikiEngine に手を入れなくてもよいので、すぐできるのはコレ。

ユーザ名とパスワード付きのトップページ URL を端末でブックマークしておけば1発でアクセスできる。

Google Mobile Proxy 経由で使う

これでケータイ(と PC)から使えるプライベート Wiki を設置できたわけだが、なにぶんもともとケータイをサポートしている WikiEngine ではないため、長いページの分割機能などはないのがちょっと不安。PageName で生成される URL が長くなった時の振る舞いもちょっと不安。

そこで Google Mobile Proxy (http://www.google.co.jp/gwt/n) 経由で Wiki を使うことにした。 ページを携帯端末向けに変換してくれる proxy で、Basic 認証もできるしフォーム の POST もできる。

Google Mobile Proxy 経由で見たページ内のリンク先も全て自動的に proxy 経由になるので、 PC 向け Web ページの URL を書いておけばそのまま携帯電話で見ることができる。

安全のためか、比較的短い一定時間立つと認証の再確認画面が表示されてしまうが、ユーザ名とパスワードを入力すれば、セッションは継続される。 テキスト編集に時間がかかってしまうと POST する時にひっかかってしまい認証の再入力がちょっと面倒だが、再認証が通れば POST リクエスト自体は有効で書き込みがロストすることはないようだ。

しばらくはこれで読み書きしてみよう。

なんで社内 Wiki じゃなくて howm + Markdown ビューアかって?

「(自前の) Markdown ビューアじゃなくて Wiki に……」って言われた。もっとも。できるだけオープンに情報共有された方がハッピーだと常々思っているので、ちょっと耳が痛い。

なぜ Wiki じゃなくて howm + Markdown ビューアなのかの言い訳。 うーん Wiki といいつつ、もはや(ハワイ語的) WikiWiki じゃないからかな。

• Confluence はリッチテキストエディタ中心になってしまったのでもはや wikiwiki じゃない。
• PageName とぱっと考えるの面倒。置く階層を考えなければならないのも面倒。 howm だと日時からファイル名が決まって新規作成なので wikiwiki。
• ブラウザベースだと Emacs でぱっと書けない。コマンドの実行手順とか。tmux でリモートホストで実行した記録をコピーして、そのまま Emacs にペーストしてちょっとメモして完了にしたい。

整理してストックしておくものはきちんと Wiki に書き直すのがもちろんいいんだけれどね……。

今日のさえずり: iPad 2 を iOS 7.1.2 にソフトウェアアップデート中

• 07:58 iPad 2 を iOS 7.1.2 にソフトウェアアップデート中。
• 08:44 RT @TwitPic: We're happy to announce we've been acquired and Twitpic will live on! We will post more details as we can disclose them
• 10:55 なんで社内 Wiki じゃなくて howm + Markdown ビューアかって? PageName と階層考えるの面倒なんだもん。テンポラリとかだと特に。
• 21:35 RT @HR_mixi: 昨日はミクシィのインターン生を集めて懇親会を行いました！弊社の社員もインターン生も、お酒を交えながら楽しく話ができてよかったです！ http://t.co/RdYgAMFji6