雑記帳 - JasminInfo

PukiWiki UTF-8版とEUC-JP版

今の ECO-Wiki (acronia) はEUC-JP版

PukiWikiにはUTF-8版とEUC-JP版がありますが、現在はEUC-JP版を採用しています。理由としては、

• 元のECO-WikiがEUC-JPだった
• UTF-8版にすると転送量が増える
• UTF-8版にするとPukiWikiが内部的に使用するファイル名が長くなる
• UTF-8版にするとURLが長くなる（けど、そんなに大した問題ではないかな）
• UTF-8はあまりおすすめしないような記述があった*1

などです。

UTF-8版にするべきか

ただ、最近はUTF-8版にした方が良いかなと考え始めてます。

• 最近の文字コード事情はUTF-8が主流
• PukiWiki公式でもUTF-8推奨になった（PukiWiki開発日記、PukiWiki 1.5.0ダウンロード）
• 転送量は圧縮が効いていればそんなに問題ないかも

とはいえ、EUC-JPで困っているというわけでもないのでUTF-8版に置き換えるかどうかはちょっと悩ましいところです。

UTF-8版にするなら、PukiWiki 1.5.1のリリースに合わせることになるでしょうか。

UTF-8版にする場合の課題

• ファイルなどを全部UTF-8に変換する必要がある
  • 変換スクリプトが作られているようなので、これで変換を試みることになりそうです。
• （英数字以外をページ名に含む）各ページのURLが変わってしまう
  • 検索エンジンなどからのリンクが切れてしまうので、存在しないページにアクセスされたら、EUC-JP版URLへのアクセスと解釈して301 Moved Permanentlyで新URLに転送するような仕組みを入れたいところです。
    • と思って探してみたら、同じ事をやってた人がいました→PukiwikiをEUC→UTF-8移行した後もEUCのURLでアクセスできるようにする - あっきぃ日誌

PukiWiki bodycache patch副作用：id重複

たまたま気が付いたのですが、ECO-Wikiのメニューバーと本文それぞれの見出しのidが重複していました。

例えば、ECO-Wiki (acronia) トップページでは、メニューバーの「ECO攻略Wiki」と本文の「ECO-Wiki (acronia)：エミル・クロニクル・オンライン攻略情報wiki」に同じid="content_1_0"が振られています。

原因を追ってみたところ、どうやらbodycacheパッチの副作用のようです。

• 発生条件
  • PukiWiki bodycacheパッチを適用している。
  • MenuBarと本文の両方で見出しを使用している。
• 原因
  • bodyキャッシュを読み込んだときは、本文に対するconvert_htmlの実行はスキップされる。その結果、convert_html内の$contents_idがインクリメントされなくなるため、メニューバー生成時のconvert_htmlの実行結果に影響を与えてしまう。

    function convert_html($lines)
    {
    	//省略
    	static $contents_id = 0;
    	//省略
    	$body = & new Body(++$contents_id); //この$contents_idのインクリメントが必要
    	//省略
    }
    

• 対策
  • 場当たり的な対応ですが、$bodycache_statusが'cached'になっていたら、bodycacheによりconvert_htmlの実行がスキップされたと見なして、$contents_idをインクリメントするコードを追加しました。

    function convert_html($lines)
    {
    	//省略
    	static $contents_id = 0;
    	global $bodycache_status;
    	if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み
    		++$contents_id;
    	}
    	//省略
    	$body = & new Body(++$contents_id);
    	//省略
    }
    

追記

改良したbodycache patchを公開しました。

タイトルプラグイン(PukiWiki)導入

ECO-Wiki (acronia)にタイトルプラグインを導入しました。これで、ページ名(URL)とは別に、自由にタイトルを設定できるようになります。

導入した理由ですが、検索エンジンでの検索結果には基本的にタイトルが表示されるので、そこを分かりやすくしたかったからです。あとは、うまく使えば検索結果の上位に表示されやすくなってくれるかな～。

bodycacheとの干渉

タイトルプラグインですが、すんなり導入できるかと思ったら、bodycacheと干渉しました＾＾；

タイトルはbody部に含まれないので、確かにそのままだとタイトルはキャッシュ対象外になってしまいます。

対策としては、bodycache側を改造して、タイトルもbodycacheファイルに含めるようにしました。(ファイル構造が変わるのでバージョンを1から2に変更。)

追記: 2015/01/24

今のECO-Wikiの構成だと、ページ内の最初の見出しがほぼタイトル相当なので、最初の見出しをタイトルとして使うようにPukiWikiを改造しました。

そのため、わざわざ#titleで指定する必要はほとんどなくなりました。（#titleによる指定も引き続き可能です。）

ECO-Wiki画像リサイズ

こちらの記事(ECO-Wikiでの画像縮小・拡大)でふれていた、ブラウザ側でリサイズされていた画像について、一部*1をリサイズ済みの画像と差し替えました。元画像は、サフィックス _big を付けたファイル名にリネームして残してあります。

• 例
  • 差し替え画像: KanadeMemory2.jpg (128x345)
  • 元画像: KanadeMemory2_big.jpg (226x609)

ECO-Wiki上の画像サイズ指定について

画像差し替えの際に、画像の実サイズと表示サイズを一通りチェックしたのですが、想像していた以上にいい加減でした＾＾；

例としては、

• 実サイズ：177x111 → 表示サイズ：100x100
  • 縦横比が合っていない
• 実サイズ：128x128 → 表示サイズ：127x127
  • 周りの画像は表示サイズ128x128に統一しているのに何故か1ピクセルだけ縮小
• 実サイズ：128x123 → 表示サイズ：123x128
  • 縦と横が逆

単純ミスのものもあるでしょうし、既存の記述をコピーして修正したときに画像サイズ指定をそのままにしてしまったという可能性もありそうです。不特定の人が編集する場合は、画像サイズ指定は省略した方が無難なのかもしれないですね*2。

画像アップローダーは実サイズを指定した&ref記述を生成するので、これをそのまま使ってくれる分には問題はなさそうですが。

「アンケートページ：今後の ECO wiki について」のコメント

最近、「アンケートページ：今後の ECO wiki について」をチェックしていなかったので気づくのが遅れましたが、

装備品データベース等を面倒ではあるが独立したWikiとしての公開をするべきと思う
acroniaでは別のサイトに飛ぶが検索する閲覧者に酔ってみれば使い勝手が良い物とは言えない

というコメントが付いてますね。

ただ、このコメントの意図がよく分からないです。

• 「検索」がWikiの検索機能を指す場合
  • 独立したWikiでは検索は結局別々なので解決にならない。
  • 今のECO-Wikiに含めるなら検索はできますが、ECO-Wikiが肥大化しかねない。
• 「検索」がGoogle等の検索を指す場合
  • データベースが検索にかかるようにすることを考えるべき。*3

あと、データベースにしておかないと、細かな条件を付けた検索や、データの機械的な再利用が困難になるので、よほどの事が無ければデータベース化が望ましいと思います。

・・・というか、Wiki管理だと数が多すぎて破綻しそう＾＾；*4

• 圧縮転送による読込時間改善
  • 結果
• 画像の遅延ロードの設定変更
• ECO-Wiki (gamedb) と検索順位
• スパム状況

圧縮転送による読込時間改善

以前、ECO-Wiki (acronia) でページ生成時間を表示するようにしましたが、内容が多いページではかなり時間がかかっているのが気になりました。

例えば、Iris/Explanationでは

HTML convert time: 0.007 sec. (total: 2.447 sec.)

と数秒かかり、実際に体感できるロード時間も同程度です。

これは、Iris/Explanationだとページ(HTML)サイズが約700kBとちょっとした画像並みに大きいため、単純に転送に時間がかかっていると思われます。

そこで、転送データをgzip圧縮して転送量を削減してみることにしました。さくらのレンタルサーバーは半年くらい前からmod_deflateが使えるようになったらしいので、以下の記述*1を .htaccess に追記します。

<FilesMatch "\.php$">
	SetOutputFilter DEFLATE

	BrowserMatch ^Mozilla/4\.0[678] no-gzip
	BrowserMatch ^Mozilla/4 gzip-only-text/html
	BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

	AddOutputFilterByType DEFLATE text/html
</FilesMatch>

続きを読む