ここ最近愛してやまないゲーム、Victoriaのwikiが、鯖缶の手抜き管理のおかげで、週に二回データが飛ぶという事態に見舞われた。
そこでついカッとなって、hikiで構築された全データをcurlで抜き出してきて、pukiwikiにコンバートするというチャレンジを始めてしまった。なぜにhikiからpukiwikiにしたかというと、hikiはページ情報をinfo.dbというファイルで一元管理するため、ファイル数が増えるとめちゃくちゃ重くなってしまう。んで、熱心なファンに支えられていたVictoria wikiはすでに総ページ数650を超え、hikiの仕組みでは正直つらい状態になっていた。ほんで、とりあえずいくつか候補を挙げて検討した結果、とりあえずバカっ早いpukiwikiに決定した次第。
ファイル数がそこまで増えてるなら、RDBの出番でしょ、ということで一瞬media wikiというのも考えたけど、ありゃあログインしてページ編集が前提のシステムなので、2chのスレ住人が中心のVictoria wikiにはスタイルが合わないと考えた次第。ちなみに海外のパラドゲーwikiは、全部media wikiだ。向こうはコテが当たり前の文化だしね。
もちろん、pukiwikiにも、現状php5がアウトだとか(勘違いでした)、管理面でのユーザビリティがいまいちだとか、書式がさわやかにゴーイングマイウェイだとか、つーか今更euc？とか、将来を見込むと色々不安要素はあるものの、現状ではベストな選択だと考えた。 ユーザーも多いし。
まず、ファイルの持ち方。
hikiは、空白を+記号に変える、RFC1738じゃないurlencode（なんて呼ぶんだこれ）されたページタイトルをファイル名として、dataディレクトリ以下の、textディレクトリ下にファイルを格納する。添付ファイルは、cache/attach下に添付されたページ名のディレクトリを作り、その下にRFC1738じゃないurlencodeされたファイル名で格納される。ここで、注意しなければならないのはページのファイル名は、最初に作成されたときのものから変わらないと言うこと、ページのタイトル変更は、info.dbの中で管理するのだ。まあ、こんな事やってるから重いんだろうな。
対するpukiwikiは、ページ名にlib/func.phpに入ってるユーザー関数、encode()を通した名前.txtをファイル名としている。格納場所はwikiディレクトリ。まー、どうせurlencodeした時点で読めないんだから、だったら独自encodeかまして、%とってファイル名短くしてもいいんじゃないと言う発想か。まあ、urlencodeしたら完全読めなくなる、2バイトコード文字圏の発想でもあるやね。添付ファイルは、 encode(ページ名) _ encode(添付ファイル名) として、attachディレクトリに格納。まあ、このファイル格納方式はhikiよりは優れてると思う。
で、コンバート方法は、hikiのtext以下にあるファイルのファイル名を一度decodeしてから、encode()をかけて、後ろに.txtをつけた形にリネームして、wikiディレクトリにコピー。画像ファイルをディレクトリ名_ファイル名で、それぞれencodeをかけて、attachディレクトリにコピー、となる。
なお、最初、autolink.infが作成されると、すべてのページが真っ白になるという謎な現象が発生したが、pukiwiki.ini.phpの$autolinkの値を32に増やしたところ直った。なんだったんだ？
hikiとpukiwikiは全然書式が違うので、ページの中身は当然変換をかけなきゃならない。
自分はここを参照した。Wikiの文法比較
ちなみに、ここの表は”text”と”’text”’のhikiの説明が間違ってるので注意。hikiでは、”text”が斜体、”’text”’が強調なのだ。pukiwikiはその逆。んじゃ、直してこいって？ うん、まあそうなんだけどね。なんとなく躊躇しちゃって…
正規表現での一括変換だけでは、なかなかうまくいかず、結局結構な手作業が発生して、激しくだるかった。でもできあがったwikiはhikiより全然早くなったので、まー満足。
Victoria’s wiki
そんなわけで、hiki2pukiwiki覚え書きでした。もー、こんな面倒なこと二度とやらねえ。