無料レンタルサーバ＋gooブログからロリポップサーバ＋MovableTypeへの移転についてのメモ書きを途中で投げ出していたのを思い出して、ほとんど忘却のかなたの出来事を思い返しながら書き留めておくことにします。

題名のインパクトだけで客寄せするのはいい加減に止めようかとも思ったのです。しかし、性分は変えられまへん。昨年１０月ころからずっと不幸なことが立て続けに起きていて、アナウンスもなしにしばらくブログをお休みにしておりました。アクセス解析を見ると固定客（ほとんどがロボットなのだが。）は数えるほどしかいないようですが、その方たちには大変ご心配をおかけしましたことをお詫び申し上げます。このサイトはおいらの唯一の毒吐き場なので、おそらく止めることはないでしょう。飽きっぽい性格ですが、相変わらず細々と続けていくつもりです。

といっても、マリナーズのイチローさんではない（笑）
というと、ますますワケが分からないわけだが(￣◇￣;)

アクセス解析の精度がいいもんで、最近ではどんなマイナーな巡回ロボットでも記録に残っててうんざりしている。ホームページ上のアクセス数は、１日あたり２０?５０を示しているが、実際のアクセス数はロボットを含めると３００以上になる。時には１０００を超える日もあるようだ。

googlebot、MSNbot、inktomisearch(Yahoo! slurp)、livebot…。先日は東京大学の実験ロボットShim-Crawlerがお見えになったところだが、今日は新手の巡回ロボットだ。その名も「ichiro」。NTTレゾナンス（goo）が運営するWEBクローラーなのだそうだが、１日３５０ページも読んで行きやがった。よっぽどヒマなんだろうか…（;´д｀）。

久しぶりにアクセス解析を見てみたら、今日は、東京大学からのアクセスがありまして、「学校からゲイサイトなんてのぞいてんじゃないわよ！」と思いながらも、とうとう最高学府からあからさまにエロサイトにアクセスするような世の中になったのね?と、半ばあきれていたところ、【UserAgent：Shim-Crawler…】となっており、どうも巡回ロボットのようらしい。東大の巡回ロボットというのも聞いたことないが、ぐぐるのような独自検索システムでも開発中なのか！？何を企んでる？？

FireFox1.5に変えてから、mixiにログインできない以外は、特に不具合は感じていなかった。
そもそもmixiは携帯か、IEでアクセスするようにしていたので、大して面倒は感じていなかったのだが、今日はヒマだったのでぐぐる先生に尋ねてみたら、簡単に答えが出た。でも、解決法に２種類あったのがナゾだ！？

ひとつめは、キャッシュの設定を変更するというもの。
１．アドレスバーに「about:config」と手入力
２．フィルタに「cache」と手入力
３．「browser.cache.check_doc_frequency」をクリックして、値を「１」にする。

ふたつめは、クッキーをいじるもの。
１．「ツール（T)」→「オプション（O)」→「Cookieタブ」→「Cookieを表示（W)」で、古いクッキー（mixi.jp）をいったん削除する。
２．「Cookieタブ」→「例外サイト（X)」で「http://mixi.jp/home.pl」を【許可】する。

一つ目の方法では解決しなかったが、二つ目の方法では見事解決。

理屈がよくわからないけれども、ウィンドウズアップデートを利用する以外は、これで晴れてFireFox完全移行だす。
ﾒﾃﾞﾀｼ、ﾒﾃﾞﾀｼ。

有料サーバの選択

有料サーバにもいろいろあるが、これら全貌を比較したサイトはなかなか見つからない。どれにしようかと3秒ほど悩んだ挙句（笑）、独自ドメインを格安で取得した関係で、その関連業者のロリポップが一番安くてお手軽、しかもお試し期間があるし、MovableType（以下、「MT」という）も設置でき、しかも親切に設置マニュアルまであるという理由から、速攻で契約した。しかし、実は、ここにはいろいろ落とし穴があった（汗）。MTは、データベースを使うソフトで、サーバ側が設置しているデータベースの性能により、使い勝手が大きく左右されることになるとは、このとき思いもよらなかったのだね。（後述）

サーバの設定とMTの設置

これは、ロリポップのマニュアルどおりにやれば、比較的簡単にできた。特に、問い合わせををしたという記憶はないし、スムーズにブログ開設することができたので、とりあえず設置までは、素人でも「あっ」という間にできると思う。

• 独自ドメインのDNS設定
• MTのソフトウェア・ダウンロード
• MTの環境設定とMT自体のサーバへのFTPアップロード
• ファイル属性の変更（ロリポップではセキュリティの関係でCGI実行ファイルは「７７７」などの属性を許可していないので、その辺のことを理解しておく必要がある。）

gooブログのデータ移行

とりあえず、入れ物が完成したので、次は、中身を整理しながら入れてかなきゃなんないわけだ。今まで日記として使っていたgooブログを、そのまま過去日記として保存しておいて、リンクとして飛ばすか、MTにデータを移行して管理するか。結論としては、gooブログ側が吐き出すバックアップデータ（テキスト）とMTが認識するバックアップデータ（テキスト）とが大きく違わないことが分かったので、テキストデータを読み込ませることにしたのだが、いくらか試行錯誤があったので、メモしておく。

ただ、画像データの移行については、ローカルに保存してあったモノを、一つ一つ手作業で、新サーバにアップロード（MTのファイルアップロード機能）しなきゃならないようだが。

• gooブログからバックアップデータ（テキスト）をローカルにダウンロード
• 文字コードを変換：Shift-JISからUnicode(UTF-8)へ（テキストエディタで一発変換！）
• 形式の違い（gooブログはコメントに題名があるが、MTにはない）を修正
• トラックバックデータ（PINGS）は、IPアドレスを埋め込まないと読み込んでくれないようなので、適当に仮想IPを埋め込み
• 修正したバックアップテキストデータを、MTが指定するサーバのフォルダにFTPアップロード
• MT管理画面から「読み込み機能」で、データを一気に読み込み

さて、このあと「再構築」というものが必要になってくるのだが、これが曲者だった。こんなに悩むことになるとは…。

まだまだ、つづく。

検索サイトからの訪問比率（過去１ヶ月）

１	Google	58.6%
２	GooBlog	14.9%
3	Yahoo!JAPAN	10.8%
4	@nifty	4.3%
5	BIGLOBE	2.4%
6	Goo	2.1%
7	Excite	2.1%
8	MSN	1.8%
9	OCN	1.5%
10	infoseek	0.6%
11	dion	0.3%

このようにおいらのサイトは、圧倒的に　グーグル　からの訪問が多いわけですが、この理由は、単に、利用者が多いだけではないと思います。googleには、googlebot（巡回ロボット）に、自分のサイトを効率的にクロールしてもらうための　sitemap　というツール（ってか、メニュー？）があり、一般に公開されていて、これを活用すれば、効率よく巡回登録してくれるというわけです。おいらは、これを利用していて、つまりは、サイトの全てのページが効率よくググるに登録されているからだろうと推察されます。ただ、これによってすぐにアクセスアップが期待できるものではないようですが、インターネット検索サイトは、今後、広告と同等の威力を発揮するでしょうから、ますます利用価値は高くなるはずです。まだ、ベータ版ですが結構賢く作りこんでるみたいですよ。サイト移転からわずか１ヶ月ちょいですが、すべてのページが効率よく登録されていて、さらに、これらを自分で確認することができるのがよいですね。サイト定義用ファイルの作り方は、ここを参考にしてくださいな。研究してみる価値はありますよ。ほかにも、いろいろ関連記事が紹介されているようなので、さらに検索してみてちょうだいませ。

一方、Yahoo!の方は、そうはいきません。おいらの知ってる限りでは、巡回プログラムもページランク設定のアルゴリズムも公開されてはいないと思います。Yahoo!カテゴリに登録してもらったり、スポンサーにでもなれば、検索結果の上位にランキングされますが、審査が厳しいとのことですから、おいらには、だめです。めんどくさー、であります。あ、その前に、有害サイトの認定を受ける自信はありますが（笑）。よくはわかりませんが、最近、Yahoo!がgoogleの検索システムを導入！？なんてニュースがありました。自分のサイトのアクセス解析を見るかぎり、inktomisearch.comからのYahoo! Slurpってのがたまに巡回にいらっしゃっていて、登録しているふうなのがなんとなくわかります。登録状況を確認するためには、自分のサイトにあるキーワードを片っ端から入力して、検索してみることが考えられますが、非現実的です。ちなみに、おいらんちのアドレスの一部「molto-vivace.net」でYahoo!検索をかけると、130件ほど自分のサイトのページが登録？されているのがわかります。しかし、肝心のキーワード検索（molto vivaceとか）では、すっかり引っかかりませんね。これでは、お客さんも来ないわけだ。おいらとしては、Yahoo!経由のお客様をもうちょっと増やしたいのだけど、その方法がよくわかりません。やっぱり地道に内容を充実させるのがいいのでしょうけどね。いかんせん内容がないようだけに…。（汗）

ちなみに、検索ワードの記録を見ていると結構面白いですよ。「タマタマ　大きい　彼氏」とかで、うちに来てる人、どんな人なんだろうって、妄想しちゃいます。ぷぷっ！(￣艸￣;)

はじめに

WEB画面にさまざまなマルチメディア情報を埋め込むことができる汎用タグとして<OBJECT>タグがある。画像、動画、音声、各種プラグインデータ、JAVAアプレット、他のHTML文書等の、様々なデータ形式をWEB文書に埋め込むことができる。しかし、現状では、データ形式ごとに<IMG>、<EMBED>、<BGSOUND>、<APPLET>、<IFRAME>などのタグを使い分けている。それはなぜか？

<OBJECT>タグは、ブラウザ側の対応が完全ではないようで、限られた状況でしか利用されていない。マルチメディアに限らず、テキストだってなんだって埋め込むことができるものの、自由度が高い反面、その挙動は、WEB製作者の意図したようにならないことがある。思わぬ落とし穴が、そこここにあるのだね。

ここでは、マルチメディア情報の活用の観点とW3Cヴァリッドの観点から極力<OBJECT>タグを使用する方向性について、自分なりにまとめてみたい。（覚書き）

<OBJECT>タグが使いづらい理由

まず、WEB製作者側にたって、OBJECTタグを使いづらい理由を自分なりに考えてみた。

第１の理由は、汎用性を確保するために<OBJECT>タグの属性には「必須属性」がないということではないだろうか。

W3Cの勧告書を英語で読んでもよくわからないので（ちなみに翻訳した日本語だとよけいわからない）、わかりやすく解説しているページを眺めていると、どうもそういうことがひとつの原因らしい。属性を何も書かなくても機能することからインライン要素にOBJECTタグを使ってブロックレベル要素を埋め込む（<p><OBJECT><blockquote></blockquote></OBJECT></p>）みたいな記述が可能になるなど、ちょっととっつきにくいイメージがあるし、どうやって使うのか、持て余している感がある。とりあえず表示できてるから、ま、いっか的な使われ方のようだ。

これを要するに、<OBJECT>タグは、<EMBED>タグに比べて、はるかにたくさんのパラメータが用意されていることから、自由度が高い。自由度が高いがゆえに、逆に使いにくいのである。しかし、使いにくいといっても、W3Cにおいて、<OBJECT>タグへの統一という大方針があるわけで、<EMBED>タグは排除される方向にあることから、今後どうしても<OBJECT>タグの活用について考えていかなければならない。

第２の理由は、処理プラグインを強要しているところにあるのではないか。どういうことかというと、現在いろいろなWEBのソースを見ても、さらには「?HTMLタグ辞典」などの刊行物を読んでも、<OBJECT>タグの使用には、必ずといっていいほどclassid属性に引き続く、暗号のような英数字の文字列が使用されている。

ここからちょっと推測が入るけれども、このclassid属性によって、埋め込まれるデータを処理するためのプラグインを指定しているふうなのだ。これはちょっと考えるとおかしいと思う。（おかしいなら笑えという突っ込みはなしよ。）というのは、音声再生ソフトや動画再生ソフトは、今ではいろいろなファイル形式に対応していて、このデータ形式はこのプレーヤーでなければ！というものは少ない。「midi」や「mp3」ファイルはそのいい例だと思う。

ユーザの環境によって、Microsoft Media Playerで再生したり、RealPlayerだったり、QuickTimeだったりといろいろあるのに、例えば、MIMEタイプがtype="audio/mp3"で、classidにRealPlayerの”暗号文字列”を記述することにより、プラグインとしてRealPlayerを明示的に指定するとしよう。

この場合ユーザ側にとっては、いつもはQuickTimeをmp3の再生プレーヤーとして関連付けしていて、再生できる環境にあるのに、わざわざRealPlayerをインストールしなければならない羽目になる。ユーザはプラグインのインストールを強要されるため、はなはだ面倒であり、かつ、不愉快だ。

したがって、WEB製作者は、この辺のことを考えてコーディングする必要があるため、面倒くさくて、やなタグやな?（笑）となるのではないかしら。（あくまで想像だが）

そして、３つ目の理由は、ブラウザの対応状況。実はこれが一番大きな理由だと思うのだが、ブラウザによってずいぶん挙動が違うということだ。表示できたりできなかったり、また、パラメータの解釈が異なるため、コンピュータそのものが、とんでもなく動作不安定になったりと、ワールド・ワイド・ウェブ・コンソーシアムで勧告されているにもかかわらず、各ブラウザの対応がまちまちというのが、まったくもってお粗末であるな。EMBEDタグの歴史的なこととか、OBJECTタグのとっつきにくさとか、古いバージョンへはそうするとか、OSの違いはこうするとかは別にして、早く対応してちょーよってのが結論（おい！）各ブラウザに対応するために、いまだにOBJECTタグとEMBEDタグを併記している現状は、どう見ても勧告無視の姿勢でよろしくないのではないでっしゃろか？（勧告はあくまで勧告なのだが…）

プラグインに対する配慮

ユーザ側のプラグインの有無のことまで考えていたら、前に進まない。これはまったくのユーザの都合であることから、考察を加えるほどのこともないが、WEB製作者として、若干、考慮しておかなければならないことがあるので、触れておくことにする。

まず、画像、動画、音声などのマルチメディア情報のファイル形式は、一般的にインターネットの世界で使用されている形式のものを使用するということである。当たり前といえば当たり前であるが、さまざまなユーザ環境に対する最大公約数的な表現に心がけるとともに、インターネットの世界で、より一般的に使用されているファイル形式で”保険”をかけておくというやり方が必要である。どういうことかというと、例として、画像の埋め込みに関するひとつの例を挙げることにする。

ある写真家が、高精細な写真を配布するWEBを運営しているとしよう。WEB製作者は、できるだけそのままの画質を保持したまま写真を配布したいという意図から、.PNGや.TIFFなどを選びたいと考えるだろう。（.jpgは画質が劣化するし、.gifは色数に制限がある。）しかし、ユーザ側では、一般的でない（？）.PNGや.TIFFなどのファイル形式を処理できない環境である可能性が、.jpgや.gifなどに比較すると高いと思われる。そこで、OBJECTタグが、幾段にも入れ子処理が可能であることを利用して、次のようにコーディングするといいかと思う。上記の例は、現実的にあるかどうかは別にして、
（１）.TIFFが処理できない場合は、.PNGを処理
（２）.PNGが処理できない場合は、.jpgを処理
（３）.jpgも処理できない場合は、「配布用画像がご覧いただけない方は、お問い合わせください。」というテキストが表示されるという3段構えのコーディングの例である。

つまり、マルチメディア情報を配布する際、いくつか一般的なファイル形式を”保険”として用意しておき、ユーザ側で取捨選択できる仕組みをWEB製作者側が配慮するということである。すなわち、ユーザ側にインストールされているプラグインに対してある程度配慮しておく必要がある場合は、OBJECTタグは、それを実現できるコーディングが可能であるということである。

ブラウザに対する配慮

ま、ココからが本番というか、本論に入るのであるが。（なげーよ！）
と、本番がやりたい（笑）ところではあるが、きょうはもう遅いし、疲れたし、W杯あるし。

（つづく。）←これで逃げてるエントリがいくつあることやら…。汗

サイト運営者の心構えとして、ブラウザ対応状況を確認することは、アクセスビリティの上で必要だ。映像や音楽などのマルチメディアを取り扱う場合は、特に互換性やらなんやら考慮しないと、自分には見えるが他人には見えないというそれこそ自己満足な世界に没頭してしまうことになる。

という前置きはべつにして、巷で徐々に流行りつつあるFireFoxをインストールしてみた。IEがFlashに対する仕様を変えたため、Flashメニューなどがワンアクション増えたことから、ちょっと使いづらくなったというのもある。それから、HTMLやCSSの本を見ていると、CSS2.1への対応状況というか、標準仕様をより忠実に実装しているのは、IEよりむしろFireFoxなんじゃないの？という認識に至ったものその理由。そのほかにもセキュリティの問題など、いろいろあるんだけどさ。印象はレンダリング速度が格段に違うということ。FireFoxを使ってから、IEを使うと描画がモタついてるのが顕著に分かる。これだけで乗り換える価値はあると思う。

ただ、ひとつ不満なのが、<object>タグがつかえないこと。ってか、FireFoxは、<object>タグを無視するんだね。初めて知ったよ。FireFoxでは、自分のサイトの映像が見れないってことがいま分かった。結構埋め込んであるので、<embed>で補完しなきゃなんないことが判明してちょっとうんざりだけど、いままでFireFoxで見てた人は、「なんじゃら？」って思ってたはず。大変参考になりました。でも、今後の趨勢としては、<object>タグに統一されると聞いてますから、Mozillaさん、対応のほうよろしくお願いしますよん。っていっても開発関係者ってあんまり芸術に得意そうな人がいなさそうだけど…。(￣◇￣;)

　小粋空間テンプレートで、リキッドレイアウトは、左右のサイドバーにPOSITION:ABSOLUTEプロパティ値を使用していることから、ヘッダーブロックの高さが可変してしまう環境の場合、サイドバーブロックがヘッダーブロックに食い込んでしまいます。これに対する、ひとつの解消法としては、

#box（
#banner（ヘッダーブロック）
#main（POSITION:RELATIVE
　　#links-left-box（#links-left（左サイドバー））
　　#content（#blog（.entry（中央カラム）））
　　#links-right-box（#links-right（右サイドバー））
）--/main--
）--/box--

というように、ヘッダーブロックすぐ下に、サイドバーと中央カラムを包含するブロックをつくり、POSITION:RELATIVEとした上で、サイドバーブロックのTOPプロパティ値を「０」指定することで解消します。（※テンプレートにおけるブロックイメージを表現しています。）

　これは、ABSOLUTEの位置決め規則が、「直近する親の布置ボックス（Static以外のRelativeかAbsoluteかFixedの３つを指す。）のパディング辺を基準にする。」仕様を利用したものです。つまり、絶対値指定されているサイドバーブロックを包含する#mainブロックを、RELATIVE布置ブロックとして追加することで、左右サイドバーが、これ（#mainブロック）を基準に配置されるようになるためです。「絶対配置」という言葉が分かりにくくしているため、使い方がよくわからなくなることがありますが、こんな使い方もあります、みたいな。

基本的に長さの指定を”PX《ピクセル》”指定している場合は、画面の解像度に対する相対指定であることから、特にそのままで不具合は生じませんが、”em《エムクワド》”指定した場合、上記のようにしておくと「食い込み」を防ぐことができます。

ただ、この処置をした場合、IE《インターネット・エクスプローラ》ではエントリー内の画像が消えてしまうという現象が発生してしまうことがあります。（FireFoxでは発生しません。）
img要素は、インライン要素なので、そのままの場合は、画像が消えてしまうという現象は発生しませんが、FLOAT:《浮動化》指定したり、DISPLAY:BLOCK《ブロックラインレベル要素》指定した場合は、ブロック要素となり、包含ブロックのPOSITIONプロパティに気をつける必要があります。画像が消えてしまう場合は、img要素をブロック要素とした上で、POSITION:RELATIVEを指定してみると解決する場合があります。