ローカル環境のXamppをバージョン8.0.3に更新した。同梱されているPHPのバージョンも8.0.3。
ここで公開しているPHPプログラムではget_magic_quotes_gpcを使っているものがエラーが出て実行できなくなった。
代替の関数などはないが、新しいPHPでは必要ない関数なので、これを使った処理はすべて削除することにする。

imagecreatetruecolor関数もエラーが出て実行できない。
GDモジュールがデフォルトで読み込まれていないのが原因らしい。

phpinfo();

で調べてみると、確かにGDモジュールがなくなっている。
php.iniファイルで

;extension=gd

とコメントアウトされていたので、

extension=gd

に変更したらエラーは出なくなった。GDモジュールも読み込まれるようになった。

配列に{}を使っていたらcurly braces is no longer supportedとでて実行できなくなった。
配列は普通[]を使うが、{}を間違って使っていた部分もこれまでは配列と認められていたようだ。

---

Xamppに同梱されているPerlはバージョンが古いので、ActivePerlの最新版に入れ替えていたが、ActivePerlよりさらに新しいバージョンが公開されているStrawberryPerlに入れ替えてみた。(現在ActivePerlの最新版は5.28だが、StrawberryPerlでは5.32が出ている。)

http://strawberryperl.com/から最新版のstrawberry-perl-5.32.0.1-64bit.msiをダウンロードする。インストール先を指定できるので、今まで使っていたC:\xampp\perlにインストールしてみたが、なんかうまくいかない(c:\usr\local\bin\perlがperl.exeのパスになるためには、C:\xampp\perlではなくC:\xamppにインストールすべきだったような感じ)。
結局C:\xampp\perlは元に戻して、デフォルトのインストール先C:\Strawberryにインストールすることにした。

いまさらだが、XamppのPerlをバージョン5.28にアップデートすると、いくつかエラーが発生するようになった。エラーログを見ると

Can't locate init.cgi in @INC (@INC contains: ./lib C:/usr/local/site/lib C:/usr/local/lib)

というようなエラーがあちこちで発生している。init.cgiが@INCの中に見つからないというエラーで、カレントディレクトリにあるモジュールの読込で発生している。確かに@INC contains ではカレントディレクトリは含まれていないようだ。
セキュリティの関係でバージョン5.26から@INCにカレントディレクトリが含まれないようになったらしい。
とりあえず動くようにするには

require 'init.cgi';

というような行でエラーが発生しているなら

require './init.cgi';

に変更して明示的にカレントディレクトリであることを表記して読み込むか、スクリプトの最初の方で@INCにカレントディレクトリを追加しておけばいいようだ。
＠INCにカレントディレクトリを追加する方法としては

push(@INC,'.');

あるいは

use lib '.';

などがある。pushだと@INCの最後に、use lib だと先頭に'.'が追加される。
推奨されているのは

use FindBin;
use lib $FindBin::Bin;

これはFindBinモジュールを読み込んで、それによって利用できるようになるパッケージ変数$FindBin::Bin(実行スクリプトのあるディレクトリパス)を@INCに追加することになる。
これだと@INCの先頭に'C:/xampp/htdocs/local/test' のようなパスが追加されることになる。

Kent-Webのサポート掲示板で教えてもらったjQueryのslidelockというスパム対策機能を、この用語集作成PHPのbbsプラグインで使えるようにしてみました。→PHP/用語集作成

いつのまにかXamppの64bit版がでていた。というか64bitに変更されたのかな。
同梱のPHPも64bitになっているようで、これで2038年問題も解消されたようだ。(PHPの時間ログについて参照)　32bit版ではエラーになっていた

$epoc_sec =  2147483648;
echo date("Y/m/d H:i:s",$epoc_sec);

も問題なく実行できる。
これはローカルだけの問題でWEBサーバーの方はとっくに64bitになっていたのかもしれない。ここのサーバーのPHPも64bitになっているようだ。

ローカルPCにインストールしているXamppをアップデートしてPHPのバージョンがPHP7.2.5になったらあちこちで警告が出るようになりました。

create_function()は非推奨

まず、create_function関数が非推奨になったためにその警告が出ます。
create_functionを使わず、ネイティブの無名関数を使ったほうがいいということです。具体的には

create_function( '$a,$b', 'return strlen( $b ) - strlen( $a );' )

は

function($a,$b) { return strlen( $b ) - strlen( $a ); }

に変えます。

each()も非推奨

このほかeach()関数も非推奨になっています。mpdfモジュールで

while(list($file,$info)=each($this->images)) {

という部分で警告が出ているので、

foreach ($this->images as $file=>$info) {

と変更すると警告は出なくなりました。

非配列に要素を追加すると警告

mpdfモジュール関係ではcssmgr.pdfで

if (!isset($attr['ID'])) { $attr['ID']=''; }

のような行でも警告が出るようになりました。
$attr['ID']がsetされてなかったら、''を代入するという処理です。$attrが未定義の場合も問題ないはずでなぜエラーになるかわかりませんでしたが、調べてみると$attrの型がstringになっている場合もあって、その状態で実行するとエラーになっているようです。エラーを回避するためにとりあえず上記の式の前に

if (isset($attr) && !is_array($attr)) { $attr = array(); }

を追加するとなんとかエラーが出なくなりました。

文字列の計算をすると警告

$tm1 = microtime();
$tm2 = microtime();
echo $tm1 - $tm2;

を実行すると警告が出るようになりました。microtime()は、現在の Unix タイムスタンプをマイクロ秒単位で返す関数ですが、デフォルトではfloatではなく、
'0.84479900 1527156353'
のような文字列を返しています。PHP7.1ではこの文字列のまま計算しても適当にfloatに変換してくれていましたが、7.2では警告が出るようになりました。microtime(True)を指定するとfloatを返しますが、小数点以下の桁数が減るので、文字列のままにした方がより精度の高いマイクロ秒が得られます。文字列は小数部分と整数部分をスペースで区切っているので、小数部分だけを抽出するために

list($tm1) = explode(' ',microtime());
list($tm2) = explode(' ',microtime());
echo $tm1 - $tm2;

のように変更すると警告は出なくなりました。

配列の追加

キーが数値の配列に追加する場合は

array_push('abc')

とするより

$array[] = 'abc';

の方が速いらしいということで、もっぱら下を使っていますが、追加する変数の型が配列になっていないとエラーが出るようになりました。たとえば

$array = '';
$array[] = 'abc';

はエラーになるので、$arrayの型がarray以外になっている可能性がある場合は、

unset($array)

あるいは

$array = array();

と初期化しておく必要があります。これは[]を使って配列を追加する場合だけでなく、配列型になっていない変数を配列として扱おうとすると、同じようなことが起こると思われます。

バージョン7.2では、型について厳格になったようです。別の型ということになっているのにその型ではできない処理をしようとしたら、前のバージョンではその処理が行える型に変更したりする部分もあったが7.2以降ではエラーや警告を出すということになっているようです。

時間単位での細かい予定を書き込み、グラフ表示する予定表です。バグなどありましたら、CGIサポート掲示板までお願いします。

• サンプル
• schedule_1.22.zip (243Download)

スパム投稿対策を追加しました。(2018/01/25)
誰でも入力・閲覧できるが、編集・削除は入力者のみというモードを追加しました。(2017/03/29)

Clip Board改造版のサンプルとして設置している掲示板に、また新しいタイプのスパムが来ているようだ。こちらも調査したい。
まだ投稿キーも搭載されていない頃のバージョンをベースに改造したものだったが、改造版投稿キーに入れ替えていたので、そこそこスパムはブロックできていたようだ。オリジナルのClipboardの最新版に更新した上で、URLを引き継ぐためにディレクトリ名とcgiのファイル名は以前のclip/clip.cgiに戻した。改造版の方もとりあえずディレクトリ名を変更して残しておくことにする。

掲示板(YY-BOARD)と同様に、ひらがなチェック、投稿IDチェック、ダミーフィールド処理を追加し、どの処理が有効かログを残すことにする。

• 研究用掲示板2(Clipboard)
• 拒否したログ一覧
• アクセスの解析

掲示板2の方はアクセスが少ないが、投稿IDを送ってこないというタイプのスパムがいるようだ。これは初めてのケースだ。投稿キーはクリアし、スタイル指定で隠したダミーフォールドの値は送ってきているのに、hiddenを指定したinputタグに気づかないのも不思議だが、単純にオリジナル掲示板CGIで送られるはずの値を送っているだけかもしれない。
いずれにしても、新しいタイプではなく、むしろ古いタイプのスパムのようだ。投稿IDを送ってこないので、時間を計測する必要も無く、その時点で拒否するだけで済むので対策は簡単だ。
と思っていたら、掲示板の設定ミスで投稿IDがフォームにセットされていなかったことが判明^^;
ひらがなチェックや投稿キー、ダミーフィールドにも引っかからず、投稿IDだけで拒否していたスパムもあるようなので、気になる。ダミーフィールドに引っかからないということは、HTMLを見ていないという可能性も残っているが。

それと、フォームにアクセスせず、いきなり投稿してくるタイプがあることも拒否ログを見てわかった。

こちらの掲示板はスパム投稿の頻度は低いが、たまに来るものの中に投稿ID、ダミーフィールドどちらも突破してくるスパムがある。やはりJavaScriptを使わざるを得ないか。

• スパム対策研究用掲示板
• 拒否したログ一覧
• アクセスの解析 2026-03-03 12:17:38更新

リンク元　ユーザーエージェント

スパム投稿の動向を分析するためで環境変数でリンク元やユーザーエージェントをログに残してみたが、こうした情報もスパムかどうか判定するヒントになるかもしれない。
リンク元はPerlの場合、環境変数$ENV{'HTTP_REFERER'}で得られる。たとえばこのページのリンクから掲示板にアクセスしたら

http://shade-search.com/sts/term/term.php

がHTTP_REFERERになる。いったん掲示板を開いて掲示板の他のページから移動した場合は掲示板CGIのURL　たとえば

http://shade-search.com/sts/fsw/yybbs/yybbs.cgi?type=2

のようなものになるはずだ。