O'GANE'S EXPERIENCES

　試行錯誤の結果yukiwikixを導入することができた。つまづきやすい初心者のyukiwikixプラグイン導入記録です。

code_utf8でつまづく

　まず何も考えずにyukiwikixとプラグイン中で使用されているcode_utf8をyu-ji's blogさんからダウンロードしてblosxomのpluginsディレクトリに入れた。(それぞれのperlソースをEUCに変換しておいた。)

　説明をよく読まずにとりあえず試したのがまずかった。code_utf8を入れてからBlosxomのコンテンツ(EUC-JPで統一)の文字化けが起こったのだ。code_utf8がblosxomの文字コードをutf8に変換して出力するプラグインだと気づくのはだいぶ後のこと。

　説明をよく読むとcode_utf8は必要ないのでpluginsディレクトリから削除した。すると今度は文字化けが起こらず(当たり前)にBlosxomが表示された。

改行コードでつまづく

　記事に＜yukiwikix＞タグを書き込んで保存すると…、ちゃんとテキストが整形されてる〜と思ったら、整形されていたのは記事の1段落目だけ(タイトルと、文頭〜改行までのこと)。残りの段落は何故か引用形式として整形されていた。

ここで頭を悩ますこと1時間半(講義一コマぶん)。

　yukiwikiでは行頭にスペースがあると引用形式に整形される。何かのコードがスペースと解釈されているのではないか、と見当をつけて原因を探る。行(段落)付近にあるコードといえば、改行コード。不具合があった記事の改行コードはCR+LF(0dh,0ah)でした。

　yukiwikixのソースの改行コードはLFでした。つまりyukiwikixはLFコードのみを処理して、おそらく行き場を失ったCRが引用整形を引き起こしていた。

　そこで記事の改行コードをLFにして更新してみたら万事うまくいったのでした。

　万事うまくいったかに見えたyukiwikixの導入はwikieditishによる新規エントリの作成によって新たな問題を呼んだ。行末への改行コードの二重付加はwikieditishで新規エントリを作成するたびに起こっていた。

　各行に、

0D 0D 0A 0D 0D 0A 
cr cr lf cr cr lf

こんな感じで。だから整形の際に毎回先と同じ問題が発生する。

　対処としてwikieditishの

    $title = param('title');
    $body = param('body');

のあとに

    #escape
    $title =~ s/\x0d\x0a|\x0d|\x0a/\n/g;
    $body =~ s/\x0d\x0a|\x0d|\x0a/\n/g;

と付け加えて改行コードの統一を行わせることにした。一応、スッキリな改行になりました。