移行理由
ある専門分野のためだけの情報サイトをPukiWikiで運用しているのですが,以下の理由でDokuWikiに移行することにしました.
- 文字コードの変換が必要
- HTMLコードを直接書き込めない(安全という意味でも有る)
- 最適化するにはかなり高度なスキルを要する
2番目や3番目の問題は余り本質的では有りません.DokuWikiにしたところで,殆どPlug-inのお世話になるだけですから.
文字コードの問題
最大の要因は,1番目の文字コードの変換.
2006年03月,同サイトを立ち上げた際に「日本製」という事も有って選んだのがPukiWiki 1.4.6でしたが,当時の文字コードは未だEUC-JPだけでした.
ところが運の悪いことに,その直後の2006年06月に公開されたPukiWiki 1.4.7で始めてUTF-8版が登場したのです.
その頃は未だコンテンツも少なめでしたので,直ぐに切り換えてしまえば良かったのですが,私のパソコン環境がubuntuのみという事も有って,余り気にもせずに放置していました.Windows環境なら少しは気にしていたかも知れませんねぇ...
しかし,コンテンツがかなり増えてきて,バージョンもPukiWiki 1.5.1となった2016年頃からそろそろ UTF-6 に変換しておくか?と考えた頃には時すでに遅し.
PukiWikiページ内の文字コードを変換するのは容易でしたが,ファイル名もEUC-JPだと知り,それが日本語のままならまだしも,Web用にURLエンコードされてしまっています.例えば
ファイル名 → %E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%90%8D
となる「アレ」です.そう,Wikipediaのリンクを貼った時に見られる「アレ」です.
この「ファイル名」はUTF-8コードですから,URL欄でもちゃんと日本語として見えますが,ETC-JPをエンコードした場合は
ファイル名 → %A5%D5%A5%A1%A5%A4%A5%EB%CC%BE
となって,URL欄でもこのままでしか表示されません.これが,文字コードをETC-JPのまま使い続ける事の最大の問題点です.
これの変換を一気に片付けるのがやたら難しすぎて,未だに解決に至っていません.
これがうまく出来ていれば,DokuWikiへの移行は考えなかったと思います.
wikiエンジンによる違い
以下に,各Wikiエンジン別の特徴をまとめてみました.正しくは「可」でも,扱い難い場合は「不可」にしている場合があります.
現在 | 推奨 | 移行対象 | Wikipedia | |
PukiWiki | PukiWiki | DokuWiki | MediaWiki | |
バージョン | 1.5.1 | 1.5.4 | “Igor” | 1.39.2 |
リリース | 2016/03/07 | 2022/03/30 | 2022-07-31a | 2022.09.07 |
文字コード | EUC-JP | UTF-8 | UTF-8 | UTF-8 |
ファイル名 | EUC-JP | UTF-8 | UTF-8 | UTF-8 |
PHP対応バージョン | 7.4以下 | 8.1以下 | 8.1以下 | 8.2以下 |
ページの階層化 | 可 | 可 | 可 | 不可 |
DBの使用 | 無し | 無し | 無し | 有り |
ビジュアルエディタ | Plug-in | Plug-in | 標準 | 標準 |
セクション編集 | 不可 | 不可 | 可 | 不可 |
サーバ環境 | レンタル可 | レンタル可 | レンタル可 | 専用 |
上の表を見ても,PukiWikiのバージョンを上げるだけで良さそうなものですが,ここに来てトラブル発生.
何度か文字コードの変換をローカルで試みては元に戻していたつもりが,差分ファイルなども全て変換しておく必要があったことなどから,Wikiシステムがおかしくなりだしたのです.
同時に,鍵をかけ忘れたファイルに不正アクセスされたらしく,ゴミファイルが溜まり出しました.
とうとう今では,サイトに表示されるページ名の最初だけ文字化けする始末.
早く原因を特定して元に戻したいのですが,この件に関してはもう疲れました.
2023/04/08追記 pukiwiki.php.ini等に加えられた変更箇所を元に戻すことでなおりました.
DokuWikiへ
と言う事で,同じWiki系システムを探していたところ,ACL(Access Control List)が作りやすく,エディタも画像添付がし易くて,「足りない機能はPlug-inで補う」事が徹底されているためか,意外に操作しやすい印象を受けたのがDokuWikiでした.
一抹の不安は,PukiWikiと違って名前空間という概念を理解しなければいけないこと.PukiWikiにも同じ様な概念はあるのですが,ページ内で階層構造に関連付けされるだけで,ファイル構造が階層になるわけではありません.ですから,DokuWikiでは同じ名前のページでも,違う名前空間で使うことは出来ますが,PukiWikiでは使えません.これは結構不便で,同じ名前を違うカテゴリで使う場合は,何かしら違う名前にしなければならないと言うことになります.
同じ名前でも違う意味のカテゴリで説明したい時などは,一工夫しなければいけません.
しかし,DokuWikiではカテゴリ自体を階層と考えれば,同名のファイルは違うカテゴリならいくつでも作成する事が出来ます.英語名と日本語名で使い分ける時も,ファイル名は同じ英語名にしておけば,URLエンコードで冗長になることもありません.SEO対策に有効ですねぇ.
まとめ
とまぁ,DokuWikiに移行する理由をゴタゴタと書き並べましたが,結局は「手作業で移行しやすい」事が全てでした.
ファイル(ページ)同士の関連付けもPlug-inが要りますが,名前空間をあちこちに移動させることで,自由に構築し直せます.こういう機能はPukiWikiにはないので,ファイル内で書き換えてやる必要があります.コレは大変です.
とは言っても,やはりシステムが違うことから「MarkDown」表記の方法が違っていたりして,慣れるまでは大変でした.
後で判ったことですが,DokuWikiは「階層の見出しレベル」がセクション扱いとなって,このセクション毎に編集が可能というのが非常に便利です.
いろいろありましたがようやく,移行が完了しそうです.
PukiWikiにはあった機能が使えないこともありましたので,一部のコンテンツは「アーカイブ」という名前空間を作って,そこにまとめて保管することにしました.いつかいいPlug-inを見つければ,正常な状態に戻すつもりではいます.
何れにしろ,本来の「Wiki」とは?を言い出すと,
不特定多数のユーザーが共同してウェブブラウザから直接コンテンツを編集するシステム
Wkipedia
と言う事から,私しか投稿・編集が出来ないWikiスペースは邪道なんですけどねぇ...
補遺
余談ですが,PukiWiki,DokuWikiの様に「複合語の先頭文字だけを大文字で表し一語にする表記方法」をCamelCaseと言うそうです.間のスペースが無くなるので,一語として扱えることからリンクを表す時に専ら使用されたそうですが,Wikipediaに使用されているMediaWikiではブラケット([[,]])等が使用されるようになり,PukiWiki,DokuWikiの何れも今ではその表記方法になっています.
ファイル(ページ)名の場合は,例えばDokuWikiでは「Once upon a time」は自動的に「once_upon_a_time」と,スペースがアンダースコア(_)に置き換わり,全て小文字に置き換わります.この事は,新たにページを作成する時に自然な単語のままで扱えるので便利です.
2023/04/08追記 この様なスクリプトを作られていました.スゴイ!
コメント