世の中の趨勢はどうやらPHPのようです。PHP化すると何がメリットなのかというと、
きちんと対策するならば、.htaccessでリダイレクトする必要がありますが、そのあたりは、ブログ自由自在 Movable Type 上級カスタマイズ術に載ってますし、検索すれば解説しているサイトがいくつか見つかるでしょう。
なお、デメリットの3の表示速度ですが、これはPHPをどう利用するかによりますが、きちんと考えて設計すればさほどストレスなく表示させることは可能かな、というのが現在の意見です。
▼続きを見る⇔折りたたむ▲とりあえず、メインページの出力拡張子をhtmlから単純にphpに変え、設定画面の「アーカイブファイルの拡張子」を同じくhtmlからphpに変えれば、『なんちゃってPHP化』は完了です。
しかし、『なんちゃって』なだけあって、これだけではメリットはほとんど皆無です。
この状態で、FTPソフトを使ってサイトの情報を見ると、同じ名前のhtmlファイルの下にphpファイルが存在していることが分かります。また、中にはhtmlファイルだけしか存在しないものもあります。これらは、カテゴリーを変えたり、日付を変えて残ってしまったファイルなので、今後はこうした残骸ファイルを削除するように心掛けようという気持ちにはさせてくれるだけ、やった効果はあったのかもしれませんね(笑)
おそらく、私と同様にこのとき初めてMTのディレクトリ構造をきちんと見ることになるのではないでしょうか。日付アーカイブは年月フォルダに格納されているのは当然として、個別アーカイブまで年月フォルダに格納されていたのは意外な事実でした(よく考えれば当然のような気もしますが)。
また、カテゴリーアーカイブはカテゴリーフォルダに格納されているわけですが、フォルダ名に規則があることが分かります。つまり、英数字で構成されているわけで、日本語はカットされて作成されます(個別ファイル名も同様の命名規則になっていますね)。カテゴリー名が全部日本語だった場合にどうなるのかは、私はそうしてませんので不明です。
ディレクトリ構造がどうなっているのかが分かっても、すぐに役立つわけではないかもしれませんが、これから行なうPHPによる軽量化をする上で、知っておいた方がスムーズに行くと思いますので、このあたりで一通り構造を見ておくことをおすすめします。
さて、PHP化して、何も効果が出ないのは悲しいので、まずは簡単なことから始めましょう。
各ページに共通している部品をインデックス・テンプレートとしてしまう方法です。共通している部品の例としては、『バナー』『フッター』『カテゴリー一覧』『年月一覧』などが挙げられるでしょう。まず、『新しいインデックス・テンプレートを作る』のリンクを押し、テンプレートの名前と出力ファイル名を決めます。名前は分かりやすければ何でもいいので『01バナー』とかでもいいでしょう。出力ファイル名も任意ですが、英語表記の方が無難でしょう。拡張子も何でもありのようですが私は先の本に習って『inc』にしました。つまり、『banner.inc』としたわけです。
整理しますと
テンプレートの名前:01バナー
出力ファイル名:banner.inc
テンプレートの中身については、それまで使っていた部分をそのままカット&ペーストします。乱暴なようですが、大概はこれで動きます。
あとは、メインページやカテゴリーアーカイブなどの部品ファイルを読み込みたいページの適切な場所(つまり部品化するためにカットした場所)に
<?php include('<$MTBlogURL$>banner.inc');?>
別の方法として、
<?php readfile('絶対パス/banner.inc');?>
これで、再構築をすると、ケース・バイ・ケースですが、私の場合は10%程度ファイルサイズが小さくなった感じです。少なくとも効果はあったと言えるでしょう。
なお、参考にしたサイトは数多くありますが、中でもいち押しなサイトはBoycott Street 221Bです。
【2005/6/16追記】
Yahooで『MovableType 複数サイト』で検索してみたところ、このサイトが上位ヒットしました。ところが、リンク先はhtmlファイル(がーん)
ということで、htaccessは作らないつもりでしたが方針を変えました。面倒くさそうと思っていましたが、ブログ自由自在 Movable Type 上級カスタマイズ術に書いてあるとおりにやったら数分で完了しました。著作権法に引っかかるので内容のご紹介ができないのが残念ですが。いろいろ調べて時間を使うより、この本買っておいた方がいいです。
【2005/6/21追記】
hohohoさんのご指摘を受け、include関数よりもreadfile関数を利用した方がいいことが分かりました(include関数とreadfile関数とを使い分けるのが面倒くさいという方はinclude関数一本に絞った方がいいかもしれませんが…)。
小粋空間の(o)さんのコメントを引用します。
<?php include("http://yujiro.dyndns.org/blog/koikikukan/hogehoge.html"); ?>
のように書くのは2つの意味でお勧めしません。まず、hogehoge.htmlはサーバーサイドにあるファイルなのでURLを指定する必要はありません。URLを指定すると単にファイル名を指定するのに比べてアクセスにオーバーヘッドがかかります。
次にincludeはPHPモジュールを読み込む関数で、引数をプログラムだと思って評価します。もしhogehoge.htmlがPHPプログラムを含まないのであれば、includeで読み込むのは得策ではありません。代わりにreadfileという関数があります。
以上をまとめるとこんな感じにするとよいのではと思います。
<?php readfile("/blog/koikikukan/hogehoge.html"); ?>
なお、あまり気にしていませんでしたが、includeでもURL指定でなく、絶対パス指定は可能なようです。
はやる気持ちもわかりますが、PHPの軽量化を実施する前に頭を整理しておくことが重要だと思います。
まずは、ディレクトリの構造です。インデックスファイルをどこに置くか(ごく一部だけ使うことにしました)、部品化したいものは「インデックス」「月別」「カテゴリー別」「個別」のどれに属するものなのか。
全てに共通する部品は「インデックス」、個別の部品は「個別」、カテゴリーに一個の部品は「カテゴリー別」、月に一個の部品は「月別」です。どこに属するものなのか、もう一度よく考えましょう。
また、この際、不要なパーツは捨てましょう。私の場合、カレンダーは重いだけで全く無意味なので捨てていますし、前後の記事へ飛ぶリンクも捨てた方がデメリットよりもメリットの方が大きいようです。その他にも、『本当に必要なもの』なのかをよく考え、『うれしで導入したもの』をこの際捨ててしまいましょう。
また、せっかくPHPにしたのですが、その前に、『テンプレート・モジュール』を使ったことがない人は、先にこちらを使うことを強くおすすめします。
▼続きを見る⇔折りたたむ▲テンプレート・モジュールは部品化の練習として非常に適していると思います。部品にしたい部分をコピーし、『新しいテンプレート・モジュールを作成する』のリンクをクリックして、名前を適当に決め(英語表記の方がいいと思います。スペースは可能です。例:ArchivePath)、中身の部分にペーストします(例:『設定』で指定したファイルパス)。『リンクするファイル』は空でいいです。
整理しますと、
テンプレート名:ArchivePath
内容:『設定』で指定したファイルパス
リンクするファイル:(空)
一方、部品を読み込む方は、
<$MTInclude module="title"$>
こうして、部品化したい部分を片っ端から、テンプレート・モジュールにします。これで、きちんと再構築ができれば、あとでPHPの軽量化の際に役立ちます。いきなりPHPの軽量化に取り組み、再構築で壊れ、原因がつかめなくなるのが一番怖いですからね。
また、テンプレート・モジュールの場合は、先の『月別』『カテゴリー別』うんぬんの判断はまだしないでいいので楽です。とりあえず、テンプレート・モジュールで部品化してから、それらがどこに属するのかを今一度考えるのが正解でしょう。
なお、念のために言っておきますが、テンプレート・モジュールは軽量化には全く役に立ちません。テンプレート・モジュールによる部品化は、再構築時にテンプレートが結合されてそれぞれのアーカイブを作成しますので、部品のファイルが作られるわけではありません(イメージは『☆A社の事情』で掴んでください)。一方で、PHPによる部品化は、それぞれのインデックス、アーカイブの部品のファイルが作成された上で、ブラウザでの表示の際にそれらを結合しますので軽量化が図れるわけです。
テンプレート・モジュールを使い倒して部品化のコンセプトは固まりましたか?それでは、PHPで軽量化を目指すためのカテゴリー・アーカイブの作成方法を説明します。
まずは、おさらいを兼ねてインデックス・テンプレートの作成から始めます。
部品化したい部分のうち、インデックス、各アーカイブ共通の部分については、インデックス・テンプレートで部品を作っておいて、表示の際にその部品を読み込むようにした方が効率的です。同じ内容なのに各ページにあらかじめ組み込んでおくのはディスク容量がもったいないですし、再構築にも時間が掛かります。
また、ちょっと考えてみてください。投稿時に再構築されるのはインデックスとその月の月別アーカイブ及び所属するカテゴリーの月別アーカイブです。その他のファイルは更新されません。これはどういうことかというと、例えば全てのページにカテゴリー一覧を表示し、そこに投稿数とか更新日とかを表示させるようにしていた場合、毎回毎回『すべてを再構築』しなければなりません。そうしなければ、昔作ったページや最近更新されていないカテゴリーインデックスでは件数とか更新日とかが古いままになってしまうのです。
したがって、各ページに共通のものを部品化しておくことのメリットは、容量とか再構築時間とかだけでなく、うまくやれば『すべてを再構築』などほとんどしないでよくなるわけですから、頑張ってみる価値があるというものです(笑)
▼続きを見る⇔折りたたむ▲インデックス・テンプレートの作成方法(おさらい)
共通している部品の例としては、『バナー』『フッター』『カテゴリー一覧』『年月一覧』などが挙げられるでしょう。まず、『新しいインデックス・テンプレートを作る』のリンクを押し、テンプレートの名前と出力ファイル名を決めます。名前は分かりやすければ何でもいいので『01バナー』とかでもいいでしょう。出力ファイル名も任意ですが、英語表記の方が無難でしょう。拡張子も何でもありのようですが私はincludeの頭文字で『inc』にしました。つまり、『banner.inc』としたわけです。
整理しますと
テンプレートの名前:01バナー
出力ファイル名:banner.inc
テンプレートの中身については、それまで使っていた部分をそのままカット&ペーストします。乱暴なようですが、大概はこれで動きます。
あとは、メインページやカテゴリーアーカイブなどの部品ファイルを読み込みたいページに
<?php readfile('絶対パス/banner.inc');?>
さて、次に各アーカイブ・テンプレートの作成方法をご説明します。
例えば、カテゴリー別のタイトル一覧を部品として用意しておきたいというニーズが考えられます。個別エントリーに所属するタイトル一覧を表示させればユーザビリティは上がると思いますが、一方、各ページにあらかじめ組み込んでおくのは容量も時間ももったいないです。そこで、『新しいアーカイブ・テンプレートを作る』をクリックして、テンプレートの名前を『CategoryEntryList』などとして、リンクファイルは空のまま、中身の部分に
<div class="sidetitleS">
【カテゴリの説明】<br />
<$MTCategoryDescription$></div>
<div class="side">
<MTEntries category=<$MTCategoryLabel$>
<a href="<$MTEntryPermalink$>"><$MTEntryDate format="%y/%m/%d"$> <$MTEntryTitle$></a><br />
</MTEntries>
</div>
これを保存して、読み込むわけですが、お気づきのとおり、このままではファイル名が無いので読み込めませんね。
そこで、『アーカイブ・ファイルのオプションを編集』に行きます。アーカイブの種類は上記の例では『カテゴリー』ですから、『カテゴリー』を選択し、テンプレートは今作ったテンプレート名(上記の例では『CategoryEntryList』)が選択できるようになっていますのでそれを選択して『追加』ボタンを押します。
すると、カテゴリー別のところに追加されました。後は、出力ファイルパスの指定です。これをしないと読み込めませんからね。
ここでちょっと考えていただきたいのですが、MTのディレクトリ構成を吟味すればカテゴリー別のフォルダの命名規則が安定していないことが分かるでしょう。ということは、カテゴリー別の部品といえどもそれぞれのディレクトリに補完するのはちょっと危険な香りがします。(うまく行くのかもしれませんが)素人は手を出さない方がいいでしょう。
そこで、カテゴリー別の部品ではありますが、私の場合はアーカイブファイルパス直下に置くことにしました。『アーカイブ・ファイルのテンプレート』というInputBoxに
<$MTCategoryLabel$>_list.inc
【2006/9/7追記】
カテゴリを任意の順番に並べ替える[cutfirstchar]の追記に記載したように、このエレガントさに関する問題点をクリアできる可能性が見つかりました(筆者はまだトライするか躊躇していますが)。
【2006/10/18追記】
カテゴリの概要にファイルパスを入れることで文字化けファイルの生成を回避できることが分かりました。
参照したのは『30代サラリーマンのためのMovableTypeで簡単!ホームページ管理』です。
カテゴリの概要は、基本的に出力ファイル名と同じ記述にします。例えば出力ファイル名が「10」であればカテゴリの概要も「10」と入力します。
但し、サブカテゴリ構造をとっている場合は、親カテゴリのファイル名も入れる必要があり、親が「10」で子が「11」である場合、親カテゴリのカテゴリの概要は「10」でいいですが、子カテゴリのカテゴリの概要は「10/11」と入力します。
一方、カテゴリーアーカイブファイルの出力ファイルの指定は
<$MTCategoryDescription$&rt;/list.inc
というように概要に記載したファイルパスを利用します。
これを個別アーカイブで読み込む場合は
<?php readfile('<$MTEntryLink archive_type="Category"$&rt;/list.inc');?&rt;
というような感じでできます。
なお、ご想像の通り、この場合、カテゴリの概要を本来の用途で使用することはできません。
【追記終了】
これで、ファイル名ができましたので、あとは読み込む方です。
先の例では、『個別エントリーが所属するカテゴリーリスト』ですから、組み込み先は当然個別エントリーアーカイブになります。
<?php readfile('絶対パス/<$MTEntryCategory$>_list.inc');?>
注意する点は、ファイルの出力先ではMTCategoryLabelタグを使ったのに対し、読み込み側ではMTEntryCategoryタグを使う点です。エントリーに属するタグとカテゴリーに属するタグとで共通なものとして、カテゴリー名しかありません(多分)。先の判断はプラグインを探すのは面倒だし、作るのは大変、ということでの妥協だったわけです。効率がいいのもエレガントの要素ですから(笑)
上記はカテゴリー別でしたが、月別でも応用すればすぐできます。しかし、カレンダー等月別の情報を個別やカテゴリー別に表示するのはあまり意味があるとは思えませんので、私は月別のアーカイブ・テンプレートは作成しておりません。
個別の場合も簡単な応用です。個別の場合は、『本文』『追記』『コメント』などが部品化できるでしょう。これらを部品化すると、インデックス、カテゴリー別、月別では表示の際にincludeすればいいので容量の節約につながるでしょう。
詳しくはBoycott Street 221Bに記載されていますので参考にしてください。なお、ファイルのパスですが、私の場合は、
<$MTArchiveDate format="%Y/%m/parts/"$><$MTEntryID$>_body.inc
この、部品化を行なうことで、ディスク容量は半分以下に減ると思います。ただし、ロリポップのユーザー管理画面でのディスク容量の数値はすぐにキャッシュが更新されないようです。また、再構築時間ですが格段に短くなります。
【2005/6/21追記】
『PHP化』のところでも追記しましたが、hohohoさんのご指摘を受けて、include関数を使うのをやめ、readfile関数を使うことにしました。今のところ、PHPプログラムには手を出していませんので。
もっとマニアックにMTをこだわりたいというあなたに贈ります。
一つ目は再構築にこだわってみます。
PHPで部品化に成功しますと、再構築時間が格段に短くなります。そこで、味をしめるわけですね、私と同様に(笑)
「もっと短く、もっとエレガントに」と飽くなき探究心を満足させるために、再構築にこだわってみました(といってベテランの方にはたいしたこと無いでしょうが)。
再構築をこだわる場合、基本は『すべてを再構築』をしないように設計することです。つまり、個別や月別、カテゴリー別に新規エントリーのたびに更新される情報は部品化して『include』するということです。これはもうやりました。
次にやるべきこと(やっといた方がいいかなということ)は、『インデックスと一緒に再構築』のチェックボタンを吟味した上で外せるものは外すというものです。バナー部分やフッター部分、スタイルシートなどは毎回毎回投稿のたびに変わるものではありませんのでチェックは外した方がその分だけ再構築が軽くなります。
あとは、MySQLの利用ですね。再構築も軽くなるといいますし(私は最初からMySQLですから実感していませんが)、もしかするとレンタルサーバでのディスク容量計算から除外されている可能性もありますので。ディスク容量の節約にもつながるかもです(笑)
その他、当たり前ですが、不要なファイルを消すというのがあります。よくよく見ると残骸が結構残っているものですので(特にいろいろ試した後)、一度整理してみてはいかがでしょうか。
▼続きを見る⇔折りたたむ▲次のマニアックなものとしては、includeを入れ子で使うというのが挙げられます。なおreadfileを使う場合は気をつけてください。
部品化したものを個別ではそのまま使い、インデックスやカテゴリー別ではもう一工夫したものを使いたい場合などに応用できます。インクルードすべき『inc』ファイルに
<?php readfile('ファイル名');?>
を入れてしまうわけです。これで応用範囲が広がりましたね。
また、私の場合、複数のブログを立ち上げているわけですが、全体で1個あればいいという部品もあるわけです。最たるものが、ブログ間をリンクしあう部分です。
メインのブロクに
<MTBlogs>
<a href="<$MTBlogURL$>" title="<$MTBlogDescription$>"><$MTBlogName$></a> [<$MTBlogEntryCount$>]<br />
</MTBlogs>
これは、MT上の全てのブログへのリンクを作成してくれ、更に、横に記事数を表記してくれます。もし、個別のブロクに同様の『Links.inc』を置いてたとしたら、他のブロクへのリンクの横に記事数を表示させているため、ひとつのブログを更新したら他所のブログも更新しないと記事数の整合が取れません(私も当初はそうしていたわけですが)。しかし、それだけの理由で全てのブログをリビルドするのは美しくないですし、負荷がかかります。
ここで、ちょっとだけ話題をそらします。私の場合、以前紹介した『総合新着ページの作成方法[MTGlobalEntries]』にあるように、(マイバブルタイプ参照)コンテンツを含まない新着ページを作成しています。そして、各ブログを更新すると『新着ページ』にPingを飛ばしてリビルドさせているわけです。
ということは、『新着ページ』の『Links.inc』を更新しておけば、他の更新されていないブロクでも、表示時にその『Links.inc』を読み込むようにすることで投稿数の整合性が取れるわけです。
読み込み方ですが、
<?php readfile('新着ページの絶対パス/Links.inc');?>
また、先ほどの『インデックスと一緒に再構築』のチェックボタンを外したインデックス・テンプレートは、同様にメインのブログだけでOKの場合がありますので検討してみてください(効果は小さいかもしれませんが)。
そのほかにはスタイルシートの一本化があげられます。これはinclude(readfile)ではなくて、直接ヘッダー部分のスタイルシート指定の箇所を
<link rel="stylesheet" href="http://www.kodakara.com/styles-site.css" type="text/css" />
【2005/6/23追記】
include関数やreadfile関数は絶対パスでも相対パスでもURLでもいいようです。一般的には、<$MTBlogURL$>などを活用することが多いと思いますが、URLだとオーバーヘッド(DNSサーバーでのアドレス変換)が生じるため、これを絶対パスで行なうことも、マニアのたしなみでしょう(笑)
なお、絶対パスをあちこちに記載するとレンタルサーバを移行したときに不便かもしれません。テンプレート・モジュールで絶対パスを記載したものを作り、<MTInclude>するというのがいいかもしれません。
マニアックにこだわるのもいいのですが、私のような『なんちゃってマニア』には、いろいろと留意すべき事項があります。
個別パーツだと思っていたものが、良く考えると共通パーツなのでは?と思えたとき、ちょっと立ち止まって考えるなり、実際、ファイルの中身を吟味してください。こうしたひらめきというか思いつきは、見落としていること多いです。後で取り返しがつかなくなるほどではないにせよ、思いつきで実行してしまうと苦労します。『急がば回れ』ですね。
また、マニアックもほどほどにしといた方がいいと思われます。偏差値60程度のマニアックさであればさほどの努力は要りませんが、偏差値70程度を目指すと『労多く幸少なし』です。また、えてしてマニアックになりすぎると目的を見失います。自分のマニアック度合いに酔いしれてしまいますので(私のことですが)。
再構築の軽量化やディスク容量の軽減もほどほどにした方がいいでしょう。「これぐらいで十分かな」というレベルには2割程度の努力で8割がた達成します。ところが後2割のためには、8割の努力が必要です。これまでの4倍努力して、効果は4分の1というわけです。悪いことは言いません。適当なところでやめておきましょう。
また、立ち上げ当初にコメントやトラックバックの軽量化などはやっても意味がないですし、データが無いだけに予想外の事態に陥りがちです。コメントやトラックバックをもらいすぎて困る、という状況になってから再度軽量化に取り組んでも遅くはないです。そんなことよりも、内容に力を注ぎましょう。
同様に、ディレクトリやファイルの解析も適当なところまででやめておきましょう。初期段階ではなかなか区別がつきにくかったところも、データが揃うことで傾向が見えてくるというものです。データが揃うまで待ちましょう(データが多すぎて解析する気が失せるという可能性もありますが)。
350日の節約生活でMovableTypeコンテストの紹介記事が載っていました。MTユーザーの方はこの機会にエントリーしてみてはいかがでしょうか。私もエントリーしてみます。
エントリーの受付は6/29~9/16です。
▼続きを見る⇔折りたたむ▲審査は審査委員会によって以下の審査項目を審査されるようです。
総合性
操作性
デザイン性
独自性
技術性
コンテンツ内容
その他
賞は
グランプリ(1サイト)
順グランプリ(1サイト)
優秀賞(3サイト)
シックスアパート賞(2サイト)
メディアカイト賞(1サイト)
ライトアップ賞(1サイト)
フィールド賞(1サイト)
グロービス賞(1サイト)
アロマネット賞(1サイト)
グロービス賞(1サイト)
の13サイトが受賞されます。
審査開始は9/17以降と思われますので、エントリー後も頑張ってサイトの充実を心がけたいと思います。
【追記】
350日の節約生活様が受賞していましたね。おめでとうございます。
MovableTypeで作られたファイルはパーミッションのことを何も考えていないと『666』になっていると思います。つまり、FTPでアクセスしてきた人は誰でも書き換えられるわけで、オーナー以外は読み取り専用とする『644』にしたいところです。
ここで気になるのが、オーナー以外に書き込み権限を与えないとコメントやトラックバックがアップされないのではないかという疑問ですが、mt.cgi経由のcgiによる書き込みはオーナーとみなすようで、『644』でも問題無いようです。
しかし、MovableTypeは通常『666』のファイルを生成しますので、これでは、作ったたびにちまちまと属性変更するはめになります。
そのため、『mt-config.cgi』に
DBUmask 0022
HTMLUmask 0022
UploadUmask 0022
DirUmask 0022
を入れると自動生成されたファイルが『644』になってくれます。
数字の意味ですが、『777』から引く数ということですが、デフォルトが「0111」のようで、「777-0111=666」というのがデフォルトで、上記の記述をすることで「777-0111-0022=644」となるようです。
基本的に、MovableTypeをインストールした『mt』ディレクトリはパーミッションが最適になっているようなので、各レンタルサーバーの指定したファイル以外にいじる必要はないと思います。
『archives』ディレクトリ以下のファイルはほとんど全て『644』で問題ないはずです。カウンター用のcgi等、自分で導入したcgiファイルが利用するdatファイルなどは、そのcgiプログラムの仕様に従って下さい。
なお、『mt-config.cgi』はバージョン3.3から非常にすっきりしましたが、上記を含めていくつかの設定を付加しておいた方がよいようで、『MovableType備忘録』に詳しく説明されていますから、そちらをご参照ください。
当サイトを参考にされた方の何人かは、「文字化けして消えないファイル」が生成されてしまって悩まれていらっしゃるのではないか」と思うと、非常に申し訳なく思います。
というのは、『PHPで軽量化!』において$MTCategoryLabel$を利用したファイルの生成方法を説明したからです。
本日、文字化けファイルを作らない方法を知りましたので、そちらについては『PHPで軽量化!』の追記部分をご参照ください。
ここでは、せっかく文字化けファイルを生成しないで済むようになったにもかかわらず、過去作った文字化けファイルが消せない現象を解決する方法を提供します。
▼続きを見る⇔折りたたむ▲FFFTPでは消せない文字化けファイルが存在すると思います(割と比率が高い)。これは、日本語をもとにファイルが生成された場合に頻発する現象で、なぜこのような現象が起こるかはぐぐってもらえれば、大体理解できますのでここでは説明しませんが、こうしたファイルはcgiで消せます。
適当に『dell.cgi』というファイルを作り、そこに
#!/usr/bin/perl
system("rm -rf /home/sites/lolipop.jp/○○○/*.inc");
exit;
と記載します。
『#!/usr/bin/perl』の部分はサーバーによっては『#!/usr/local/bin/perl』の場合がありますので、他のcgiファイルの一行目を確認してください。
パスを指定している部分はフルパスで記載します。MovableTypeを利用している方であれば、設定を見ればすぐ分かるでしょう。
問題はファイル名で、文字化けしているので正確なファイルパスが記載できないのですが、私の場合、文字化けしているファイルは全て拡張子が『inc』でしたので、ワイルドカードの『*』で消しました。
この『dell.cgi』をcgiが稼動可能な『mt』ディレクトリあたりにアップロードし、属性を『700』とかに変更して実行ファイルとし、実行します。実行すると『500エラー』が出るかと思いますが、ちゃんと消えていますので安心してください。FFFTPで消えていることを確認したうえで、dell.cgiを削除してください。