こんばんは、aquaです。

さて、何とかffmpegthumbnailerをインストール出来たので、そもそもの目的であったmediatombの動画サムネイル対応をトライしてみる。PS3で動画選択時に動画のサムネイルを表示出来るようにする。最新版である0.12.1をダウンロードしてソースからインストール。前バージョン同様、インストール自体はすんなり問題なく出来た。一応気にしたのは、configureの最後に表示されるCONFIGURATION SUMMARYの中で、ffmpegthumbnailerがyesになっている事。当然だが、ffmpegthumbnailerを準備する前はnoになっていた。

新しいconfig.xmlにて、もう一度設定を加える。設定ファイル内でffmpegthumbmailerが有効になっている事を確認。以前と同じく、mysqlを利用する設定やm2ts、asfなどの拡張子への対応を加えていく。DBも一度消去してテーブルから再作成した。mediatombを起動した後、ウェブから管理画面にアクセスして対象の動画ディレクトリを登録する。以上で再構築は完了なので、早速PS3からアクセスしてみる。XMBからmediatombの動画コンテンツを表示すると、しばらくウェイトした後に･･･サムネイルが表示された！

ここまでは非常に簡単だったのだが、再び動画タイトルの文字化け問題が発生。今回も様々な組み合わせを試みるが、なかなか解決せず。テンプレートもいじったりしてみたが効果なし。諦めて一旦設定を戻して、対応を翌日に延期する。翌日、改めて見てみると文字化けが解決してる･･･。結論から言うと、config.xmlでは以前と同じく、filesystem-charsetやmetadata-charsetをCP932に指定する。今回のバージョンでは、mysqlはutfのままでよいみたい。この組み合わせで、データをローディング直後は文字化けするのだが、しばらく放っておくだけでそれが直るようだ。

あとは各種フォーマットのコンテンツへの対応を確認する。動画コンテンツから見てみると、asfはwmvとして処理する事で問題なし。m2tsもmpegにマッピングして再生出来た。音楽コンテンツもomaについては再生可能。更に驚きだったのだが、前バージョンでは再生出来なかったaa3もomaに紐付ける事で再生出来るようになった。文字化けのところの動きがちょっと納得いかないが、基本的にやりたかった事は全て可能となった。参考までに、以下に自分で設定したファイル・フォーマットのマッピングを記しておく。

<map from=”asf” to=”video/x-ms-wmv”/>
<map from=”m2ts” to=”video/mpeg”/>
<map from=”oma” to=”audio/x-sony-oma”/>
<map from=”aa3″ to=”audio/x-sony-oma”/>

こんばんは、aquaです。

以前の記事で紹介したとおり、ファイルサーバ上に貯まった動画や音楽をネットワーク上で共有するために、LinuxのDLNAサーバであるmediatombを利用している。ファイルサーバはsambaで公開されているので、Linux側ではsmbmountしてmediatomb上で公開している。DLNAクライアントは今のところPS3しかない。一般的な動画や音楽は再生できているが、幾つか気になる問題が残っていた。その1つが主題にもなっているコンテンツの日本語タイトルにおける文字化けだ。sambaサーバ上でコンテンツを管理しているため、ややこしい状況になってしまっている。

sambaサーバ上の文字コードだが、ファイルサーバであるtera stationなので細かい設定を確認する事は出来ない。が、windows環境から文字化けせずに見えているので、おそらくSJISだろう。これをmediatombのブラウザでアクセス出来る管理ツールで確認すると、既に文字化けしている。まずはここから修正を試みてみよう。これについてはそれほど難しくなく、mediatombのconfig.xmlにてファイルシステムとmediatombの文字コードをSJISに指定すればよい。具体的には以下のような設定を追加した。

<filesystem-charset>CP932</filesystem-charset>
<metadata-charset>CP932</metadata-charset>

この設定でブラウザ上で確認できる文字化けは解消する事が出来た。しかし、それはFilesystemタブ側だけの話で、Database側の文字化けは依然続いていた。DBにはmysqlを使用しているのだが、ここのテーブルの文字コードはutf8が指定されている。ここも同様にSJISに直さなければならないだろう。タイトルが含まれるテーブルはmt_cds_objectというテーブルなので、この表だけSJISで作成し直した。この変更はテーブル定義を修正する形で対応した。こちらも具体的には以下のDDLを実行した。

ALTER TABLE mt_cds_object CHARACTER SET sjis;

しかし、それでも文字化けは解消しない。ほぼ諦めかけていたのだが、もう一度DBの中身を確認してみると文字化けしたままの状態だった。何となく一度データを消して、コンテンツを再登録してみると･･･上手くいった！これで日本語を多く含む音楽データもDLNAサーバ上で扱う事が可能となった。ついでにATRAC3のaa3ファイルを対応させようとしたが、PS3では再生する事が出来なかった。ファイル名の拡張子をomaにして、以下の設定を追加すると再生出来るのだが。ATRAC3のハンドリングがいい加減面倒になってきたのでmp3に移行しようかな･･･。

<map from=”oma” to=”audio/x-sony-oma”/>

こんばんは、aquaです。

本ブログへgoogleからの誘導が激減してから約一ヶ月、しばらくはPVの改善も見込めなそうなので、思い切って携帯対応してみた。携帯コンテンツであれば、また別の評価がなされるかもしれないし。どうやらwordpressのモバイル対応はプラグインによって簡単に実現できそうだ。今回は『Ktai Style』という評判の良いプラグインを使う事にした。いつも通りダウンロードして解凍したファイルを${WORDPRESS}/wp-content/pluginディレクトリに配置し、『プラグインの管理』画面でktai styleの欄で『使用する』をクリックする。

プラグインを有効化すると、『設定』と『テーマ』というリンクが選べるようになる。まず設定から確認したが、特に気になる設定箇所はなかった。次にテーマを見てみると、最初から幾つかのテーマが用意されていた。『photolog』というものが最も好みだったので、これを選択してみた。『コメントなし』がやたら目立つので少しだけ内容をいじった(wp-content/plugins/ktai-style/themes/photolog/index.html)。コメントへのリンクを削るのと(38行目辺り)、スペースが出来たので記事サマリーの文字数を増やした(43行目辺り)。

コンテンツが出来たところで、今度はモバイル用のsitemapを作成する。プラグインの改造もやってみたかったが、今回は時間をかけずに生成されたsitemap.xmlを変換して構築する。大した変換は必要なく、以下の変更を行えばよさそう。ファイルはsitemap-mb.xml.gzとして保存する。

xmlnsの箇所にxmlns:mobile=”http://www.google.com/schemas/sitemap-mobile/1.0″の追加
urlの箇所にの追加

our @input;
our @output;
our $file;
our $root_dir="${WORDPRESS}";
our $source="sitemap.xml";
our $mobile="sitemap-mb.xml";

open(IN, "<$root_dir/$source"); open(OUT,">$root_dir/$mobile");
while(<IN>){
        s/(xmlns=\".*\")>/$1 xmlns:mobile=\"http:\/\/www.google.com\/schemas\/sitemap-mobile\/1.0\">\n/;
        s/<\/url>/      \n     <\/url>/;
        print OUT;
}
close(IN);
close(OUT);

my $src_file="$root_dir/$mobile";
my $zip_file="$root_dir/$mobile.gz";
gzip $src_file => $zip_file;

以上の設定でしばらく運用していると、googleのウェブマスターツールでHTTPエラー(400 bad request)が多く発生していた。調査してみると、これはktai styleの仕様らしいので、robots.txtで該当の処理をクロールされないように設定する。具体的には以下のように設定した。

User-agent: *
Disallow: /wp-content/plugins/ktai-style/inc/redir.php

以上で、本ブログを携帯でも使う事が可能となった。

こんばんは、aquaです。

先日のURL改変について、ほぼ全ての旧URLを新URLに301リダイレクトするように設定出来た。数日が経過した後、googleウェブマスターツールにて状況を確認してみる。しかし、残念ながらタイトルタグの重複数は減少していない。状況を正確に確認するためにアクセスログを見ながら、実際に旧URLをクリックしてみる。間違いなく新URLに転送されているが･･･、よく見てみるとリダイレクトのHTTPステータスコードが『302』になっている。ソースを確認し、『ylsy_permalink_redirect.php』ファイルの405行目を以下のように修正。

function wp_redirect($location, $status=302) {
↓
function wp_redirect($location, $status=301) {

これで、今度こそ301でリダイレクトするようになった。次にクロールエラーを確認してみると、数百件に及ぶ『クロールを完了できませんでした』というエラーと更に十件強の『見つかりませんでした』エラーが発生している事に気付く。中身を確認してみると、幾つかの投稿ページのうち、タイトルを変更したページの旧タイトルが404としてリストされている。それほど数もなかったので『Redirection』プラグインにて、新タイトルにリダイレクトするよう個別に設定していく。

今回は念のため、アクセスログにてHTTPのステータスコードを確認する。旧URLをクリックしながら、アクセスログをウォッチしていると妙な動きが目に入った。旧タイトルが新タイトルにリダイレクトしているのは想定通りだったのだが、投稿ページへのアクセスが大文字含むURLから全て小文字のURLへと301リダイレクトされている。気になったので、ウェブマスターツールにて先ほどの『クロールを完了できませんでした』ページを見てみると、全て投稿ページで『リダイレクトエラー』と表示されている。

とにかく、このリダイレクトが悪さをしていると判断。どのプラグインで処理がなされているかの特定から調査を始める。各プラグインを有効・無効を切り替えていく方法で、すぐに『Permalink Redirect』の問題とわかった。かと言って、プラグインを止める訳にも行かないので回避方法を検討。Permalink Redirectのページ内に『Paths to be skipped』という設定を行う箇所があった。うちのサイトは投稿ページのURLが『/%category%/%postname%/』で、しかもカテゴリが全て日本語のままなので、全ての投稿ページが『/%』で始まる。試しに『/%.*』と設定して動作確認したところ、投稿ページにおける小文字リダイレクトは発生しなくなった。URL改変は本当に怖いね･･･。

こんばんは、aquaです。

前回のURL改変後より相変わらずPVが回復していない。今度はsitemap.xmlを作成して、検索エンジンに認識して欲しいURLを明示的に伝える事を試す。wordpressでsitemap.xmlを生成するには『google-sitemap-generator』を利用する。こちらよりプラグインをダウンロードしたら、いつも通りプラグインのディレクトリに配置する。wordpressの『プラグインの管理』ページより『Google XML Sitemaps』を有効化する。設定メニュー内にある『XML-Sitemap』にて必要な設定を行った後、『サイトマップを構築する』リンクをクリックすれば生成できる。

生成と同時にgoogleへの通知も行ってくれるが、念のためgoogleの『ウェブマスターツール』でも確認しておく。実は今まで利用していなかったのだが登録は非常に簡単。『サイトを追加』ボタンをクリックして自サイトのURLを登録する。あとは幾つか用意されている確認方法にて正当性をチェックする。今回は一番簡単そうなメタタグによる確認を選択。発行された任意のメタタグを自サイトのトップページに埋め込む。これで確認が済めば検索に関係する様々な情報にアクセス出来るようになる。

適当に情報を見ていると『診断』の『HTMLの候補』ページにて『タイトルタグの重複』が数十件カウントされている。中身を見てみると、投稿ページの旧URLと新URLが幾つも表示されていた。canonicalで処理していたつもりだったけど、余り意味ないのかな･･･。日付ベースだった旧URLからカテゴリベースの新URLに301リダイレクトをする方法を考えてみる。URL内に動的要素があるので、ちょっと悩んでいると『Permalink Redirect』というプラグインを発見。早速、セットアップしてみる。

プラグインを有効化すると『設定』ページに『Permalink Redirect』というリンクが出来るので、そのページで設定を行う。『Old Permalink Structures:』というテキスト・ボックスがあるので、そこに旧URLである『/%year%/%monthnum%/%postname%/』という情報を記載。『Update Options』ボタンで変更を適用し、動作確認をしてみると旧URLはきちんと新URLへ転送される。これで、まずは期待通りの動きとなったので、しばらく様子見てみる事にする。後半へ続く。

こんばんは、aquaです。

前回ユーザビリティの改善のために各文言の和訳や表示順の入替などを実施した。この変更は図らずもページタイトルのフォーマットにも及ぶ事になった。基本的にはPVを上げるための施策だったが、結論から言うとPVは激減した。正確な因果関係は不明だが、状況としてはgoogleの検索結果順序が大きく落ち込んでしまった。やはりgoogleのクシャミ一つでネット上でのポジションが大きく変わるというのは相変わらずのようだ。以前に運用していたサイトも、この手の問題でやる気がなくなって実質凍結状態にした事を思い出した。他の誘導パス作りをさぼっていたのがいけないんだけどね。

そんな訳で、すっかりPVも減ってしまったので、今まで試せなかった実験的な変更を追加していく。主にSEO対策まとめ系のページを参考にした。カテゴリにシングル・バイトのスラッグを準備していたが、これを日本語に戻した。URL内の日本語がどういう意味を持つか怪しいものだが、とりあえず様子を見てみる。更に記事のURLも『/%year%/%monthnum%/%postname%/』から『/%category%/%postname%/』に変更した。この変更により記事ページのURLが世の中的には重複する事になるので、それを防ぐためのcanonical属性導入を考える。

canonical属性は、検索エンジンに任意の記事について正しいURLを認識させるために使用される。canonical属性の追加には幾つかのプラグインが用意されている。『All in One SEO Pack』を試してみたが、タイトルの変更も行われてしまう。タイトルを処理に任せると日付の表示が『YYYY MM月 DD』のようにイマイチになる。ここは手元で修正したので、canonical属性のみ対応してくれるプラグインに変更する。その名も『Canonical URL’s』。プラグインとしてのインストール以外は何も設定できないツールだが、期待通りきちんとcanonical属性の追加は行われている。

ここまで作業が完了したところで、『404 not found』がちょこちょこ起きている事に気付く。過去のスラッグに対するアクセスが404になっていた。直接『.htaccess』を修正しようかとも思ったが、それ用のプラグインである『Redirection』を発見したので、旧スラッグURLを新スラッグURLに転送するように設定。ここでふと気付いたのだが、外からawstatsへのアクセス可能になっている。awstatsは元々、狙い済ました直接アクセスが非常に多い。調べてみたところ、httpd.confにアクセスを許可する設定が追記されていた。以前にawstatsを再構築した際に、スクリプトか何かで入り込んだのだろう･･･、こわやこわや。

こんばんは、aquaです。

ここ最近のUU及びPVは右肩上がり。とは言っても元々が大したトラフィックではないけど。年末と正月の投稿ラッシュで誘導が増えたのかな。そんな訳で、前回もblogそのものを修正したのだが、今回はアクセスログ解析であるawstatsを久々に修正していく。awstatsはドメインごとに準備する『awstats.www.domain.com.conf』というファイルをカスタマイズする。まずは内輪からのトラフィックがノイズになりつつあるので、カウントしないように設定する。『SkipHosts』というパラメータにスペース区切りで必要なIPを記載する。正規表現も使える。今回は以下。

SkipHosts=”REGEX[^192\.168\.0] 123.234.56.254″

次に24時間に一度しか更新していなかったバッチを1時間ごとに変更する。最近のapacheのアクセスログはrotatelogsによって、日次でログファイルを分断する事が多い。その為、現在は昨日の日付になっているアクセスログを読み出す、という設定になっている。これを昨日のアクセスログと本日のアクセスログの両方を見るように修正する。本日のだけだと前日てのログが完成する24時の時点で解析してくれない事になるからだ。アクセスログのファイル指定は『LogFile』というパラメータに対して設定する。コマンドも使える。今回は以下。

LogFile=”cat /usr/local/apache/logs/access-%YYYY-24%MM-24%DD-24.log /usr/local/apache/logs/access-%YYYY%MM%DD.log|”

そして検索文字列の問題も検討する。googleなどからどのような検索文字列で誘導されたかをレポートしてくれるのだが、その際に全角スペースなどが使われてしまうと、それ前後の言葉と合わせて1語と判断されてしまい、ノイズになってしまう。ググってみると幾つか対応方法はありそうだが、今回は修正が簡単そうなこちらのページにあるパッチを当てる事にした。パッチ適用後に念のため全データをリフレッシュすると、検索文字列も妙な重複や文字化けが解消し、すっきりと期待通りに表示されるようになった。

最後は似たような問題で、ページ表示ランキングでよく見られたURLをまとめてくれるのだが、何故か同じページが幾つかに分かれてしまったり、そもそもURLEncodeされているため一見してどのページが分からない。このURLEncodeも変換出来ないか調べてみた。こちらのページにて、アクセスログのURLEncodeを変換するコマンドが準備されていたので利用してみたが効果なかった。自力で簡単な修正もしたが変化せず。設定ファイルをよく見ていくがそれらしきパラメータはない。しかし、偶然『URLNotCaseSensitive』というパラメータを見つけた。これを1に設定すると、URLの大文字小文字を無視して集計してくれる。400種類近かったURLが半分近くまで減って分かり易くなったので、今回はこれでよしとした。

こんばんは、aquaです。

まもなく100投稿目を迎える我がブログ。100投稿目は何がいいかなあ、とかぼんやり考えてみたりする。2009年を振り返ると、19投稿から70投稿が追加され、89投稿まで増えた。内容の良し悪しはともかく、日次の訪問ユニークユーザー数及びページビューも4倍に膨れ上がった。投稿が4倍近くになったためだろうか。規模に合わなくなった機能を諸々修正する。まずタイトルを見直していく。カレンダーやアーカイブで表示した際のタイトルなどを以下のように修正(※”>>”という表示も削除)。

<title>
<?php
if(is_year()):
	echo get_the_time('Y年');
elseif(is_month()):
	echo get_the_time('Y年m月');
elseif(is_date()):
	echo get_the_time('Y年m月d日');
else:
	wp_title('');
endif;
if(wp_title('', false))echo ' - '; bloginfo('name');
?>
</title>

次に主要な箇所の英語表記部分をコツコツと和訳していった。RSSの表示も『WP Multibyte Patch』というプラグインを利用して抜粋表示に変更。そして、投稿ごとに表示されているadsenseを最初の1記事目のみ表示されるように修正し、サイドバーにもスカイスクレイパー型のadsenseを追加する。広告収入もPVに比例していないので、ちょっとテコ入れしてみた。1記事目だけにする制御は以下のようなコード。

<?php $ad_flg=true;
while (have_posts()) : the_post(); ?>
	<div id="post-<?php the_ID(); ?>">
		:
	記事内容の表示処理
		:
	</div>
	<div align="center">
		<?php if($ad_flg): adsense_deluxe_ads(); $ad_flg=false; endif; ?>
	</div><p/>
<?php endwhile; ?>

最後にナビゲーションの改善に取り組む。何と言っても、まともな投稿ナビが『最近の投稿』のみでカテゴリやタグをクリック時に選択された記事の索引がないのが痛い。数十の記事であればページングしてスクロールしていけば記事を見つけ出せるかもしれないが、100投稿近くになると非常にだるい。そこで、これについてもサイドバーに表示中の記事が一覧できるようなスペースを設ける事にした。カテゴリを選んだ場合は該当カテゴリに所属する記事一覧、タグを選んだ場合も同様である。日付や月単位のアーカイブを選択した場合もそれに対応する。

また、少しだけ設定を捻って1記事しか表示されない場合は、その記事が所属するカテゴリの記事一覧を表示。更に日付で記事を表示する場合も、うちのサイトは必ず1記事になるので同様に処理する事にした。この対応によって、興味のある記事に関連する記事タイトルを一望出来るようになったので、はるかに使い易くなったはず。少しはユーザーの滞在時間に効果があればいいなあ。複数カテゴリに所属するケースなどの課題は残っているが実装コードは以下である。

<ul>
<li><div id="recent-posts-2" class="widget widget_recent_entries">
	<h1>表示中の投稿</h1><ul>
<?php if (is_single() || is_day())
	foreach ((get_the_category()) as $cat)
		query_posts('showposts=20&cat='.$cat->cat_ID); endforeach; ?>
<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
	<li><a href="<?php the_permalink() ?>"
		title="<?php the_title(); ?>"><?php the_title(); ?></a></li>
<?php endwhile; else: ?>
	<p><?php _e('該当する記事はありません。'); ?></p>
<?php endif; ?>
</ul>

こんばんは、aquaです。

既に1年使っているwordpress。プラグインや改造にも大分慣れてきたところで、また苦痛になってきた箇所を修正していく。まず本体のバージョンアップについてだが、管理画面に『バージョンアップしろ』というメッセージが多く、何となく見ててイライラする。前回は手動更新したものの、そもそも自動更新できるはずだから、設定して頻繁にキャッチアップさせたい。どうやらローカルサーバ(wordpress稼動サーバ)上にFTPサービスが必要なので予め起動しておく。FTPはローカル上にあればよいだけなので、NATなどで外側に開放する事はしない。管理画面にてツール→アップグレードで日本語版の方の『自動インストールを実行』をクリック。フォームが現れるので、以下のように埋めていく。

• ホスト名 → localhost
• ユーザー名 → USERNAME
• パスワード → PASSWORD
• 接続形式 → FTP

USERNAMEとPASSWORDはそれぞれローカルサーバでFTP可能なユーザー名とパスワードを入れる。埋め終わったら『開始』ボタンをクリックして、しばらく待つと完了。すごい楽だね、これ。最初から設定しておけばよかった･･･。その後、2.8.3が出てたので、それも『自動アップグレードを実行』で一発完了。期待通りの結果。このバージョンから、編集画面のカスタマイズが強化されている。早速、編集リスト画面の表示件数を15→20件に変更(編集画面の右上にある表示オプション)。それから、編集画面の列数を2→1に変更(投稿記事編集画面の右上にある表示オプション)。これで、大分好みの画面に変わった。

次にスパム対策。大してPVも増えていないにもかかわらず、コメントスパムはやたら増えている。akismetというプラグインで対応できるようなので、管理画面→プラグインにてakismetの『使用する』をクリック。API KEYというものが必要らしく、公式サイトでユーザー登録をして入手する模様。サインアップの画面に行き、フォームを埋めてユーザーを作成する。『ブログを作る』という選択肢もあったが、今回は『ユーザー名のみ』という選択肢にした。すると、登録したメアドにメールが届いているので、そのメール内のリンクをクリックしてユーザーを有効化する。あとは、この辺のページで『Your API Key:』と書かれた箇所でキーを確認。かそのキーを管理画面にて入力すれば完了。あとはダッシュボードのakismet統計などで状況を見るだけ。スパムはすっかり消滅するようになった。

もう幾つか修正を行っている。記事ごとのadsense広告をテンプレート内に設定。管理画面→外観→編集で『main index template(index.php)』を選択。『<?php adsense_deluxe_ads(ad); ?>』というタグを該当箇所へ挿入。見づらかったstat traqのバージョンアップはプラグインの一覧画面からクリック一発で完了。ついで(？)にwp-slimstat-exというプラグインも入れてみたが、まだ見方がよくわからない。とりあえず日本語パッチはエラーになるので当てない事。最後にログイン期間のカスタマイズ。デフォルトで14日になっているが、これを好みの期間に変更する。設定値がハードコーディングされているので、ソースをいじる必要がある。例えば100日にする場合は、${WORDPRESS}/wp-includes/pluggable.phpの637行目にある数値を以下のように編集。

$expiration = $expire = time() + apply_filters('auth_cookie_expiration', 1209600, $user_id, $remember);

↓

$expiration = $expire = time() + apply_filters('auth_cookie_expiration', 8640000, $user_id, $remember);

こんばんは、aquaです。

ブログを書き始めてから9ヶ月。どうせ途中で飽きるかと思っていたけど、意外にもまだ続いている。記事を書く度に、誘導キーワードが増えていき、PVが伸びるのがモチベーションに貢献している。その割りにさぼっていたのがPV解析だ。まあ趣味の範囲だし、SEOやら被リンク対策など何もしていないので、大して意味はないんだけど。一応、wordpress上で動作するStat Traqというプラグインは入れているが、何となく取れている数値は一部怪しい気がする。自分がアクセスするソースIPを対象から外していないせいかもしれないが。

と言うわけで、アクセスログ解析。今までのツールに合わせてLAMP構成で探してみたが、ちょっと求めているものとは違うものしか見つからない。結局、新しいものを探すのは諦めて、使った事のある解析ツールから選ぶ事に。HTML生成型として、以下の一般的に人気のあるツールがある。

• analog
• webalizer
• awstats

今まで、analog → webalizer → awstats とツールを変えてきた。awstats以外は今となっては古いバージョンしか使っていないので最近のものについては知らないが、当時はリファラ周りの解析が不足していた。今回もまずはawstatsを使う事に。以前、使っていたときの不満としては以下。

• URLEncodeしたURL内の日本語がデコードされない
• リファラ上の検索キーワードが検索サイトによっては文字化けする
• 日本語化がちょっと面倒

とりあえず、本家の最新版を落として構築してみる。落としたアーカイブを解凍して/usr/local辺りに配置。tools配下に存在するawstats_configure.plに設定されているパスを自分の環境に合わせて修正する。そして、このファイルを実行するとコンフィグを生成するか聞かれるので『y』と答える。次にサイト名を聞かれるので、それも正しく答える。最後にコンフィグを配置するディレクトリを聞かれるので、自分の環境に合わせて答える。すると、該当ディレクトリに『awstats.ドメイン名.conf』というコンフィグ・ファイルが出来上がる。うちの場合、apacheのアクセスログをデフォルト名から変えているので、それに合わせてコンフィグ・ファイルを修正する。あとは、以下のコマンドですぐにデータを生成できた。

${AWSTATS}/tools/awstats_updateall.pl now

データ生成後は以下のようなURLでawstatsのHTMLインターフェースにアクセスできる。

http://ドメイン名/awstas/awstats.pl?config=ドメイン名

軽い気持ちで作ってみたところ、HTMLの日本語化は普通に行われていた。リファラの検索文字列もきちんと日本語で表示されている。唯一、URLのURLEncodeは相変わらずエンコードされたままの表示。但し、firefoxの場合はURLをフォーカスするとステータスバーに日本語に変換されたURLとして表示される。HTML上でも同様に表示された方がわかりやすいが、わからないよりは遥かにまし。awstatsで求めていた機能が全て満たされてしまったので、今回もawstatsで解析をする事に決定した。