- ベストアンサー
「フォームメールの値の引渡しの失敗の回避」について
cgiで (A)注文画面 → (B)確認画面 → (C)終了画面 というのを作っています。 (A)で商品の内容、氏名、届け先、メールアドレス などの入力 ↓ perlプログラム 1.pl で ↓ 入力内容のチェック・確認画面への値の受け渡し (B)で入力した商品、氏名、届け先、メールアドレスの表示・確認 ↓ perlプログラム 2.pl で ↓ 送信者が入力されたメールアドレスのメールをsendmailで送信 (C)終了画面(注文のお礼の表示) この流れでメールで注文を受けているのですが (B)から(C)へ値を受け渡す時に失敗しているようで、ごく稀にエラーメールが届きます。 サーバの管理会社へ問い合わせるとsendmailの使用時にFROMがないメールだとそのエラーメールが届きますとの事。 殆どの場合うまくいくのですが、 100件に1件程度でしょうか、エラーメールが届きます。 この値の引渡しの失敗を減らす、又はなくすような対策をご存知ではないでしょうか? 文字数の制限の為、perlプログラムの内容は載せられませんでしたが 必要でしたら補足を頂いた時に載せますので そのときに補足要求をお願いします。 宜しくお願いします。
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
受取りの処理自体は問題は無いようです。 #2の方の回答のようにメールアドレスの@の扱いは気を付けてください。 恐らく、チェックの段階で解決していると思いますが・・・。 jcode.plの問題となると文字コードの問題となるので全体とデータのコードの違いに気を付けていれば大丈夫です。 ただ、(B)の受取りで &jcode'convert(*name, "jis"); となっているのはどうしてですか? ファイル全体はEUCで記述して送信直前にデータをJISに変換しておけば良いと思います。 http://www.presso.jp/text/perl/mail.html やはり、エラーが起こる状況の情報が少ないので原因の特定は難しいですね。 あとはエラー時にログを取って引き渡されなかったデータなどを取得して 同じ現象が起こるか検証して見なければならないでしょう。 あまり、お役に立てなくて申し訳ありません。
その他の回答 (2)
- mahou
- ベストアンサー率0% (0/1)
自分もその問題で困ったことがありました。 原因を突き止めて見ると、「入力したメールアドレスが変な形」の場合にエラーが返ってきてました。例えば、アドレスに@マークが入っていないとサーバーがエラーを返すんです。 これはサーバーの設定でそうなっているのでしょうが、レンタルサーバーな為、回避の使用が無かったです。javascriptで@マークを必須にすると制御するとかなりエラーは減りました。 検討違いかもしれませんが、参考になれば。
お礼
回答有難うございます。 メールアドレスのチェックは結構厳しく(?)していると思います。 メールアドレスのチェック↓ $FORM{'e_mail'} =~ /^[-_\.a-zA-Z0-9]+\@[-_\.a-zA-Z0-9]+$/ (A)から(B)への値の引渡しは上手くいっていると思うのですが (確認はできませんが・・) (C)の時点でメールアドレスが入るべきところに、何も入ってないためのエラーのようです。 ありがとうございました。m(_ _)m
- wolfwood
- ベストアンサー率50% (199/398)
>サーバの管理会社へ問い合わせるとsendmailの使用時にFROMがないメールだとそのエラーメールが届きますとの事。 FROMに入るのは入力したメールアドレスですよね。 入力チェックは前の処理で行っているようなので未入力ということはないですね。 それが正確に渡らないと言うのはそのスクリプトかWebサーバ側のバグではないのでしょうか。 100件に1件だとちょっと頻度が高めですので、そのスクリプト自体の見直しが必要です。 引渡し、受取りの方法はどのようなものでしょうか? 緊急回避的な方法ですと送信処理の直前でFROMの値をチェックしてエラーとして送信自体をやり直してもらうという方法があります。
補足
回答ありがとうございます。 >FROMに入るのは入力したメールアドレスですよね。 はい、(A)で入力して引き継いできたメールアドレスです。 >引渡し、受取りの方法はどのようなものでしょうか? (A)から(B)へ (B)のデータの受取 if ($ENV{'REQUEST_METHOD'} eq "POST") { read(STDIN, $query_string, $ENV{'CONTENT_LENGTH'}); @a = split(/&/, $query_string); foreach $x (@a) { ($name, $value) = split(/=/, $x); $name =~ tr/+/ /; $name =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1))/eg; &jcode'convert(*name, "jis"); $value =~ tr/+/ /; $value =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1))/eg; $value =~ s/[\r\n]+/\n/g; &jcode'convert(*value, "euc"); $FORM{$name} = $value; } } で(B)のhtmlに hidden で項目をもち (B)から(C)へ (C)のデータの受取 if ($ENV{'REQUEST_METHOD'} eq "POST") { read(STDIN, $query_string, $ENV{'CONTENT_LENGTH'}); @a = split(/&/, $query_string); foreach $x (@a) { ($name, $value) = split(/=/, $x); $name =~ tr/+/ /; $name =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1))/eg; &jcode'convert(*name, "euc"); $value =~ tr/+/ /; $value =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1))/eg; $value =~ s/[\r\n]+/\n/g; &jcode'convert(*value, "euc"); $FORM{$name} = $value; } } となっています。 (こんな書き方でいいでしょうか?わかりにくかったら補足要求おねがいします(^_^;) ) >緊急回避的な方法ですと送信処理の直前でFROMの値をチェックしてエラーとして送信自体をやり直してもらうという方法があります。 この方法も検討してみます。 ちょっとjcodeの変換を疑っているのですが、 もし、お手数でなければjcodeの変換についてもみてみていただけませんでしょうか? (お時間がないなど不都合がありましたら無視して下さい(^_^;))
お礼
再び回答ありがとうございます。 >&jcode'convert(*name, "jis"); となっているのはどうしてですか? ・・・本当ですね・・(汗)これが原因だったかもしれません。 (B)から(C)に引渡しすとき(B)に作成したhiddenの項目名を使って メールのFROM欄を作成していました。 (C)内メールヘッダ作成部分 $from = $FORM{'e_mail'}; ・ ・ $mailmain .= "From: $from \n"; jisと変換していたのは↑でいう'e-mail'の部分です。 もしここで、変換がうまくいかなかったとなると引渡しに失敗してもおかしくないですよね。。。? とりあえず、"euc"に変更してその後の動きを監視してみます。 >あまり、お役に立てなくて申し訳ありません。 いえいえ!こちらこそお時間を割いて回答いただきましてありがとうございます。 またどこかでコミュニケーションできることを。ありがとうございました。(^-^)