☆ショッピングカートのCGIを作りたい！Perlで☆

知り合いにWEBショップ作ってくれと頼まれたのは良いけど、
フリーのショッピングカートCGIは設置は簡単でも、商品の登録
とかが手作業だったりで使い勝手が悪いです。
で、短絡的に「自分で作ってみようか」と思っているのですが・・・・
Perlも、いやプログラミングさえ未経験。「必ずわかるCGI」と
その他の入門書で何とか「掲示板」の仕組みがようやく理解できました。
やっぱ、無謀ですかねぇ・・・・・・

http://headlines.yahoo.co.jp/hl?a=20020118-00000006-imp-sci
無理して作らなくてもこの辺使えば？
>>114のサイトでも十分だと思うがな。
自作にこだわる理由て何？。
商品登録の使い勝手が悪いというなら既存のショッピングカートCGIの商品情報を
GUIで設定するアプリをＶＢ当たりで作った方が早いぞ。

>>156 に禿げしく胴衣
そのほうが絶対楽。

クレジット決済効かない職種だったりしてな。
それにしても、クレジット手数料、ピンハネしすぎ。

>>1
うちでは、1のいう tmp ファイルをお客さんごとに作ってる。
途中で買い物やめた人の分は、時間で消してる。
PHPだけどセッションは、hiddenで持ち回り。
クッキー使うと i-mode 使えないから。

>>154に同意

>159
うん、クッキーはだめだよね。
よそのサイトからスクリプト投げられるのはどう防いでいます？

うちもPHPで格闘中。

>>106
ホントに夜のrootがウヨウヨしてるとしたら、よっぽどヤバイ鯖？
でも、まぁ共有鯖は危険なことは同意。せめて、置き場所と権限はキッチリしないとね。

>>1
初プログラムがカートはやめたほうがいい。せめて小さいものを１０コぐらい作ってからにしたほうが、時間の効率的利用になると思われる。
イマはまだマシ。部分ごとにカンペキにしていっても、全体動作がうまくいくとは限らない。大きなプログラムは虫取りが大変だぞ。

いまおれもPHPの開発だ！最初はとっつきにくかったがなれればOK!
おとなげなくおこってしまったが、
>>161

にかかれているように、段階を踏んでPGを勉強していったほうがよいとおもわれる
PGって積み重ねていくものだからね！>>1
>>156
おれも同意する！おれはVB嫌いだが・・・そっちのほうがはやいかもよ！

Perlによるセッション管理の難しさ、俺も痛いほどわかるぜ・・・。
ちょっとgoogleで旅してくるかな

いろいろレスありがとうございます。
＞自作にこだわる理由て何？。
う〜ん・・・前前からCGIを作れるようになりたいと思ってたんですが
掲示板とかカウンターとかは自分のHP作る際もフリーので満足できちゃって
きっかけが無かったんです。で、今回のがきっかけになっただけで・・・

どちらにしろ、いろいろ寄り道しながらperlを勉強していきたいと思ってますので、
お暇な方は今後とも激励、お叱り、罵倒などいただければ幸いです。

さて、セッション管理の件ですが、とりあえず「Cokieを使う」という検討を付けたのですが、
セッションID発行する際って一般的にはどうしてるんでしょう？調べてみると
Perl自体にはユニークなIDを発行する関数が無いみたいなので、環境変数を利用
して生成するようなのですが・・・取得できる環境変数の中でユニークな値って
いうと、IPと時間でしょうか？

＞GUIで設定するアプリをＶＢ当たりで作った方が早いぞ。
平行して既存のフリーのCGIに使うページ生成のプログラムをAccessで作り始めてます。
どうせなら、こっちを先にPerlで作ってみようかな・・・・

つうか １には無理
まずは １は掲示版CGIでもつくってなさいってことよ
単なる掲示版でも荒し対策とか色々細かいこと考えると結構大きなプログラムになるぞ

しかし、１ってプログラムの経験がないとか言う割には
そうでもなく感じられるようなことも書いてるね。
VBAは使えるの？

>VBAは使えるの？
VBAを使える、というかアクセスのマニュアル本見ながらどうにかこうにか
簡単なものが作れる程度です。アクセスってその気になればMACROだけでも
かなり複雑なことやらせられるし・・・・
「よーし、パパプログラム作っちゃうぞ！！」って言いながら
エクセルのマクロ得意げに組み合わせてるおじさんとかわらんレベルです。

ここまで来て、疑問なんですが。
プログラムをしたこともない素人に頼む知り合いって
なかなか理解に苦しみます。
商売を舐めてるのでしょうか？ｗ

ていうか、たかが２ちゃんの書き込みに、いちいち詮索入れるってのも
不思議で性がない。
ネタならネタで乗ってあげるか、放置できないのか？

>>165
>Perl自体にはユニークなIDを発行する関数が無いみたいなので、環境変数を利用
>して生成するようなのですが・・・取得できる環境変数の中でユニークな値って
>いうと、IPと時間でしょうか？

ユニークな値が欲しいなら、現在の時間と、プロセスIDを組み合わせる
のが定石かな。プロセスIDは、$$と書けば得られる。
実行中のプログラムに割り当てられるIDで、同時に同じ値が割り当て
られることはない。知ってるかもしれんが。

時間はtimeとかなんとか書けば、エポック秒が得られるだろ。
マイクロ秒まで出す方法があったはずだけど、忘れた。

プログラムの内容にもよるけど、大半この組み合わせでいけるでしょ。

> 171
> マイクロ秒まで出す方法があったはずだけど、忘れた。

実は知らないんじゃないの？

>172
いや、実は知らなくってもちっともかまわない(笑)

>>165
apacheが生成してくれるの使えば?

最初に見たときは糞スレだと思ったけど、>>1の根気とチャレンジ精神で
良スレになりつつある予感。PGには必須の資質なので頑張ってくれ。

>>172
モジュール入れないとダメだった。他の方法は知らん。

use Time::HiRes;
$time = Time::HiRes::time;

どんな内容でもレスがつくのがありがたい限りです。
>>169
単にHPの作成頼まれただけです。一応既存のカートでOK貰って
ページ自体は完成してます。プログラム作ろうと思ったのは単にきっかけ
になったに過ぎません。極端に言えば作る必要性は無いんです。

で・・・
$id=$$+time()でユニークID作って、cookie渡して
split(/\=/,＄ENV{'HTTP_COOKIE'})で埋め込まれたID参照して
これが無ければcookieを渡す、もし有るようなら{取り出したID}.dat
ていうファイルを作ってその後の処理をさせようと思ってるんですが、
方法的にはこんなんで良いんですかね？

process ID + time で unique だと思ってると mod_perl ではまるよ。

>>176
OK,OK

失速気味age
ここまでよくがんばった！

クッキー・・・
if ($ENV{'HTTP_COOKIE'} eq ""){
&set_cookie
}
print "content-type: text/html\n\n";
print $ENV{'HTTP_COOKIE'};
ってやると、もともとクッキーがあるときは＄ENVを表示するんですが、
持ってないときは&set_cookieでクッキーをセットしてるはずなのに
表示してくれません。リロードすれば表示するんですが・・・
ちなみにサブルーチンはこんな感じです（変数省略）
sub get_cookie{
$cookie="set-cookie: Tscart=$cid; expires=$gmt; ";
print <<EOF;
$cookie
EOF
}

set-cookieした次のアクセスからクッキーが使える。

う〜ん、本当にがんばってるね。
陰ながら応援の機会を伺うとしよう。

>>180
>>181にも書いてるけど、1セッションで一発読み書きは出来ない
そこにくる前(Top辺りで)、コッソリとダミーのCookieを仕込んでおいて
そいつを読んでクライアントのONOFFを確認するっつのが常套手段

>>181,183さん
なるほどですね。>>183さんの方法は考えたんですが、Cookieに
埋め込むIDでその後の処理を管理する予定なので、どうしようかと・・・・

で"$cookieのID.dat”を定義するのに
以下のような方法で解決できたっぽいんですが・・・

$ctime=time();
$cid=$$+$ctime;#クッキー用ＩＤ

if ($ENV{'HTTP_COOKIE'} eq ""){
&set_cookie
$cart="$cid"."\.dat";
}
else{
@id=split (/\=/,$ENV{'HTTP_COOKIE'});
$cart="$id[1]"."\.dat";
}

クッキー食わない奴がいるから、最初にチェックしたほうが良いと思われ。
操作した後に駄目でしたはイラツキの原因。
後、クッキーはセッションクッキーで充分だろう。

とりあえずクッキーに関しては>>185の方法で一応動作してるようなので
その方法で進めてみます。>>186さんの進言に関しては後々方法考えてみます
で、普通のクッキーとセッションクッキーの違いって？

さて、またひとつ問題が発生してるのでどなたかよろしければご教示ください。
データの削除に関してですが、現在.datの中身が
$id\t$hoge\t$mona\t$giko\n
$id\t$hoge\t$mona\t$giko\n
$id\t$hoge\t$mona\t$giko\n
・
・
・
というようにタブ区切りで一行づつ格納されています。でこの中の
たとえば３行目を削除したい時なんですが、画面表示するときに
open(FH,$file);
@line<FH>;
close(FH);
foreach$list(@line){
@item=split(/\t/,"$list")
}
として、各要素をテーブルで区切って表示した上で
画面上に各行ごとにフォームボタンを作り、Hideenで削除用のキー（=＄ID）を入れています。
で削除ボタンを押した時にそのキーに対応する$idを持った行を丸々消したいんですが・・・
いろいろ試してるんですが、ファイルの中身が全部消えちゃったり・・（鬱
<FH>で呼び出して、foreachで配列に格納して$id＝削除キーだったら
その配列を消して、残りの配列をまた\n区切りの変数にもどして.datに格納・・・
みたいな事を考えたんですが・・・

>187

$i = 0;
foreach (@line) {
($id,$hoge,$mona,$giko) = split(/\,/,$_);
if (削除キー eq $id) { splice(@line,$i,1); last; }
$i++;
}

削除キーには、削除ボタン押したときに飛ばされる値を指定する。

やっぱりこうやって見てるとＤＢ使った方が楽だよね（わら

>189
禿同。
セッションIDだけhiddenで渡しておいて、あとは全部DB任せ。
この方が絶対楽だね。ソートするにせよ、合計金額を出すにせよ
全部DB任せ。こんなに楽な方法ばかり普段使っていると
>1が凄いことをしているように見えてくる・・・

>>190
だよね（わら
久しぶりにファイル操作スクリプトみたんで懐かしいよ。

>>1さん
エラー処理はきちんとしましょうね。
クッキー渡すときも、ファイルを開くときもね。
あとデータ受け取ったときもサイズとか中身のチェックいれとかないと
だめだかんね〜♪
全ての人間がフォームに従って入力してくれるとは限りませんから。

>>188
ありがとうございます。試してみます。ってやってみたけどいまいち
うまくいかん・・スクリプトの意味もう一回良く見ながら考えてみます。
>>189-190
DBでMySQLとかでしょうか？
私が借りてる鯖（共用）は使えるようになってるみたいなんですが、
一般的にはどうなんでしょ？置く鯖が決まってればそれにあわせた
仕様で書けば良いんでしょうが、出来るだけ汎用性のあるものを
書きたいので・・・・もしDBが鯖依存でなくてPerlが使えれば
必ず使える、とかUNIX系の鯖ならほぼ大丈夫ってものなら
勉強してみようと思うのですが・・・

↑
×DBでMySQLとかでしょうか？
○DBってMySQLとかでしょうか？

>192
いいところ突きまくり・・・

>192
最近は安い共用鯖でもMySQLとかPostgreSQLを使えるところが
増えてきているから、汎用的だって判断しても良いんじゃない？

漏れはDB使えない（使わない）って仕事を受ける時は、それだけで
料金５割増にしてる（ｗ　しかも最近はPHPとかJavaを使うことが
多いんで、「Perlで書いてね」なんて言われたら、さらに５割増（ｗ
最低限DBが使える鯖に移転することを強く薦めている。

フリーでばらまくならPerlでファイル操作で構成しておく方が
汎用的と言えるだろうが、作るのが面倒だよなぁ。
漏れの場合は、過去に使ったクラスを使いまわして自分の中で
汎用的にするだけだな。もちろん、客には「１から作りました」
と言って、「あっという間に作ってくれましたね」と言われて
喜ぶのが好きだけど（ｗ

えっと・・>>188を試しているんですが、これの意味って
$i = 0;#行数カウント用の初期設定
foreach (@line) {
($id,$hoge,$mona,$giko) = split(/\,/,$_);
if (削除キー eq $id) { splice(@line,$i,1); last; }#もし削除キー=$idだったら、@lineの$i個目（つまりファイルの$i行目）を空にする）
$i++;
}
って事で良いんですよね？

>196
うん、その通り。

>196
あ、ちがうよ。
空にするんじゃなくて、その行削除ね。

いろいろ試してみて近いところまで来てると思うのですが・・・
open(DEL,"$cart");
@dl=<DEL>;
close(DEL);
$i=0;
foreach $line(@dl){
@cell = split(/\t/, $line);
if ($cell[0] eq "$del") {
$line="";
}

@del=join("\n",$line);
close(DEL);
#ここまで@delには削除済みのリストが入ってるのを確認
#その後
open(FH2,">>$cart");
print FH2 @del;
close(FH2);
}
で書き込もうと思ってるんですが、>>でやると元のリスト＋（元のリストー削除した要素）
が追加されちゃうし、>でやるとなぜか、もとのリストが全て消えて、削除すべき要素だけがファイルに書き込まれてしまいます。
＠delで欲しいリストは完成してるので、あとはファイルに書き戻すだけだと思うのですが・・・

>199
なんでそんな苦労をしているんだろう・・・・

open(IN,"$cart");
open(TMP,">${cart}.tmp");
while(<IN>){
my @cell = split/\t/;
if($cell[0] ne "$del"){
print TMP;
}
}
close IN;
close TMP;
rename(${cart}.tmp,$cart);

でどうよ。

んじゃもっと短くして・・・

open(IN,"$cart");
open(TMP,">${cart}.tmp");
print TMP grep { ! /^$del\t/ } <IN>
close IN;
close TMP;
rename(${cart}.tmp,$cart);

grep使うのは別におすすめしないけど、
判定のためだけにsplitする必要はないかと。
というか、素直にApache::Session使えばいいのにと思ったり。

>>201
最初、うまく行かなかったんですが、renameのところを変えたら
うまくいきました↓
open(IN,"$cart");
open(TMP,">$cart.tmp");
while(<IN>){
my @cell = split/\t/;
if($cell[0] ne "$del"){
print TMP;
}
}
close IN;
close TMP;
rename("$cart\.tmp","$cart");
ありがとうございました。

>>202
$id（＝削除キー）が単純に振られた連番（数字）なので、配列で
確実に指定してやったほうがいいかな・・・と。grepも使いかた調べたんですが、
個数とかの数字を拾っちゃいそうな気がして・・・
☆進捗状況
おかげさまで、
・買物カゴに入れる
・カゴの中身を削除する
の部分は動作するようになりました。皆様の助けが無ければとても10日でここまでは
出来なかったと思います。ありがとうございます。
次の予定は、個人情報の入力画面です。
・・・と、思い出したので質問です。非常に基本的なことだとは思うのですが、
cookieって有効期限内でも、新たに渡せば上書きされるんですかね？
買物カゴで渡したcookieを個人情報画面で、書き換えたいんですが・・
てかそういう場合って新たにクッキー渡すんですか？

もう解決ずみみたいだけど。

>で書き込もうと思ってるんですが、>>でやると元のリスト＋
>（元のリストー削除した要素）が追加されちゃうし、
> でやるとなぜか、もとのリストが全て消えて、
> 削除すべき要素だけがファイルに書き込まれてしまいます。

>> で開くのは、追加書き込み。ファイルは安全。
> で開くと、ファイルサイズがゼロになる。ファイルのデータは失われる。

ファイルロックを併用で、ファイルから読んだあと同一ファイルに
書き戻したい場合は、読み+書き（+<）で開くのが一般的かな。

該当ファイルが存在しない場合は、ファイルを作ってはくれないが。

>>203
クッキーの上書きだァ？
それ位調べろってんだよヴォケ！

>>205
数少ない自分が知ってるネタが出て来てよかったね　ﾎﾞｸちゃん
早く病院に戻りなさい

とりあえず今までのスクリプトどこかにＵＰしてみ
添削してくれるぞ、きっと

>>207
今、個人情報の入力＆その処理、の部分を書いてるので、それが終わったら
どっかにアップしてみます。垢とってこなきゃ・・・
もう、自分で処理内容を忘れないためのコメントが各所、各行に入りまくりの
ソースなんで恥ずかしいんですが、なにぶん2週間前までは「配列って何？」
っていう人間が書いているものなのでその辺はご容赦ください。
今日の夜くらいにアップできればと・・・

>>208
ソースパクって明後日ぐらいからシェアウェアとして
配布させてもらいます。w
プログラム名は、SuperCart2002です。
早めにうｐして下さいね。

ココまで伸びてきていてなんだが‥‥

>>65
>えっと最終的にイメージにあるのは、来訪者（客）が各売場（ページ）で
>任意に商品をカートに入れていって、最終的に注文ボタンを押すと
>その内容が管理者（店主）と客注文明細のメールが行く、というものです。

以前作ったことがあるぞ、それ。個人商店向けで、ほとんど同じ仕様。
メール送信だけPerlでSendmail叩いて、あとJavaScript。

あ、商品ページは商品と単価はtextであげといてCGIから書かせたけどね。

＃これなら途中で放棄してジャンプされてもカンケーなしだね。

ID/Pass発行して再ログインとか考えないなら、これで十分かもよ。

>>209
つうか、ここの住人の方ならパクらないでも数時間で書き上げる内容じゃないかと・・・（ｗ

>>210
javaScriptも触ったこと無いんで、スクリプトを書くという意味では、結局はどっちではじめても同じだったのかも
知れません。ただ、とっかかりが「既存のショッピングカートに商品ページ作成機能があればなぁ」
だったので、何も考えずにPerlでCGIを始めてしまいました。
しかし・・・普段HP作る時はDWとかばっかりだったんで、CGIの中のHTML書くのにタグが
わからず苦労してたりします(苦笑

クッキーは正常終了する場合消しとけよ、意味は自分で考えろ。
途中終了の場合は仕方ないがそれでも退室ボタンなどで消せるようにしとけ

>タグがわからず苦労してたりします

ドリウィで満足行くまでデザインして、ﾊﾟｸれ。

商品ページ作成機能ってなに？
イメージが湧かない

>>212
はい、最終的にマイナス時間で渡して消すつもりです。
>>213
いやそのつもりではいるんですが、現段階DW立ち上げてると重くて効率
悪いので、手で打ってます。ある程度目処がついたらデザイン面は見直そうと思います。
>>214
究極で言うと、楽天みたいにWEB上で全てのページが作れてしまう機能とでも言いましょうか・・・・


http://www.xrea.com/に垢取ってアップしたけど動かん・・
ローカルはもちろん自分の借りてる鯖でも動いたんですが・・・・・

>>215
ああ、そういう機能ね。わかりました。
うちのは、エクセルからコピペして終わりだから
そんなこと考えたことなかったです。

>>211
初心者ですが、質問です。
JavaScript のカート、フリーのやつ
見たことあります。
フレームのindex.html の部分に、
プログラムが書いてありました。
あれって、フレームなしじゃ、
できないもんなんですか？

>>217
>フレームなし
JSの諸事情で、商品が複数ページに渡る場合、正直フレームにしないと
辛いな。

カート（このスレでの実装の場合、単なる送信フォームだが）と、
商品ページあわせて一枚なら、問題ないね。（ECサイトまで行かない
小さいショップのサイトの通販ページなんかで、この一枚タイプは
結構見かけるよ）

複数ページでフレーム避けたいなら、途中退場処理のコストを払っても
やはりカートをサーバーサイドに置いたほうが楽だと思われ。

ただ、JavaScript使用を前提とする場合、フレームを嫌う理由はあまり
ないね。この辺はクライアントの意向によるな。

  あげ。

そろそろあきらめたかな？

そろそろあきられたかな？

あきらめてないです。なんとか・・・
一応sendmailでメールを送信するところまでは漕ぎ着けました。
まだ、文字化けしたり、mailに必要な内容が反映されなかったり
とかありますが・・・・・それが解決したら次はページ作成用の
スクリプトに着手です。

いつのも間にかどんどんすすんでるね！
がんばれよ>>1

がんばれよ。

日本語は本文はベタにISO-2022-JPだが、
subjectのエンコードはけっこうめんどくさいんだ。

>>224
原理主義者で無ければ全部MIME::Base64しちまえば良いだろう。
これで困るMUAある?

日本語コードって難しいですね・・・・
本とか読むと”EUCで書く”って書いてあり、フォームから取得したデータを
&jcode::convert(*form, 'euc');でデコード、でsendmailに送る時は
&jcode'convert(*name, 'jis');って書いてあるんですが、それでやると
表示が文字化けしたり、送られたメールが文字化けしたり・・・・
でいろいろ試した結果、スクリプトをsjisで保存、フォームでコードは
&jcode::convert(*form, 'sjis');メールはjisでデコードしたら今のところ
うまく行ってます。ちなみにw2k＋IE6での検証です。あとはWinのNNと
MACでIE&NNを試してみないと・・・・

うんこすけーぷ4.xのヤロウ、たまにエンコード間違えやがるから、
確実にjis/sjis/eucを判定できる文字を各フォームに突っ込んどいて、
jcode.plかなんかで判定、convertんとき元コード指定せんと、テストで
上手く行ってても稼動させてしばらく経ったらクレームがなんて事が。

# 昔はまったな、これで。

charsetもHTTPヘッダ、METAで両方吐き出しとけ。念には念だ。

>>215
アップされるのを待ってるんだが。

>>226
gooとかhotmailとかの有名どころも
アカウント取って検証した方がいいよ。
以前 goo ではまったことがある。

ｽｲﾏｾﾝ。どうしてもxrea.comで動かないんです・・・・・
他のところで垢とって試してみます。

困ったらとにかくへろぅわぅうど!
#!/usr/bin/perl #サーバにあわせりゅ
print "Content-type:text/plain \n\nHelloWorld.";
exit;
をｳﾌﾟだ。
これが動かないなら設置/設定方法が悪いかCGIが使えないかどっちかだな。

flockやsymlink、スクリプト本体より上のディレクトリにアクセスしてる
場合なんかもサーバによっては引っかかるぞ。

なにげに人気のあるｽﾚだな。
何でだろう？

>>232
1のマメなレスと、微妙なｼﾞｻｸｼﾞｴﾝによるものであろう。

これ自作慈円？なの？

>>234
なんか>>1が叩かれても逆切れせず、氏ったかもしないで真摯にｶﾞﾝﾊﾞｯﾃｲﾙから、
漏れはいくつか応援出したじょ。

#なんか自分がPerlいじりだしたころを思い出すんだよな、このｽﾚ。

先の鯖でどうしても動かないのですが、ご協力いただいた方へのお礼も含めて
とりあえずソースだけでもｳﾌﾟして晒してみます。
コメントだらけの汚いソースですが2週間前にCGIに手をつけた素人という事で
見逃してください・・・・
ttp://cgitest.s7.xrea.com/cart.txt
まだエラー処理とかは全然してません。とりあえず動いたというレベルです。
今他の鯖の垢申請中なので動けばまたｳﾌﾟします。

ちなみに自作自演はしてません。てかこんな自作自演できるくらいなこんな苦労しなくていいのに・・・・・(ｗ

さまになってきたジャン。
なんかスゲー懐かしい感じだyo

たいしたもんです。感心しました。

文字コードEUCで送ったら動きました
ttp://cgitest.s7.xrea.com/cgi-bin/shop4.htm
ただやっぱりブラウザで頻繁に文字化けするし、sendmailで送られる
データはﾊﾞヶﾊﾞｹなんですよね
はてさて、何にあわせるのが一番楽なのか・・・・
EUC統一がよさそうなんですが、そうするとブラウザが頻繁にエンコードミスるようなんですが
うちのIEのせいでしょうか？それともやっぱりブラウザ出力部はS-JISにしといたほうがいいですか？

>>239
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
だからじゃないの？

少し休め。
CGIが吐き出すHTML、<html>〜<head>〜</head>〜</html>が丸々抜けてんぞ。
shop4.htmはMETAの指定がShift_JISなのにファイル自体はEUC-JPだしな。

よくやったよ。フィニッシュに向けて、まずは寝れ。

正直、ここまでたどり着くとは思わなかった。

おおー、よくやったなー。お見事。

ちゃんとサブルーチンに分けてあるし。
見やすいし。
別に汚いソースじゃないじゃん。いいんじゃないの？

>sub sub_add{
> $ctime=time();#クッキーID作成用要素（時間）
> $cid=$$+$ctime;#クッキー用ＩＤ

厳密には、クッキー用のIDが足し算だとイカンと思うが・・。

プロセスIDは一回転して戻ってくるから。
Windows だと、プロセスIDはランダムに割り当てられるし。

お褒めの言葉ありがたい限りです。ホントここに来て見てよかったですありがとうございます。
で、文字コードなんですが・・・
一般的にはスクリプト自体はEUCで書けとものの本には書いてありますよね？
ただ、HTML表示はS-JISが一般的（だと思うのですが）
たとえばスクリプトをeucで書いて（保存して）フォームからのデータは
jcode.pl使ってEUCにコンバートで、スクリプト内のHTML表示部だけMETAタグでs-jis
指定してやればブラウザはちゃんと解釈してくれるんでしょうか？
CGIというよりWEB作成の基礎の気もするんですが、今まではDW使ってて
文字コードって意識した事無かったもので・・・・・
前に書いた通り全てS-JISで統一すれば楽なんですけど、スクリプトがeucじゃないと
動かない鯖にいきなりあたっちゃったもんで・・・・・
あと、この鯖、（てかeucでスクリプト書くと）sendmailで送られたメールが
どうしようもなく文字化けするんですよね・・・・ちゃんとコンバートはかけてる
はずなんですが。

>>245
$$で得られるIDが3桁みたいだったので重複する可能性も考えtime()とあわせてみたんですが
ﾀﾞﾒですかね？1秒以内に$$が重複する可能性は無いと思いまして・・・
アクセス数の極端に多い（同時に買物をスタートする可能性が高い）場合は問題になりそうですが・・・・

>>246
内部でEUC処理するなら、出力もEUCで良いんじゃないの。
METAタグと、出力ヘッダの両方でEUCに指定した方がいいよ。
あと、メール本文はJIS出力でいいけど
subjectはそれだけじゃダメでちゅ。バケまちゅ。

プロセスIDは、65535 までいくよ。
+ って、文字列くっつけるんだっけ？　忘れちゃった。
$cid = "$ctime$$"; とかにしとく方がいいかと思ったんだけど。

あとcgi なら、同時アクセスでも、別のプロセスを立ち上げるから、
同時に買い物をスタートされても平気。

お！キレイにかけてるじゃん
俺のスクリプトよりもキレイだぞ；

しかしCGI.pm使ってないの見るの久しぶりなんでなんとも懐かしいにおいがする
のう。。。

あ、そうか・・・・数字の足し算だと確かに重複の可能性がありますね・・・
修正させてもらいます。

で、やっぱりメールの本文の文字化けが解消しない・・・・
スクリプトとHTML出力はEUCで統一したんですが。
@sendml＝メールの本文;
&jcode'convert(*sendml, 'jis');
じゃﾀﾞﾒなんですかね？
@sendmlはファイルから読み出して格納してます。
ファイル自体は開いて見るとeucになってるみたいなんですが。

ソースよく見てないんだけど、
@sendmlってことは、配列なんでしょ。
jcodeなら各要素ごとにやらなだめでしょ。

なるほど・・・だとすればファイルに書き込む段階で各要素（変数）
をjisでコンバートして最後に一気に読み込んで送信すれば良いんですかね？

readparseが見当たらないが、ブラウザから受け取ったデータの汚染チェックはしているかな?
たとえばcookieに予想していない文字列突っ込まれたときとか

メールの文字化けの件、ほぼ解決しました。ご指導いただいた方ありがとうございました。

>>253
ReadParseってフォームからのデータの取得にしか使ってないんですが、
他にも何か使い方があるんでしょうか？なんやら重要そうな内容みたいですが・・・

ソース見たんですが、ReadParseのあと
フォーム要素のハッシュに対してもjcodeで一括変換しようとしてるでしょ。
テストしてうまく行ってるのかもしれないけど、
jcodeは効いてないんじゃないかな。