2008年07月24日
PHPからPOSTリクエストを送る
備忘録として。PHPは、4.3.9です。
1.PHPの Client URL Library(cURL)を使う。
cURLが何に使う関数なのか定かでなかったのですが、こいつを使えば、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 が表示されると一番ありがたいんだが。。。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2008年07月15日
UTF-8とUTF-8Nの違い
何気に見過ごしていたこの2つですが、どちらもUTF-8には間違いないのですが、UTF-8には、BOMがあり、UTF-8Nにはありません。
BOMとは、このファイルの形式を表すコードでファイルの先頭に付きます。UTF-8の場合、先頭に、EF BB BF (16進)のコードが付加されます。
リダイレクトでうまく動かなかったのは、header()でヘッダを出力する前に、この3バイトが出力されてしまったからです。
このコードは要る時と要らないときがあって、少なくともWebの世界では要りません。なので、UTF-8Nでファイルを保存する必要があります。また、これが無いと動かないソフト等もあるみたいです。
今さらながらにこの違いがわかりました。
通常、Web系のソフトでUTF-8というと、UTF-8Nのことを指すそうです。
そう言えば、TOPページのヘッダ画像の上に妙な空白がありました。

よくよく見てみると、この部分のMTのテンプレートがUTF-8になってました。それで余計なコードは出力さてたのです。
これをUTF-8Nに直して再構築したところ

となり、余計な空白は消えました。
以前はEUCだったのをUTF-8に変更した際、漢字コードの変換ソフトで一括変換した時に、UTF-8NではなくUTF-8になってしまってたのでしょう。
ややこしい・・・
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
Cannot modify header information
簡単なリダイレクトのプログラムが動かない。
既に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?
これは何が違うんだ??
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2008年07月13日
PHPエディタを使ってみる
PHPエディタを試してみた(今さらながら…)
PHPエディタ - フリーのwindows用php統合開発環境(IDE)
プロジェクト管理が出来るので、複数のソース一括検索が出来ることや、コードエクスプローラと呼ばれる、ソース内の関数やクラスの一覧が表示されるのが良い。VBっぽい。
構文カラーもそこそこカスタマイズ出来るのもうれしいところ。

しかしながら、プロジェクトへのファイルの追加を1つづつ行わないといけない。これがあるフォルダを指定すれば自動で取り込んでくれるといいのだが、その機能がないみたい(知らないだけかも)。
これの単なるエディタ版もある。

単にプロジェクト管理がなくなっただけで、コードエクスプローラは残っている。
案外、こっちのほうが使い勝手があるのかも。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2008年07月05日
mbstring関係の設定内容
サーバが違うと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');
UTF-8でコードを書けば、入力文字もUTF-8、出力文字もUTF-8です。携帯サイトはSJISで書くので、それはSmartyのテンプレートをSJISで書いて、表示文字だけUTF-8からSJISに変換するだけでOK。
それでも、他のサーバでも同じように動かすために、最初に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');
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2008年05月16日
IEでセッションが切れる
セッションを使ったシステム(まぁ、システムは普通セッション使いますが)で、不思議なことに、IEだけセッションが切れてしまう現象になってしまった。
Firefoxでは正常にセッションが保持されている。
そのシステムは今回初めて使うロジックもなく、ごくごく普通のシステム。
調べてみたら、URLに問題があった。
今回は、リリース前の開発環境だったので、http://xxxx_test.yyyy.com とかいうサブドメインで動かしていた。
このサブドメインに、アンダーバーがあるのが原因らしい。
http://xxxxtest.yyyy.com にしたら、IEでも正常にセッションが保持された。
サブドメインにアンダーバーはいけない。
そう言えば、ちょっと前に、セッション名にアンダーバーを使って、smartyでうまく表示出来ないという事があった。
文字の区切りとしてアンダーバーは見やすくて、安易に使ってしまいますが、開発環境であっても、極力、アンダーバーは使わないほうがいいです。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2007年10月09日
PHP暗号化ソフト CODELOCK V2
PHPの暗号化ソフトの CODELOCK V2 のお試し版を使ってみた。
PHPの暗号化ソフトはいくつかあり、このCODELOCKの最大のメリットは、価格が安い点。
ナント、6,200円で、ライセンス無制限で使えてしまう。
こんなに安くていいんだろうか???と思いつつ、15日の評価版をダウンロードして早速使ってみた。
圧縮されたファイルを解凍して、サーバにアップロードする。IISでPHPが動く環境なら、サーバにアップロードする必要はなく、ローカルマシンでも動かせる。
簡単な使い方ですが、まず、unlock key のところ(赤枠)に暗号化に必要なキーを入力します。3文字以上の英数字を入れます。Ask for key のところ(青枠)は No を選択します。Yesのままだと、PHPが動いた時にキーの入力を要求されます。「Next」をクリックします。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2007年04月27日
掲示板(BBS)英文SPAM対策
ずっと以前に作ったPHPの掲示板が、常に、英文SPAMの標的になっていた。
掲示板のデータはデータベースに書き込むし、書き込みお知らせメールも送信している、その上、送信先のアカウントでは、SpamAsassinが動いているので、どう考えても、サーバのリソースの無駄使い。
そこで、PHPで英文SPAMをはじくように修正。
件名に日本語が入ってなければ、書き込みNGとした。
//日本語が含まれていればtrueを返す
function is_japanese($arg)
{
$r = false;
$c = strlen($arg);
for($i = 0; $i < $c; $i++){
$chr = ord($arg[$i]);
if((0x80 < $chr)){
$r = true;
break;
}
}
return $r;
}
件名でも投稿者でもいいので、POSTされた文字列をこいつでチェック。
false(英文のみ)だったら、エラーで書き込みしない。
■参考エントリー
簡単な BBS spam対策
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2007年04月18日
PHPで配列の中身を見る
print_r() でもいいんですが、どうも、横にずらずら表示されるので、見難い。
なもんで、
function display_array_data($data,$pre="")
{
while(list($key,$val) = each($data)) {
if (is_array($val))
display_array_data($val,$pre."[".$key."]");
else
print $pre."(".$key.")->[".$val."]<br>";
}
}
最近、ブログがメモ変わりになっている・・・
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2007年04月07日
SNSとのセッションの競合 PHPSESSIDの変更
SNSやXOOPSを入れたサイトに新しくシステムを作る場合や、SNSとXOOPSが同居するサイトでは、よくセッションの競合が起きる。
オリジナルのCMSとかは、ログイン情報を保持するためにセッションを使いますが、そうすると、SNSにログイン出来なくなったり、いろいろと面倒な部分があります。
IEだと、2つ立ち上げた時はそれぞれのセッションIDは違うので、こういう問題も起きない(起きにくい??)のですが、Firefoxだと、別のタブでも、別のウィンドウでもセッションIDは同じなので、もろ、この問題にあたります。
こういう場合は、セッションの名前をそれぞれ別にすると解決します。
phpinfoで見てみると、session.nameがPHPSESSIDとなっているので、PHPの先頭で
ini_set('session.name',HOGEHOGE);
と別の名前を指定します。
これで、セッションの名前が別になるので、競合は避けられます。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
MySQLの文字化けを直す
MySQLで文字化けで解決したかに見えた文字化け問題ですが、テストデータベースから本番データベースに移行した際に、再び、「?????」の表示になった。
どうも、データベースを作成した際の文字コードが違っていたらしい。
コマンドラインから mysql を上げ、以下のコマンドを実行。
show create database データベース名;
テストデータベースは、DEFAULT CHARACTER SET utf8 と表示されるが、本番データベースは、DEFAULT CHARACTER SET latin1 になっていた。そもそもデータベースを作成するところが違っていた。
phpMyAdminでデータベースを作る際の指定がなってなかった。
照会順序を、utf8_general_ci というやつにしないといけない。
まずは、phpMyAdminの「操作」タブの一番下のところで、照会順序をutf8_general_ciにする。
テーブルを作成する際、テキスト系の型(textとか)の照会順序は、デフォルトでこの照会順序が使われるみたいです。
そこで、テーブルの列の照会順序も変更します。そもそも、ここがutf8_general_ciになっていないことが、文字化けの根源です。ここがutf8_general_ciになってないと、いくら set names utf8 を指定しても文字化けは直りません。
それか、テーブルをcreateする際に、しっかりと、
DEFAULT CHARSET=utf8
と、文字コードを指定することです。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2007年04月04日
MySQLで文字化け
このブログに文字化けという事を何回書いただろうか・・・
今回も、MySQLの文字化けで、2日悩んでしまった。
PHPもMySQLもUTF-8。そのシステムのデータをちょこっと利用するので、新しくPHPを書いたら、文字化け・・・
もちろん、UTF-8で。
mb_convert_encodingばかり疑ってた。同じ文字コードなので、余計に分からなかった。
ドツボにはまるとこんなもんである。
いろいろ調べたら、
http://wota.jp/ac/?date=20061011
なサイトを発見。
おや・・・
どこかで見たことがあるような内容だ。
どこだ!どこだ!どこだ!
| この記事へ | コメント (1) | トラックバック (0) | 先頭へ
2007年04月01日
アマゾンのようなパス
PHPでは、一般的にクエリーは、
hogehoge.php?a=1&b=2&c=3
のように書く。そして、プログラムのほうでは、$_REQUEST["a"]とかで、クエリー文字列を得る。
会員のページを表示する時は
member.php?id=1000
とかって。
前々から思ってたことで、これだと、じゃ、1001番の人は誰?って言うんで
member.php?id=1001
とアドレス欄に入力してた。
つまり、URLのクエリーを見れば、容易に、そのクエリーの意味がわかってしまうわけである。
アマゾンのサイトを見てみよう。
このサイトもどう考えても、データベースばりばりのサイトなのだが、上のような一般的なURLではない。?や&が一切見当たらない。まさか、こんな深い階層に実際のページがあるもと思えない。
これは一体、どうやって実現しているのか?
先の例で言うと
member.php?id=1000
を
member/1000/
でアクセス出来ないのか?
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2007年02月28日
PostgreSQLの設定
書類を整理してたら、メモ紙に、PostgreSQLの設定が書いてあった。
そのまま捨てるのもアレなんで、Todo(笑)
正しいのかな。。。
■データベースにアクセスするPostgreユーザの作成
postgresユーザで
$ createuser --pwprompt
これでパスワードが付けられる
■Postgreデータベースの作成
$ createdb xxxxx
■psql
$ psql xxxxx;
grant all on データベース to ユーザ;
これは、そのユーザがデータベースのアクセスを許可するってこと。
以上、今見ても、よくわかんないメモでした。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2006年12月15日
PHPからPostgreSQLにつながらない
ウチのサーバは最初からPostgreSQLがインストールされている。
phpPgAdminは後で入れましたが。
早速、PHPからアクセスしたら、これがつながらない。。。
今まで使ってきたサーバは、ちゃんとお膳立てしてあったからなぁ。。。と思いつつ、原因を探る。
いろいろ調べてみると、どうやら、pg_hba.confの記述に問題があったみたい。
インストール直後の状態では、ローカルからの接続が出来ない設定になっていた。
(そりゃないだろ・・・と思ったが)
そこで、この1行を追加した。
local all all trust
とりあえず、これで動くようになった。
よかった!よかった!と言いたいところだが、別サーバのシステムを移行するので、また新たな問題が発覚するかも。。。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2006年10月27日
IIS+PHP環境で、fopenでPermission denied
長いタイトル(笑)
マイマシンは、WIndowsXPで、IIS上でPHP動かしてるんですが、PHPのfopen()で、Permission denied と言われてしまった。
そう言えば、このマシンに変えた時、同じようなことがあって、なにがしかの対処をしたんですが、、、もう、すっかり忘れてしまった。
ググってみたら、よく似た悩みをもった人のページにたどり着いたが、肝心の対処の方法が書いてない。
なんちゅうヤツや!
書いとけっ!
で、よくよく見てみたら、見覚えのあるメールアドレス。。。。
あれ?これ、ワシや!!!
昔昔も同じようなことで悩んで、MLの投稿した時のだ。
全然、進歩してねぇ~なぁw
| この記事へ | コメント (2) | トラックバック (0) | 先頭へ
2006年06月03日
WindowsでPerlが動かない
Windows上で、Perlのプログラムを動かそうとしたら
The specified CGI application misbehaved by not returning a complete set of HTTP headers.
というメッセージが出る場合があります。
同じCGIをLinuxサーバでは全然問題なく動くのに・・・
Windowsの場合、Perlプログラム(CGI)の設置ディレクトリと、実行時のディレクトリが異なる場合があります。
これが原因です。
Perlの場合、ほとんどと言っていいほど、
require './jcode.pl';
を記述します。Linuxの場合は、CGIがあるディレクトリでそのCGIが動くわけで、同じディレクトリに jcode.pl を入れておけばいいのですが、Windowsの場合は、上記の理由により、CGIがどこか別のディレクトリで動く場合があります。とすると、jcode.pl は、その動くディレクトリに入れておかないとダメということになります。
そのディレクトリに入れれば、いいわけなんですが、Perlのプログラムの中で解決するとなると、プログラムの最初に
chdir("Perlのプログラムを設置したディレクトリ");
と書きます。ディレクトリは、例えば、C:/Inetpub/wwwroot/abc のように書きます。
これにより、このプログラムは指定したディレクトリで動き、正常に動作します。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
2006年04月20日
WindowsにPHPをインストール(サーバ機編)
WindowsサーバにPHPをインストールした。WindowsにPHPをインストール(正解)で一度やっているので、同じようにやったが、うまく動かない。。。やはりサーバ機となると違うのか。。。
以下、サーバ機への手順です。手順1~4までは、正解編と同じです。
"WindowsにPHPをインストール(サーバ機編)"の続きを読む
| この記事へ | コメント (3) | トラックバック (1) | 先頭へ
2006年04月10日
Radishを使って、自Windowsからメール送信
Radishという、Windows用のメールサーバをインストールした。
インストールと言っても、ダウンロードした圧縮ファイルを解凍するだけである。
特に何も設定せずに、起動する。タスクトレイにアイコンが表示される。
ここと同じソースでメールを送信してみる。
注意点は2点。
・php.iniは元通りに戻す。(このように変更した場合)
・IISの仮想SMTPのサービスを止める。IISで■ボタンを押すだけ。
これで、自マシンからメールが送信出来ます。プロバイダやレンタルサーバのSMTPの制限が厳しい時使えます。特に、大量にメールを送る場合(メルマガとか)で、サーバ屋からイエロー食らう心配もありません。
今回のテスト用に入れたが、ずっと使おう。
Radish
http://homepage2.nifty.com/spw/software/radish/
ドキュメント
http://www.asahi-net.or.jp/~NM4M-KRD/Radish/doc/
| この記事へ | コメント (2) | トラックバック (0) | 先頭へ
mb_send_mail() の呼び出し方
Windows+PHPの環境で、以下のように、mb_send_mail を使えば、php.iniで指定したSMTPを使って、メールを送信出来ます。
この書き方は、どういうプラットフォームでも同じだと思います。
$header = "From: ".$from."\n";
mb_language("Ja") ;
mb_internal_encoding("EUC");
$ret = mb_send_mail($to,$subject,$body,$header);
PHP4では、mb_language("Ja") ; をすることで、適切な Content-Type および Content-Transfer-Encoding ヘッダが生成されます。PHP5では、再定義も可能なようです。
mb_send_mail
http://www.php.net/manual/ja/function.mb-send-mail.php
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ
WindowsでPHP使ってメール送信
を試みているんですが、メールサーバも何もインストールせずにやってみた。
結果、php.iniのパラメータを変更すれば、送信可能となった。どこかのSMTPサーバを使うやり方です。
php.iniの
[mail function]
; For Win32 only.
SMTP = localhost
; For Win32 only.
sendmail_from = me@localhost.com
を変更します。
[mail function]
; For Win32 only.
SMTP = どこかのSMTPサーバ(プロバイダとか)
; For Win32 only.
sendmail_from = メールアドレス
これに変更すれば、そのSMTPサーバを使ってメール送信できます。
sendmail_fromはどう使われているのか、わからずです。
でも、IISのSMTP使って送れないものかなぁ。。。
| この記事へ | コメント (0) | トラックバック (0) | 先頭へ



