セルの書式に文字列を指定すると、
Notice: Undefined variable: formatstr in D:\xxx\xxx\Excel\reader.php on line 636
という注意が出ます。
xxxは適当なパスだと思ってください。
このエラーメッセージの出るところを見てみると、変数の初期化がきちんと行われていなため、例外処理が不完全だということのようです。
このあたりの一連の処理が始まるところで、$formatstrを初期化してしまいましょう。
630行目に
$formatstr=”;
とでもしておきます。
これで注意が表示されなくなりました。
このあたりは、PHPのバージョンが違うと注意は表示されないのかもしれません。
このライブラリのようなコードの書き方はあまり馴染めません。
中括弧（{}）を使ったほうが見やすいと思うのですが。
最近始まったバンドアニメ。
全てにおいてクオリティが高く、いろんな視点で見ても満足。
ゆいのタイツ姿がなかなかそそります。
javascriptでlocationを変更した場合、IEではHTTP_REFERERを返さない。
ちなみにFirefoxとOperaはきちんと返してくれる。
処理の戻りを手抜きしたかったのに・・・
Firefox限定でもいいや･･･
ぜんまいざむらいが終わってもテレビをつけっぱなしにしていたら始まった番組で、第1話をみてぶったまげました。
しばらく見ていましたが、なかなかのロリコンホイホイで、自分も捕らえられたその一人。
このようなご乱心をNHKが続けてくれることを望みつつ。
Perlの場合
ref( $str );
全て大文字の文字列が返る
PHPの場合
gettype( $str );
全て小文字の文字列が返る
| コード範囲 | 内容 |
|---|---|
| 0x00～0x1f | 制御文字 |
| 0x20 | 空白 | 0x21～0x7e | 図形文字 |
| 0x7f | 制御文字 |
「文字」として表示可能なのは0x20～0x7e
その中で・・・
「数字」である0~9は0x30～0x39
「大文字の英字」であるA～Zは0x41～0x5a
「小文字の英字」であるa～zは0x61～0x7a
これ以外は記号文字とか言われたりするが、正式な名称はあるのだろうか？
ちなみに、バックスラッシュである0x5cはいろいろ面倒を引き起こすことで有名。
リリースがズルズルと延びていたCentOS5.3ですが、2009年3月31日にリリースされていました。
英語をまともに読めないので､PlanetCentOSの記事はさっぱりなのですが､リリースだけは理解できます.
とりあえず､ファイルサーバを用意する機会があったので､インストールしてみました。
画面ではおなじみのブルーのグラデーションに、和風な模様が追加されて、和らいだ感じです。
イラストレータといっても、手持ちのは古いままで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ファイル
個人、板チーム内チーム、板チーム、チーム別のpointsグラフが見えるようになりました。
http://wcg-team2ch.no-ip.info/stat/transition.cgi?member_id=351765
ひさしぶりにGD::Graphをいじったので、すっかり忘れていましたが、なんとか見えるようにだけはなりました。
細かな調整はやってないというか、GD::Graphの使い方をしらないので、今はこれが精一杯。
通常の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つのファイルに全部詰め込む荒業に出るか？
