「@nifty @homepage」利用者だった人のための「@nifty ホームページサービス」について

【2021/05/10】
「標準モジュール」に関する記事について、認識の違いがあったので修正。

いつも「ホームページの仕様、どんなんだったっけ?」ってなるんで、備忘録。

経緯

元「@nifty @homepage」利用者は、「@nifty ホームページサービス」への移行案内の際、適切に手続きをしていれば、「@niftyホームページサービス(ミニ)」というプランで移行されている。

これは @nifty を2016年以前から契約利用し、かつ当時無料にて提供されていた「@nifty @homepage」を利用していた人向けの、言わば「救済」プラン。

プラン毎の違い

ちなみに「@nifty ホームページサービス」には、以下の3つのプランがある。

  • LaCoocan ライト(1G。CGIなど色々不可)
  • LaCoocan スタンダード(4G。CGI、DB利用可)
  • LaCoocan スタンダードプラス(10G。スタンダードの大容量版)

「ミニ」プランから「LaCookan スタンダード」「LaCookan スタンダード」のプランに変更することは可能。ただし変更後は、再度「ミニ」「ライト」プランに戻すことができない。

「@nifty ホームページサービス」既存の各種プランと違うところ

  • ディスク容量が2GB(ライトは1GB、スタンダード4GB、スタンダードプラス10GB)
  • CGI は Perl のみ利用可(ライトは利用不可)
  • CGI 定期実行が利用可(ライトは利用不可)

機能の違い

「@nifty ホームページサービス」への移行によって変わった機能

プライベートパック

アクセス制限機能(.htaccess、.htpasswd)による BASIC 認証に変わる(利用には再設定が必要)。

SSLも未提供。

URL

別物のサービスなので、URLも変わる。

FTP

サービス自体が別物扱いなので、すべて再設定が必要。
接続先ホスト名・アカウント名などが変更になる。

CGI

ホームページアドレスとCGI環境のアドレスが統合され、すべてホームページアドレス内で動作するようになった。
つまり cgi-bin ディレクトリがなくなり、すべて homepage ディレクトリ配下で、HTML ファイルと同じ場所にCGIの実行ファイルを設置し、そのファイルに実行権を与えれば動作するようになる。

「@niftyホームページサービス」では提供されなくなった機能

  • アクセスカウンター
    (自前CGIで実現可能。だが今時のコンテンツにおいてアクセスカウンターは流行らないし機能不足。解析用途であれば、Google Analytics などを導入するほうがよいと思う。)
  • サクサクかきあげ君
  • 簡単マイページ設定
  • 公開停止・再開機能(アクセス制限機能で代用可能)
  • 素材集(巷のWebコンテンツから拾えばよい)

「@nifty ホームページサービス」から提供される新機能

  • CGI 定期実行(LaCoocanライトを除く)
  • .htaccess(アクセス制限)
  • 独自ドメインの利用(ドメイン取得や維持は別料金)
  • カスタムエラーページ

LaCoocanスタンダード(プラス)にアップグレードすることで提供される新機能

  • sendmail
  • アクセスログ解析
  • 簡単インストーラー(WordPress などが導入可能、らしい)
  • データベース(MySQL、SQLite)

Perl(CGI)について

Perl 5 標準モジュールが一部欠けている

@homepage 時代と同じ。
ちなみに、perl 5.8.7(2021年3月時点)

ちなみに公式的には標準モジュールは提供しないとしているが、実際のところ、一部は利用可能。
しかしながら、例えば「DB_File」や「DateTime」モジュールが利用できない等、便利なモジュールが一部省かれている。
それに、今は使えているモジュールが今後使えなくなる可能性だってある。
なので、意味合いとしては標準モジュール提供は保証しないという形で捉えるのが妥当。

その影響により、ファイルアクセスだろうが、データアクセスだろうが、何をするにしても、原始的なレベルの作り込みが必要になる場合がある。

よって「@nifty ホームページサービス」における Perl は、かなり単純な機能のみを提供するようにしないと、開発・保守の両面からコストが発生することを念頭に置く必要あり。

自分の場合も、バックオフィスは別プロバイダで提供されている PHP と MySQL などで実装し、「@nifty ホームページサービス」はフロントエンドに徹し、Webコンテンツの稼働に必要なデータ類を、可能なかぎり構築してから転送している。

具体的には、バックオフィスにて tsv 形式のデータファイルなど、フロントエンド用のWebコンテンツ動作に必要なデータを構築・管理。
フロントエンド側では、バックエンド側からアップロードされたデータファイルなどを Perl を用いた CGI で動作させている程度に留めている。

ちなみに自分で必要な Perl モジュール(パッケージ・ライブラリなど)を設置することで「@nifty ホームページサービス」上で高度なWebコンテンツを構築することができる可能性はある。

ただ個人的には、今のご時世、小手先でゴチャゴチャ調整するのは時間がかかるし、ライブラリのアップデート時などの追従性やセキュリティ面も考えると不安。
もしそのようなコンテンツを実現したいのであれば、コスト面も踏まえると、もっと別の自由度の高いプロバイダーのサービスを使うと思う。

そもそも「@nifty ホームページサービス」が、いつまで CGI のサービス(というかホームページサービスそのもの)を提供してくれるかも不明。
(昨今ISPのホームページサービスは、契約者の利用率も右肩下がりなうえ、システムアップデートの追従やセキュリティなどの観点からコストに見合わず、提供終了されつつある。)

ここまで考えると、他のプロバイダーサービスを利用するほうが良いのではないかと。

use strict; use warnings; は役立たず。

とは言っても「外せ」という意味ではなく。

「@nifty ホームページサービス」は、(@homepage サービスの時代と同じく)ブラウザ上では全部500エラーが表示されるだけ。
また管理画面等からエラーログを確認するための手段もない。そのためエラーが発生しても、原因を掴むことは至難。

実際には、デバック文を挿入したり、変数を表示させるなどの手法で動作確認したり、ソース全体を、

eval {
  ...(CGIソース本体)...
};
if ($@) {
    print "Content-type: text/html\n\n";
    print "<title>error</title>\n";
    print "$@\n";
}

で囲い込んで、無理矢理エラーを表示させることも可能かもだが、正直微妙。

自分の場合はエラーを追跡するため「だけ」に、標準モジュールの存在しない開発・動作確認用のサーバを別途建てて、それから「@nifty ホームページサービス」にデプロイしています。

この環境を構築するのが一番面倒、という話もある。

【参考】使い道

これらサービスの制約下でも、当方では無駄なく使っている。
以下参考まで。

ちなみにいずれのコンテンツも、管理機能はWebプログラミングが可能な別サイトに構築。

期間限定の共有フォルダ

URLを知っていればアクセスできるようなファイルを置く場所。
期間超過のファイルは、「CGI定期実行」機能によって削除。

ただし前述の通りSSLが使えないため、盗聴されると可能性あり。そのため、そのリスクを負っても問題ないようなファイルしか扱えない。

画像アルバム

風景写真とか。素材写真とか。
こちらも当方(撮影・作成者)で権利関係の弊害がなさそうな画像を公開するために作った。

郵便番号⇒住所変換

文字通りのツール。
そもそも tsv 形式のデータの抽出速度がどれ位かかるのかを調べるため、実験的に作ったもの。
現実的な速度で提供できるように試行錯誤しながら提供中。

CSS と DOCTYPE の設定に悩まされた週末

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

いわゆる「ゆるゆるHTML」フォーマットです。
でも互換モードブラウザが表示する形になるため、ブラウザによって見栄えが大きく変わってしまう場合がある。

今後の Web デザインのブラウザ間の統一性を図るためにも、以下参考に変更する方向で。

基本は「Strict」タイプで。
ちなみに「Strict」とは「厳格な」という意味。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

おそらく、意味としては「HTML 4.01 で定義されているタグと属性以外は認めない」でよいかと思います。

そう考えると、HTML 4.01 以降に定義された新しいタグや、ブラウザで独自拡張されたタグは駄目だと思います。

例えば、Flash などのオブジェクトを動作させるための <embed> タグなどは、今となってははどのブラウザでも動くようになっていますが、HTML 4.01 定義では <object> タグを使う必要があります。

それ以外にも、HTML タグとして利用できない要素(タグ名)や属性(タグの続けて記述する付属の設定)があり、それらは CSS に記述するなどの対応が必要です。

あとフレームセットも使えません。詳しくは以下のページ参照。

ただし、この厳格に沿った場合、想定したレイアウトが実現できない場合もあります。

その場合は、適宜以下を使って緩めてく方向で。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

ちなみに XHTML の厳格宣言は以下。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

table レイアウトと div レイアウト

基本的には <div> とスタイルシートを用いて、コンテンツデザインが実現できるのであれば、そうすべきだと思います。
理由としては、以下。

  • <table> タグを使用すると、自ずと <tr> <td> タグを使用することになる。
    その点 <div> タグとスタイルシートの関係さえ効率的に定義すれば、タグの記述が減らすことが可能なため、HTMLファイルの中身がスッキリする。
  • スマートフォン用ページなど、レイアウトを変更したページを実現する事が比較的容易。

ただし <table> タグによるレイアウトを用いないと、上手く実現できないレイアウトもあります。例えば、

  1. メインブロック(枠線付き)は、常にウインドウ縦横両中央(ど真ん中)に表示。
  2. ウインドウ下部にフッタ。
  3. ウインドウの縦幅を縮めた場合、メインブロックとフッタが重ならない、レイアウトは崩されない。
    メインブロックとフッタがくっついたら、縦スクロールで逃げる。

この場合、諦めて <table> タグを使用するほかありません。

また、<div> タグとスタイルシートの関係さえ効率的に定義体系的に行わないと、タグは減らせません。

それに、iモードをはじめとする携帯向けページは、HTML 規格そのものが異なるため、<div> や <table> タグでは対応できない。
本当なら携帯でもスタイルだけを変更して表示させたいところだが、現時点では HTML ファイルそのものを別にするしかない。

  • tableレイアウトとdivレイアウト…どっちも地獄(マイコミジャーナル)(閉鎖)

まぁでも、将来を見据えて XHTML 化ぐらいは視野をいれておくとよいかも。
とはいえ、現状関係しているクライアントは HTML 世代の方々なので、本格的な XHTML ソースコード化は避け、XHTML 化する際に影響の少ないソースコードを書いていただく方向だけで。
そうする事により、将来のリニューアルも見据え、かつ現状デザインにおいても、体系的なコンテンツ制作がもできると思います。

Web コンテンツの動作確認

  • Internet Explorer 6.0
  • Internet Explorer リリース最新版
  • FireFox リリース最新版
  • Google Chrome リリース最新版
  • Safari リリース最新版
  • Opera リリース最新版

これらで動作確認をすれば、世の中で使用されているブラウザの90%以上で正常に表示されるはずです。
基本的に最新版ブラウザで表示されることを確認すればよいかと。

なお「Internet Explorer 6.0」(以下、IE6)については、主に企業ユーザが利用されているPCのブラウザとして標準的に使用しているなど、未だにシェアが高いため、例外的にIE6での確認もする必要があります。
おそらくxpのサポート完全終了となる2014年頃までは利用されるのかな、と。

ただし企業などを対象としないコンテンツを制作する場合は、正直意識しなくてもよいかと。
実際 Twitter の Web サイトをはじめとする幾つかの有名サイトが IE6 の配慮をあまりしない方向でコンテンツを提供してますし。
何よりも、IE6 のためにわざわざ CSS や HTML、レイアウトを考慮するのは、時間もかかるし、正直なところ馬鹿馬鹿しい。
いっそ IE6 用には、テキスト版コンテンツを提供するとかでも良いのかもしれない。。。