PHPからGoogleカレンダーのXMLを読み込んでみた。
あわよくば、Googleカレンダーからデータを読み込んで、ホームページ上のイベントカレンダーなるものに自動で表示出来ないかと・・・
実際、読み込んでみると、予定の日付、内容、場所などは取得できる。GoogleカレンダーのURLも取得できる。
が、読み込む順番は、新しく更新した順番。当然と言えば当然ですが、そこから今月の予定だけを抜き出そうとすると、結局全件読まないといけない。
しかも、全件と言っても、25件しか読み込めない。
25件じゃちょっと・・・
Googleカレンダーと連携するソフトがいろいろ出てますが、25件以上はどのように処理してるのだろう。
備忘録として。PHPは、4.3.9です。
1.PHPの Client URL Library（cURL）を使う。
ｃURLが何に使う関数なのか定かでなかったのですが、こいつを使えば、POSTリクエストが送れます。
参考URL：JUGEMの自作テンプレートを配布 Show-U PHP HTTPリクエストを送る CURLパッケージ
すっきりとしたソースコードで実現が出来ます。結果を変数で受け取る（CURLOPT_RETURNTRANSFER が True）と、その結果を表示すれば、POSTしたURLの実行結果が表示されます。これを表示しなければ、HTTPヘッダーには何も出力されていないので、そこから別ページにリダイレクトも可能です。また、結果を変数で受け取らなければ、リクエストした時点で、POST先のURLの出力結果が表示されます。
これを使って作った簡単な（笑）関数
function http_post($url,$postdata="",$redirect="")
{
//POSTに設定するパラメータ
if ($postdata == "")
$param = "";
else {
$param = "";
while (list($name,$value) = each($postdata)) {
if ($param != "") $param .= "&";
$param .= $name."=".$value;
}
}
//curlでPOST
$ch = curl_init();
curl_setopt($ch,CURLOPT_URL,$url);
curl_setopt($ch,CURLOPT_HEADER,false);
curl_setopt($ch,CURLOPT_POST,true);
if ($param != "")
curl_setopt($ch,CURLOPT_POSTFIELDS,$param);
curl_setopt($ch,CURLOPT_RETURNTRANSFER,true);
$res = curl_exec($ch);
curl_close($ch);
//リダイレクトがある場合はそのページへ
if ($redirect != "") {
header("Location: ".$redirect);
exit;
}
//リダイレクトがない場合は結果を表示
else
print $res;
}
POSTで送るクエリーは、$postdata["key"] = "12345"; のように連想配列で指定します。
$urlで実行されるPHPは、呼び出し側とは別セッションになります。セッションでもデータ渡しの場合、POSTクエリーにセッションIDを渡す必要があります。戻ってくると、元のセッションが保持されています。
また、この関数を a.php で実行し、ここから b.php にPOSTリクエストを送っても、アドレスバーの表示は a.php のまんまです。コードを見れば明らかですが。。。
実際にPOSTした時のように、アドレスバーに b.php が表示されると一番ありがたいんだが。。。
何気に見過ごしていたこの２つですが、どちらもUTF-8には間違いないのですが、UTF-8には、BOMがあり、UTF-8Nにはありません。
BOMとは、このファイルの形式を表すコードでファイルの先頭に付きます。UTF-8の場合、先頭に、EF BB BF （16進）のコードが付加されます。
リダイレクトでうまく動かなかったのは、header()でヘッダを出力する前に、この３バイトが出力されてしまったからです。
このコードは要る時と要らないときがあって、少なくともWebの世界では要りません。なので、UTF-8Nでファイルを保存する必要があります。また、これが無いと動かないソフト等もあるみたいです。
今さらながらにこの違いがわかりました。
通常、Web系のソフトでUTF-8というと、UTF-8Nのことを指すそうです。
そう言えば、TOPページのヘッダ画像の上に妙な空白がありました。
よくよく見てみると、この部分のMTのテンプレートがUTF-8になってました。それで余計なコードは出力さてたのです。
これをUTF-8Nに直して再構築したところ
となり、余計な空白は消えました。
以前はEUCだったのをUTF-8に変更した際、漢字コードの変換ソフトで一括変換した時に、UTF-8NではなくUTF-8になってしまってたのでしょう。
ややこしい・・・
簡単なリダイレクトのプログラムが動かない。
既にHTTPヘッダが出力されていまっせ！というエラーメッセージ
Warning: Cannot modify header information - headers already sent by (output started at /var/home/yyyy.php:1) in /var/home/yyyy.php on line 2
<?
header("Location: xxxx.php");
exit;
?>
エラーの原因は文字コードにありました。
UTF-8で記述しているのですが、使っているエディタには、UTF-8 と UTF-8N の指定があって、UTF-8 になっていた。これを UTF-8N にしたら正常に動作した。
UTF-8とUTF-8N？
これは何が違うんだ？？
PHPエディタを試してみた（今さらながら…）
PHPエディタ - フリーのwindows用php統合開発環境（IDE）
プロジェクト管理が出来るので、複数のソース一括検索が出来ることや、コードエクスプローラと呼ばれる、ソース内の関数やクラスの一覧が表示されるのが良い。VBっぽい。
構文カラーもそこそこカスタマイズ出来るのもうれしいところ。
しかしながら、プロジェクトへのファイルの追加を１つづつ行わないといけない。これがあるフォルダを指定すれば自動で取り込んでくれるといいのだが、その機能がないみたい（知らないだけかも）。
これの単なるエディタ版もある。
単にプロジェクト管理がなくなっただけで、コードエクスプローラは残っている。
案外、こっちのほうが使い勝手があるのかも。
サーバが違うとPHPの初期設定も違うので（同じにして欲しいものだが…）同じプログラムでも文字化けを起こす。
mbstringの設定をしないといけない。
主な設定項目として
（参考ページ：http://manual.xwd.jp/ref.mbstring.html）
※以前はPHPマニュアルにもこの記述が載っていたのだが、一新されてから分からなくなった。
mbstring.detect_order：文字エンコーディングの検出順序（no value）
mbstring.encoding_translation：入力されるHTTPクエリに関して内部エンコーディングへの変換を行うか？（Off）
mbstring.func_overload：シングルバイト対応の関数をmbstring関数の対応する関数でオーバーロードするか？（0）
mbstring.http_input：HTTP入力文字のエンコーディング（pass）
mbstring.http_output：HTTP出力文字のエンコーディング（pass）
mbstring.internal_encoding：内部文字のエンコーディング（no value）
mbstring.language：mbstringで使用する言語（neutral）
mbstring.substitute_character：無効な文字を代替する文字（no value）
（）内はウチのサーバの設定内容
この設定だと、言語設定を日本語にすれば、問題なく動作します。
日本語の設定
mb_language('Japanese');
それでも、他のサーバでも同じように動かすために、最初にmbstringの設定をしてしまう。
mb_language('Japanese');
ini_set('mbstring.detect_order', 'auto');
ini_set('mbstring.encoding_translation',0);
ini_set('mbstring.http_input' , 'auto');
ini_set('mbstring.http_output' , 'pass');
ini_set('mbstring.internal_encoding', 'UTF-8');
ini_set('mbstring.script_encoding' , 'UTF-8');
ini_set('mbstring.substitute_character', 'none');
セッションを使ったシステム（まぁ、システムは普通セッション使いますが）で、不思議なことに、IEだけセッションが切れてしまう現象になってしまった。
Firefoxでは正常にセッションが保持されている。
そのシステムは今回初めて使うロジックもなく、ごくごく普通のシステム。
調べてみたら、URLに問題があった。
今回は、リリース前の開発環境だったので、http://xxxx_test.yyyy.com とかいうサブドメインで動かしていた。
このサブドメインに、アンダーバーがあるのが原因らしい。
http://xxxxtest.yyyy.com にしたら、IEでも正常にセッションが保持された。
サブドメインにアンダーバーはいけない。
そう言えば、ちょっと前に、セッション名にアンダーバーを使って、smartyでうまく表示出来ないという事があった。
文字の区切りとしてアンダーバーは見やすくて、安易に使ってしまいますが、開発環境であっても、極力、アンダーバーは使わないほうがいいです。
