「スクリプト」カテゴリーアーカイブ

EPSファイルのリンク配置でつまづく

投稿日時: 投稿者:
返信

細かい構文は別の機会に。
EPSファイルを作るには、ImageMagickで画像をEPS化したものを、PerlのPostScript::Simpleでデータ毎埋め込んでいましたが、1つのデータでは特に問題がなくても、面付けまで自動的にやろうと思った場合、ファイルサイズがとんでもないことになってしまいます。
そこで、画像のEPSファイルをリンクで指定できれば面付けしてもファイルサイズはぜんぜん問題になりません。
そこで、いろいろ調べて見つけたものを試してみました。
しかし、GSViewでは問題なく表示されても、イラストレータで開けません。
いろいろ試してみると、ファイルパスの指定方法に問題があるとわかりました。厳密にいうと、イラストレータのファイルパスの扱いに問題があるのですが。

リンク先の画像EPSを特定の場所におこうとした場合、ドライブを含む、若しくはドライブ以下の絶対パスが必要です。
そのパスを指定したくない場合は、ドライブの直下に置けばいいことがわかりました。
つまり・・・
Cドライブの直下に置けば、

%%BeginDocument: image.eps
(image.eps) run
%%EndDocument


となります。
仮にC:/eps/に置くとすれば、

%%BeginDocument: image.eps
(C://image.eps) run
%%EndDocument


となります。
ファイルパスを指定するのは面倒なので、ドライブを1つつぶしてその直下に置いたほうが断然楽でしょう。

PHPのparse_ini_fileでハマる

投稿日時: 投稿者:
返信

parse_ini_fileは設定ファイルをパースしてくれる関数ですが、使い勝手が良いのか悪いのか。
文字列に「”」ダブルクオートを含む場合、そのままでは記述できません。
エスケープしてみたり、文字列をほかのもので囲んでみたりしたけど、希望するとおりにならない。
しかたなくphpのリファレンスを見ると、定数で逃げればいいとの事。
iniを動的に作成したりする場合は、

define( 'QUOTE', '"' );

必須ということですね。

こういうやり方が残っているとは、PHPもまだまだだなぁと思う今日この頃でした。
ちなみに、検索で調べた中で文字列自体を定数にしろという意見もありましたが、定数と変数の違いを理解していない人が多いのは残念です。
とはいえ、自分も定数に逃げている部分もあるので、大きいことはいえませんが。

HTTP_REFERERは使うな

投稿日時: 投稿者:
返信

PHPで組んだものをIEデミルとどうも動きが怪しい。
ちょっと調べてみると、IEがセキュリティ設定の都合でHTTP_REFERERを吐いていないらしく、一部画面の推移に影響が出ていた。
てっきりJavaScriptだけだと思っていたのに、サーバにも情報を隠蔽していたらしい。
仕方がないので、HTTP_REFERERを使わないようにい変更するしかない・・・

Spreadsheet_Excel_Readerのバグ

投稿日時: 投稿者:
返信

セルの書式に文字列を指定すると、

Notice: Undefined variable: formatstr in D:\xxx\xxx\Excel\reader.php on line 636


という注意が出ます。
xxxは適当なパスだと思ってください。

このエラーメッセージの出るところを見てみると、変数の初期化がきちんと行われていなため、例外処理が不完全だということのようです。
このあたりの一連の処理が始まるところで、$formatstrを初期化してしまいましょう。
630行目に
$formatstr=”;
とでもしておきます。
これで注意が表示されなくなりました。
このあたりは、PHPのバージョンが違うと注意は表示されないのかもしれません。
このライブラリのようなコードの書き方はあまり馴染めません。
中括弧（{}）を使ったほうが見やすいと思うのですが。

イラストレーターのEPSデータを考察

投稿日時: 投稿者:
返信

イラストレータといっても、手持ちのは古いままで7でのお話です。
EPSで保存すると、プレビューとサムネールを保存するかどうかの確認がありますが、これはいったいどのように格納されているかを調べてみました。

調べるといっても、サムネイルもプレビューも含まないで保存したEPSファイルと、サムネイルまたはプレビューを含んだEPSファイルを比較しただけです。

保存したファイル名と保存日時のデータは無視して、それ以外を比較します。

まず、サムネイルを含んだEPSファイルを比較しました。
違っていたのは、以下のとおりです。
46行目にある
%AI7_Thumbnail: 128 128 8
から
%%EndData
これが、サムネイルデータのようです。
バイナリが16進で格納されているようです。
どの画像形式かはわかりませんが、おそらくTIFFではないでしょうか。

次に、プレビューを含んだEPSファイルを比較しました。
違っていたのは、以下のとおりです。
1行目の先頭にバイナリデータが含まれています。
その後に通常のEPSデータが始まります。
%!PS-Adobe-3.0 EPSF-3.0
そして34行目に、
プレビューを含まないEPSファイルでは
%AI3_DocumentPreview: Header
となっているところが、
プレビューを含むEPSファイルでは
%AI3_DocumentPreview: PC_ColorTIFF
となっいます。
そして一番最後にまたバイナリデータが含まれています。
通常のEPSデータの末尾である
%%EOF
の後に、バイナリデータが追加されています。

他のイラストレータのバージョンでは、また違うかもしれません。
比較に使用したファイルをおいておきます。
サムネイルもプレビューも含まないEPSファイル
サムネイルを含むEPSファイル
プレビューを含むEPSファイル

mod_perlでライブラリが見つけられない

投稿日時: 投稿者:
返信

通常のCGIでは問題なく動くスクリプトを、いざmod_perl環境下に置いたとたんに動かなくなるのはよくある話。
変数や配列などの初期化がいい加減で、どんどん肥大化してしまうのは、日ごろから心がければ何とか回避できるものの、いまだに良くわからないエラーが次のもの。
「Undefined subroutine &ModPerl::ROOT::ModPerl::Registry::」
Registryの後には実行されるスクリプトのパスが入る。
つまり、mod_perl環境下で実行ファイルはモジュールとして扱われる。
このため、ライブラリやモジュールの読み込みまわりで順番がおかしくなり、ファイルが見つからないといわれることになるのだ。

この文字を検索すると以下のようなサンプルが表示される。

LoadModule perl_module modules/mod_perl.so

PerlRequire "/path/to/startup.pl"


SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI


# in startup.pl, i have this:
use lib "/path/to/webObjects";
use Apache2 ( );
use ModPerl::Registry ( );

use Carp;
use CGI;

use lib_webObjects;
1;


startup.plを読めばいいらしいのだが、そのとおりにやってもサーバーエラーになる。Apacheのエラーログを見ても同じメッセージか載ってないので、構文エラーという前に効果がないのかもしれない。
日本語のサイトがひとつも見つからないときは、英語が苦手でなければと常に思う。
しかし、このエラーも.htaccessと、httpd.confにディレクトリで指定したときでは挙動が違うような気がする。
Apache起動時に読み込ませた環境では、実行時に読む.htaccessと違うのはもちろん当たりまえなのだが、解決方法が見つからなければいくら原因がわかっていてもしょうがないのである・・・

さてはて、いったいどうしたものか。
最悪の場合、ライブラリをやめて1つのファイルに全部詰め込む荒業に出るか？

path設定のセパレータがOSで違うのにハマった

投稿日時: 投稿者:
返信

ちょっと複雑な設計になってくると、パスの制限を回避したくなります。
いや、本当はそういう制限があっても問題ないのが本当はいいのだけど、いちいちdefineで宣言するのもめんどくさいし、過程よりも結果に重きをおくべきなのはいうまでもありません。
ということで、set_include_pathをいじって、システムの設計を一部変更して、テストサーバにアップしたとたんに異変が。
今まで動いていたのが、ファイルが見つからないの嵐に。
よくよく調べたら、Windowsとそれ以外ではpath設定のセパレータが異なるという。
OSのpathを利用しているからだと分かればたいしたことないのだけれど、コロンとセミコロンなんて、ぱっと見て違いに気づきませんよ、普通。
定数のPATH_SEPARATORを使えばいいのだけれど、こういう回避の仕方はｐｈｐだからこそというか、無理やりというか・・・
マニュアルのページには以下のようなコードが載っていました。

<?php
if ( ! defined( "PATH_SEPARATOR" ) ) {
  if ( strpos( $_ENV[ "OS" ], "Win" ) !== false )
    define( "PATH_SEPARATOR", ";" );
  else define( "PATH_SEPARATOR", ":" );
}
?>

phpの定数とか関数の初期値は、バージョンが変われば変化してしまう危険があるので、あまり使いたくないけど、どの道php6はまだ先のことだろうから、とりあえずPATH_SEPARATORをつかってしのぐことにしようかな。

.htaccessでやればいいみたいだけど、詳しい説明が載ってない。
設定済みのものを取得私鉄かしたいような場合だと、.htaccessでは全部書き直さなければいけないようなので、phpで一度取得した後に再設定する方法がいいのだろう・・・。

と、散々愚痴っていたけど、php.iniをよく見たら

; UNIX: "/path1:/path2"
; Windows: "\path1;\path2"


このように、しっかり書かれてあった。

まとめると、以下のようになる
php.iniで設定する場合

include_path = ".;c:\php\pear;c:\php\cli\pear;c:\home\php_myLib"

.htaccessで設定
する場合

php_value include_path ".:/usr/local/lib/php:/home/user/php_myLib"

長いこと使っていても知らなかった。
というか、使うことがなかっただけかもしれない。

PHPでメールを送信するときのメモ

投稿日時: 投稿者:
返信

メール送信はどうも使い慣れません。
現在のWebコンテンツでメール送信は切っても切り離せないものですが、どうも使い方に慣れません。

とりあえず、何度かこうやってメモしていけば体が覚えてくれることでしょう。
本棚にはオライリーの4000円もする「電子メールプロトコル」の本がありますが、たいして活用されていません。

とりあえず、さて、メールを送信したアドレスが存在しない場合、その送信先のドメインが存在しなかったり、ユーザが存在以内場合はリターンメールが返ってくるのですが、その通知先を指定できます。
（そもそもこの考え方であっているのか？）
ヘッダでは「Return-Path」です。
ヘッダにあたる部分には以下のように記述しておくことになっています。

Return-Path: return@exsample.com


しかし、この方法ではほとんど有効ではなく、スクリプトやサーバが指定したものに強制的に上書きされることがほとんどのようです。
もちろん、設定できるのですが、動的に変化させる場合この方法では使えません。
これを回避するには、sendmailへのスイッチが有効なようです。
PHPでは第5引数に次の内容を追加します。

"-f return@exsample.com"


つまり実際にはこうなります。

mb_send_mail( $to, $subject, $body, $headers, "-f $mail" );

これで、受信したメールのソースを見ても正常に設定されました。

メール送信用のモジュールやライブラリを使っている場合はこの限りではありませんので、ご注意ください。

参考にしたのはこのあたり
http://builder.japan.zdnet.com/member/u87200/blog/2009/02/08/entry_27020134/

PHPのHTTP_Clientライブラリ

投稿日時: 投稿者:
返信

ファイルをアップロードするにはHTTP_Clientがいいらしいんだけど、
セッションでログイン管理しているからCookieを食わせなくてはいけない。
正確には、すでに食っているので、クッキーの値を送ってやる必要がある。
いろいろ調べてみると、HTTP_Client_CookiManagerというものがあって、passCookies()でセットできるらしいところまではわかったけどうまくいかない。
解説サイトも翻訳しただけで、ろくなサイトが見つからない。
やっぱりこういうクライアント側のごにょごにょはPerlしか使い物にならないのだろうか・・・