![[うさぎ印]](/image/usagi/usa-s.png)
おたより, お待ちしていますSSI を使ってページ製作で手を抜く
web page 制作って, 割と面倒だと思いませんか? 「そんなことを言うなら, web page なんて作らなければいい」と正論を吐く人もいるとは思いますが, 事情はそんなに単純ではありません. 基本的に web page を制作することが好 きであっても, 次のような作業は面倒だと思いませんか?
ネタを考える, レイアウトを考える, 文字を打つ, 絵を描く, 音を作る, 何かを作る -- こういう行為は好きなんですが, 上に挙げたような, web page を作る上での 非本質な作業 は面倒じゃないですか?
上に挙げた中で, 気分転換に, 全てのページの背景色, 背景画像を一気
に変えてみる
というのは, CSS
を使うことで楽に行うことができます. でも, それ以外は通常の HTML の枠組
で解決するのは難しそうです. そこでここでは,
SSI を使って上に挙げた問題の
一部を解決したいと思います.
SSI は, もともとは NCSA で開発された web server の機能でしたが, 現在では Apache をはじめ, いくつかの web server にも実装されている機能です. これを使うと, そのページが要求され たときに次のようなことができます.
これを使えば, 例えばあるページの最終更新日を別のページに自動的に挿 入したり, 共通のフッタを全てのページへ埋め込んだりすることができそうで す.
ページが要求されたときにひと捻りする方法としては, SSI 以外にも, 次のようなもの があります.
それにも関わらず, ここで SSI を選択した理由は, 私の HTML 編集方法に SSI が一番合っているからです. 私は, Mule + PSGML で HTML 文書を 編集し, SP に含まれる nsgmls で文法をチェックします. つまり, HTML 文書の編集中でも常 に文法を意識したい のです. 上に挙げたものは, 自由度は高いんです が, 編集中に気軽に文法チェックができないんです (私がやり方を知らないだ けか?). それに比べて SSI は, 一見すると HTML 文書中のコメントなので nsgmls には無関係ですし, やれる ことが少なく, SSI を処理 する前後で大きくページが変わらないので, 編集中に文法をチェックして OK ならば, SSI の処理後の文書の文法も OK だろうということが期待できます.
ところで, あなたの使っている web server では SSI を使えますか? 残念ながら, 私は使えません (;_;) じゃあ, どうしよう? 手元のマシンで SSI を処理して, それを web server へ FTP すればいい んです. もちろん, 外部コマンドの実行 結果を取り込むようなことは, この方法ではできないので諦めます. でも, 最 終更新日の表示やテキストデータの挿入などは, 手元のマシンで十分可能です.
あるいは
they are too slow to parse
という理由で, SSI
を動的に実行させたくない場合があるかもしれません.
条件分岐 (if など) やコマンド実行 (exec) の
ように, その場で解釈しないと意味がない element もあります. しかし
element によっては, HTML 文書が要求されたその場で解釈しなくても何とか
なるものもあります. そういう element については, あらかじめ処理してお
いた HTML 文書を用意しておくほうが, 動作が速くなるでしょう.
というわけで, SSI の一部の element を理解し処理する HTML 文書向けのフィルターが欲しくなりました. 同じことを考えている人はいるだろうと思って, サーチエンジンを探しまくっ たのですが, 見つけられません (;_;) ならば, 無いものは作る しかありません. これが, この道 (?) の掟です.
とりあえず解釈してほしい element は include だけだった
のですが, だんだんと欲が出てきて, 今では次のような element を解釈して
欲しいと思います. これだけあれば, 十分でしょ?.
config
<!--#config sizefmt="…" --><!--#config timefmt="…" -->fsize
<!--#fsize file="…" -->flastmod
<!--#flastmod file="…" -->include
<!--#include file="…" -->echo
<!--#echo var="…" -->set
<!--#set var="…" value="…" -->
LAST_MODIFIEDどうせ自作するのなら, 自分向けに少し拡張したいと思います. これまで HTML 文書を作ってきた経験から, 次の 2 つの機能が欲しいと思います.
<!--%usagi% lang -->他言語で記述されたページへのリンクを自動付加
<!--%usagi% copyright year -->簡単なコピーライト表示
残念ながら, web 上のデータの多くは英語で書かれています. ということ
は, web の利用者も, 日本語を理解する人よりも英語を理解する人の方が, 圧
倒的に多いでしょう. 「ふん, 俺の書いた文書を読みたいなら, 日本語を勉強
して出直してきな」と言い切れるほどのネタを持っていればそれでもいいかも
しれませんが, 私なんかは「英語でも書きましたので, ぜひ見に来て下さい」
という低姿勢です (^^; というわけで, 私の作った HTML 文書の一部には, 英
語版が存在します. そのような状況で, 日本語版と英語版の文書間に, 相互に
自動的にリンクを張るのが, 前者の
他言語で記述されたページへのリンクを自動付加
です.
具体的には, 以下のような命名規則を決めました.
そして, もし処理するファイルが日本語版なら, その英語版のファイル名 を探し, もし見つかったらリンクを張るというようにします. 処理するファイ ル名をプログラムを知るためには, 処理するファイルをプログラムの引数で指 定する必要があり, 標準入力から処理するデータを入れることができないこと になります.
後者の 簡単なコピーライト表示
とは, 西暦を指定するだけで次の
ようなコピーライト表示を出力するというものです.
<p class="copyright">Copyright (C) 2000 Masahiro SATO</p>
オリジナルの機能の識別子は %usagi%. usagi とは, "Usagi Sells A Great Iceberg" の略で…
Ruby が必要です.
入力ファイル名を指定します. データを標準入力から入れることもで きますが, そのときは前に説明した通り, 他言語への自動リンクがで きなくなります.
出力するデータの文字コードを指定します. 以下のどれかを指定しま す.
このオプションが指定されていないときは, 入力データの文字コー ドと同じコードで出力します.
このオプションが指定されているとき, あるいは指定されていなくてもスクリプト内部で推測可能な場合は, 内部で EUC に変換してから処理します. 出力文字コードが指定され ておらず, かつ推測不可能な場合は, そのまま処理します.
他言語で記述されたファイルが見つからなくても, 強制的に他言語へ のリンクを張ります.
./hf.rb --input-file index.uhtml > index.html
元ファイルの拡張子を通常の shtml にすると紛らわしいので, 私は個人的 に uhtml を使ってます. 上に挙げた element は, 全 て解釈します. ついでの機能 も実装してますが, これ を無視して ごく普通の SSI フィルタ として 使えると思いますので, 興味のある人は試してみて下さい.
ただし, 以下の機能は実装されてませんので, 御了承下さい. 今後の課題 としたいです.
<!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" -->
のような, ${foo} による変数の参照なお Lynx は, そのままでは, *.uhtml という拡張子のファイルを HTML 文書だと認識しません. *.uhtml な ファイルを Lynx でチェックした いときは, -force_html オプションを付けて起動しましょう. こ んなふうに.
lynx -force_html index.uhtml
楽したいこととしてリストアップした項目 を振り返 ると, 実はごく一部しか実現できていないことがわかります (^^; でも, 単純 な SSI だけでもかなり楽ができ るので, 私としては結構満足です :-)
でも, 例えば index.uhtml を更新したら, 毎回 index.html を作り直さね ばならず, 新たな面倒の種ができたような気もします. 次は, このような場面 で手を抜く方法を考えていきたいと思います.
(補注) タイトルでは「製作」を使っておきながら, 本文では「制作」を使っ てますね :-) 一応, 両者の違いは理解しているつもりですが…
おたより, お待ちしています
Copyright (C) 2000 Masahiro SATO