ある HTML ファイルを別の HTML ファイルに含めるにはどうすればよいですか?
Web サイトに一貫したテーマを設定するのは非常に一般的な方法です。標準のナビゲーション バーやロゴ、さらには著作権や管理情報を含むページ フッターだけがある場合もあります。実際に各ページにその情報を含めるのではなく、ナビゲーション バーを 1 回作成して 1 つのファイルに保存し、その後、複数の異なるページのそれぞれでそのファイルを参照できれば確かに便利です。ナビゲーション バーを 1 か所で変更すると、すべてのページが即座に更新されます。
「インクルード」ファイルへようこそ。これは、Web サイト上でこれやその他のことを実行できる非常に強力な機能です。
•
クライアントとサーバーの 2 つのカテゴリに分類されます。 「クライアント」側のインクルードは、ブラウザによって実行されるインクルードです。残念ながら、HTML にはクライアント側インクルード用の特定の構文がないため、JavaScript を使用して小さなゲームをプレイする必要があります。 「サーバー」側のインクルードはまさにそれです。インクルードは Web サーバー上で行われるため、クライアントのブラウザーはそれが起こったことさえ知りません。
サーバー側インクルード
概念的に簡単な方、つまりサーバー側インクルードから始めます。具体的な構文は、サーバーの種類とページの記述内容によって異なります。
ほとんどの一般的な Web サーバー上の単純な HTML ページでは、サーバー サイド インクルード (SSI) と呼ばれる構文を使用できます。例として、HTML ファイル a.html に次の行を配置できます。
a.html を表示しているブラウザーに表示されるページは、include 行の前にある a.html の内容で構成され、その後にその行が続きます。 b.inc のコンテンツ、その後に include 行の後に a.html のコンテンツが続きます。ナビゲーション バーの HTML を b.inc などのファイルに配置すると、すべてのページにまったく同じバーを表示できます。
SSI は、Apache と Microsoft IIS Web サーバーの両方で使用できます。 Apache では、いくつかの設定が必要になる場合がありますが、実際のサーバー設定ファイルにアクセスできない場合でも、通常は、サーバーの Web ディレクトリで検索または作成できる .htaccess という名前のファイル内のコマンドによって有効にすることもできます。 Apache SSI の詳細については、こちらをご覧ください。 IIS では、「.asp」ページを使用するときはいつでも SSI が有効になります。そのため、必要な設定はページに .html ではなく .asp という名前を付けることだけです。 ASP ページのサーバー側インクルードの詳細については、こちらをご覧ください。
もう 1 つの人気のある ASP のようなプログラミング環境は PHP です。 PHP のインクルード構文は非常に単純です:
readfile("b.inc"); ?>
当然、PHP には追加の処理能力が多数ありますが、ASP と同様に、上記のインクルードを機能させるための唯一の要件は、Web サーバー上に PHP を配置し、ファイル「.php」。
上記のすべてのアプローチでは、ページを表示しているブラウザーはインクルードについてまったく何も知りません。すべてはページがダウンロードされる前に起こっています。ただし、サーバー上でインクルードを処理することが適切なオプションではない場合があります。ここで、クライアントでのインクルードの処理が必要になります。
クライアント側インクルード
上で述べたように、クライアント側インクルードの実際の構文はありませんが、JavaScript を使用して模倣することができます。例:
が見つかると、ブラウザーはスクリプト「b.js」をダウンロードして実行し、スクリプトが生成する出力をインライン HTML であるかのように出力します。技術的には、これはインクルードではありませんが、スクリプト "b.js" は、次のような一連の JavaScript "print" ステートメントにすぎません。
document.write("
") document.write( "
")
... など
含めたい HTML が「印刷」されていることがわかります。つまり、インクルード ファイルを一連の JavaScript 出力としてフォーマットできる場合は、クライアント側のインクルードを使用してそのファイルを挿入できます。
ここで、リモート インクルードと CGI プログラムという 2 つのものを混合に導入するので、物事は非常に興味深いものになる可能性があります。
リモート インクルード
これまでにインクルードしたファイルは、他の HTML ページと同じ場所にある独自のサーバー上にあると想定されています。ほとんどの場合、インターネット上の他のサーバーへの完全な URL を使用して「含める」ことができます。
クライアント側インクルードの場合は非常に簡単です。
readfile("http://example.com/b.inc"); ?>これは、b.js が独自のサーバーではなく example.com からロードされることを除いて、前の例とまったく同じように機能します。同様に、PHP も「正常に動作します」:
残念ながら、Apache SSI ディレクティブはリモート インクルードをサポートしていません。しかし、ほとんどの場合方法があり、CGI を使用した回避策があります。
CGI に含まれる
これまでのところ、「静的」HTML ページのみが含まれています。結局のところ、サーバーで実行される CGI プログラムの出力を「含める」ことができることがわかりました。これは、Apache がリモート インクルードをサポートしていないことに対する解決策になります。この非常に短い Perl プログラムから始めます:
use LWP::Simple; print "Content-type:text/htmlnn"; getprint ($ENV{'QUERY_STRING'}));
We'll call it "proxy.pl". Proxy.pl must be appropriately installed on your server into your cgi-bin directory or its equivalent. By being local to your server Include directives can reference it.
Proxy.pl simply fetches the contents of URL passed as a parameter. This means we can perform an apache remote include this way:
It works like this:
The include executes proxy.pl with the parameter "http://example.com/b.inc"
Proxy.pl then fetches b.inc from example.com and prints it.
The result is that the contents of b.inc show up as an included file.
Includes + remote includes + CGI
So far we've used a CGI program to fetch what is essentially just another static html file. In fact, if we put all these pieces together we can create some very useful and interesting internet applications.
Randy Cassingham of This is True wanted to be able to provide his readers who had web sites the ability to host one of his stories. Sounds like a job for an include file, right? But he also wanted that story to change every day. That's more than a static HTML page; that's a CGI program that outputs a different story each day.
The result is tad.pl (True-A-Day) - a Perl script that picks a new story every day and outputs HTML. Given what we've talked about so far so you can probably guess how it's used. As a client side include:
That's it in its simplest form. Note that:
tad.pl is written in Perl. It does whatever it needs to gather the HTML for the story to be output.
tad.pl outputs javascript. In fact, tad.pl's output is nothing more than a series of "document.write" statements.
The client browser executes the javascript. The result is that it prints the HTML that tad.pl constructed for today's story.
Using tad.pl in a server-side include looks like this:
Note that as discussed above we had to use a local CGI program, proxy.pl, to fetch the remote URL.
Note also that we've added an additional parameter, ssi=1. This causes tad.pl to output the HTML it gathers without the javascript document.write statements. The final sequence looks like this:
proxy.pl executes on your server, and is passed the URL "http://www.thisistrue.net/cgi-bin/tad.pl?ssi=1".
proxy.pl fetches that URL, causing tad.pl to execute on www.thisistrue.net.
tad.pl once again does whatever it needs to gather the HTML for the story to be output.
tad.pl outputs the HTML to be included.
That output is returned to proxy.pl, which in turn prints it, where it becomes the "included text".
The client browser sees nothing but HTML - the HTML from the containing page with the HTML from tad.pl inserted in place of the include statement.
As you can see, includes are not only a great organizational tool allowing you to collect common information into fewer files, but also a powerful way to add functionality to your web site and perhaps others. I'll end this with True-A-Day included via a client side include:
