CSCGI
クライアント・サイド・CGICGIでよく使う?のあとのパラメタを、クライアントで実行されるプログラム(つまりスクリプト)で処理する方法について解説します。
1998年4月27日
■CGI
CGI(Common Gateway Interface)というものは、サーバー側でプログラムを実行し、 その結果をHTMLなどの形式でブラウザに転送してくるというシステムです。細かい説明については専門書を参考にしてください。このCGIにはプログラムにパラメタを指定することができます。 CGIのURLに続けて｢?｣のあとにパラメタを指定する｢QUERY_STRING｣方式と、 フォーム内のテキストボックスなどのコントロールの値をパラメタに指定する｢stdio(スタンダードアイオー)｣方式があります。
どちらもネーミングは私が付けたのでaboutです。細かい仕組みについても専門書を参考にしてください。 この二通りのパラメタの指定のうち、前者の｢QUERY_STRING｣方式を、クライアント(WWWブラウザ)側で処理するのがCSCGI(クライアントサイドCGI)です。 ｢クライアント・サイド・イメージマップ｣という言葉を文字って名前を付けましたが、 HTMLファイルのURLにパラメタを付けて、プログラムに解釈させるところがCGIに似ているのでこういう名前に付けました。
ただクライアント側(WWWブラウザ)のスクリプトで、URLの解釈をしているだけなので、だいそれた事ではありません。
■その前に
パラメタを指定して、特定のHTMLページに違った処理を行うには、本来はCGIを使うしか方法がありません。 ただしCGIはサーバーのプログラムなので、当然ですがサーバーの力を使うことになります。私は｢クライアント・サーバー・モデル｣という言葉が好きです。 現代のコンピュータの分散処理というのを担うこの考え方は、サーバーに処理を集中させないというものでした。 私はサーバーに負荷をかけるというシステムはあまり好きではありません。 Webページを作っていてもなるべくサーバーの負荷を気にする必要がないように、 極力はHTMLのスクリプトでダイナミックなページを提供できるように考えています。 だからCGIというのはあまり使いたがりません。 CGIによく使われるPerlなどの言語も大嫌いなせいもありますが…。
で、HTMLでパラメタを指定できる方法がないものかと考えたのが、JavaScriptを搭載したNavigator 2.0が登場した96年でした。
当時のJavaScriptでは(Netscape提供の)資料が不足していたせいもあったので、この企画自体を考えただけで気が遠くなるような思いをしました。
当初の計画では、ヘッダーとコンテンツに分けたフレームのWebページを使ってパラメタの処理をやっていました。 その頃の私の代表作が、｢SIGNLANG(マルティメディア手話)｣でした。 常に表示されているヘッダーのスクリプトでパラメタを変数として管理しておいたのです。
かならずフレームのページにしなければいけないという制約があったので、この手段ではあまりスマートではありませんでした。
■本題
このCSCGI自体を実際に体験してもらうためにここをクリックしてください。突然ページがジャンプしてびっくりする(した?)かもしれませんが、ツールバーのURLを見てください。CGIのように?でパラメタを指定されているのが分かると思います。
それ以前は｢/~snagano/factory/｣で、実は今も同じURLに入ることになっています。 最初はこのページくるまでに、Factoryのホームのリンクからここまできたと思いますが、 上の｢ここ｣のリンクをクリックしてページがジャンプしたら一発でこのページまで来ましたよね。
｢?｣の後ろをスクリプトで処理するのがこの企画なので、長いゴタクを読んだらさっさと次へ進みましょう。
■スクリプト
まずは何も言わずにこのスクリプト(JavaScript)を見て分かってもらえないでしょうか？テキストボックスにしたので、後でコピーして使いやすいと思います。
このスクリプトの2行目の｢location.search｣の値から｢?｣の後ろのパラメタを抽出しています。 3行目以降は、パラメタの解釈をしているだけです。
で、このスクリプトの関数は、｢変数名1=値1&変数名2=値2&...｣の形式で指定されたパラメタから、 引数paramで指定された変数名の値を返す仕組みになっています。指定した変数名がなければ長さ0の文字列を返します。
パラメタ全体の解釈の仕方は、このケースではCGIと同じスタイルにしてみました。
｢?｣でパラメタが指定してあっても、WWWサーバー側ではHTMLなのでパラメタの処理はされないので、 パラメタを含んだ形でURLがサーバーから返ってくるのです。 もしファイルの拡張子が｢*.cgi｣や｢*.pl｣ならサーバー側で実行されることになります(もちろん実行権が与える必要がある)。 しかしHTMLは拡張子が｢*.html｣であり、WWWサーバーの標準では実行権を与えても、テキスト内容がそのままクライアントに送信されます。
このテキスト内容(HTML)に、自分のURLを解釈させているのがlocation.searchという変数です。
■余談
以前に、URLが｢index.html｣なのにCGIとして実行されているサーバーをよく見ました。おそらくSSIを装備したWWWサーバーだったのだと思います。 ですがSSIなどを装備していないNetscape系のWWWサーバーなどでは、 拡張子が｢*.html｣をテキスト形式ではなく、なおかつ実行権を与えることでCGIのように動作させることはできないのでしょうか？ ちょうどMicrosoftのIISのActive Server Pageと同じ仕組みになると思います。HTMLのファイルに実行権を与えればSSIがなくてもカウンターなどを動かすこともできるでしょう。
■応用方法
話を戻しますが、このパラメタを解釈する前にパラメタ自身を暗号化する必要があります。 パラメタに｢?｣や｢=｣や｢&｣が紛れ込んでいると、上述の方法ではパラメタが正しく解釈されなくなります。 暗号化とはPerlなどのCGIのスクリプトでよく見る16進数表記を元の文字列に戻す処理と同じです。上述のスクリプトではescape()メソッドとunescape()メソッドを使って、それぞれ暗号化と解読をしています。
ただしescape()関数は、非ASCIIキャラクタにはUnicode式の暗号化(%u2E4Cなど)をするので、従来のCGIで処理にまわすときには注意が必要です。 詳しくはMicrosoft Internet Client SDKなどをご覧ください。
さて私の応用方法ですが、私のWebサイトではフレームを多用しています。
フレームページを使っていて、一番困るのは、そのページを開いていても、
ブラウザのツールバーに出ているURLと現在のフレーム内のページがイコールではないということが起るのです。
よくない例がここです。
このページのURLにアクセスしても、細かなセクション(裕太君の部屋)などへアクセスするには、
トップのページから必ずユーザーがリンクをたどっていかなければいけません。
それでもかまわないWeb管理者はいますが、見ているユーザーにとって面倒だし、
それが美的ではないというWeb管理者も入ると思います。
そのようなときに、このパラメタの解釈を使えばいいのです。
私のページのほとんどはフレームを定義しているindex.htmlというファイルに、このパラメタ解釈できるようにしています。
index.htmlのあとに｢?url=cscgi.html｣というパラメタを指定すると、｢url｣という変数の値である｢cscgi.html｣というページをフレームの中で表示するようになっています。
COPYRIGHT 1998
COPYWRONG 1987, 1998
トップ
管理者へのメールはこちら