フォームを送信すると，何らかのかたちでその内容が処理されたページが返ってくることが多い。それを行うための CGI について，簡単に紹介しておこう。また，アプレット作成言語の Java も紹介しよう。

　フォームデータの処理に頻繁に用いられる CGI は Common Gateway Interface の略で，WWW サーバとたとえばフォームデータを処理するプログラムとの仲介をするものである。したがって，フォームデータを処理するためには，CGI からデータを受け取って結果を WWW ページのかたちで出力するプログラムがなくてはならない。

　CGI プログラムは一般にサーバ上で動作するものなら種類は問わない。よく用いられるのが Perl と呼ばれるインタプリタ型のスクリプト言語である。このほかには，C で組まれたプログラムをコンパイルしたものが使われたりする。ともかく，結局はプログラムが組めなくてはならないのである。

　CGI を利用するためには下準備が必要である。たとえば，“.htaccess”というファイル（先頭がピリオドから始まることに注意）を作り，CGI を使用することを宣言しておく。

　フォームから送られたデータは，<FORM> の METHOD 属性によってプログラムへの渡され方が異なる。

　METHOD="get" の場合は，フォームデータは環境変数に格納されて渡される。いっぽう，METHOD="post" では，フォームデータは標準入力から流し込まれる。それらをパラメータとして，適当な処理をしてページを吐き出す。

　CGI プログラムの中には，入力がある種のコマンドとして実行されるケースも少なくない。もし，“ファイルを消す”コマンドが第三者によって実行できてしまうようなプログラムを作ってしまったら，これはセキュリティ上の大穴になってしまう。

　というのはもっとも簡単なケースで，実際にはもっと考慮すべき点・防衛すべき点がある。CGI に関しては，セキュリティというのは最大の課題である。

　これは CGI プログラムを作るときの問題だが，フォームから受け取るときに，データが基本的にほとんど無防備で送られるという点にも注意しなくてはならない。また，UA はしばしば METHOD="post" のフォームデータを送るさい，警告を出すことも気にとめておく必要がある。

　このような問題から，プロバイダによっては CGI の使用を許可していない場合もある。CGI が使用できるかどうかはサーバ管理者あるいはプロバイダに問い合わせられたい。

　JavaScript を紹介したときにこの Java を引き合いに出したが，ここでは Java アプレットを作成するときに限って，特徴から述べてみよう。

　Java の動作に関しては，Java VM という仮想マシンが実装されている必要がある。Java のプログラムはいったんコンパイルされるが，それは CPU に依存した機械語になるわけでなく，中間言語と呼ばれるものになる。この中間言語をインタプリトするのが Java VM である。まったくのソースコードを実行するのではないから，一般のインタプリタ型言語に比べると動作は速いが，それでも一気に CPU 依存の機械語を吐き出す C のようなコンパイラ型の言語よりは低速である。そこで，中間言語を CPU 依存のコードに再コンパイルする JIT を使って高速動作を実現させることもある。ただし，その場合はアプレットが始動するまでに若干の時間を要するというデメリットもある。

　Java のオブジェクト指向はひじょうに厳格（純粋）である。オブジェクトは，その性質によってモデル化されたクラスからインスタンスという実体を確保することで利用可能になる。おなじ“オブジェクト”が強調される JavaScript と比べても，その扱いに異なる点があることにお気づきいただけるだろう。

　Java の開発環境は現在さまざまなものが出回っている。アプレット作成の実際は本稿の範囲外なのでここでは触れないが，Java に関する書籍もひじょうに多く，開発環境にオンラインヘルプなども添付されているであろうから，それらをご覧いただきたい。

　無償で利用できる Java の開発環境としては，サン・マイクロシステムズ社が配布する JDK，インプライズ社が提供する JBuilder Foundation（使用には登録が必要）がある。

　リソースなどの制限によって，Java を使わないような設定にしてある場合もありうるので，それも想定してアプレットを含めた WWW ページの作成を心がけることが大切である。

　UA の拡張機能として提供されるプラグインも，種類によっては，インタラクティブなサイトを構築するのに利用することができる。マクロメディア社の Flash で作成したベクトルベースのアニメーションムービーを再生するための Flash Player などが知られている。

　ただし，多くのプラグインは Netscape Navigator または Internet Explorer 専用なので，今でこそこれらの UA が大多数を占めるとはいえ，プラグインのベンダが作らない限り絶対的にコンテンツの実行および閲覧不可能なプラットフォーム，UA もでてきてしまう。また，プラグインを改めてインストールする必要もあるので，プラグインばかりを使ったようなページというのは，見る側にとっても負担が大きい。

　プラグインは <OBJECT> で使うことになろうから，必要に応じて代替措置を講じておくことも忘れないようにしたい。

　インタラクティビティというのは，これからのインターネットの重要なキーワードのひとつになる。しかし，何でもかんでもインタラクティブというのは逆効果であろう。見る側にやさしいインタフェースで，オンデマンドに提供されるインタラクティブなサービスが魅力あるサイトにつながるのではなかろうか。