或るサイトの制作過程(25)

しかし、問題はありました。相互リンクしているサイトの一覧を表示してくれるページに、サイト毎の「表示・非表示」の区別がないため、どのサイトが非表示になっているのかわからない。これは、さきほどからプログラム担当の方がカスタマイズを始めているようです。どうやら他のサイトからも指摘されていたことのようで、いよいようちから言われれば動かないわけにはいかないのでしょう。どうしてうちにそんな影響力があるのかという話は、いちおう企業秘密です。

無料サイトも全てサーバを移行してランキング・プログラムも新しくなり、いよいよこれでリニューアルにしっかり取り組めそうです。これまでの数日間は、殆ど業務日誌のようになってしまったため、実質的なリニューアルのお話ができなくて残念であります。ていうか、今日も今日で、サーバを移行したサイトから送信されるメールが文字化けを起こしていたため、フォームから受けた値を処理する PHP コードを修正していたところです。

PHP のメール送信で文字化けを起こす場合、そのよくある原因は、PHP の処理で internal encoding に指定したエンコードと、メールフォームなどの HTML ファイルを保存するときのエンコードが違っていることです。そこで、チェック項目としては、

• HTML ファイルの（charset の値としてではなく、テキストファイルとしての）エンコードを確認する。
• PHP ファイルのエンコードを確認する。
• PHP の設定（/usr/local/lib/php.ini など）を確認する。
• Apache の設定（/usr/local/apache/conf/httpd.conf など）に PHP に関する設定がある場合は確認する。
• 動作ディレクトリにある .htaccess に、エンコードに関する設定があるかどうかを確認する。
• ついでに、allowoverride on なら、上位のディレクトリも確認する。
• mb_send_mail(); 関数を使う前に、どこかで mb_convert_encoding(); を使っていないか確認する。

といったことになります。もともと、こういったいろいろな場所で設定を確認しないで済むように、動作条件を変更する場合はスクリプトの先頭で ini_set(); するのがよいのかもしれませんが、昔はそんなこと知らなかったので、いろんなところに書いていたりします。スクリプトの先頭で書くのであれば、

ini_set( ‘register_globals’, 0 );
mb_language(”japanese”);
ini_set( ‘mbstring.http_output’, ’sjis-win’ );
ini_set( ‘mbstring.internal_encoding’, ’sjis-win’ );
ini_set( ‘mbstring.func_overload’, ‘7′ );

といった具合でしょうか（mb_language(); の指定を忘れると、なかなか文字化けの原因を突き止められなくなります）。.htaccess であれば、

php_value output_handler mb_output_handler
php_value default_charset Shift_JIS
php_value mbstring.language Japanese
php_value mbstring.http_output sjis-win
php_value mbstring.internal_encoding sjis-win
php_value mbstring.func_overload 7

でしょうか。ともかく、自分の考えている処理の環境をどこかで一括して設定できればそれに越したことはありませんが、後で変更したいときに、その環境を前提として書かれたコードがある場合は修正に時間がかかります。そう考えると、一つ一つのスクリプトで冒頭に環境を強制する方がよいかもしれません。まぁ、もちろんそんなのはメールフォームとか、それほど大量に動かないコードだからできることなのかもしれませんが。

で、サイトのリニューアルだよ。ランキング・プログラムも新しくなったことですので、これを活かしたデザインを考えたいのですが、サイトのピックアップには神経を使います。以前まで使っていたランキング・プログラムもそうなのですが、IN カウントに対する OUT カウントの割合（「OUT率」と呼んでいます）に、重みがないのです。そのため、次のようなことが起きます。或る箇所で、20位～30位までのサイトのうち、OUT 率が低いサイトを一つピックアップ表示するとしましょう。そこの場所では、平均して一時間あたりに OUT が 500 出るとします。また、このランキング・プログラムは一時間更新でページが新しく書き換わり、そのときに各サイトの OUT 率を算定し直すものと考えます。いま、20 位のサイトが IN 1,000 に対して OUT 500 、30 位のサイトが IN 100 に対して OUT 10 だとします（20～30位のうち、他のサイトは OUT 率がそこそこ良いと仮定するので、考慮にいれなくてもかまいません）。すると、どちらも OUT が足りないのでアクセスを送ってあげたいのですが、ランキング・プログラムは IN に対する OUT の割合を計算して、「30 位のサイトが最も OUT 率が低い」と算定し、一時間に OUT を 500 出す場所に 30 位のサイトを表示します。当然、90 も送れば OUT 率が 100% になるサイトに対して、OUT を 500 も送るのですから、「返し過ぎ」が起きます。更に、20 位のサイトよりも、今度は 29 位のサイトの OUT 率が低くなれば、20 位のサイトには一向に OUT が出ないままとなり、相手サイトでうちの順位が下がってしまいます。順位が下がると相手からの IN カウントも少なくなり、このサイトは順位を落とします。次に 20 位となったサイトは、前の 20 位よりもアクセスが低いので、このような循環が始まれば、最悪の場合はどんどん全てのサイトとのアクセスが減ってしまいます。

この算定には OUT 率の重みが全くないため、一時間あたり OUT が 500 アクセスほど出る場所に、そこそこの OUT 率に落ち着けるため数十アクセス足りないだけのサイトを表示してしまいます。しかし、OUT 率の割合では 30 位のサイトよりも高いけれど 500 アクセス出る場所には数百も OUT が足りないサイトを表示してあげたい。現状では、OUT が足りない上位サイトがある場合は、強制的にこちらが選んだサイトを「管理者ピックアップ」として表示させているのですが、こういうことをやっていると相手方は労せずしてうちにピックアップしてもらうことになり、うちからはアクセスを送るばかりでなかなか帰ってこないという事態に至ります。

もちろん、これはピックアップした箇所でどれくらい OUT が出るかにも依るので、ほんとうは OUT が 500 出る場所で、その程度のアクセスのやりとりしかしていないサイトを指定してはいけないわけです。もっと大きなアクセスをやりとりしている順位を指定しなくてはいけません。そうすると、たとえ下位サイトの方が少し OUT 率が低いからといって、たくさんアクセスを返してあげたい上位サイトをさしおいてピックアップされても、いわゆる「返し過ぎ」は防げます。こうした、ページ内での予想 OUT カウントを考慮に入れながら、ページのレイアウトを構成していかなくてはなりません。アダルトサイトの「ページデザイン」は、見栄えではなくて、こういうところからスタートするものなのです。

ていうか、明日もとい今日からこれをやっていくんですが。