けんども日記: カテゴリ: web

カテゴリ: web のエントリを新しい順に 20 件まで表示します。 21 件以上ある場合、それらは省略されます。

2004-08-15

Slurp 系の検索エンジンがディレクトリ名のスラッシュを省く問題

404 Not Found になったリクエストを抽出してみると、ディレクトリ名で終わる URI に対して、スラッシュを省いたために起こったものが目に付いた。このサイトでは URI のスラッシュの有無を厳格に区別している。デフォルトの Apache と違い、ディレクトリ名にスラッシュをつけ忘れたのでリダイレクトさせるようなことはしない。具体的には次のとおり。

本来の URI

http://home.kendomo.net/board/decode/

誤った URI

http://home.kendomo.net/board/decode

後者だと 404 になる。この原因は Yahoo や MSN などの旧 Inktomi Slurp ベースの検索エンジンにある。これらの検索結果では、ディレクトリ名で終わる URI のスラッシュが省略されているため、そこからの訪問者が対象となる。クロール時にもなぜかどこからもリンクされていないはずのスラッシュ抜きでリクエストしているようだ。その際、スラッシュをつけないと 404 になることは認識しているはずなのだが。もっとも、代表的な Web サーバの標準状態ならこんな問題に遭遇することはないに違いない。それを前提に作られたシステムなのだろう。そうだとしても、なぜスラッシュを省略してしまうのだろうか。

2004-07-23

アダルトサイトの宣伝に使われる画像掲示板

ウェブサイトの開設以来、画像が添付可能な掲示板を設置している。そこへたまにサイトの宣伝が貼り付けられる。ここ 1 週間でアダルトサイトの宣伝が 3 件あった。もともと利用者がいないため、たとえ宣伝でも利用されるだけよいと思っているのだが、画像を見た訪問者はどう思うのだろうか。このサイトの印象が悪くなるようならば、削除したほうがよいのだろうか。

ログを探って興味深いことに気づいた。それは、画像掲示板に書き込む際、専用のツールが使われているらしいこと。通常は画像掲示板へアクセスすると、貼り付けてある画像のサムネイルもリクエストされるのだが、画像掲示板自体にしかリクエストがない。そして、読み込みから POST するまでの時間が非常に短いため、フォームへ手動で入力したとは思えない。しかも、このサイトのトップページや検索エンジンからやってくるのではないので、「画像掲示板の URI リスト」のようなものに登録されているのかもしれない。ちなみに、画像掲示板は「ふたばちゃんねる」のスクリプトを利用している。 blog では Movable Type のような有名なシステムを使うと、コメントスパムが届くという話をよく目にする。このように、広く使われているスクリプトを使うと狙われやすいということだろう。

2004-06-20

使っていないメールアドレスにスパム

昔メインで使っていたメールアドレスにスパムが来だした。今はそのメールアドレスを使って送信することはないし、 Web サイトで公開しているわけでもない。ではなぜか。 @ 以前が短いので、機械的にメールアドレスを生成してメールを送り、エラーが返ってこなかったアカウント (= 存在するアカウント) としてスパムリストに登録されているのだろうか。

昨日 2ch のドメインに関するスレッドを見ていると、ドメインの連絡先に登録したメールアドレスにスパムが来るという書き込みがあった。もしかするとこれが原因かもしれない。問題のメールアドレスはドメインの連絡先として使っているのだ。とりあえず Plala のフリーチケットで「ニックネームメール」というサービスを使い、転送専用のメールアドレスを作り、 Whois の情報をそれに変更した。今度はスパムが来たら簡単に変更できる。

2004-04-16

Googlebot/Test ってなんだろう

先ほど Googlebot/Test というロボットを確認。いつものユーザエージェント名ではないので、偽物だろうと思って IP アドレスを逆引きしてみたら本物のようだ。動きに注目してみると、まず最初に robots.txt を参照し、その後 vote.js を参照していった。 vote.js というのは当サイトで使用しているアンケートフォームを出力する外部 JavaScript ファイルで、 9 割以上のページに埋め込んでいる。続いて style.js も参照していった。これはスタイルシートの調整用 JavaScript ファイル。これら以外のファイルは参照していない。 JavaScript 専用なのだろうか。まだよくわからない。

2004-04-04

favicon.ico 収集サイト IconSurf.com

取得したものの、使用していないドメイン名がいくつかある。使用していないとはいえ、 Web サーバに割り当ててアクセスログを取れるようにしている。その中のあるドメイン名では今まで平均で 2PV/Day ほどのアクセスだった。しかし、今月に入って急に増えた。しかも、 favicon.ico ばかり。リファラによると、http://iconsurf.com/ ではじまる URI から参照されている。 IconSurf.com というサイトらしい。

この IconSurf.com では実際に使われているアイコン (favicon.ico) を閲覧できる。まず、トップページではランダムで 500 個のアイコンが表示される。 Filter by top level domain で jp を指定すると、トップレベルドメインが JP のサイトだけ表示される。なるほど。私のドメイン名もここに含まれていた。これらの JP ドメインサイトを集めた基準は、 3 文字アルファベットの汎用 JP ドメインだけのようだ。検索エンジンのようなロボットを走らせるという高度な方法で見つけたのではなく、 http://www.3 文字アルファベット.jp/favicon.ico で favicon.ico が見つかったサイトだけが挙げてある様子。サーバのログによると、その際使われたと思われるユーザエージェントは「favicon finder」となっている。

サイトの趣旨としてはとてもおもしろいと思う。今後、扱うアイコン数が増えればもっとよくなるだろう。ところで、まだ遊んでいる 3 文字の汎用 JP がいくつかある。そこにも favicon.ico を置いて試してみたい。

2004-03-15

代替広告にちょっとした工夫

AdSense の代替広告として Amazon アソシエイトを使っている。代替広告は AdSense で適切な広告が表示できない時に使用される。この Amazon アソシエイトの呼び出し部分を PHP で作り、ページの内容に応じて適切な広告 (本のリンク) が表示されるようにした。これは「キーワードリンク」のコードに目的のキーワードを渡せばよい。方法はいくつかある。

• 〜/ad.php?keyword などというように、キーワードを引数で渡す。
• リファラを取得して呼び出したページを知り、スクリプト内で照合。

引数で渡した方が正確でスマートなのは言うまでもない。しかし、出力を 1 つのスクリプトだけで一括して処理したかったので、リファラを読むことにした。リファラは Web ブラウザの設定やセキュリティソフトで吐かなくすることができる。また、 Mac 版 IE では正常に取得できないことがある (代替広告の場合、リダイレクトして呼び出される形になり、 Mac ではリファラがリダイレクト元の URI になってしまうことがある) 。そのため、リファラというのは常に取得できるわけではない。

処理はあまり難しいものではない。ただし、 blog の部分はデータベースからカテゴリを引っ張るようにしたので、わりとまともな広告が出るかもしれない。おもしろいので代替ではなく、普通に呼び出してもよいのだが、これでは広告だらけになってしまう。「blog = 広告を使った小遣い稼ぎ」みたいに思われることもあるようなので、ほどほどにしておく。

2004-03-14

メールアドレスを HTML エンティティ化

Web サイトに掲載しているメールアドレスにスパムが届き始めた。以前、変なワームにメールアドレスを収集されて勝手に使われたこともあるので、プレーンなメールアドレスを載せない方がよいのかもしれない。

とりあえず HTML エンティテ化というページでメールアドレスをエンティティ化してみることにした。何もしないよりは効果があるかもしれない。

2004-02-29

評価システムを設置

評価というより簡易投票といえばよいのだろうか。各ページに「このページは役に立ちましたか？」というものを設置した。役に立つという声が多ければ該当ページの関連コンテンツや情報を増やしていこうと思う。逆に役に立たないという声が多ければ該当ページの修正、公開停止も考えている。

この手のシステムを作るときはデータベースがとても役に立つ。そもそも最近はサーバサイドスクリプトを PHP と PostgreSQL でしか作らなくなってしまった。それほど扱いやすく、処理も簡単になる。

2004-02-27

悩める携帯電話向けサイト作り

何気なく復活させた携帯電話版。データベースの文字コードが EUC-JP なので、このサイト自体も EUC-JP にしていた。私が以前使っていた au の EZweb では EUC-JP だろうが UTF-8 であろうが閲覧できたので問題ないと思っていたのだ。しかし、 EZweb 以外はシフト JIS にしか対応していないような情報もあるのでシフト JIS にした。

さらに、以前知人に XHTML Basic で作ったサイトを i モード (FOMA ではない) で確認してもらったところ、 XML 宣言が表示されてしまったらしいので、仕方なしに XHTML Basic ではなく HTML 4.01 で作ることにしている。なんか i モードは IE のような存在に思える。シェアは高いのに仕様が変なので、 Web ページを作る側にとっては厄介という共通点。

個人的には昔 EZweb の標準だった HDML が扱いやすくて好きだった。

参考サイト

携帯電話用Webページの作成情報

iモード用ホームページの作成法

XHTML BasicでつくるWebサイト

2004-02-24

Google のインデックス更新

私が管理している各サイトのトップページはほぼ毎日 Google のロボットが来るのだが、トップページ以外は月に 2 回程度しかこない。今月最初にクロールした分がようやくインデックスに反映されたらしい。実は今回からキャッシュされないようにした。その理由は今までに何度も書いたとおりなのでここでは省略する。キャッシュされないようにしたことで Google に嫌われないか心配したが、特に問題はない様子。いろいろなキーワードでこの blog が上位に表示されるようなので、うざがられないようにしよう。情報としてあまり役に立ちそうにないエントリは削除したほうがよいのだろうか。

2004-02-04

検索結果のキャッシュ機能

普段 Google ばかり使っていて気づかなかったのだが、 Yahoo! Japan の Web 検索結果 (カテゴリの検索結果ではない) にもキャッシュのリンクがあることに気づいた。いつからついていたのだろう。他に Google の検索エンジンを使っているところを調べてみると、 goo もキャッシュ機能が付いていた。

前にも書いたように、私はあまりキャッシュが好きではない。元は自分で作ったページでありながら、そのキャッシュは自分の管理範囲外となってしまうからだ。掲載している情報が間違っていることに気づいて修正しても、キャッシュにはすぐに反映されるわけではないので、キャッシュからは誤った情報を発信してしまうことだってあるかもしれない。他にも、 XHTML で作ったページに、汚いコードをくっつけられてしまうのはあまり気分がよくない。

などと書いてはいるが、キャッシュにはお世話になっている。目的のページを公開しているサーバがダウン中だとか、ページが急に削除されてしまった場合、 2ch の DAT 落ちしてしまったスレの閲覧にも。

2004-02-02

スタイル変更

2 ヶ月近く使ってきた CSS を変更。色とボーダを軽くいじっただけで、大きく変わったわけではない。昔は CSS で熱くなったこともあったのだが、最近はあまり頑張る気にならない。読みやすければよいと思っている。 h2 は前の方が見出しとしてわかりやかったかもしれない。

2004-02-01

URI へ勝手に / をつける

おせっかいというか。「URI の最後が拡張子で終わらない場合はスラッシュをつける」なんていうものがある。ディレクトリ名の / を省略した場合の対策だと思われるのだが、それがディレクトリでなかったらどうなるか。例えば、私がよく使うような PATH_INFO を使った動的なページ。他には Apache のコンテントネゴシエーションを使った場合もファイルの拡張子を省略することがある。このようなページでは / の有無で全く違った意味になってしまう。

Photo@けんどもネットでは自然の風景や生き物の写真を扱っているせいか、 キッズ goo 経由の訪問者がちらほらある。キッズ goo では検索してヒットしたページをプロキシのようなもの (Wget を使っているらしい) を通して表示することになっている。同サイトの目玉である「ふりがな」機能を使うためと、有害なコンテンツのフィルタリングのためだろう。そのプロキシを経由させるための URI 生成部分にに / の補完があるから困る。 PHP で PATH_INFO を使っている Photo@けんどもネットの多くのページは余計な / によって正常に見れなくなってしまう。今日の時点ではキッズ goo で「テーマ別表示」というキーワードを使って検索した結果の 1 件目と 2 件目に該当ページが表示される。スクリプトなので対策は簡単なのだけど、別の URI で全く同じ内容を表示させるというのも悩む。

2004-01-31

DB を XREA に自動コピーする

約 3 週間前からやろうとしていたことがやっと実現できた。この日記のデータベース (PostgreSQL) を XREA に自動でコピーするすることだ。前にも書いたように、ダンプしたファイルを psql コマンドで取り込むときにパスワードを要求されてしまう。このパスワードは XREA では手動でしか入力できそうにないので、スクリプトで全自動で行うことは困難だった。

よく考えてみると、何も全部シェルで処理しなくてもよいことに気づいた。 XREA にはアカウントの管理ページがあり、そこからデータベースの保存や復元といった処理ができてしまう。ページのソースを見てみると、ただの POST リクエストのようだったので、 Wget でなんとかできてしまいそうだ。作業の流れは次のとおり。

1. データベース機で pg_dump コマンドを使い、日記のテーブルのみをファイルに書き出す。
2. Perl を使い、 XREA で取り込める形式に修正。
3. ftp コマンドで XREA に転送。
4. Wget を使い、管理画面でデータベースの復元ボタンを押したのと同様の POST リクエストをする。

これを cron で 1 日 1 回実行する。こうすれば XREA にも日記のデータベース (テーブル) がコピーされる。この日記は日々挑戦したことを後でも思い出せるようにするのも目的なので、いつものようにメモしておく。特定のテーブルのみバックアップするには次のようにする。詳しくは pg_dump --help 。

今日試したかぎりでは、 XREA の管理画面で復元できる形式は、管理画面で保存したファイルのような形式でなければならないようだ (復元はリアルタイムで処理されないので、あまりしつこく調べなかった) 。よって、上の方法でダンプしたファイルそのものが使えるわけではない。これは管理画面で保存したファイルを参考にし、 Perl で処理。テーブルの差分を送るのでない場合は、いったんテーブルのレコードを消す文を追加する必要がある。続いて FTP で XREA のサーバに転送する方法。これは忘備録 - KAZ Home Page 小技「ftp 自動運転」の項目を参考にした。

open s1.xrea.com
user ユーザ名 パスワード
lcd "転送するファイルのあるディレクトリ"
bin
put pgsql.dump pgsql.dump
quit

上記内容のファイルを次のように使う。

そして最後は管理画面で復元ボタンを押したときと同等のリクエストを Wget でする方法。 Red Hat Linux 9 の Wget は POST が使えないらしく、最新版のソースを落としてインストールした。

$ wget --post-data='id=ユーザ名&pass=パスワード&pgsql_restore=%95%9C%8C%B3' \
http://www.s1.xrea.com/jp/admin.xcg

こうしてしばらく待てばデータベースの復元処理が行われる。これで携帯電話版も復活させることができそうだ。携帯電話だとフレッツ ISDN の自宅サーバではレスポンスが悪そうなので、他のサーバで公開したいと思っていた。

2004-01-27

PageRank 0 から 4 に

驚いた。トップページの PageRank が 0 から 4 に急上昇。けんども日記は 0 から 3 だ。思えば、 5 年間いろいろな Web サイトを作ってきて、過去最高の PageRank が 1 だった。これでわかったのは次のとおり。

1. PageRank が低すぎると、 Googlebot は全ページをクロールしない。過去にトップページしか拾われなかったのはこのためだと思われる。
2. しかし、何らかのはずみで少しでも PageRank が上がり (このサイトの場合はウェブリング) 、ほぼ全ページがクロール対象となった。
3. 全ページにトップページへのリンクをつけているので、それらページの PageRank はトップページにも反映される。

というように、入ってきた少ない PageRank をたくさんのページで増幅したと思われる。このサイトへリンクしてくださっている方々にはとても感謝している。

それにしても、非 Windows 環境でも使える Google ツールバーは出してくれないのだろうか。

2004-01-26

SurveyBot/2.3 って何だ

たまに www.kendomo.net へ SurveyBot/2.3 (Whois Source) というロボットが来る。 www 以外のサブドメインには来ない。リファラが http://www.whois.sc/ だったり、 http://www.whois.sc/kendomo.net だったりする。 whois ということは、私のドメインをねらっている奴 (そんな人いないと思うけど) が監視しているのか？しかも偽のリファラをつけていて気味が悪い。そんなわけでこのロボットは拒否していたのだが、 Google で調べたら 1 件目にこのロボットについてのページがに出た。別に怪しいものではないらしい。 Survey Bot - Monitoring Internet Statistics を簡単に要約。

• インターネット上の統計をモニタする。この情報は Whois Source の検索エンジンに使用する。
• robots.txt に従う。ロボットが記録するのはデフォルトドキュメントの title タグだけである。

http://www.whois.sc/ に続いてドメイン名を入力すると、そのサイトの概要とスクリーンショット、 whois の情報が表示される。例えば、 XREA だと http://www.whois.sc/www.xrea.com のようになる。 XREA を例に挙げたのは、日本語サイトかつ、次のようないろいろな情報が表示されたため。説明とは異なり、 title 以外に meta 要素の Keywords や Description も拾っている。 dmoz や Yahoo.com に登録されていれば、それらの URI や説明文なども表示されるようだ。 XREA の場合は、ユーザが作成したサブドメインのページが dmoz と Yahoo の登録情報として出てきた。なかなかおもしろいが、これが使えるのは Whois Source で扱っている .com、.net、.org、.info、.biz、.us ドメインだけ。

2004-01-18

プロバイダの Web ページに独自ドメイン

たいていのプロバイダでは無量で Web ページの開設ができる。フレッツ ISDN の自宅サーバだと画像の転送でかなりの負担になるので、そのようなところに画像だけを置いて使わせてもらうことを思いついた。しかし、私としては kendomo.net というドメインを使いたい。最近、名前ベースのバーチャルホストばかり使っていて感覚が狂っていたが、プロバイダのスペースではあっさりと自分のドメインが使えることに気づいた。その方法はというと、使いたい独自ドメインをプロバイダのサーバの CNAME レコードにしてしまうというもの。今回は images2.kendomo.net を cgi35.plala.or.jp の CNAME とした。元の URI が http://cgi35.plala.or.jp/x-kd/ なら http://images2.kendomo.net/x-kd/ で使えるようになる。もちろん http://images2.kendomo.net/ だけで使うことはできないが、なんとしても自分のドメイン名を使いたい場合に便利かもしれない。 A レコードではなく CNAME レコードにしておけばプロバイダのサーバの IP アドレスが変わっても問題ない。これによって余計な問い合わせが増えてしまうが、仕方がない。応用としては、プロバイダのドメインが長い場合、短いドメインを割り当てれば URI の短縮になる。ただし、今回の私の設定を含めて、同じサーバの住民全員がそのドメインを・・・。

2004-01-17

RSS の description 要素と実体参照

たまには正しい RSS が生成されているかどうかを確認することにしている。昨日 FEED Validator で確認すると、 UnicodeDecodeError と表示されてしまった。文字コードは UTF-8 なので問題ないはずだ。 日本語を除去し、 ASCII 文字だけを残すとエラー内容が変化した。例えば、 2003-12-31 キャッシュされますでは meta 要素の例を挙げている。これはもちろん実体参照を使って表している。日本語を除去して UnicodeDecodeError にならない状態で試すと description should not contain meta tag というエラーになる。どうも description 要素に記述した実体参照 < と > を展開してしまっているらしい。これは RSS の仕様なのだろうか。勉強不足なので時間のあるときに調べてみよう。とりあえず、実体参照で表した < と > を除去しておくことにした。

2004-01-14

AdSense コードの変更はダメ

先日 Google にメールで質問した返事がきた。このサイトは XHTML1.1 で記述しているのだが、 AdSense をはじめてひとつ問題があった。それは、 AdSense コードの <script>〜</script> にコメント <-- と --> が含まれるということだ。 XHTML では本来このような使用はできない。 Another HTML-lint でも減点されてしまう。 これを解決するには次のような方法が考えられる。 Google に以下のような方法を使ってもよいか質問してみた。

1. <-- と --> だけ削除してもよいか。
2. しかし、<script>〜</script> を認識しないブラウザはコメントを外すとコードが表示されてしまうので、外部 JavaScript として利用してもよいか。例えば次の内容の外部スクリプトを用意して呼び出してもよいか。
   google_ad_client = "pub-000000000000000";
   google_ad_width = 468;
   google_ad_height = 60;
   google_ad_format = "468x60_as";
   document.write('<script type="text/javascript"
   src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>');

結果はダメらしい。表示された広告コードを正確にコピーして直接貼り付けなければならないとのこと。 AdSense コードを張りつけた状態でも W3C MarkUp Validation Service では Valid と表示されるのでがまんしよう。

2004-01-12

データベースの同期

データベースをいじっている途中でいつの間にかこの blog のテーブルを消してしまっていた。 1 日 3 回バックアップをしているので復旧は簡単なのだが、けっこうな間、閲覧ができない状態が続いていたかもしれない。閲覧者に迷惑をかけてしまったことをお詫びしておく。

何のためにデータベースをいじっていたのかというと、自宅サーバと XREA で公開しているサイトとでデータベースを同期させたいと思っているからだ。双方向だと困難なので、自宅サーバのデータベースを XREA に反映させるということになるだろう。しかし、困ったことに XREA では psql コマンドを使うときにパスワードを要求される。パスワードを指定するオプションがないため、シェルでは psql コマンドが使い物にならない。そこで、テーブルにデータを挿入する作業を PHP スクリプトで行うことにした。そのスクリプト自体をまた PHP スクリプトで作り出すというなんともややこしいシステムになってしまった。今日はここまで作り、実際にこのスクリプトを XREA に転送する方法と転送してからの処理は後日考えようと思う。もちろん全自動を目指している。

何のためにこんなことをやるのかというと、自宅サーバのトラブル時に一時的に DNS を XREA に切り替えることがあるのだが、準備ができていないため blog のデータが古いままになってしまう。いつでもできるだけ新しい blog を表示させるためだ。また、携帯電話サイトの復活も考えている。