ＴＮＯ２:ＣＧＩのトラブル・ガイド

私自身が実際に経験した、 ＣＧＩ(Ｐｅｒｌ)作成の際のトラブルです。
今後も増えるでしょう。(^^)?polipoli

Ｐｅｒｌスクリプト（プログラム）を自分で書こうという人を、 読者として想定しています。 ＨＴＭＬやＪａｖａＳｃｒｉｐｔに付いては、ページ最下段のリンクで。
尚、サーバやブラウザによって仕様が異なる場合が有ります。
そろそろ、このページもＣＧＩとＳＳＩに分割かなぁ。 構成も変えてみたいし。
ＣＧＩが、ＴｉｋｉのＷｅｂサーバからＣＧＩ専用サーバへ移行しています。 従って、現状を意味する部分は、実際の現状と一致していない場合があります。

1. require

   Ｐｅｒｌの「require」文でライブラリ等を設定する場合、
   そのライブラリの最後に真値を返すための「1;」が必要です。
   参考書やオンライン・マニュアルにも載ってないので、 実例を調べるまで全く気が付きませんでした。
   

2. ｃｈａｒｓｅｔ

   文字コードの設定に「charset」を使用します。
   ＨＴＭＬではメタで、ＣＧＩでも最初の標準出力行に付加出来ます。 ＳＳＩ用のＣＧＩでは、設定しないと、 ＣＧＩ部分のみの文字コードが変ってしまうことがあります。
   ところがＣＧＩでページ全体を表示させ様とする場合、 ｢更新｣「再読み込み」させないと表示しなくなってしまいました。
   

3. Ｃｏｏｋｉｅ

   Ｃｏｏｋｉｅには、path設定があります。
   ＣＧＩプログラムは、専用ディレクトリに入れます。 そこでＣｏｏｋｉｅを設定すると、 path設定はＣＧＩプログラム専用ディレクトリになります。
   ところがＳＳＩを使用した場合、
   （例：<!--#exec cgi="cgi-bin/〜.cgi"-->）
   path設定は ＳＳＩを使用したＨＴＭＬファイルのパスに なってしまいます。
   お陰で、Ｃｏｏｋｉｅが見つからずに困ってしまいました。
   

4. Ｃｏｏｋｉｅ２

   Ｃｏｏｋｉｅには、有効期限があります。
   同じ名前で同じパスのＣｏｏｋｉｅを設定すると、 有効期限が後になるＣｏｏｋｉｅが残る様です。 でも、後から設定した期限の早いＣｏｏｋｉｅが、 一時的に見えることもある様です。
   対策は、有効期限を後になる様にすることです。
   

5. Ｃｏｏｋｉｅ３

   同じ名前でパスの違うＣｏｏｋｉｅを設定すると、 両方見えて区別出来ません。
   もちろん、許可されたパスに限られますが。
   

6. Ｐａｔｈ[Ａタグ]

   ＣＧＩで表示したページのリンクＰａｔｈが正常に動いていない。
   「<A HREF="../〜.html">」が
   「<A HREF="〜.html">」扱いされる。
   原因不明。取りあえず絶対Ｐａｔｈ。
   「<A HREF="./../〜.html">」かも？
   （ぶっきらぼうなのは、「原因不明」のため。）
   

7. 漢字コード

   Ｐｅｒｌプログラムをサーバ上で実行すると、 シフトＪＩＳの漢字コードが文字化けすることがあります。 「表示」の「表」等の様に、漢字コードの２バイト目が、 半角「￥」と同じコードになる場合です。 シングル・クォート「’」中では、起こらないですが。
   

   半角「￥」発見方法 ==>

   小道具:「漢字→％」変換

   本来はＥＵＣを使うべきですが、 その「表」等の文字の次に半角「￥」を入れて、 「表\示」等としておけば取りあえずＯＫです。
   半角「￥」が潰れるため、文字化けが起きます。 もう一個「￥」を加えておけば、 ２個で１個の「￥」の代わりになるので文字化けを抑制出来る訳です。
   

8. ｅａｃｈ

   Ｐｅｒｌのｅａｃｈ関数による検索を中断して、 同じ連想配列を次にｅａｃｈで検索すると、 前の検索の続きになってしまいます。
   オンライン・マニュアルにも載っていますが、 見落としていました。
   

9. 文字列変数

   Ｐｅｒｌで文字列を変数に入れてサブルーチンの引数にした場合、 いつのまにか空文字列になってしまっていることがあります。
   原因不明です。
   取りあえず、引数を「変数名.''」(<=ダブル・クォートじゃないぞ！)としてやればＯＫです。
   

10. ＨＴＭＬ名

    １つのＣＧＩが複数のＨＴＭＬから呼び出される場合、 ＨＴＭＬからＳＳＩでＣＧＩを呼び出した際に、 呼び出したＨＴＭＬの名称がほしいことがあります。
    「$ENV{'REQUEST_URI'}」で可能です。
    ただし、サーバやブラウザによって仕様が異なる場合があります。
    

11. Ｃｏｏｋｉｅ４

    ＣＧＩからの出力のヘッダで、Ｃｏｏｋｉｅを設定することが出来ます。 しかし、ＳＳＩで呼び足されるＣＧＩでは、 Ｃｏｏｋｉｅを設定することが出来ませんでした。
    取りあえず、 ＳＳＩで「<IMG SRC="〜/〜.cgi">」を出力し、 その<IMG>タグのＣＧＩでＣｏｏｋｉｅヘッダを出力すればＯＫです。
    尚、そのＣＧＩで出力する画像データが正しいものでないと、 ブラウザが再読み込みしようとするので、 Ｃｏｏｋｉｅを２回送ってしまいます。
    

12. ＣＧＩ用ディレクトリ（フォルダ）

    「user-cgi」などが、プロバイダに指定されます。
    セキュリティを考えてわざと違う名前にしておいたら、 いつの間にかＦＡＱページに変更が必要というメッセージが。
    大移動が必要になってしまいました。 しかも、古いディレクトリも、しばらくは残す必要がありました。
    

13. Ｐａｔｈ２[ＳＳＩ−ｉｎｃｌｕｄｅ]

    ＳＳＩのｉｎｃｌｕｄｅで指定しようとするＰａｔｈが、 うまく動いてくれませんでした。
    「<!--include file="../〜.txt"-->」のファイルが、 無いものとして扱われます。 「"./../〜.txt"」も駄目！
    取りあえず、 ＳＳＩを使ったディレクトリ内にもそのファイルをコピー して回避しました。
    ……と思っていましたが、 「<!--include virtual="../〜.txt"-->」の様です｡
    絶対ＵＲＬとは、「http://」から書けるという意味ではない様です。 「..」は無視されるかと思いましたが、違う様です。
    

14. ファイル名

    ファイル名の規則は、実行環境によって異なります。
    ＣＧＩ（Ｐｅｒｌ）プログラムをサーバにアップする前に、 当方のパソコン（Ｗｉｎｄｏｗｓ９５）上で 動作試験をしています。 が、この動作環境はＭＳ−ＤＯＳモードで、 ファイル名の規則もＭＳ−ＤＯＳになってしまいます。 ＵＮＩＸやＷｉｎｄｏｗｓ９５のつもりで長いファイル名を使うと、 ファイル名の後ろが切られてしまい、 ファイルが読めなかったりします。
    以前も同じ間違いをしたのですが、 つい忘れてしまい、 しばらく原因が判らず混乱してしまいました。 ＵＮＩＸのことも考えると、 ＣＧＩでアクセスするファイルは 半角英小文字で 「８文字以内＋拡張子３文字以内」に して置くのが良い様です。
    また、ＭＳ−ＤＯＳモードで作成したファイルのファイル名を、 Ｗｉｎｄｏｗｓ９５で表示すると 小文字表示されることがあります。 しかし、実際のファイル名は大文字になっていて、 ＵＮＩＸへ転送すると、 大文字と小文字を区別されて アクセス出来ない事態が発生します。
    

15. アクセス・カウンタ

    「<IMG>」タグでＣＧＩを呼び出して アクセス・カウンタをカウント・アップする場合、 カウントされないアクセスがある様です。
    ロボットや巡回ソフトからのアクセスで、 「<IMG>」タグを無視する様になっているためと思われます。
    対策は、ＳＳＩでＣＧＩを呼び出してカウント・アップする手でしょうか。 それとも、メタ・タグのリフレッシュを使い、 ページを丸ごと表示させるＣＧＩへジャンプして、 そこでカウントするしか無いでしょうか。
    ちなみにＴＮＯ_２ページでは、 「<IMG>」タグとＳＳＩを両方併用していました。 又、一時、ＳＳＩエミュレータでカウントしていました。
    

16. アクセス・カウンタ２

    ページ表示の度にアクセス・カウンタをカウント・アップすると、 連続したアクセスを多重にカウントしてしまいます。 が、それで良いという仕様にするのが最も簡単です。
    防止には、期日無しの保存されないクッキーを発行するか、 「$ENV{'REMOTE_ADDR'}」等と アクセスした日時をファイルに記録しておく手でしょう。
    ちなみにＴＮＯ_２ページでは、両方併用していました。 が、保存されないクッキーの設定でも、 数日前のクッキーを残しているケースもある様です。
    現在はＩＰアドレス毎の最終アクセスを記録して、 ３０分以内はカウントしないようにしています。
    

17. ｃｈｍｏｄ

    理解が間違っていた。 「オーナー」のみ書き込み可能の設定のファイルに、 ＣＧＩで書き込みが出来る。
    「オーナー」は、アクセスした人（アカウント）ではなく、 書き込んだプログラムのこと。
    ＦＴＰでは、ＣＧＩで書き込んだファイルは上書き／ｃｈｍｏｄ出来ず、 削除しか出来なくなります。 一旦削除した上で、新たに書込みし直しします。
    

18. ＳＳＩ停止

    1998/8/10の20時頃、プロバイダが突然ＳＳＩ機能をオフしてしまった。
    殆どのページでＳＳＩを使用している上に、 ＳＳＩ無しでは重要なページが表示されなくなってしまった。
    上記についてプロバイダに問い合わせて、 ＳＳＩは使用出来ないとのメール。 これに対応するには、 全ぺージの構成、仕様などを全面的に見直して修正する必要があるが、 時間が無い。 仕方が無いので、暫定でＳＳＩエミュレータを組み込んで対応。
    

19. ＳＳＩ停止-2

    プロバイダからの連絡無しに、 いつの間にかインクルードや更新日付の機能が復活していた。 要は、ｅｘｅｃを禁止したかった様だ。
    ＳＳＩエミュレータで対応していたが、 エミュレータ無しでも殆どのページは表示出来る様になった。 が、既にエミュレータ対応にページを変更しているので、 更に直すのは躊躇。 表示も出来ているし、 エミュレータ無しでは実現出来ない機能も付加している。 今後再び、インクルードや更新日付の機能が停止するかもしれないし。
    と思っていたら、停止してしまいました。 ＳＳＩエミュレータも停止して、対応におおわらわでした。
    

20. ＦＯＲＭ

    次の様にFORMタグのACTIONで直接パラメタを指定しようとしたら、 パラメタに「?」がくっ付いて「B=j?」となってしまった。
    <FORM ACTION="bbs_answer.cgi?B=j">
    当たり前ではあるが。
    

21. パラメタの受け渡し

    "〜.cgi/P=xxx"でパラメタ受け渡しをすると、 相対ＵＲＬがおかしくなる。 "yyy.cgi"を"〜.cgi/yyy.cgi"と解釈してしまう。 (ブラウザにもよるのかもしれないが。)
    "〜.cgi?P=xxx"ならＯＫ。
    

22. パターン・マッチ

    パソコン上のＰｅｒｌで、 「/[\200-\376]/」などの形でパターン・マッチをしようとした。 が、「[]」の中では､ シフトＪＩＳ漢字を１文字としてマッチしようとしている様な気がする。
    サーバでは確認していないが､ 動作確認のためにはパソコンで動かないと困る。 漢字変換は「%16進」の状態でするしかないか。
    

23. ２０００年問題

    インターネット上／ＣＧＩ上でも、２０００年問題が発生します。
    1998/9月現在、 ＴＮＯ_２の利用しているＣＧＩプロバイダのサーバでは、 Ｐｅｒｌのlocaltimeの年は２桁になっていました。 2000/1月現在、システムの年は100となっています。 が、いつ４桁化するか判ったものではありません。
    ということで、 1998年から、年が２桁でも４桁でも、 1900年からの差でも良いようにプログラムしてありました。 皆さんの対応はどうでしょう。
    一般的なシステムの、外部から送られて来るデータについても、 両方に対応出来るようにした方が良いですね。
    

24. ページ内参照

    ＣＧＩで表示した頁でも、次の様な「#」を付けたページ内参照が可能。
    http://ww3.tiki.ne.jp/~tno2/user-cgi/ssi.cgi?html=trouble@trouble2.htm#Yen
    なぜか出来ないと思い込んでいました。
    

25. ＊．ｐｓ

    ＳＳＩのｉｎｃｌｕｄｅ機能で、 拡張子「.ps」のファイルがｉｎｃｌｕｄｅ出来ない。
    拡張子を変えると可能。 原因不明だが、この拡張子に何らかの特殊用途があるのか？
    

26. ＣＧＩの移行

    プロバイダが、ＣＧＩ実行環境を外部の別のプロバイダへ委託。 ＣＧＩを新しいサーバへ移行しなければならないが、 移行先のＣＧＩの殆どの実行で、原因不明のエラー。
    ＦＴＰで、複数のＣＧＩファイルをまとめて転送すると、 その実行時にエラーになる模様。 個別転送でも、なることがある様だか。 再度転送し直すと、何事も無かったかの様に、正常動作。
    ASCIIとBinaryの転送モードが、拡張子によって自動設定されていなかった模様。
    

27. 容量

    ＣＧＩ移行先で、容量オーバーになった。
    移行元では１０ＭＢだったため問題が無かったが、 移行先は１ＭＢ。 普通なら十分の容量で、 ファイル・サイズの合計なら十分に制限内。
    しかし、 問題発行の小さいファイルが３００×２ぐらいあり、 移行の暫定処置で更に＋３００。 ファイル記録が１ＫＢぐらい(cluster)単位で行われているため、 それら合計で既に約９００ＫＢ。 ＣＧＩ自体のファイルを加えれば、……
    取りあえず、暫定の＋３００を削除して移行処置を完了し、 その後ゆっくりと対策を取りました。
    

28. パターン・マッチング

    新しいＣＧＩサーバ環境のパターン・マッチングで、「＠」が使えない。
    旧環境で動いていた次のパターンが、新環境で動かない。
    /\e(%24[@B]|%28[BJI])/
    仕方が無いので、次の様に変更。
    /\e(%24[\@B]|%28[BJI])/」
    原因は、Ｐｅｒｌ４からＰｅｒｌ５への移行でした。
    

29. ＳＳＩ機能も停止

    ＣＧＩの旧サーバ停止に伴い、 「ｅｘｅｃ」以外のＳＳＩ機能も停止した様です。
    これまでのプロバイダの対応状況から見て、 復活するのか、しないのか、 判断がつかない。
    

30. ＠

    半角「＠」が半角「”」で囲った文字列中などでも、使えない。
    半角「’」で囲った文字列中や半角「￥＠」なら、ＯＫ。
    

31. ＣＧＩ環境の移行１

    ＣＧＩ作成環境をWindowsのまま、 インターネット接続環境をWindowsからLinuxへ移行した所、 FTPで転送したＣＧＩプログラムが動作しなくなってしまいました。 結論から言うと、 ＣＧＩの改行コードが、Windows形式(CR+LF)では駄目で、 UNIX形式(LF)でないと動作しないためでした。 拡張子「.pl」のライブラリは、Windows形式でも大丈夫だったため、 気付くのが遅れました。
    Windows環境からのＦＴＰ転送では 改行コードを変換する様に設定していました。 そのファイルをそのままLinuxへ送って、 そこから改行コードを変換せずにＦＴＰ転送したためでした。
    対策は、Linux下でnkfコマンドで変換し、 その後の修正はeMacsで行うことにしました。
    

32. ＣＧＩ環境の移行２

    ＣＧＩで読込ませるファイルをWindowsで作成する必要があり、 前述と同様、そのままLinuxからＦＴＰ転送していました。 当然、改行コードが異なり、ＣＧＩの動作に支障が出ました。
    このファイルはLinuxでは作成出ず、一々変換するのも大変なので、 どちらの改行コードでも対応出来る様にしました。 具体的には、各行の終わりのLFを削除していた所を、 LF削除の後でCRも削除するようにしました。
    

質問・ご意見等、お待ちしております。 質問については、判る範囲で出来るだけ答えて行きたいと思います。