- 2 サイト表紙
- 3 しらぎくさいと実験室
- 4 雑記帳
- XHTMLから旧式HTMLへの変換スクリプト
『しらぎくさいと』が導入した、XHTMLから旧式HTMLへの変換機能を実現するPerlスクリプトについて解説します。
制作者は新しい仕様には、後方互換性を確保出来る限り決して反対しません。
XHTMLについては、
から、いずれにしても後方互換性が維持されたものとなっております。
従って、制作者はXHTMLに関しては現在反対しない立場を採っております。
この文書も、決してXHTMLを批判するためのものではありません。
上記の通り、この手の機能を実現するには、XSLTを用いるのが一番いい方法です。
しかしながら、XSLTをサーヴァ側で使う技術はまだ余り普及していない事(制作者のサーヴァにも入っていませんでした)などの理由から当面代用出来るCGIを導入する事としました。
上述の通り、制作者は後方互換性には常に最大限に配慮する主義を持っております。
このため、GIF画像に較べて利点が多いとされたPNG画像も導入を控えてきました。
一方、HTML文書に関しても、幾つかの問題がありました。
現行のXHTML 1.0/XHTML 1.1は旧式のユーザエージェントがサポートしているとされるHTML 2.0/3.2とさえ極めて高い互換性を持ちます。
しかしながら、XHTMLは後発の規格のため、旧式のウェブブラウザでは幾つかの問題が生じます。
具体的には、以下のような問題があります。
<?xml ?>宣言は、サーヴァが文書配信の際に文字コードを指定するか、UTF-8文字コードを採用している場合は省略可能です。
しかしながら、省略出来ない場合は、旧式のウェブブラウザで幾つかの問題が発生します。
これらの問題から、旧式のブラウザには<?xml ?>宣言を除去してやる必要があります。
ネットスケープ 4.x以前では、id属性によるフラグメント(≒終点アンカー)を認識しません。
この事により、id属性をフラグメントとして用いた場合、アンカーによるページ内のフォーカスの移動が出来なくなります。
従って、id属性を含んだ要素を<a name>要素に変換してやる必要があります。
ネットスケープ 4.0xでは、認識しない後発のインライン要素(<dfn>要素, <q>要素など)が含まれたHTML文書を読込むとクラッシュする場合があります。
また、このような問題が無いにしても、旧式のユーザエージェントが認識しない後発の要素に関しては、何らかの補助的な処理が必要でしょう。
いくつか例を挙げておきます。
勿論、これらは実装の問題なので、XHTMLの仕様には何の責任もありません。
しかしながら、それはXHTML文書を公開するにあたって旧式ウェブブラウザを排除していい理由にもなりません。
一方、それなら在来のHTMLでマークアップすべきと言う意見もあるでしょうが、後方互換性を確保出来さえすれば、対応出来る環境には新しい技術を導入する事は決して否定されるべきものでもありません。
つまり、
と言う事なのです。
サーヴァがHTML文書を配信するに当たって、或いは<meta http-equiv="content-type">要素で文字コードを指定するに当たって用いられる公式なシフトJISコードの表記は言うまでも無く「shift_jis」です。
しかしながら、ネットスケープ 2.xではこの表記を認識せず、それどころか文字化けの原因にさえなります。
x-sjis」を指定するものとしました。実際問題として、ネットスケープ 2.x以前のユーザエージェントは絶滅したと判断して問題はありません。
なぜなら、ネットスケープの2.x版以前には有効期限が設定されていて、その期限を越えた今日では利用出来ないようになっているからです。
こう考えると、制作者が日ごろ主張する後方互換性の「後方」にさえなっていないと言えます。
ただ、何らかの形で利用されないとも限らないので、一応対応しておく事にしました。
具体的には、以下の処理を行いました。
ここでは、後者の処理CGIについてのみ解説いたします。
旧式ユーザエージェントとしては、以下の範囲を考えました。
インターネットエクスプローラ 3.xではCSSだけでなくJAVAスクリプトにも大きな問題を孕んでいるそうなので、対応が必要でした。
マッキントッシュ版4.xでは一部<?xml ?>宣言が重大な問題を惹き起こすため対応します。
id属性をフラグメントとして認識出来ないため、4.x以前は全て対象とします。
更に、ネットスケープ 2.xは文字コード表記の問題もあります。
オペラやネットフロント以外のモバイル向けフルブラウザでは、CSSが効きません。
また、モバイル環境ではJAVAスクリプトが使えなかったり、使えても却ってユーザビリティを損ねる恐れがあるため、スクリプト関連の要素を取り去ります。
処理CGIでは、以下の処理を行っております。
インターネットエクスプローラ 4.x(マッキントッシュ版)ではこの処理のみが行われます。
XHTML文書ではこの他にも幾つかの処理命令が用いられる場合があり、これらも全部削除されます。
id属性の値をname属性値とする<a>要素に変換します。
このとき、<a>要素の配置にはそれなりに配慮します。
尚、稀に空の<a name>要素をフラグメントとして認識しないものがあるそうですが、ネットスケープ 3.x〜4.xなどでは問題は無いようです。
尚、id属性には他にも幾つかの機能がありますが、ネットスケープ 4.x以外では全く意味が無いので最終的には削除されます。
現時点では予め非表示扱いとするクラス名を設定しておいて、それに合わせてコンテンツの出力/破棄を判断しております。
勿論、非表示クラスを与えられた要素の下位要素に関しては、非表示が継承されます。
但し、クラスセレクタのみを対象としており、一意セレクタや要素セレクタ、CSSの継承を活用した複雑なセレクタ(子孫セレクタ, 直下セレクタ, 隣接セレクタ及び属性セレクタ)などは現在のところ認識出来ません。
この点に関しては是非改良したいと思っております。
一応、以下のものを変換しました。
x-sjis」に置換します。今後の課題としては、以下のものが挙げられます。
例えば、オプション処理に関して、記述をより容易にするには、仕様の整備が欠かせません。
こういった問題を詰めて行く必要があるでしょう。
クラスセレクタ以外のセレクタにも対応すべきでしょう。
また、複数のセレクタを組み合わせたものにも対応出来るようにしたいものです。
例えば、論理要素を<font>要素などの物理要素に置き換えたいと言う要望もあるかも知れません。
こう言ったものに対応するには、カスタマイズ出来るようにする必要があります。
より文法的に正しい配置になるようにする事は勿論、<a>要素もなるべく空要素にしないようにしたいものです。
これらの機能を充実出来れば、配布も可能になるでしょう(需要があるかどうかは分りませんが…)。
初めに述べた通り、このようなコンテンツ変換機能の実現には本当はXSLTを用いるのが一番順当な手段です。
所詮CGIによるコンテンツ変換は代用品に過ぎないのです。
とは言うものの制作者にはその代用品さえも欲しかったため作る事にしました。
蛇足ですが、ストリクトなHTML/XHTMLは、旧式のユーザエージェントでも取扱えるレガシィなHTMLへの変換も比較的容易に出来るのも長所と言えるのではないでしょうか。
