Lightweight Languageの最近のブログ記事

zipファイルは、lang_perl_MENTA_tags_release-0.05-r24525.zipになっていました。

ぱっと見では、リンクの仕方が変わったような？
…と思ったのですが。
今のところ、変わったのはオフィシャルだけのようです。

cgi-serverで起動したところ、どちらも同じ挙動でした。

しかし、結構warningが出ているようです。
コマンドプロンプトが文字化けしていたので、一旦ctrl+cで止めて、コマンドプロンプトの文字コードの変更を参考にして「chcp 65001」とタイプして、utf-8を表示できるようにしました。

うちの環境では、コマンドプロンプトを「MS ゴシック」に設定したあとは、コマンドプロンプトを立ち上げて、すぐに「chcp 65001」とすると「MS ゴシック」のまま切り替わるようです。

レジストリの「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont」のあたりを色々といじって試してみましたが、うまくいかず、断念。

ま、それはそれとして。
エラーの正体は以下のとおり。

static/menta-logo.png/ を処理する方法がわかりません at lib/MENTA.pm line 96, <DATA> line 16.

ということで、app/tmpl/header.mtの6行目にゴミ（後ろにスラッシュの文字）が入っていたようです。
以下のように直したら上記のエラーはなくなりました。

<img src="<?= static_file_path('menta-logo.png') ?>" alt="Web Application Framework - MENTA" title="Web Application Framework - MENTA" />

MTでつけたタグを管理するのにも丁度良いので、HatenaBookmarkerプラグインを使って、ブログ記事をはてなブックマークに登録しているのだが、最近、余計な仕事もしてくれているようだ。

トラックバックを受け取ったときに、その記事をブックマークしにいくのだ。
しかも、なぜかパーマリンクが間違って（ファイル名が日付と時間になって）いる。

解決できないかとソースを見ているのだが、さっぱりわからない。
トラックバックを受け取ったときに動作しないようにできればまったく問題ないとは思うのだが…。

お手上げ。

Perlでもなんでも、ソースをブログに載せるときは気をつけたいもの。

ファイルを見ると、2年前から使っている自分用のツールがある。
「<」や「>」など、HTMLでそのまま表示できないものを実体参照に変更したり、preとcodeで括ってソースとして表示しやすくするためのものだ。

少し前に、perltidyを覚えたのだが、ブランクがあいていたのと、パソコンを変えていたので、改めてインストールすることにした。
自分の記事も役に立つものです。
ただ、以前と違っていたのは、perlと同じbinフォルダではなく、site/binのほうに入っていた。

で、ソースがきれいにハイライトされているページをちらほら見かけたので、色気づいて調べてみた。
とりあえず簡単にできそうだったのが、「Quick Highlighter」というサイト。

というわけで。
euc2utf8.plをperltidyで整形して、Quick Highlighterでハイライトさせてみた。

…しかし、スタイルシートが競合するのか、ブログ上で見るといまいちかなぁ…。
もう少し調べてみよう。

久しぶりに知的活動（？）をしていたら、面白そうなものを見つけた。

MENTA は CGI で気軽につかえるウェブアプリケーションフレームワークです

• CGI でも高速に動作
• レンタルサーバーでもつかえます(ロリポとかXREAとか)
• Object 指向がわからなくてもつかえます
• 正しいプログラミングスタイルが自然と身につきます

数日間追いかけていたのだが、今日、zipファイルでダウンロードできるようになっていたので、早速ダウンロードしてWindows上で使ってみた。
使ってみた、というか、デモをそのまま動かしてみた、というか。

まあ、久しぶりにPerlな気分の時に見つけたので、しばらく追いかけてみようかと。
XREAでも使えそうなので損はなさそうです。

スクリプトのutf8化計画に役立つであろうコードを書いた。
スクリプトのあるディレクトリ以下のファイルを走査して、ファイルの文字コードをeuc-jpからutf8に変換するスクリプトだ。

それにしても、作るのに妙に時間がかかった。
徐々に勘を取り戻せればいいのだけど…。

で、色々と調べながら書いていたら、面白いモジュールを色々と見つけた。

Fatal が、渡されたサブルーチン（上の例だと open と close） をくるんで、自動で or die してくれます。open や close がだいぶすっきりしました。あとついでに先ほどの例に対してファイルハンドルを変数にしたり open を3引数にと今風に変更してみてあります。

まずはFatal。使いどころは結構あると思う。
ついでに、今までファイルを扱うときは、FileHandleを使っていたのだが、「今風」にしてみた。

File::Findの使いやすいインターフェィス

次はFile::Find::Rule。標準モジュールではないのが残念だけど。
File::Findをうまく使えればいいんだけど、いまいち使い方がよくわからない。
ファイル一覧を作って、それを順番に処理する、という感覚なので、File::Findの&wantedの考え方がいまいちしっくりこない。

perl5.8 では文字コード自動判別も用意されており，Encode::Guess がそれです．

あとは、Encode関係で、Encode::Guess。文字コードの推測です。
guess_encodingという関数が自動的にインポートされるようです。
それ以外に、Encode::Guess->guessとする方法もあるようですが、メンテナーは404 Blog Not Found:ruby|perl - 文字コードのちょっと高度な判定でguess_encodingを使っていました。

Encodeは、安定性重視から速度重視まで、色々なメソッドが用意されているようなので、404 Blog Not Found:perl tips - Encodeを速く使う方法も参考にしようと思っています。

ずっとPerlEditorを使っていたが、これからの開発はUTF-8に対応していく必要があるので、新たなエディタ探しをした。

以前から思うが、Perlで開発をする人というのは、環境にこだわらないというか、あまり特殊な環境を必要しないというか。
そんなイメージがあった。

でも、それは、私があまり環境探しをしていなかったから、ということに気づかされた。
まあ、それほどPerlEditorで十分満足していた、ということです。

で、そんなわけにもいかなくなり、探してみると、環境を探している人はいるものですね。
3年前の記事に探すものがありました。

perl ハッカーの方々にお聞きします。近頃ますます良い感じなperlですが、どのような開発環境で開発していますでしょうか。(エディタ、そのほか)

というか、皆さんこのころからutf8を視野に入れていたんですね…。

というか、こういうのがモジュールにあるのを知らなかった。

#!/usr/bin/perl
use strict;
use warnings;
use POSIX;
 
my @vars = (1, 0.999, 0.9, 0.1, -0.1, -0.9, -0.999, -1);
 
foreach my $var (@vars) {
    print "Target is $var\n";
    print "ceil  : ", ceil($var), "\n";
    print "floor : ", floor($var), "\n";
    print "int   : ", int $var, "\n";
}

use POSIX;

とすることで、ceilとfloorが使えるようになる。
便利だね。

何年も前から使っている自分フレームワーク（というか自分モジュール集？）があるのだが。
スクリプトの漢字コードが「euc-jp」前提で書いてあるので、それに愕然としている。
…まあ、自分がやってきたことだけど。

Perl5.8になってEncodeが標準で搭載されるようになってからも過去の遺産を使っていたわけですが。
ウェブまわりがどんどんUTF-8標準になっていくにしたがって、色々と限界を感じてきた。
「Perl 5.8.x Unicode関連」とか見ながらやってきましたが、そろそろ限界です。

MT3時代のブログで文字コードまわりがうまくいかなかった事もあるし、最近ぶち当たった「MySQLで文字化けする」問題もある。

もうね。
スクリプトも基本は「utf8」ですってよ。
MTも生成するHTMLは「utf8」がデフォルトだし。
MySQLもバージョン5（？）から「utf8」が基本みたいだし。

Encodeには他にもうんざりするほどいろいろな機能がありますが、上記の基本で日常業務の9割5分はカヴァーされているかと思います。「decodeしていじってencode」、この基本をお忘れなく。

まとめだけを引用しましたが、この「上記の基本」はすべて「use utf8」です。

基本からやり直し。

しばらく前から認識はしていたのだけど、サーバの仕様ということで放ってある問題がある。

携帯向けにShift_JISに変換して出力する、EUC-JPで書かれたスクリプトがあるのだが、それでMySQL5.1.11と今までのようにDBIを通じて書き込みを行うと、文字化けする、という問題だ。
しかし、CGI::Sessionを通じて同じデータベースの別テーブルに書き込んでいるほうは文字化けしないのだ。

漢字コードを指定するためには「SET NAMES ujis」というSQLを入れるといいらしいので、それをやってみたら、そこはうまくいった。

しかし、今度はもともと文字化けしていなかったほうが文字化けする。
データベースハンドルは同じものを使っているのだけど。

何がどうなんだろうねぇ。

ActivePerl5.10.0Build1003をインストールしてから、どうもcpanがうまく動かなくて困っていた。

色々と試したところ、cpan.orgからIO::Compress::Zlibの最新版を落として入れなおすとうまく動くようになった。