Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

不完全なHTMLを動的にタッチアップ

Greasemonkeyを活用した互換性の確保とTouchUpWebプロジェクト

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2006/08/31 00:00

本稿では、Internet Explorerに特化したコンテンツをFirefoxなど他のブラウザでも正しく閲覧できるようにするための仕組みとして、Greasemonkey拡張機能を利用したコンテンツのタッチアップと、そのためのスクリプトを管理するシステムであるTouchUpWebプロジェクトを紹介します。

目次
図1 Greasemonkeyの設定ダイアログ
図1 Greasemonkeyの設定ダイアログ

はじめに

 HTMLの仕様はW3Cで定められており、標準に則ったコンテンツであればどのようなWebブラウザでも閲覧できるという建前のもと、Webベースのシステムが急激に普及しました。しかし標準仕様に関する細かな部分の解釈の違いや、独自拡張の存在などにより、必ずしも互換性が完全に確保されているとは言い難い状況です。本稿では、その問題を解決する一つの方法としてGreasemonkey(グリースモンキー)を利用するやり方を説明します。Greasemonkeyのユーザースクリプト・プログラミングを解説すると共に、これらの問題の自動的な解決を試みるTouchUpWebプロジェクトを紹介します。

対象読者

 FirefoxやOpera、SafariといったInternet Explorer (以下、IEとします)以外のWebブラウザを利用しているユーザーで、特定コンテンツに関してブラウザ間の非互換性に悩まされているユーザー。もしくはWebシステムの設計者やWebコンテンツ制作者でマルチプラットフォーム対応の意識が高い方。

必要な環境

 Firefoxの動作する環境であればプラットフォームは問いません。ただし、Greasemonkeyを動作させるには比較的新しいバージョンのFirefoxでなければなりません(2006年8月現在、GreasemonkeyはFirefox 1.5およびFirefox 2.0に対応しています)。なおGreasemonkeyのユーザースクリプトはJavaScriptで書かれています。

Webコンテンツの相互運用性

 WWWの登場から10年以上が過ぎ、ネットワークアプリケーションと言えばWebベースのシステムであるという状況があたりまえになりました。Webアプリケーションを支える技術も、AjaxやSOAP、WebサービスAPIなど百花撩乱で、いまやWeb 2.0というキーワードでさまざまな分野から注目を浴びています。

Webシステムのメリット

 Webアプリケーションがこれだけ普及した理由はなぜでしょう。

 一つには、WebブラウザがOSに組み込まれていたというマイクロソフトの戦略がうまく作用したことを挙げることができます。これまでのクライアントサーバシステムと違い、クライアントを作る必要がないからです。

 またWebアプリケーションは、HTTPという共通の通信プロトコルを用い、HTMLやECMAスクリプト (JavaScript)という標準規格でコンテンツが記述されています。このようにプラットフォームがしっかりしていたことも、急速に広まった理由の一つでしょう。

相互運用性の喪失

 ところが残念なことに、さまざまなWebブラウザが登場したものの、それらのすべてが完全にHTMLの仕様に準拠していなかったところに、問題が生じる隙がありました。また仕様の細かな部分の解釈の相異から、実装に差が出るという状況も発生しています。次の図は、ある記述に基づいたHTMLの表組みを、さまざまなブラウザで表示させてみたもののスクリーンショットです。同じHTMLの記述でも、実装の違いから、このようなレンダリングの差が出ていることが分かります。

図2 定義解釈の違いによる表示の差
図2 定義解釈の違いによる表示の差

 またWWWが普及する初期の段階においては、ブラウザ戦争として知られるNetscape NavigatorとInternet Explorerのシェア争いがありました。その際、それぞれのブラウザで仕様を逸脱した独自タグによる身勝手な拡張合戦が行われたという不幸な歴史があったことも皆さんご承知の通りです。その結果、Webアプリケーションの相互運用性(インターオペラビリティ)が失われることになりました。

現在の状況

 このように、ブラウザ間での非互換状況が生じてしまったために、コンテンツ作成者やWebアプリケーション作成者には、さまざまなWebブラウザに対する相互運用性を確保するための努力が強いられることになりました。

 一つには、HTML解釈の差が生じないような、共通な範囲のみでコンテンツを作成するというアプローチがあります。ただしこの方法はデザイン上の制約がかかる場合もあり、そのトレードオフが難しいところです。

 またJavaScriptを利用してクライアントごとにコンテンツの記述を切り替える方法もあります。あるいはリクエスト時にクライアントから送られるユーザーエージェント情報を参考にして、サーバ側でそれぞれのブラウザに最適化されたコンテンツを配送する工夫をしているところもあります。ただしこれらの方法は、Webブラウザをクライアントに用いることでシステム開発のコストを削減するというメリットを最大限に享受していないうえに、同様のコンテンツを重複して作らねばならないという無駄が生じています。

 最近では、ブラウザ間の差をシステム的に吸収できるようにあらかじめ構築されているフレームワークやprototype.jsなどのライブラリ、あるいはCMS (Contents Management System)を利用するという解決策もあります。

依然として残る非互換問題

 しかし検証コストの削減や、マルチプラットフォーム対応に関する意識の低さなどから、いまだにアクセスを特定のブラウザ(IE)に限定しているケースも少なくありません。

 「このコンテンツはIEで正しく表示できることを確認していますが、その他のブラウザでの閲覧については未検証のため保証しません」というように、ただし書きで制限しているレベルであればまだかわいいほうです。先に述べたようなユーザーエージェントの値をみてサーバ側で判断し、システムとしてブロックしてしまう例もあり、困った問題です。

ユーザーエージェントの擬装
 サーバ側でユーザーエージェントの値をみてブロックしてしまい、IEからのアクセスを要求するような場合でも、Firefoxなど他のブラウザからアクセスしても問題ないことがあります。サービスの提供者がIEの特定のバージョンからのアクセスしかテストをせず、安全のためにクライアントを限定しているようなケースでは、実際にはIE以外のブラウザからアクセスしても問題なく利用できることも少なくありません。
 このようなケースでは、HTTPのリクエスト時にブラウザからサーバへ送信するユーザーエージェントの値を切り換えるだけで何の不都合もなくサービスを受けることができます。UserAgent Switcherは、ユーザーエージェントを切り替えてブラウザの種類を擬装することができるようにするためのFirefox拡張機能です。
 これを使うと、実際にはFirefoxからアクセスしているにもかかわらず、IEからサーバにアクセスしているフリをすることができます。
 そもそもIEにしても、IEがまだマイナーなブラウザでNetscapeが大きなシェアを占めていたときに、Netscapeに限定したサービスにも対応できるように、あたかもNetscapeからアクセスしているかのようなユーザーエージェントの値を送信していました。現在でも、IE 6.0から送信されるユーザーエージェントは、「Mozilla compatible...」となっています。
 ただしこれはサービス提供者の意図しないアクセス方法であることには十分に注意してください。この機能を使ってアクセスした際に問題が生じたとしても、サービス提供者に苦情を申し立ててはいけません。あくまで自己責任で利用するようにしてください。

  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 飯尾 淳(イイオ ジュン)

    1970年生まれ。株式会社三菱総合研究所 情報通信技術研究本部 情報技術研究グループ 主任研究員。専門は、画像処理とユーザインタフェース……のはずが、なぜか最近はOSS普及振興の手伝いで多忙な毎日を過ごしている。著書に「Linuxによる画像処理プログラミング」、「リブレソフトウェアの利用と開発~I...

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5