楽天ブックスで送料無料にする方法

インターネットで買い物をすると、とても便利です。田舎に住んでいると、なおさらそうです（笑？）。田舎の場合、近所の本屋には、プログラムの本はほとんどゼロです。ですから、Amazonや楽天ブックスで買い物したりするのですが、問題になってくるのが送料の問題です。Amazonの場合、税込み1,500円以上で送料無料となるため、税込み1,470円の本を買おうと思った場合、非常に躊躇します。送料300円があるだけで悩みます。

送料無料にするために100円とか200円の本があれば良いのにと思ったことは何度あったか分かりません。

同様に、楽天ブックスでも税込み1,575円以上なら送料無料になるため、1,400円台の書籍が欲しい場合に非常に悩みますね。たったの送料250円がもったいなく感じます。ところが、つい今しがた知ったのですが、コンビニでの店頭受け取りを選んだ場合は、ご注文金額にかかわらず送料無料になるんですよね。ファミリーマートなら、ビデオ屋（韓国ドラマにはまっていて、よく「朱蒙」などを借りに行きます。）に行く途中にありますし、私には非常に都合が良いです。

コンビニで受け取るのも都合が悪いという場合は、送料を甘受するか、それとも100円とか200円の本を探すしかなさそうですが、楽天が公開しているAPIで価格検索ができるので、こんなのを作ってみました。

300円以下でも購入できる書籍（2008年2月22日現在、31円という本もありますね。）

絵本の場合、100円台も多いです。（お子様をお持ちの方向け）

PHP・PEARでXMLを処理する

Amazonでアフィリエイトをしているのですが、Amazon.co.jpからメールが先日届きました。ECS 4.0に移行する案内メールは何度か送っているが、まだのようだから連絡してくれたとのことです。ECS 3.0は3月末で終了するという。ああ、すっかり忘れていたか、メールを見落としていました。

慌てて、ECS4.0でのXMLへのアクセス方法を調べてPHPプログラムを作り直してみました。ところが、なかなかうまくいきません。ECS 3.0の時は、xml_parse_into_struct関数を使ってやっていたのですが、Amazonのデータには、例えばある商品には「Availability」が設定されていても、設定されていない商品（=在庫が無い商品）がありますので、単純な配列の要素番号でのアクセスはバグります。Amazon Web Serviceでの開発を始めた数年前の時は、このような異常な？（というより、技量の低いプログラマーには不都合な）データは少なかったように思うのですが（そのようなデータがあった場合には、その都度、対処療法で対処していました。）、今回、ECS4.0用にいざ書き換えとうとして、いろいろ調べてみると、そのようなデータが非常に多いことに気づかされました。空データであれば、XMLデータの中に最初から入っていないようです。転送量を考えても、当然の仕様かもしれません。

xml_parse_into_struct関数の使い方が間違っている可能性もありますが、もはや対処療法では不可能ぽいので、別の方法を探ってみることにしました。PHP5ならSimpleXML関数が使えますが、私が使っているレンタルサーバはPHP4なので、使えません。そこで、PEAR（http://pear.php.net/package/XML_Serializer ）を使ってみることにしました。私のレンタルサーバにもPEARがインストールされていることは分かっていたからです。

まず、XML_Serializerをダウンロードして、ローカルのPEARフォルダーの中の「XML」フォルダーにUnserializer.phpとSerializer.phpをコピーして、ローカルでのテストは成功しました。ところが、同じように、「XML」という名称のディレクトリーを公開サーバ上に作成し、そこにUnserializer.phpとSerializer.phpをアップロードしてみたのですが、「Fatal error: Call to undefined method: xml_parser->sethandlerobj() in /usr/home/*******/public_html/XML/Unserializer.php on line 852」のようなエラーが出てダメです。

もしかして、わざわざ、Unserializer.phpとSerializer.phpをアップしなくても、既に同パッケージはインストールされていて、使えるようになっているのかなと思って、ためしに両ファイルを削除してみると、今度は、「require_once("XML/Unserializer.php");」のところで、「main(XML/Unserializer.php) [function.main]: failed to open stream: No such file or directory
Fatal error: main() [function.require]: Failed opening required 'XML/Unserializer.php' (include_path='.:/usr/local/lib/php') in /usr/home/*******/public_html/test.php on line 2」となり、やっぱりダメです。サーバ事業者に連絡してXML_Serializerをインストールしてもらうか、自分のユーザー領域にコピーして使う（もちろん、sethandlerobjのエラーを解消しなければなりません。）しかないようです。

では、何でsethandlerobjのところでエラーになるのかなと思ってGoogleで調べてみたところ、原因はすぐに分かりました。

●undefined function: sethandlerobj() (Nega Diary)
http://www.ironhearts.com/diary/archives/001239.html
PEARの本体のバージョンが古いことが原因のようです。結構同じエラーではまった方も少なくないようで、852行目という数字まで一緒だったりします（ある意味、当たり前？）。レンタルサーバの事業者に連絡してPEAR本体をアップグレードしてもらうのもいろいろ面倒なので、WindowsのローカルサーバにあるPEARフォルダーを丸ごとサーバにアップし、「/usr/local/lib/php」ではなくて、そちらのパスを見に行ってもらうようにプログラムすることにしました。

ini_set関数ではうまくいかなかったので、.htaccessでinclude_pathを変更して、やっと動くようになりました。
php_value include_path "/home/******/public_html/php/PEAR"

のように.htaccessの中で設定しました。これでECS4.0にようやく移行できます。

印刷禁止・テキストのコピー禁止の掲示板やブログの作成も可能になるPerl/CGIライブラリー

掲示板やブログ上のコンテンツ保護・情報流出を防ぐ、HTMLソース難読化用Perlライブラリ「サーバサイドSHTML for Perl/CGI」をプランセスがリリースしました。Perl/CGIプログラムが出力（printやecho）するHTMLソースを出力前に、サーバ上でリアルタイムに難読化（≒JavaScript化）するというもの。

HTMLソースを難読化できるかだけでなく、右クリック禁止をはじめとして、印刷禁止・テキストのコピー禁止・PrintScreenキーの無効化などを盛り込むことができます。イントラネット内の掲示板やブログ、リリース前の商品に関する市場調査など情報が漏れてはいけない場面などで利用るという。

もちろん、完璧に保護したいと考えるのであれば、専用ブラウザ（右クリックが最初からできないというか、コンテクストメニューが最初から存在しない、シンプルすぎるブラウザでありながら、各種画面キャプチャーソフトの起動プロセスを終始監視することのできる専用ソフト。）を開発するしかないと思います。そして、「その専用ブラウザでしか、私どものサイトを閲覧できません」とサイト訪問者に説明し、専用ブラウザの使用を強要するという方法しかないと思いますが、これは、いろいろな意味でかなり大変です（イントラネットであればある程度の強要は可能だと思いますが、費用はかなりかかると思います。ちなみに、「サーバサイドSHTML for Perl/CGI」は72,000円～）。

さらに言えば、漏れたくないコンテンツならば、「究極の話・公開しなければ安全であり、それが唯一の方法である」と言えるかもしれませんが、そのような虚無的な選択肢は「無し」とするのであれば、JavaScriptで出来る限りのことをやるという結論になるかと思います。

Perl/CGIでデータの改行コードが0x0D0x0D0x0A（\r\r\n）になった場合の原因と対策

Windows Vistaのテストサーバで最近、Perl/CGIのテストをいろいろやっています。そんな中、テキストファイルにデータを書き出すという単純なプログラムで、改行コードが変てこになる現象に遭遇。ここ数年、PHPばっかりやっていたためにPerlのお作法をすっかり忘れてしまっているみたいです。

秀丸でファイルを開いてみると、改行が増えています!! 1回しか改行していないところは2行になっていますし、1行空白行を作っている場合は、3行空いています。何だこれは？　バイナリーエディタで見てみると、改行の部分が「0x0D0x0D0x0A（\r\r\n）」（0x0d0d0a）になっています。調べてみたら、すぐに原因が見つかりました。

● とほほのperl入門（概要編）
http://www.tohoho-web.com/wwwperl1.htm

Windows上で上記のスクリプトを実行した場合、STDOUT や OUT への出力は \n が \r\n に自動変換されて書き込まれます。これをテキストモードと呼びます。この自動変換を行わないようにしたい時は binmode()を用いてバイナリモードにしてください。

このサイトのおかげで一発で解決できました。PHPではこのような現象は起きたことがなかったので気づきませんでした。また、Perl/CGIをメインに使っていた数年前は、Windowsにテストサーバを準備してという技量もなかったので、直接、Unix系サーバにアップロードしてテストしていた（今考えると恐ろしい。）ので、こういう問題に気づきませんでした。まさしく、「とほほ」な感じです。

Perlって使いにくいなと思いましたが、PHPでも、4.3.2以前の出力モードは環境依存だったようです。

● 開発規約/95 - BugbearR's Wiki「テキストモードとバイナリモードの区別を明確にする。(改行コードの取り扱い) 」
http://www.bugbearr.jp/?%E9%96%8B%E7%99%BA%E8%A6%8F%E7%B4%84%2F95

調べてみると、PHPのマニュアル「fopenの項」にも、そのいきさつが明記されていますね。まだまだ勉強しなければならないことが多そうです。とほほ。

MacOSX+Web共有でPerl/CGIをプログラムする際に注意すべきこと

WindowsでApacheをインストールして、ローカルのテストサーバを運営していると、実にプログラムのテストが容易です。その便利さにかまけて、基本的なことを忘れてしまっていたことが原因ではまった現象がつい先日ありました。

基本的に、Windows XPもしくはVistaでテストすればそれで十分なのですが、現在開発中のプログラムで、MacOSXでのテストをどうしても行ってみる必要が出てきました。その時、非常に初歩的なことで、はまりました。お恥ずかしい話ですが、備忘録として・・・。

１．パーミッションの変更をしないといけない
Windowsでテストをしている場合には、そのようなことを意識せずともテストできますので、最初、eMac（Tiger）で5行程度のCGIプログラムを作成して実行してみると、「403 Forbidden」と言われたので、理由が分からず焦りました。Terminalからファイルのパーミッションを705に変更て、これでOKかと思ったら今度は恐怖の「Internal Server Error」大王の登場です。

２．改行コードはLFに明示的に変換しないと動作しない。
エラーログを見てみると、「[error] (2)No such file or directory」となっています。「そんな（such）ファイルやディレクトリーはない」というのですが、suchが何を指しているのか最初は分かりませんでした。Perlのパスかなと思い、whichコマンドで調べて、「/usr/bin/perl」であることを確認。「おかしいな、あっているのににな」と考えること数分。Perl/CGIの場合、改行コードの問題で動作しないことがあることを、遠い記憶から呼び起こしました。

Windows + Apacheでは、改行コードが「CRLF」のままでも動作します。また、FTPソフトでUnix系サーバに転送した場合、自動的に改行コードを変換してくれるので、「改行コードが問題になっている」ということに全然気づきませんでした。

Jedit Xでプログラムしていて、デフォルトのまま使っていたので、改行コードがCRになっていることに気づきませんでした（もちろん、別に、Jedit Xの責任ではないですけど）。改行コードをLFに変更したところ、Internal Server Errorは消えて、無事にプログラムが実行できました。

結局のところ、Windowsでプログラムを作成して、UnixサーバにFTP転送する際に、パーミッションも自動変更してくれますし（NextFTPでは設定できます。）、改行コードも自動変更してくるので、基本的なことをすっかり忘れてしまっていましたのでした。

EmEditorと補助漢字

EmEditorのバージョンが7になりました。2006年11月に「秀丸エディタとEUC補助漢字（「繋がる」と「繫がる」）」という記事を書きましたが、EmEditorは当時、補助漢字には対応していませんでした。実際、2007年3月には、EmEditorの公式フォーラムで以下のような質問がなされていました（なお、質問した人は私ではありません）。

●EmEditor テキスト エディタ - フォーラム「EUC-JPは実際にはサポートされていない？」
http://jp.emeditor.com/modules/newbb/viewtopic.php?topic_id=195&forum=2&post_id=746#forumpost746

この中で「次の EmEditor のメジャー バージョンでは、ほぼ確実に、このような新しいエンコードにも対応していきたいと思います。」と開発者の方が語られていたので、バージョン7になって実際どうなっているだろうかと思い、試してみましたが（バージョン7.00でテスト。）、未対応のようでした。（ちょっと意地が悪いですね。補助漢字に対応するのは本当に大変なことだと思います。私のWEBアプリも、まだ対応できていません（汗）。）

データベース（文字コード：EUC-JP）のバックアップなどを取った際に、バックアップファイルをEmEditorで再編集後、データベースに戻す処理をする場合は、注意が必要な場合もあるでしょう。なぜなら、Firefoxで登録された「鷗外」や「繫ぐ」を補助漢字に対応していないテキストエディタで開き、それを再保存すると、文字化けした結果である「乗ｽ」「恕ﾘぐ」が確定化してしまい、バックアップファイルからの復元前は「IEでは文字化けするけれどFirefoxでは文字化けしない」状態だったのが、「IEでは文字化け。Firefoxでも文字化け」という事態に悪化してしまうこともありうるからです。

もちろん、このような事態を避けるためにも、Firefox（やSafari）で送信された3バイトのEUCデータは、データベースに登録する前に数値文字参照化してしまい、IEでもFirefoxでも文字化けしない状態にしておくのが理想的だと思います。そうすれば、補助漢字に対応していないテキストエディタを経由しても文字化けしないようになりますが、なかなかそこまで手が回らないのが実情でしょう。

話を、テキストエディタの比較の話に戻します。では、補助漢字の対応だけを見るのであれば、今のところ、秀丸に軍配が上がりそうかというとそうでもなさそうです。私が誤解している部分があるかもしれませんが、両テキストエディタの機能を比較してみますと、

0x8Fで始まる3バイトEUCのデータがある場合
	秀丸エディタ	EmEditor
読み込み時	○ （文字化けせずに表示）	× （文字化して表示。 保存時に文字化けが確定）
保存時	× （EUCのファイルで「鷗外」「©」などと新規入力したHTMLファイルの場合、その文字がFirefoxなど一部のブラウザでしか意図通りに表示できないことを認識できないまま、ユーザーが思わず使ってしまう危険性があります。）	デフォルトの設定の場合 ○ （自動的に、数字文字参照・文字実体参照に置き換えて保存）

好き好きはあるかもしれませんが、私は、EmEditorの保存時の設定は優れていると思います。EmEditorの場合、このデフォルトの設定が気に入らない場合は、【ツール】→【現在の設定のプロパティ】→【ファイル】タブ→【保存時】ボタン→【Unicode文字をHTML/XMLの文字参照として保存】及び【名前による実体参照を使用する】のチェックを外せば良いでしょう。

●EmEditor テキスト エディタ - FAQ: 「HTML、または XML ファイルを保存する際に、EmEditor はUnicode 文字を文字参照 "Numerical Character References" (NCRs - &#xx; など) として、エンコードすることはできますか?」
http://jp.emeditor.com/modules/xoopsfaq/index.php?cat_id=6#q63

続きを読む "EmEditorと補助漢字"

【PHPのとあるエラー】Warning: fopen(): URL file-access is disabled in the server configuration in

AmazonのWebサービスを使ったサイト（PHP）の構築のために、海外のレンタルサーバでfopen関数を使って、XMLデータを取得していました。もちろん、AmazonのXMLサーバが混んでいて、うまくデータを取得できない場合も考えて、エラー処理を入れていました。

エラー処理では、そのような場合には、http://www.amazon.co.jpの該当asinページに飛ばす（redirectする）ようにしていました。ただ、ログに残したり、メールで通知が来るようにまではしていませんでした。そのため、いつのまにかfopenに常に失敗している事態が発生していることに最近まで気づいていませんでした。

ところが、最近になって、常にエラー処理の方が行われており正常な処理がされていないことに気づきました。関数名の前の「@」を取って、確認してみると、

Warning: fopen(): URL file-access is disabled in the server configuration in ・・・

エラーの内容から、allow_url_fopenの設定がいつの間にか変えられていて、fopenでリモートのファイルをオープンすることが禁止されていることが想像できました。「やられた」と思いました。恐らく、レンタルサーバの事業者から事前に連絡はなかったと思います。（スパムが大量すぎるので、英語の件名のメールの場合は、ウイルスバスターのスパム判定をほぼ無条件に信じて削除して待っているので、スパムと間違って削除した可能性はありますが・・・。）

セキュリティを考慮してサーバの設定をいじくるのはレンタルサーバ事業者としてありうることでしょうが、事後でも連絡してほしいものです。おかげで、正常処理されていればサーチエンジンにしっかりと登録されているはずのページが、amazonへ単純にリダイレクトしているだけの意味のないページとして判断され、サーチエンジンから登録の多くが消えてしまっていました。

ただ、過去の記事にも書いたように、海外のレンタルサーバ事業者は絶対に「I'm sorry.」とは言わないし、文句を言ってもストレスがたまるだけです（早く乗り換えようと思っているのですが、安さとディスクスペースの多さに負けて、なかなか乗り換えられないでいます）。だから、今回は黙って対処することにしました。

PHPの本家のfopenのページを見てみると、すぐに解決策は見つかりました。「Luiz Miguel Axcar (lmaxcar at yahoo dot com dot br)」さんのユーザーコメントにcurlを使った代替策が載っていました。この代替策で無事解決できました。