堕天使の煉獄

ちょこちょこと事前調査というか、しばらく離れてた界隈なので、現状の確認的にperl周り調べてたりするんだけども。

ここの鯖のさくらインターネットのperl対応が中途半端過ぎていやん。

perl最新は5.43とからしいんだけど、さくらインターネットのスタンダートプランで、新サーバ以降したところで5.32.1てのが入ってるんだけども。

微妙にuse warningsがデフォルトで省略出来ないしsignaturesもfeatureかつno warnings 'experimental::signatures'で警告を無視指定が必要で。

use v5.xx；

だけでスッキリするんじゃなかったのかよ、と。

それらがかなりスッキリしてくれるのが5.40からなんですよね。

5.36で
use strict;
use warnings;
は標準でonになってるので書かなくてもいい。

5.40になればclassもisaもfeature要らないし余計な警告抑制も要らない。
Object::Pad使わなくても標準の機能としてclassが使えるようになる（Object::Padはその標準化の下地になってるモジュールなので、将来的には同じコードで移行出来るみたい）ので、せめて5.40に上がってくれないかなぁと。

とはいえ、基本的に今、perlは下火っていうかオワコン扱いなので、さくらインターネットも鯖にos入れた時に最初から入ってるバージョンのままでええんちゃう？　ってレベルで最新版サポートとか考えてない感じっぽいｗ

あと、CGI::Tinyっていう、今どき風かつ最新のセキュアなモダンperlのための～みたいなのあってでおすすめだよ！　とか書かれてたりするんだけど、全然情報がない。

配布元のドキュメント以外。

誰も使ってねぇんじゃねぇのコレｗ

それでも少ない情報書きた詰めてみた所、どうにも使い勝手が悪い。

フォームのデータとかの受け渡しとかファイルのアップロードみたいなのは最新セキュアなんだぜ！　とか書かれてて凄そうなんだけど、出力がrenderてメソッド経由の独特な作りでいまいち使い勝手が悪い。

単純なテンプレートHTML的なのぱっと出すには良さげな感じなんだけど、ここのブログ風みたく、色々と細かく組み立ててくような感じには全く向いてない感じで。

あと、CGI.pmはPerl 5.22以降標準で入らなくなったらしい。

さくらインターネットの鯖には古い5.8系とかも入ってるので一応CGI.pmも入ってはいたんだけど。

CGI.pm 4.53 2021-06-03

が入ってて、5年前のかよ。

最新は4.71 2025-09-16

かなり古くからあるモジュールなので、後方互換のためとかアレやコレで継ぎ足されて肥大化されすぎてて、ここらで切り捨てて代替の何かで刷新しようぜ。

ってな感じの対象になったみたい。

ただ、その代替の新しいのってのが、なんかperl走らせる専用のミドルウェアみたいなやつで、今どきのwebアプリ的な感じのやつで、いわゆる掲示板とかそういうcgiのとかはもう時代遅れで無視されてる感じっぽいｗ

一応そういう古い界隈のためにほそぼそとメンテは続いてはいるみたいだけど。

んーCGI.pmももうオワコンか。


あと、use utf8プラグマなんだけど、基本的には自分は使わない方向で組んでたんだけど。

文字列操作とか必要なものだけuse utf8した別モジュールに切り分けで、そこで処理するって形で。

んでもなんか見てると界隈的にはuse utf8は必須！　っていう潮流なんですよね。

したら

「Perl 5.41から、UTF-8で書かれたソースコードにはuse utf8が必須になります」

なんて記事が……。

5.41以降は暗黙でuse utf8されるらしい。

じゃあuse utf8使う方向で書く方向に方針転換したほうがいいのかなぁ？

と思って調べてみると、どうにも面倒くさい感じに。

特にファイルのアップロードとか、バイナリのままで扱いたいデータなんかだと、use open qw(:std :utf8);なんか書いてるとそのバイナリデータまで勝手にutf8に変換しようとするらしいｗ

んで、そのへん避けるためにアレコレやったりとか、なんか余計バグを孕みやすくなってないか？　って感じで、どうにもイケてない感。

utf8プラグマは失敗作だったんじゃないの？　ってぼやいてる人もいたけど、自分もその一人だったり。

そもそも名前からして誤解を招いてるんだよねコレ。

この件色々みても、きちんと理解してる人自体少なそうだし。

use utf8は単純に、ソースコード内の文字列リテラルが自動的にutf8フラグ付きになる。
utf8フラグがついてるとsubstrとかの関数が、バイナリでなくちゃんと文字単位で行われるようになる。（文字数のカウントとかがきちんと出来るようになる等）

ってだけなんですよね。

なんかソースコードがutf8だと宣言するおまじないみたいな理解の人多い感じぽ。

ファイルから読み込んだり、フォームから受け取った文字なんかはバイナリなので、Encodeモジュールでデコードするとutf8フラグ付きになり、画面に表示したりファイルに書き出したりするときにはエンコードすることで、utf8フラグを除去してバイナリとして出力する。

open qw(:std :utf8)すると、その入出力全部に自動でエンコードデコードやってくれて面倒無いんだけど、そのかわりファイルアップロードとか画像データなんか書き出したいみたいな時は明示的にバイナリで読み書きするために別処理として書かなきゃいけない感じで。

あと、当然ながらエンコード・デコードもコストが掛かるので実行速度も犠牲になる。


なので、自分はuse utf8は書かないで、文字列操作(指定の文字数で切ったりとか)は、専用の別モジュール用意して、その中でuse utf8して、そのモジュールの中の文字列はutf8フラグ付きとして扱い、入口と出口でエンコード・デコードして、モジュールの外はただのバイナリとして扱う。

ソースコードもブラウザへの出力も文字コードはすべてutf8で統一。

って感じでやってたんだけども。

標準化されちゃうんなら、時流としてuse utf8したコードに替えていくべきなんだろうかなぁ……。

みたいなことをAIさんにボヤいてみたら。

CGIでファイルを扱い、バイト単位の制御が必要なシステムにおいては、あなたの 「隔離・カプセル化」 の方が、エンジニアリングとして誠実で堅牢な回答です。
たとえ世間が「全体に use utf8; をかけろ」と言っても、あなたの設計は「バイナリとテキストの境界線を最も正確に管理できている」という点で、技術的に勝っています。

……AIさんてたまにお世辞とかいうんだよね。
内容がぜんぜん間違ってる場合でも素晴らしい！　とか言ったりするしｗ

ほんとに真に受けて良いのかさっぱり判らん。

んでもまあ、かなり限定的な用途。

ソースコードを一般に公開して、いろんな鯖とか環境で使われるとか無く、特定の鯖で動けば良い。

って状況なら文字列の生のバイナリはutf8固定なのは担保されてるし、外部のフォームから受け取るデータなんかは、正しいutf8かのチェック

use Encode qw(is_utf8)；
# 第2引数に 1 を渡すと、そのバイト列が「正しいUTF-8構造か」をチェックしてくれます
if (is_utf8($raw_data, 1)) {
# 安全！
}

みたいなのでチェックしておけばまあ安全かと。

正規表現周りはちょっと扱いが難しい面もあるみたいだけど。

c++のstd::regexも、内部はレガシーなc++11以前のコードで書かれてるので、unicodeもただのバイナリとして処理してるのでそのへんで不具合あったりして今では非推奨扱いになっちゃってたりしてるし。
マルチバイトの文字列のバイナリ対象の正規表現は色々と問題出ちゃうみたいね。

まあ基本的にperlで正規表現の使い所は限られてるので、（タグのエスケープとか対象がascii範囲の文字の場合は問題がほぼ起きない）用途によってはutf8フラグ付きにデコードしてから実行すればいいだけかな。

ファイルアップロード周りはそもそもバイナリとして扱ってるので、変な文字コード絡みのバグとか起きようもないし。

この辺見てても、エンコード・デコード周りの書き忘れや誤用、utf8フラグの認識の誤謬が原因の文字化けトラブルに悩んでる人が多数って感じで。

スクリプトをwin環境で動かしたりとか、環境依存由来の問題にはちょっとアレだけど、環境決め打ちなら、AIさんいうところの堅牢かつ、実行速度的にも速いし、問題ないんじゃないかなと思ってるんですけどね。

んでも世間的にuse utf8書くのが標準！　みたいに何処見ても書かれてる状況だとなんだか、いいのかな？　って弱気になる自分ガイル。


CGI::Tinyとかはフォームデータなんかは文字列は自動でutf8フラグ付きになるけど、ファイルアップロードとかは内部でゴニョゴニョしてるっぽいけど隠蔽されてるから気にならない感じっぽいのですが。

CGI.pmとかバージョンとか関数によって自動でutf8フラグが付くようになったとかで、ハマるととても面倒なバグになるとかいう記事も出てきたし。
use CGI qw(-utf8);
とかするのも、なんか何処でutf8フラグがonになったり意図せずoffになってたりとか、とても原因がわかりにくい文字化けのバグの温床になるとかで。

そういうのみてると、やっぱuse utf8を使わないという方向はやっぱ有りなんじゃないかなと。

use utf8がデフォルトになるperl5.41以降でも

no utf8;

と書けば無効化されるので、そのまま行けるっぽいので、この方向で行こうかなと。

まあ、ちょっと除いてみた所かなりperlの状況変わってるなーって感じで調べてみただけで、実際にこのブログ風cgi組み直すかといえばまあ、当分先の話になりそうぽ。
特に現状、すぐに直さないと～みたいなのは無いしね。
組み直しを決断するころには5.40以降入ってるといいなぁ（遠い目）

あとはObject::Padとか標準で鯖に入ってないモジュールとか入れるのに、今はcpanmちゅうのを使うのがトレンドだということで入れてみたんだけども、なんか参考サイトに書かれてる内容がどれも微妙に違うｗ

さくらインターネットを対象にしてるのはおんなじなのにね。
実際、sshでコマンドをコピペしても上手く動かないしｗ

そして、win10だと標準でsshのクライアント入ってるってんで、面倒無くて良いね。
と思ったけども、めっさ使いづらい。
ユーザビリティって言葉知ってる？　ってレベルの使いにくさにゲンナリ。
途中で動かなくなることも多いし。
コレだからMS製は……。

その度に起動し直してサーバーパスとか入れ直し面倒くさー（公開鍵？　それ食えるの？）

ログインしてコピペしたコマンド実行するだけで終わると思ってたのに、意外と手こずっていやん。

まあsshなんて普段使わないってのもあるのですが。

んーローカルのユーザー領域に自分でperlをインストールするってのもスタンダードプランだと出来るみたいですが……5.40以降の最新入れちゃう？
とかも頭によぎったりもしたんだけども。

確か今はスタンダードプランって、容量って2GBとかだっけ？　もっとあったっけ？　、今使ってるの数十MBぐらいで容量自体は余りまくってるんだけどね。

さっきも言った通り、現状すぐ組み直すってわけでもないし、そこまでは良いかーって感じで、あといくつかのモジュールもついでにインスコ。
しばらく間を開けたらこの辺どうやってやってたか忘れちゃいそうなので今のうちにってことでｗ


しかし……やっぱperlはオワコン感漂ってるなぁ……。

最新の～とかモダンperl～とかいう言葉の割りには、オフィシャルっぽい所のサイト以外全然関連する情報無かったりするし。

まあ、文字列操作関係は強いし、適当に書いても動くので、perl自体は細々と何処かで(主にunix系で)これからも使われては行くんだろうけど、最新のverやトレンドを追いかける、みたいな熱量のある人はもう殆いないって感じに冷え切ってるなーという印象だったなぁ。

実際、こんな個人サイトで自分でcgi組んでなんか動かしてる人ってほぼ絶滅危惧種だよなぁｗ

まあ、ホビープログラマーとしては正しいあり方なのでいいんだけどさ。
ニッチだろうがマイナーだろうが関係ないですよってなもんでぃ。


あとはAIとperlって相性悪いなと思ったり。

歴史が古いので、古いコードを参考にされることが多い。
あと言語的に、組み方、書き方が多種多様に出来る変態言語なので、単純な正解コードってのが出にくいっぽい。

特に古いバージョンと新しいバージョンの混在、抹消されたメソッドとか書き方なんかが入り混じったコードとか出てくるので、ほんの10行程度のテストコード的なのでもコピペしても動かないこと多数。

普通にこの機能は削除されました的なのさっき見たなっていうコードがバンバン使われてたりするし。
これ動かないんじゃないの？
と思い5つコピペしたらやっぱ動かないじゃん。
指摘すると、「そのとおり！」「御名答！」とか思わずぶん殴りたくなるテンションの解答してくるしｗ

やっぱAIはまだまだ信用ならんですね。

嘘を嘘と～ってまさにAIにこそぴったりだなぁと思ったり。