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

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

2ゲット。
やってみれば？
しかしそれをそのまま商売につかうとなると
イロイロ危険だと思われ

ﾚｽありがとうございます。で、ちょっとお聞きしたいんですが、
掲示板スクリプトとかって、かなり高機能な奴もそこらじゅうで「フリー」
で転がってますけど、ショッピングカートって、ちょっと使い勝手が良くなると
みんなシェアになってますよね？
これって、やっぱり掲示板なんかに比べて圧倒的に
手間がかかる＝作るのが難しい
のでしょうか？それともスクリプトの性質上「利益を生む」物なんで
「金稼ぐんだから、少しくらい払っとけ」的な考え方で、
作る手間＝技術
は掲示板なんかとそれほど変わらないものなんでしょうか？

やってみれば。
テキスト弄りまわすだけだから丁度良いんじゃないかな
それと出来たらそのWEBショップの名前教えてくれる？
絶対そこ利用しないから　（笑

＞４
えっと・・・・
まぁ、もし出来上がったとして穴だらけになるのはわかっているのですが・・
そういう場合って、設置者（お店）側だけじゃなく、利用者（お客さん）側
にもリスクがあるような穴が出来る可能性があるってことですか？

もしそうだとしたら・・そうでないにしても、ｾﾞｯﾀｲに注意しなくちゃいけないことって
何がありますか？

リスクて、、、、
カードのID漏れたらどうすんのさ　（´＿｀；）
DBを生でネットに晒すのは狂ってるよ

>>3
シェアにしてるのは、金儲けに利用するなら
作者にもチットは金貰う権利があるでがしょってことでしょうね。
難しさに関しては一概には言えないと思います。
BBSにもショッピングカートにもいろいろあるし、
同じ機能でも速さがエラく違う場合もあるので。
しかし、若干カートの方が難しくなりがちかも。
個人情報にきちんと配慮するとなると
ショッピングカートの方が、スクリプトを組む前に
必要な知識は増えるでしょう。
作る前に>>5のような事がわかってないと危険。

ども・・
カードに関してはどっちにしろSSLが使えない鯖の可能性もあるので
基本的には支払の項目で、｛カード、代引き、振込み｝を
選べるようにしておいて、後でメールででも確認するような形になるかと・・・
でもSSLとか使えないと、住所等の情報も危険に晒されるわけですよね・・・
はてさて・・・・・・・

やる前に確認できる事って限られているので
簡単なものを試しに作ってみるしかないでしょうね。
スポーツ、料理、デザイン、プログラミング・・
何にしても、概要を知るのと実践とでは次元が違うでしょ？

ところで、その辺のセキュリティ関係勉強しとくのに必要な
キーワードってなんでしょう？書店で本探すにしても何から
手をつけていいかわから無いので・・・・
今のところSSLって言葉しか頭に浮かばないんですが

LANのPCで試すんでしょうから、とりあえず、鯖のインストール・設定から
テストスクリプトの作成・設置までやってみたらどうですか。
そこでかなりの部分が勉強できると思います。

＞２さん
親切にありがとうございます。
とりあえず、今のところローカルのHDにapacheとPerl入れて
テストの出来る環境は整ってます。
家のネットワークがWin2000S使ってプロ串経由でCATVにつなげているのですが
Win2000SにApachとか入れちゃうと外部からのアクセスとかが恐いので
端末になってるWin2kProの機械の中でテスト環境作りました。
一応、本に載ってる「掲示板もどき」は打ち込んでみて、ページを行き来
しながら、処理の内容を理解できるようにはなってきました。
次はファイルのロックとか、一度登録したものの削除とかを試そうと
思います（flockに関してはwin環境じゃ動かないらしいですが・・・・・）

>>12
ショッピングカート作るんだったら、flockとか使わないことをおすすめするよ。

ちょっと話はずれるかもしれませんが、僕も最近バイトができたらと
いう少し不純な動機でperl始めました。
まだブラインドタッチもままならない状況で無謀者さんよりもさらに無謀
な挑戦をしています。
おたがい結構大変な挑戦をやってますけど頑張りましょう！応援してますよ。

それはどういうことでしょ？ロックしないってことですか？
それとも他の方法が？

>>15
うん。ていうか、テキストでデータ吐き出さない方がいいって事かな？

＞テキストでデータ吐き出さない方が〜
？？？？？？？
今の私の知識の中ではフォームから受け取ったデータに関しては
「テキスト」で処理するしか思い浮かばないんですが・・・・
他にどのような方法があるのでしょう？txtじゃなければバイナリ？
受け取ったデータを何か加工するのでしょうか？

>>17
カートと商品の大きさにもよるけど、DB連動とったりした方が安全かな？
tieつかってGDBMに納めたりね。
お金が絡むcgiになるから、そのあたり慎重に考えた方がよいと思います。

>>18
カートと商品の大きさっていっても、実寸じゃなくて、データの大きさです(笑)。
読みにくい文章でごめんね。

・・・もうわけわかめ・・・・
DB連動、tie、GDBM・・・全て初耳です。
ちと調べてみます。

しかし、２ｃｈって多少の煽りにめげなければ、情報収集したり、
アドバイス貰うのに良い場所だと思ってこの板でｽﾚ立てたは良いけど
ｽﾚが気になってエディタに集中できないという諸刃の剣(w

>>12
もし公開鯖がUNIX系なら、LANの方もそれにしておいた方が何かと良いです。

もうひとつ、「プログラミング的な物の考え方」にいついて質問させてください。
一般的にひとつのスクリプトを作り始める時「設計図」は書いた方が良いんでしょうか？
はるか昔にベーシック（PC-8001)をかじろうとした頃は「フローチャートを書く」みたいなのが
あったと思うのですが・・・
それともいきなり書き始めて、後で必要になった処理を継ぎ足すなり
割り込ませるというのは可能ですか？可能にしても相当めんどくさく
なるもんなんですかね？

＞２２＝２さん
公開鯖は間違えなくUNIX系なんですが、LAN環境にLinuxなりを導入
しようとすると、Perl云々以前にそれに時間を取られ、スクリプトを
書く段階までたどり着けないような気がするので・・・
ある程度Perlがわかってきて、簡単なスクリプトを”自分で”書けるように
なったらLinuxも導入しようとも考えてるんですが、今の段階ではPerlでCGI
を書くことを優先したいと思ってます。

>>23
その程度のことは入門書にも書いてあるんで
読んだら良いかと思われ。
あとは、経験を通して身に染みてというか
身についていくものと思われ。

>>24
結局、>>22は遠いようで近道になるんですが、
まあ、やりかたは人それぞれでしょうな。
どんなトラブルも後からすれば肥やしになるでしょうから。
商売だとクレームになったりしてアレですけど。
では私はこれで。

こういう奴が作ったECサイトでは買い物したくないな。

セキュリティ（SSL）はVeriSignへの登録が手っ取り早い。
http://www.verisign.co.jp/
年間10万円ちょっとかかりますけど。
カートはゼロから作ると大変。フリーなどを改造した方が良いと思われ。
鯖は安価で高性能のものが数千円/月〜。
小規模サイトなら重要データにDBは使わず、フォームメールで注文を飛ばし、
メーラー側でDB(Accessなど)に格納（フリー or 数千円〜）がおすすめ。
中規模〜なら鯖からDB(MySQL・Postgresなどバイナリデータ)への接続が必要。
初心者が短期間に構築するのは無理かと・・・でも応援します。
俺も作りたいって思ってるから。

う〜ん、話がどんどん難しくなってる・・・・
依頼主が非常に小規模なのでVeriSignへの登録は無理かも。
カートはフリーでユーザー側のインターフェースがﾜﾘと
使いやすい奴は見つけたんですけど、商品ページをいちいち手書き
でフォーム使って作らなきゃならない。一度商品登録して”はい終り”
てのなら良いんですが、あまり詳しくない人が商品登録の為に商品ページに
フォームと各オブジェクトを配置、それぞれに属性指定せねばならず、後々面倒なことになりそう。
で、最初に考えたのが、フォームからデータを受け取って、そのフリーのカート
に必要なフォームを出力するCGIを作ろうということでした。
そうすれば、カート部分は完成してるので、商品登録だけ出来るものなら
ﾜﾘと簡単かな？と・・・・
で入門書とか読んでるうちに、「どうせなら」と思い、1から作ってみよう
と思ってるところです。
長文ｽﾏｿ＆応援感謝

保守契約は、ちゃんとしておいた方がいいと思うよ。
実際に使われると、なんやかやトラブルが発生するから。

ヘタすると、いつまでも延々、タダでトラブル対応し続ける
ことになる。

どんなプログラマーでも、入門書みたいのからはじめて、
トラブルを経験しては、ノウハウを身につけて
腕を上げていくんだとは思うけど。
損害賠償とか個人に請求されることだけは、避けたい。

あと、>23
>一般的にひとつのスクリプトを作り始める時
> 「設計図」は書いた方が良いんでしょうか？

ぜったい書くべき。面倒がらずに。
しょーもないスクリプトでも。
CGIなら、カンタンでいいから画面遷移図は書く。
フローチャート書けるなら、書くに越したことはない。
あとプログラム内で使う変数の一覧表は、作らないと後で困る。

とくに初心のうちに、それもスクリプト言語で作り始めると、
こんがらがってわけのわからないことになりやすい。
つか、まず間違いなく、わけのわからないことになる。

どうしても、「こうするには、こう書けばいけるかな？」
と、試し試し作っていくことになると。
設計が変更につぐ変更になって、イヤになるかも知れないが。
でも、書いたほうがいい。

設計メモも無しに、いきなりガリガリ書いて「動きました」って
プログラムだと、ちょっと直すにもエライ苦労することになる。

あと、ついでに。

>> flock 使わない件
>それはどういうことでしょ？ロックしないってことですか？
>それとも他の方法が？

ショッピングカートは関わったことないんで分からないけど。
Webがらみだと途中でプロセスが落ちちゃったときに、
ファイルがロックされたままで動作が止まっちゃうことも考えられるね。
プログラムの書きかた次第とは思うけど。

>＞テキストでデータ吐き出さない方が〜
>？？？？？？？
>今の私の知識の中ではフォームから受け取ったデータに関しては
>「テキスト」で処理するしか思い浮かばないんですが・・・・

プログラム内では、テキストとして処理するけど。
データを、テキストファイルとして出力はするな、ということかな。

とりあえず、データベース使った方がいいよ。
そんな難しいもんではないので。

連続ゴメン。

>とりあえず、データベース使った方がいいよ。

って書いちゃったけど、既存のCGI使うんでしたね。
じゃあ、ファイルで処理するのもしかたがないか・・。

漏れなら、商品ページを生成するアプリをVBかHTAで作るな。
ま、初心者が穴のあるCGI乱造してくれるのは大歓迎だ。

>>34
CGIでもいいんだよ。
ローカルのPCで実行して、アップするやり方にすりゃ安全。
開発も早いだろうし。

レス感謝です＞皆様
＞３０
なるほどですね。設計書、てかアイディアプロセッサー使って
流れ図と必要項目のリストアップはやって見ます。

＞３４　商品ページを生成するアプリをVBかHTAで作るな。
そうか・・・Accessでも使って簡単なDB作りそのデータを
フォームオブジェクト含んだHTMLに吐き出させれば良いんですかね？
相手の要望で「出来るだけ簡単に」って事だったんでWEBで出来るように
と思ったんだけど、HTMLだけ生成しちゃえば後はFTPだけですからね・・・
う〜ん・・・どっちが簡単なんでしょ？

>>35
そーか? CGIというインターフェースを介する分だけ余計な手間がかかると思うが…
perlだってActive Scriptで書けるんだろ? だったらHTAだ。
どっちにしろ、ローカルで設定ファイル生成するアプリ作るが吉。
使いやすけりゃ売れるぞ。

>>36
CGIは状態を持てない、それゆえ自分で状態を管理しなけりゃならないから面倒。

ところでデータ-ベースを使うってのはどういうことなんでしょうか？
サーバー側のそういう機能を利用すると言うことでしょうか。
IISとかだとSQLとかODBCとかASPって「言葉」がなんとなく思い浮かぶんですが
UNIXベース＋Perlでも同じような事なんでしょうか？

○ 教えてクン養成マニュアル
明日の「教えてクン」を目指す、若き戦士達に以下の文章を捧げる。
日々精進し、パソコンヲタクどもの親切を蹂躙してやれ。

１．努力を放棄すること
　　いやしくも「教えてクン」たるもの、努力をしてはならない。
　過去ログを読んだり、検索してはいけない。
　「英語は苦手なので、分かりません。」は、高く評価できる。
　辞書片手にマニュアルやReadMeを読むなど、決してしてはならない。
　他力本願と言われようと、自分で調べたり試行錯誤したりせず、
　他人の努力の結果を搾取するのが、正しい「教えてクン」である。
　また、「もう何が悪いのかサッパリ分かりません。」と言って
　ふてくされるのも有効である。「サッパリ」という単語が
　「やる気の無さ」を効果的に表現している。
　「原因を特定するには、何をすべきでしょうか？」と訊いてしまうと
　自己の積極性が現れてしまうので、「教えてクン」失格である。

２．情報を開示しないこと
　　使用ＯＳや、機器構成などの必須の情報を知らせてはならない。
　マザーボード名やＢＩＯＳのバージョンも同様だ。
　具体的なアプリ名やバージョンも隠蔽すべきだ。
　「ＤＶＤ再生ソフト」のように曖昧に表記しておけばよい。
　反対に「前から欲しいと思っていた○○」とか「安売りされていた
　○○」　等の「どうでもいい情報」は、どんどん書いてやれ。
　　トラブルの場合は、状況を正確に記述してはならない。
　「なんだかうまく動きません。」とか「エラーが出ます。」等と
　具体的なことは何も書かないことが重要である。
　また、自分の試してみた事も具体的に書いてはいけない。
　考えられる組合せのマトリックスを作成し、状況を整理するなど
　もってのほかである。最悪の場合、それだけで問題が解決してしまう
　こともあるのだ。
　「いろいろやってみたけど、動きません。」が理想的だ。

３．答える人間のことを考えないこと
「教えてクン」は、孤高の戦士である。相手のことを考えるようでは
　教えてクン失格というものだ。
　以下のような行動が、望ましい。
　　初心者であることを高らかに宣言し、初心者向けの丁寧で
　分かりやすい説明を強要する。専門用語の使用を禁じておくと
　さらに効果的である。簡潔な説明を禁じられたヲタクどもは、
　同じ内容を説明するのに、何倍もの労力を強いられる。
　自分は努力せず、相手には多大な努力をさせることこそが
　「教えてクン」の真骨頂である。
　　マルチポストも有効である。そのＢＢＳを信用していないことを
　明確に示せる。「どうせ、お前らじゃ分からんだろう。」という
　意志表示として高く評価できる。もちろんマルチポストの非礼を
　あらかじめ詫びてはならない。それでは、単なる「急いでいる人」
　になってしまう。それは、教えてクンではない。
　　質問のタイトルは、「教えてください。」で良い。
　タイトルを読んだだけでは「何に関する質問」か全く分からない。
　そういう努力は、答える人間にさせれば良いのだ。
　とにかく、答える人間が答えやすいように気を使って質問しては
　ならない。傲慢で不遜な態度が必須である。
　「聞きたいことがあります。」など、プロの仕事であろう。

最後に、言うまでも無いことだとは思うが、答えてくれた人達に
お礼の言葉を返すなど言語道断である。
せっかく「教えてクン」を貫いてきたのに、最後にお礼を言っている
ようでは、臥竜点睛を欠いていると言わざるを得ない。
質問だけしておいて、後はシカトが基本である。
上級テクニックとして、「そんなことはもう試しました。」とか、
「そこまで初心者じゃありません。」などと言って、回答者の
神経を逆なでしておけば完璧である。

以上のことを踏まえて質問すれば、君も立派な「教えてクン」である。
ビバ！教えてクン！　教えてクンに栄光あれ！！

>>39
データの管理をＤＢ使うってことさ。
君の理解した掲示板に例えると題名や投稿者や本文をテキストファイル
ではなくてＤＢのレコードにしまうということ。

プレーンテキストよりはいろいろセキュリティ設定ができるし使用する
ＤＢによっては面倒なロック作業から解放される。

ただし文面から察するにどこぞの共用レンタルサーバーでは使用できな
い場合があるのでご注意

>>43
他にはデータの検索をしたい時にいちいち検索するための複雑なスクリプトを
自分で作らなくてもちょこっと SQL 書くだけで欲しいデータを素早く取り出せて
(ﾟдﾟ)ｳﾏｰ ってのはあるね。多少データベースの設計と SQL を勉強する必要は
あるけども。Perl だと DBI で DBMS にアクセスするのが一般的かな。
こんな本も出てるみたいだよ。

http://www.oreilly.co.jp/BOOK/perldbi/

Unix + Perl なら、データベースサーバは MySQL か PostgreSQL で
いいんじゃない？
ロック処理とか、トランザクション処理とか、面倒なことはぜんぶ
サーバがやってくれるよ。

もしサーバ使えない環境なら、PerlのDBモジュール使うしかないかな。
こっちだと、基本的に一枚のファイルでデータを保持することになる。
で、検索にはハッシュを使う。
だから、複雑なデータ処理をする場合や、データ数が数万件とかの規模に
なると、パフォーマンスが低下して、苦しいかもしれない。

PHPで作ればいいじゃん

取りあえず動作するCGIは比較的簡単にできるけど、
堅牢なそれを作るのは大変だよな。

>>45
>こっちだと、基本的に一枚のファイルでデータを保持することになる。
どういう意味でいっているのかわからないけど、tie使うって意味合いでいってるんだったら
そんなことないっす。

>>48
ほんとだ。
余裕で複数のファイルからデータ取ってきてマージして
使ったりできた。しかもBツリー使う引数もあった。
ゴメソ。

つか、共有鯖で共有DBMSなんぞ使うな。
共有鯖や外側鯖に顧客のプライベートデータを置くことに何の疑問ももたない
君らに恐ろしささえ感じる。

う〜んだんだん・てかどんどん難しい話になってきちゃいましたね。
自分としては、カートCGIなんかもシェアとはいえﾜﾘと普通に配布
されているし、ためしに設置してみてもそんな特殊な事やってそうも無いので
掲示板なんかに比べてちょっと複雑な位かな・・・程度に思ってたんですが。
いや、確かにある程度の規模のWEBショップ構築するならセキュリティとか
相当大変なんでしょうけど、個人商店とかで騙されて楽天とかに出店して
全然元が取れてないような規模の商売のところってあると思うんですよ。
ちょっと分けます

で、一番単純なWEB通販の方法として,商品リストをHPに載せておいて
欲しいものをメールで送ってもらう。
てのがあると思うのですが、それだとあまりにも使い勝手悪い。
形だけでもショッピングカートがついてると、フォームで（ブラウザで）全てが
済むから、お客さんも買いやすいでしょ？だから極端な話、お客さんの個人の情報
はフォームに入れなくても良いかな？って感じです。注文商品とメールアドレス
だけを取得できれば、住所、電話等は後でメールでやり取り・・・ってのも
ありだと思うんですがいかがでしょ？

>>52
それはただのフォームメールで十分じゃねーかよ
別にカート使わなくてもＯＫでしょ。
あと君の言った商品管理にもテキストよりＤＢの方が使いやすいと
みんなが言ってくれてるの。
ご理解いただけてる？
ってか君はどれくらいのスキルなのか教えてくれないか？
ＣＧＩは初めてだということはわかるが他の分野のプログラマなのか？

>>52
それで済むならそうすれば？

>>53
>>1読んだ？

いろいろご提案いただいてる皆さんにちょっと、言い方が失礼だったかもしれませんね。
すいませんでした。
>>53
＞それはただのフォームメールで十分じゃねーかよ
フォームメールだと基本的に内容は自分で書かなきゃいけないですよね？
私としてはそれぞれの「購入」ボタンを押していって、購入商品を積み重ねていって
その結果をメールで送信するって言う形にしたいんです。もちろんセキュリティ
が確保できれば住所等個人情報もフォームで送りたいんですが・・・・
基本的には客側にあんまり考える時間を与えずフォームのクリックだけで
注文できる、って方式のほうが買ってもらいやすいと思うので・・・
まぁ、「そんなこと以前に客を集められるHP作れ！！」って話もあるんですが
それはまた別の話と言うことで（ｗ

☑購入
チェックボックスつけりゃ、フォームtoメールでいいだろ。
それからSSL使わないんだろ？
どっちなんだよ、ハッキリしろヴォケ！

商品のページが１ページだけなら、おっしゃる通りの方法でも大丈夫
だと思うんですが、複数ページにまたがっていてもその方法で大丈夫でしょうか？
一応商品カテゴリごとにページを分けたいといわれているので・・・・

で、SSLはとりあえず使わない方向でお願いします。

１がこのスレを立てたことについて各界の反応

総理大臣／小泉純一郎さん 「何で今さら、こんな質問が出てくるのか分からない」
自由党党首／小沢一郎さん 「（事務所を通じて）コメントする価値を見いだせない。」
東京都知事／石原慎太郎さん 「くだらないねえ。何が楽しみでこんなスレ立てるのかな。連中は。」
日銀総裁／速水優さん「頭の中までデフレが浸透していると、再認識せざるを得ない。」
ソニー会長／出井伸行さん 「ブロードバンドが普及すれば、こういう削除も速くなると思う。」
白鴎大学教授／福岡政行さん 「やっぱり自公保連立政権の発足からこういうスレが増えたと思います。」
タレント／デーモン小暮さん 「わが輩が地球を征服した暁には１から処刑するぞ。グハハハハ。」
新しい教科書を作る会／西尾乾二さん 「このスレほど戦後民主主義教育の欠陥を表しているものはない。」
元グリーンベレー／柘植久慶さん「海外にはこの程度の変質者はコンビニにもいる。日本が平和すぎた。」
女優／広末涼子さん「こういう人がいる日本って、やっぱりすごすぎると思う。」
プロデューサー／テリー伊藤さん「１は本当にバナナの皮を踏んで滑ってこけそうな人だよね。」

>>58
そんなこたないよ。
何でそんなに怒ってんのさ？

サッ○ー｢もしもし>>1？マミーだけど。あんたなんでこんな駄スレ立てたの？｣
　　　>>1｢うん…｣
サッ○ー｢うんじゃないわよ。それからレスはあったの？｣
　　　>>1｢うん、いろいろあったよ。DBとか、わけがわからなかったよ。｣
サッ○ー｢何て言ったの？｣
　　　>>1｢しらべるの面倒だから、一応あやまってから放置した。｣
サッ○ー｢なんで？こちらは糞スレは立ててない事になってるんだから！｣
　　　>>1｢でも立てちゃったから。２ちゃんねらー相手にごまかせないよ｣
サッ○ー｢だから立ててないって事になってるんだから。裏で色々手を打ってるから大丈夫よ｣
　　　>>1｢でも調べるのめんどくさいもん。やってられないよ。｣
サッ○ー｢それじゃあんた、調べてみますって言っておけばいいのよ｣
　　　>>1｢うん…｣
サッ○ー｢あんたこの文誰かに見られてる？｣
　　　>>1｢見られてないよ｣
サッ○ー｢これはファミリーの問題なんだから。あんたが駄スレ立てたのがばれるとこっちも騙られるのよ｣

>>55
商品の蓄積？ってか商品は何点あるのさ？ってか予定でもいいから教えて
お客さん自体が一回の注文に数点注文するような性質の商品なのか？
蓄積自体は君が思ってるほど難しくはないのだよ。
問題は君自身がどういうものを作りたいかがわかっていないことに起因
していると思われ
とりあえずフォームTOメールのスクリプトを自分で書いてみてそこの
機能を追加していったらどうかね？何ができるかわからない状態では
お答えする方が疲れる

ショッピングカート系の仕様って、概要のシェイクダウン大変だよね。
設計ちゃんとしてないと、後が大変だし。
たいてい「●●が不満なので改良してほしい」
みたいなののソース見ると
「一から作り直した方が早いです」
みたいな状況になってることも多いし。
他の人にとっても、そういうものなのかな？

>>50
なんで？
SuExecで、パーミッションしっかりさせておけば外側サーバで大丈夫じゃないの？
ていうか、それ以上のセキュリティを、どうやって確保しろっていうの？
そういうことをアドバイスするんならともかく、一言だけ

＞つか、共有鯖で共有DBMSなんぞ使うな。
＞共有鯖や外側鯖に顧客のプライベートデータを置くことに何の疑問ももたない
＞君らに恐ろしささえ感じる。

こういいっぱなしってのもどうかと思うよ。
真剣に取り組んでる人間だっているんだし。
＞１はどうかしらんけど。

注文から先はうちはSSL使ってるよ。
ベリサインじゃないけどね。

難しくてわけわからない事も多々ありますが、とにかくいろいろレス感謝です。
>>58　各界有名人からの御言葉光栄の至りです
>>60　ただのｺﾋﾟﾍﾟかと思ったらちゃんとｽﾚをトレースしててちょとｳﾂﾆﾅﾀﾖ

>>61
商品の蓄積っていうか・・・
えっと最終的にイメージにあるのは、来訪者（客）が各売場（ページ）で
任意に商品をカートに入れていって、最終的に注文ボタンを押すと
その内容が管理者（店主）と客注文明細のメールが行く、というものです。
で、各商品はそれぞれ色とかサイズとかのオプションをリストボックスから
選べるようにしたりしたい。あと商品写真も載せておきたいですね。
もっと簡単な方法として、商品リストに”購入”のチェックボックス
付けといて、チェックの有る無しで注文品を抽出するというのも考えたんですが、
やっぱり「カゴに入れる」っていうイメージのものを作りたいもんで・・・・

アイディアというか考え方のTIPSみたいのをもらえたら良いかな？
と思って立てたｽﾚなんですが、教えて君になっちゃってるみたいで
申し訳ないです。

Tips
http://www.jadma.org/kisei/jyouhou/seibi.html

>>65

この板でPerl修行中の者ですが、この手のものなら
蓄積量が少なければ、フォームの中にHIDDEN属性で情報を
追加していくことで、簡単に作れるような気がしますね。

>>63
> SuExecで、パーミッションしっかりさせておけば外側サーバで大丈夫じゃないの？
プライベートデータはS/MIMEで送っちまえばsuExecより安全。
どんなに優れた攻撃者でも無い物は盗めない。
まず、置かない事を考えたほうが良いよね。

> こういいっぱなしってのもどうかと思うよ。
> 真剣に取り組んでる人間だっているんだし。
商用DBは知らないけど、PostgreSQLやmySQLは攻撃対象になってないと
いうだけで、結構穴あいてるでしょ。
例えば、FreeBSD portのPostgrSQLなど、デフォルトインストールはlocalhostが
trustになってる(なってた)けど、セキュリティに気を配ってるとは考えられない。

>>67
客に入力してもらう以外の必要項目（価格、商品名等）をHIDDEN属性で
指定しておけば良いらしい。ということはなんとなくわかってきました。
作る順番としては、とりあえずフォームを作ってそれを受けるカートのCGIを
作り、その後その仕様にあったフォームを作るためのスクリプトを書いて行く予定です。
いろんな本で調べながらなんですが、今のところわからないのが、
買物途中にテンポラリファイルに格納された「買物商品のデータ」を
客が「ヤッパ要らない」となったときに削除する方法です。
「買い物カゴの中身表示」の画面に削除ボタンをつけとく事になるんでしょうが、
それをどうやって処理するのか・・・・

>>69
カゴに品物入れて、そのまま他のサイトに飛んでったら
テンポラリファイルは残したままにしますか？

opne(IN,"<$file");
@data = <IN>;
close(IN);
@dataの中をmapなどで編集
--例--
map {
@cell = split(/,/, $_);
if (@cell[0] eq $in{'dellitemid'}) { $_ = ''; }
} @data;
opne(OUT,">$file");
print OUT @data;
close(OUT);
------------------
<$fileの中身の設定>
1024,電気ストーブ,・・・etc
商品ID,商品名・・・など

>>71
CSVですか。
商品名とか金額にカンマが入ったときの対策が要りますね。

>>70
そうか、そういう可能性も考えとかなきゃいけないんですね。勉強になります。
理想はある程度時間がたったら買物を終了しててもしてなくても削除ってところでしょうか。

>>71
入門書読みながら、意味理解してみます。ありがとうございました。

>>1って何やってる人？

区切りはタブがよい

>>1
書籍で勉強するのも大事だけど、実際にコードを書いてみないと
ダメだと思いますよ。
ここまで読んだ限りでは、考えるだけで一行も書いてないように
思えます。
今のままでは、「脳内カート」で終わるでしょう。

せめて、配布されてるCGIの改造をしてみるとか。

>>76
いろいろ書いて（てか打ち込んで）みてはいます。
ただいかんせん、”プログラム”という経験が皆無に限りなく
近いので、配列だとかの概念から一つ一つ確認しながらなので
いきなりカートを作れる状態ではありません。
現在は書籍に書いてある、掲示板スクリプトを弄繰り回しながら
その流れを一つ一つ噛み砕いている段階です。
それと平行しながら、自分で考える”カート”の設計図
というか流れ図みたいのを書きながら、ここでいろいろ
参考にさせていただいております。

>>77
あぁ、全くの初心者か…
ここあたりも見て置くように。動かすだけじゃ駄目。
http://choco.2ch.net/news/kako/1010/10103/1010387528.html

>70
普通はテンポラリファイルって消すんだろうけど（方法は知らないけど）、
途中で買い物を止めたって人の統計を取るために、何らかの形で
残した方がよくないですか？
例えば($section=買い物の段階、$cart=カートに入れた商品数)
カゴに1商品だけ入れて止めた ＝ $section=1;$cart=1
カゴに3商品、住所等入力画面で止めた＝ $section=2;$cart=3
カゴに5商品、最終確認画面で止めた＝ $section=3;$cart=5
アクセスがあるのに何故買わないのか？を調べた方がよいと思われ

先にお詫びしときます。今回は教えて君です、すいません。
えっと、カートとかで”金額”を扱うのに、普通”,”を入れますよね
20,000　みたいに、で個数とかを計算させて、
kingaku*$kosu
ってやると20,000*2でやると40って数字が帰ってきます。
こういう処理ってのは、普通20000*2で計算させて、出力時にカンマを挿入
するんでしょうか？それとも数値に自動的にカンマを入れて表示させるような
関数があるんでしょうか？もし前者だとすれば、

$kingakuにカンマが入っていたらそれをはずす
$kingaku*$kosuを実行する
計算結果ににカンマを入れる

とかの処理をカンマ付の数字を出力するたびにやることになるのでしょうか？

>>79
なるほどですね。店主の人にはその機能はいいかもしれません。
ただ、全ての利用者（中途キャンセル者も含む）のログとっておくと
鯖のスペース圧迫しますよね。サイトの規模にも拠ると思いますが。
って、定期的にログ削除すればいいのか・・・・

申し訳ありません。ぐぐるで発見できました。

> 今回は教えて君です、すいません。

毎回そうだろ。

>>80
数値へのカンマの付け方は「Perlメモ」参照してください。
http://www.din.or.jp/~ohzaki/perl.htm#NumberWithComma
関数があるかどうかはリファレンス系のサイトをどうぞ、
そんな処理にいちいち関数あるか知りませんが・・・。

>>82
調べずにここで訊くのが習慣化されてんだね。
教えて君です、すいませんなんて書いてる暇があったら
グーグルで検索しろ。

　　　　　　　　　　∧　　　　　　 ／ヽ
　　　　　　　　　/　　ヽ　　　　/　　　ヽ
　　　　　　　　 l　　　　レ──l　　　　ヽ
　　　　　　　　j　　　　　ヽ　　　　　　　　ヽ
　　　　　　 ／　　　　　　　　　　、　　＿　ヽ
　　　　　 /　　　　　　　__ ﾉ　　　ヽ￣・ﾉﾉ　l　　>>1　んなことシラネーヨ
　　　　　/　　　　λ￣ ・ノ　　　　 ｀⌒　　　l
　　　　 l　　　　　　 ｀⌒　　　　　 、　　　　　l
　　　　 l　　　　　　　　　λ＿＿ノ　　　　　 l
　　　　　ヽ　　　　　　　　ヽ| | | /　　　　　 /
　　　　　　ヽ　　　　　　　　　￣ﾌ　　　　ノ
　　　　　　　　ヽ ＿　　　　　　　 ＿─ ´
　　　　　　　　　　　￣＼　<´￣ 　　　　　　　/|
　　　　　　　　　　　　　　＼.＼＿＿＿＿__／/
　　　　　　　　　　　　　　　 ＼　　　　　　　／
　　　　　　　　　　　　　　　　　∪∪￣∪∪

まー気持ちは分かるよ。
関数の有る無しとかってより、ノウハウの部分を聞きたいんじゃないの。

>>80
とりあえず、プログラム中で計算に使うなら、その変数は
数値データにしておいた方がいいんじゃないの。
で、画面に表示する時だけ,を挿入する。

「計算に用いるデータだけど,を含んでいます」とか
イレギュラーなことは、俺ならとりあえず避けるな。

ふと思うがなんでこのスレって人気あるんだろう？
っていいながら見てるオレも不思議なんだがな（わら

>>85
以後気をつけます。

>>87
ありがとうございます。やはり、方法としてはそうなりますか。
カンマ挿入用のサブルーチン作って、とりあえずカンマが
必要な時はそれを使うことにして進めていこうと思ってます。
ただ,そういう場面が多いと一々subを呼び出す事になるんですが、
そういうのって良いんでしょうか？

>>89
そういう感じでよいんでない？その都度微妙に処理が異なるならともか
くとして同じならサブルーチンでしょ。
ちなみにその使用だと入力されたデータを数値として揃えるサブルーチン
も必要になるよね。

がんばってね

>>88
いかにショッピングカートって仕組みが必要とされているかって事だと思うよ。

>>89
しょうがないな〜、JAPUたんが最近いないので、
変わりに教えてあげるYO！

print "合計金額",comma($total);

sub comma{
($_) = @_;
1 while s/(.*[0-9\?])([0-9\?]{3})/$1,$2/;
$_;
}

こんな感じかな。

>>92
ありがとうございました。m(__)m
実は、一応なんとか書きあがってたんですが・・・・(汗

>>89
>ただ,そういう場面が多いと一々subを呼び出す事になるんですが、
>そういうのって良いんでしょうか？

ぜんぜん問題ないよ。それで普通。

もう諦めてPHPでつくりなさい

>>1
俺達これだけ協力したんだから、
できあがったスクリプトをちゃんとUPしてね。
それくらい分かってると思うけど。

>>96
完成がいつになるかわからないけどガムバってみます。

＃進捗状況
フォームから受け取ったデータをタブ区切りでTMPファイルに
書き込み、そのデータを配列に格納して、HTMLにテーブルで表示する。

ようやくこれだけ出来ました。タブ区切りのひとつひとつのデータを
\nを区切りとして配列にして、それをさらに\tを区切りとして配列にしてから
テーブルに埋め込んで表示させました。カートの中身を表示する部分の実験です。
＃次の予定
テーブルの列の最後に「削除」ボタンを表示させ、それを押したら
その列を削除（カートから消す）という方法を見つけたいと思います。
配列の最後に何かデータをくっつけさせてそれが有るか無いかで判断させて
削除しようと思ってるんですが・・・・・

ﾀﾞﾐﾀﾞ・・・・・
とりあえず寝よう・・・
なんか、根本的に削除の方法論が間違ってる気がする・・・・・

例えばだね。

注文（注文番号　商品番号　注文個数　顧客番号）
商品（商品番号　商品名　単価　写真ファイル名）
顧客（顧客番号　氏名　連絡先）

などというテーブル構成にして、画面上では注文の部分のみを扱う
それぞれの番号には同じ数字を重ねない。
で、削除の場合。削除確認のラジオボタン（かなにか）をチェックする
と削除する注文番号が飛んでいってその注文番号と一致するレコード
なりファイルなり配列なりクッキーを消せば(･∀･)ｲｲ!!だけじゃない？

100か。

>>1
・・・・楽天でいいじゃん。

今日は進捗無しです・・・・・
ちょっと脳みそ沸騰ぎみ。
プログラムの経験自体が無いので、自分でやろうとしてることの、
可否、考え方の良否が不安で頭の隅から離れません　はぁ・・・

>>99さん
その方法っていわゆるリレーショナルDBと同じ考え方ですよね？
後々便利そうでは有るんですが、現状たった一つのテキストを
扱うのにｲｯﾊﾟｲｲｯﾊﾟｲなモノでして・・・・
それらを各キー（番号）を使って扱うなんてとても無理です・・・
>>101
えっと、上のほうに書いた気もするんですが、楽天って高いじゃ無いですか？
で、そのコストパフォーマンスの悪さに辟易した友人から相談されたわけです。
楽天で売上上がらないところもそうだけど、上がってるとこだって、
ドメイン取っといて契約が終わる直前にでも誘導すれば、コスト抑えられると
思うんですが・・・・・ま、セキュリティの問題とかｺﾝﾋﾞﾆ決済とかの利便性も
有るんで一概には言えないと思いますが・・・・
でも、月五万（でしたっけ？）の粗利を稼ぐって楽じゃないと思うんですが。
特に楽天に多い、花屋とかアクセサリ屋とか。

すいません、sage忘れました・・・

で、この板見ていて感じたんですが、常駐住人の方は、業務で
ﾊﾞﾘﾊﾞﾘと大きなお仕事をしてる方がほとんどなのでは無いかと。
でも、上の例にあるような、花屋とか産直の食品扱ってるとことか
、業者に3桁万円の金を払って頼むのは無理だけど・・・・
ってところはいっぱいあると思うんですよね。私の知り合いも、そのクチ
でして・・・・
で、フリーとかシェアで探してみても、どれも、帯に短し＜以下略＞
って感じだったんで、良い機会だから、と思ったわけです。
ちなみにその知人の所はフリーの使ってとりあえず、稼動出来るようには
しました。

1は保険とか絶対入らないタイプだな
(こう言うの見てるとカード使うのは怖いのぅ。。)

確かにユーザー側の利便性（安心感）って言うのは重要なファクター
ですね。ただ、現在のECの普及見ると、いずれ貸鯖にしてもその辺
が整備されていくと思うんですよ。上に出てきたベリサイン使う
って手も有るでしょうし。
って、もっともらしいこと書いてますが、たまたま、上記のような
頼まれ事がきっかけ（Perlを覚えてみようと思った）になっただけです。
そもそも、ゼロから初めて、実運用に耐えられるものが作れるとは
思ってませんし・・・・

ちなみに、保険は家計を圧迫するほど入っております・・ﾊｲ

基本的にそう言う事は共用でするもんじゃ無いと思うぞ。
共用サーバなんてのは本当のROOT以外に、何故か何でも出来る(所謂、夜のroot)
輩が何人か居ると思って間違い無い。
そう言う奴に対してDBの安全を保障出来ないだろ？
そうなると、スクリプトの安全も勿論だが、寧ろ管理するOSの
勉強の方がずっと大事だと思う、実務レベルではね。
perlのスクリプトってのは安全なんだよ、標準関数が豊富だから
得体の知れない外部コマンドを使わなくていいし、perl自身が実行前に
権限のチェックを厳密にしてるからね。
それと通信経路の暗号化も大前提、今時SSLも使ってない所は誰も使わないよ。
いずれにしてもその調子で一通り動く物が出来ても多分穴だらけだと
思うから、一冊FW構築本なんかを読む事をお勧め。

あ、何か読み直したら結構適当な事言ってる
酔っ払いなんで読み流してくり

1さんって、何年か前に●nakaとか名乗ってませんでした？

>>108
いや、人違いだと思いますよ。この板本格的に見始めたの極最近なので。
>>106-107
ご忠告、ご提案ありがとうございます。やはりセキュリティ関連の勉強は必須
ですかね。今はともかPerlでCGIを書けるようになることでｲｯﾊﾟｲｲｯﾊﾟｲですが、
時間のあるときにその手の本も目を通してみます。

>>109
106ではないのだが、共用鯖でセキュリティといっても限界があると彼は言ってる
のだと思われ。
テストでサンプルデータ入れるのは問題ないけどそれを本格運用する場合には
気をつけてくれってことだろ。
とにかく形にもなってないんだろうからがんばれよ

>>1
本当に書いてるなら、できあがってるところまでのコードを見せてよ。
どこかでDLしたものはナシね。

>>110
了解です。＞セキュリティの件
あと励ましありがとうございます。
>>111
本当に書いているんでが・・・・
今のところ、あれこれいじりながら、何をすれば何が起きるのか？ってのを
確認してる段階なので・・・
Hallo World! に毛が生えた程度のもの晒すのもどうかと・・・

未経験から始めるのならPHPの方がよかったと思うよ。
2か月くらいかかったけど素人でもできたから。

楽天じゃなくても安価な（無料な）ショッピングモールって結構あるじゃん。
何でそれらを使わないの？
http://www.cubit.co.jp/shopgear.html
http://www.mallkun.com/
このへんで良いじゃん。

>>114
商売にしたいんじゃないの。

別に商売にしてもそれはそれでいいと思うんだよな。
使う人間が便利だと思えばね。
GPLにしてくれとはいわないよ(笑)

>>116
俺も別に悪いとは思わないよ

売るのは悪くないがショッピングカートCGIって売れるか？
シェアウエアがあるのは知ってるがフリーな物も沢山あるし
無料レンタルもあるからよっぽど使いやすく堅牢な奴でないと
買う奴は居ないと思うが。

レスキューのヘボい奴でもそれなりのユーザはいるので親切なページ生成が
作ってやれば需要はあると思われ。
堅牢性は本来最重要なのだが評価されにくいね。

なるほど、じゃあ使いやすいUIのCGI生成プログラム作ったら売れるかな。
堅牢性は知識無いから考えないことにしよう（藁

じゃ、負荷テストプログラムを用意して
脆弱そうなところに堅牢なのを売る、と。

いつの間にやら、いろんなレスが・・・・
商売については・・・頭の隅の方に無いって言えばウソになりますが、
とてもじゃ、無いですけど今の段階じゃ(藁
確かに、シェアやフリーであることは有るんですが、いろいろ調べてみると
結構痒い所に手に届いてるものが無い。思うに「通販サイト」に直接
携わってない人たちが作ってるのでは無いかと・・・
実際、頼まれて見ると、運用者側に親切な機能が搭載されて無かったりします。
ページの生成機能なんて最たるものですね。
ここの皆さんのように、スクリプトをホイホイ書けるような人たちなら
小遣い稼ぎくらいすぐ出来るんじゃないですか？　”商売”ってなるとまた難しいでしょうが・・・

れすきゅーにOEMするとか (藁

はっきりいって１時間あれば作れるよ
>>1さんのような人も使うと思うとやっぱりフリーで免責事項書いたって
やだな（わら

別に>>1は嫌いじゃないぞ、そういう何かに挑む姿勢は好きだ。
いろいろ試してみて３ヵ月後くらいにはいい友達になれそうだ、がんばれ

>>124
それは、素人が使って、あとからうだうだ言われるのがたまらん！
という事でしょうか？
確かにそうかも知れませんね。ボロクソ言われているKENT氏にしたって
サポート面だけは評価されてるようですし。ソフト（スクリプト）ってのは
例えどんなに良いものが書けても、使う側ってのは自分の能力じゃなく
そのソフト（製作者）に全責任を取らせようとしますからね(藁
あと、激励本当に感謝です。地道に勉強を続け、ここで進捗状況を報告させていただき、
たまには、質問もさせていただこうと思います。
って、「日記に使うなｳﾞｫｹ！！」とか言われそうですが（ｗ

>>125
日記につかったら呪いますから。

>>125
それは一理ありますね。
自分の場合、ネットショップやってて、カートも自作ですが
商売をしてない人が作ったカートは、やはりそれなりです。
ショップ側にも、お客さん側にも細かい気配りができていない
ことが多いです。

まぁ、1つも作っていないくせにKENTさんのことを言ってる
ｳﾞｫｹよりはマシだけどね。

＞1つも作っていないくせにKENTさんのことを言ってるｳﾞｫｹよりはマシだけどね。
すいません、私の書き方がﾏｽﾞかったでしょうか・・・
私自身がKENT氏をどうこう言う立場に無いのは100も承知のつもりです。
実際、趣味でやってるHPでも使わせてもらってますし。
そんなんで、たまたまこの板のKENT氏関連のｽﾚ見たら、ﾜﾘと評判が悪く、
それでもコトアフターフォロー（サポート）に関しては悪く言ってる方が
いなかったので、引き合いに出させていただきました。
お気を悪くなされたのでしたら、申し訳ありませんでした。

ところで、今フォームから受け取ったデータをタブ区切りでファイルに格納し
その中身が
商品名　価格　個数　値段
みたいになってるんです。でカートの中身が増えていくと行が増える。
で、最終的に合計金額を求めるのに、
open (FH,$file){
@list=<FH>;
close(FH);
foreach $line(@list){
@item=split(/\t/,$line);
$count=unshift(@list);
$total=$item[4]*$count;
}
}
とやっているのですが・・
他にもっとスマートなやり方って有るのでしょうか？
一応走らせてみると期待通りの結果は得られてるんですが。

うわ・・・
↑じゃﾀﾞﾒだった・・・
足し算を繰り返さなきゃﾀﾞﾒですね・・・・・やりなお〜し

レスの速さは凄いですね。いやみじゃなく。
それだけで、かなりの売り上げ増に結びつくから
あなたが通販やった方が良いですよ。
これだけスレが伸びるのが、その証拠。
カートの使いやすさも大事だけど、個別の対応も大事。
と、関係ないマジレスしたりして。

ﾀﾞﾐﾀﾞ、合計が出せない・・どなたかご教授ください
$total=$kingaku+$kingaku+kingaku+kingaku･･････
ってのをやりたいんです。で$kingakuてのが何回来るかわからず、
$kingakuが一定なら>>129でやったみたいに個数だして掛け算すれば
良いんですが・・・・・

>132

中身は良く知らないけど、価格が販売価格、値段が価格×個数ということでいいのかな？
だとしたら、

open (FH,$file);
while($line=<FH>) {
($hinmei,$kakaku,$kosuu,$nedan)=split(/\t/,$line);
push (@kakakus,$kakaku);
}
close(FH);
$all_kakaku = 0;
foreach $kakakus(@kakakus) {
$total = $total + $kakakus;
}
で、良いのでは？
きっと誰かが最適化してくれるだろうけど。

>133
あ、訂正。

> close(FH);
> $all_kakaku = 0;
> foreach $kakakus(@kakakus) {
の、$all_kakaku　ってのを、$totalになおしてね。

>133
ほかの処理が泣く、単に合計出すだけだったら、

$total = 0;
open (FH,$file);
while($line=<FH>) {
($hinmei,$kakaku,$kosuu,$nedan)=split(/\t/,$line);
$total = $total + $nedan;
}
close(FH);

だな。
しかも、前の、ちょっと間違ってるし。

てか、
$nadanはchompしないでOKなんですか？
俺はいつもやっちゃうけど無駄なんですか？
あと、
$total += $kosuu * $nedan;
かと思った。

$nadanは→$nedanは

>136
わかんない。動作確認してないし、サンプルデータもないし。
下書きも校正もしないで書き終わったらがんがん書き込んじゃったから。

カートはMySQLとかPostgreSQL使うのがラクチンでいいよ。
追加、削除、計算も簡単だし。

PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL
PostgreSQLPostgreSQLPostgreSQLPostgreSQLPostgreSQL

そんな甘いもん出ないよ！おれなんかショッピングカートで地獄見たもん
質問もすごく初歩的な四則演算とかしてるぐらいなんだから
アルゴリズムについてもっと勉強してからスレッドたてれ！
PGってそんなあまくないよ！！
設計の手法だって勉強しないといけないしさ！
初心者だから？
おいおい・・・・・システム作るのがドンだけ大変か
なんか怒りを覚えてきたぞ！
PERLの特性ってしってんのか？
PERLでやるよりプログラムの基礎勉強しろ
ああ
はらたってきた

. ∧　　 ∧
(　´ ・∀・｀)　へー

（　・∀・）y━~~ ﾌﾟﾊｰ　ﾏｧﾏｧ>>141ｵﾁﾂｹﾖ

>>141
まあ、そう怒らずに。
これから>>1が身をもって知るんだから。

さて、ここまでのまとめ。

・共用サーバーで運営する（？）
・言語はperlで
・RDBMなどは使わずCSVファイルにてデータを管理
・今あるものは使いにくいからインターフェースにはこだわりたい
・>>1はまったくの素人である
・合計金額だすだけであたふたする>>1の支援人ももうちょっと勉強しろ

これくらいでよろしいか？

さて、ここまでの結論

・>>1には絶対無理

でよろしいか？

>145
＞・合計金額だすだけであたふたする>>1の支援人ももうちょっと勉強しろ

ああこれおれのことか(笑)
勉強というか、ちゃんと睡眠取るようにするよ(笑)

すまん
>>143
>>144
怒らずにはいられんかった
PGなめてんのかってぐらい無知だからさ！
ふぅ　

. ∧　　 ∧
(　´ ・∀・｀)　へー

（　・∀・）y━~~ ﾌﾟﾊｰ　ﾃﾞ　>>1ﾊﾄﾞｺｲｯﾀ?

>149-150
社会的弱者は役に立たないから、２ちゃんねるに来なくていいよ。

>怒ってる方
別に、プログラムを馬鹿にしているつもりは無いんですが、気分を害されたようなら
申し訳ありません。四則演算云々に関してはおっしゃる通りです。学生の頃
もっと数学勉強しときゃよかった・・・・
いろいろ、親切にレス頂いてる方もいるので、ありがたい限りですが、
やはり大勢として「システム構築」「セキュリティ」「運用」という
話が結構出てきますね。やはりプロフェッショナルな方が多いからでしょうか？
自分としては、それこそ「とりあえず動くスクリプト」という気持ちで
作り始めてるので、舐めてるといわれればその通りかも知れません。
ここにｽﾚ立てたのは、外部と違って、多方面の情報をいただけるかな・・・と・・・

現在の進捗状況。
合計を出すのは>>135でいけました。ありがとうございました。が・・・
ここまで来て気が付いたんですが、注文ボタン押すたびにｔｍｐファイルに書き込んでたんじゃ、
同時に二人以上の人が使えないですよね・・・
注文の最終段階まで配列で処理していって、最後に吐き出すようにしないとﾀﾞﾒなのかなぁ・・・・
というわけで、振り出しに戻ってます（藁

セッション管理ィィィィィィィィィｨｨｨｨｨｨｨｨｨ

なぁ>>1よ
過去のログは読んでるかい？たとえば>>99なんて結構親切に書いてくれ
ていると思わないかい？
我々も段階を追ってアドバイスしてるのだ、だがどうしても説明しき
れないことがあるから具体例も出している。
経験して失敗するのはかまわない、そっちの方が身になって覚えるこ
とができるからな。でももし>>99のようなアドバイスを難しいから
とか面倒だからと言って聞き流してるとだれもアドバイスをくれなく
なるよ。

だから>>153のキーワードも大切にして欲しい。
多分セッション管理と聞いて難しいことをしているように思えるだろ
う、説明している人によっては理解不能なくらい難解な言葉を使って
いて読みにくいことだろう、でもperlには効率的なセッション管理は
苦手とする分野だ。

>>141のぶち切れてる部分を除いて読んでみて、perlの特性と言って
るがセッション管理にも十分出ている。たとえばこれをPHP4でやろう
とすれば簡単にできるのだよ。
とりあえずはperlでできることを学んで行こう。キーワードはわかる
ね、セッション管理だ。

. ∧　　 ∧
(　´ ・∀・｀)　へー

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だしな。

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

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

　　　　　　　　　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　 　 　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　>>1 ねぇねぇまだなの？早く早く〜
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　 長野りんご. 　 |／

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

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

>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は効いてないんじゃないかな。

例えばcookieに"../xxxx%00"とか仕込まれて、汚染チェックをしていないと
cartファイルが../xxxxになってしまう。

ブラウザから渡されたデータは全て信用できないものと仮定して汚染チェックを行わなければいけない。
それをReadParseの中でやっているのなら問題はないが、汎用ルーチンのようなのでやっていない可能性大。

お、直ってんジャン、CGIの吐くタグ。
まだ余計な<center>が<body>の前にひとつついてくるが。
EUC統一ついでにHTMLファイルもEUCに統一しちゃうと、フォームから入力される
文字コードはEUCと決め打ちできるから、入力段(&ReadParseのあと)でのコード
変換は要らなくなるぞ。

いま化けるのは>>255さんの言うとおり、商品ページがSJISで、jcode.plが
SJIS->EUCを変換し切れてないからだろう。
（ひょっとするとメールの件もここの変換ミスが一枚絡んでいるかもね）

&ReadParse( *form);
foreach $key(keys %form){
　　jcode::convert(\$form{$key}, 'euc'); #現在内部処理をEUC統一したそうなんで
}

とかのほうがベターだろう。（生書きだから検証してないけど）

いろいろありがとうございます。shop.cgiに関しては少しずつ煮詰めていきたいと思います。
さて、これを始めるきっかけにもなった商品用ページ作成用CGIの作成に取り掛かろうと
思ってるのですが、その方法についてお知恵拝借いたしたく。
作りたい商品ページの形式としては今ｳﾌﾟしてあるようなかたちです。
画像ファイルのアップロード等勉強しなくちゃいけないことは山ほどあるのですが、手順として
どういうものがあるのか。
今考えてるのは、テーブル一個分の項目（１商品分）を一行としたdatファイルに保存しておいて
それにタグを挿入してHTMLファイルを作るというものです。新規商品を追加する時や削除
する時はそのdatファイルを呼び出して編集・削除・追加を行いHTMLファイルを丸々上書きという
方法です。HTMLファイルを直接いじるのはタグなどが邪魔して非常にめんどくさそうなので、
HTMLファイルをいじるのではなく、datファイルを編集してそのたびにHTMLを書き直すほうが
楽かなぁと思ったので・・・・
HTMLを作らずにdatファイルからcgiで表示も考えたのですが、鯖の負荷等考えるとHTML生成しちゃった
方が良い気もしたので。
あとページごとのデザイン等の一括変更とかの機能にはCSS使うしかないですかね・・

編集、削除が出来る掲示板で、管理者以外カキコ禁止にすれば、あと一ひねりだろう。

画像は専用ディレクトリを作って、ファイルリストをgetして、
BBSの書き込みフォームのページかなんかにWidth/height指定してfilenameと
画像をサムネイル表示。
書き込みフォーム自体にはプルダウンメニュー(select/option)か何かを動的に
生成して、書き込み情報に加えるとかすればOK

画像ｳﾌﾟは説明が長くなるから、まあ「form multipart」あたりでｸﾞｰｸﾞﾙ逝け。

デザイン一括変更は雛型式（デザインを外部ファイルで指定）のBBSを
(拾ってく|作)ればいいんでないかい？

なるほど、掲示板を応用すれば良いんですね。商品ページは複数ページ作りたいんで、
・多板作成が可能
・板毎のデザイン変更が可能
・書き込み内容編集が可能
・画像アップロード可
って掲示板探してそれを参考にしてみよう。
・・・・って思って、画像以外は２ｃｈ型改造のAhhanBBSがよさそう
なんでソース見てみたら複雑すぎてわけわかめ（鬱
もうちょっと簡単そうなの探してみよう。
というわけでCGI INDEXとCGI ZOOで旅してきます。

ttp://cgitest.s7.xrea.com/cart.txt
これみれなくなってるぞ？！
けした？
おれもソースみてみたいからみせてくれ>>１
なんかだいぶできてきたみたいだね！

>>261
スイマセン消してました。
またアップしますのでしばらくお待ちください。

うぃ！たのしみにまっとるよ！

あげ。

ちょっと仕事がつまり気味で、停滞中・・・・・
>>263さんｽﾝﾏｿﾝしばらくお待ちください

1よ、もうこのスレは放置かい？

スイマセン、ちょっと仕事が立て込んでて・・・・
尻取りスレにでも使っといてください

援助交際な出会い
http://www.kgy999.net/e.html
女子小学６年生レイプ画像
http://www.kgy999.net/imc/434233455231.jpg
女子小学６年生レイプ動画
http://www.kgy999.net/imc/94324.mpeg
ertret

r r
et rt

良くココまで来た・・・。

ちと進行が遅くなってるのが残念だけど、無謀者氏とレベルが
近しいので、実用的な読み物としてヲチしてます
…ま、目先の仕事優先は仕方なし…かな？

>>267
あんたさ、折角なんとかマトナなスレになりつつあったのに、
尻取りスレにでも、は無いだろう。
一体どういう神経してるんだよ。

それじゃ、始めるぞ。


「パール」

>271
まったくだプンプン。
早く帰ってくるのみんな待ってるのに。

「ルビー」

おいおい、本当に>>1は呆れた奴だなー

「ビール」

「ルビー」（´Д｀；）

>274
しりとり侍かよ！

フォッフォ
「ビール」

仕事が忙しいのは仕方ないとして、

ttp://cgitest.s7.xrea.com/cart.txt

これの再アップだけでもして欲しい・・・

なぁ、>>1よ
俺も君と同じようにPerl馬鹿だった。
でもさっきPHPの本を軽く読んでみた。
馬鹿にならんくらい簡単だぞ、これくらいできるようになった君ならあっという間に
完成できるかもしれない。
PHP4をお勧めするよ、マジで。
こんなにセッション管理が楽だとは思わなかったよ。

>>276
お待たせしました。ｳﾌﾟ完了です。
最初のに送料計算用のスクリプトを加えようとしてるんですが、今のところ機能
してません。しばらくいじってなかったらすっかり忘れてるし(ｗ

>>271-275
ご協力ありがとうございます。てか、一瞬で終わってるな・・・・
>277
PHPは最初の方でも勧めてくれた方がいたような・・・・
とりあえず現状最もデファクトスタンダードに近いと思われるという事で
Perlから始めて見ました。まぁ、こんなタラタラやってるうちにPHP全盛って事に
なったりは・・・・しませんよね？

というわけでまたボチボチ続きを始めますのでよろしくお願いします・・・（何をだ？）

送料の自動計算と「〜円以上送料無料」のの機能を追加してみました。
未だに微妙に文字化けするのがﾁｮｲ鬱・・・・
文字コードをフォームのHTMLも含めて見直してみます。

ほう、ちゃんと計算できてんじゃん

>>279
HTTPヘッダのところでも指定した方が良いよ

>278
そうだね、現状ではサーバを製作者側で指定できない限りはPHPはまだ使えないね。
ｼｶｰｼPHPも4になってほぼ機能的に出尽くした感があるし、ぼつぼつ標準設置の
ﾚﾝ鯖増えてきたし、WebアプリののRADとして、Perlとはすみわけしながら普及
しそうな勢いがあるな。

ところで設置URIは、上記と同じ
ttp://cgitest.s7.xrea.com/cgi-bin/shop4.htm
でいいのかえ？最終確認画面で文字化けしちょるようだが

なかなかのデザインだのう。
はよ完成して動くことを祈る。

Mac/iCab2.71で見ると、購入ボタンの次の画面でunknown Content-Type:　が出よりますな。

CGI中のHTMLヘッダで文字コードを指定する場合って、たとえばeucにしたいのなら
"content-type: text/html;charset=EUC-JP\n\n";

で良いんでしょうか？ここで言われたので、ぐぐるで検索掛けてみたら
上のような書き方がちらほらあったので。ただ「文字コード、charset」とかで検索すると
ほとんどが<META>タグの記述方法になってるので、いまいちこれでいいのが自信が無い・・・

いまさらながら気が付いたんですが、どの本読んでもhtmlヘッダ
に関しては
"content-type: text/html\n\n"
を書けとしか書いてないんですよね。散々文字コードの事は書いてあってjcode使って
コンバートしろとかは書いてあるのに・・・・

スイマセンsage忘れ・・
間に合いませんでした。

>>285
あってる。
ただ、；のあとに半角スペース入れた方がいいのかな
意味あるのかは知らないけど、みんなやってるということで
print "Content-type: text/html; charset=euc-jp\n\n";

でもmetaにも書いてくれると親切だ。

ありがとうございます。ヘッダとMETA両方にしつこいくらいに書きます（ｗ
しかし、なんで入門書にこれが書いて無いんですかね？
文字コードの自動判定なんてまともに出来ないｳﾞｧｶブラウザがゴロゴロしていて
純粋なHTMLはS-JISで書くのが一般的（？）なのに・・・
いくらフォームデータエンコードしても、CGI内のHTML表示部分で
ちゃんと指定しとかなきゃ行ったり来たりしてる間にブラウザも迷うっちゅねん！
と思うのですが・・・・

ところで、皆さんはCGI内のHTML部にMETAとか<HTML></HTML>書くときに
何処に書いたらいいかわからなくなる事無いですか？
一箇所で完結すれば良いんですがHTML出力を前半と後半をサブルーチンで
分けたり、使いまわしたりする時に、</html>は何処に入れるんだ？
とかここは<html>はいるのか？みたいに

>>288
そうだよ両方書くんでちゅ。
それが当たり前でちゅ。
ていうかここで2回も書いたんでちゅ。

ヘッダ出力とフッタ（は要らんかもしれんが）を
サブルーチンとかモジュール化したら？
CGI.pmでもヘッダ出力できるけど、
日本語の場合、文字コードの指定が必要だから
ジブソで用意しました。

>>289
うろ覚えだけど、最近の CGI.pmなら
文字コードやContent-Typeとかも
指定できた気がする

えらいぞ！短期間でよくここまで！
後は２８９のいうとうりモジュール化することを進めるよ！
あとでつかいまわしができるよ！

CGI.pmでヘッダ出力できるよ。

#!/usr/bin/perl

use CGI;

$query = new CGI;
print $query->header(-charset=>'Shift_JIS');


おいらは最初にヘッダを出力しちゃってそれぞれの出力終了時にフッダの
サブルーチンに飛ばしてる。

>>289
＞ていうかここで2回も書いたんでちゅ。
そうでしたね。いや、読んではいたんですが、どうしても>>285の方法が
はっきり自信持てなかったもんで・・・・
＞CGI.pm
その辺の事は今後順次勉強していきたいと思います。とりあえずはできるだけ
自分で書くというのも勉強になりますので・・・
＞モジュール化
プログラム経験が無いのでモジュールと言うものの概念がいまいちワカランのですが
「良く使うものをサブルーチンにして、それを別ファイルに纏めておく」と言うことで
良いんでしょうか？
>>291
ほんとにここでスレ立ててよかったです。本とかWEB情報だけじゃこの短期間ではとてもじゃ
無いけどここまで出来なかったと思います。
調子に乗って「ド素人のド素人のためのCGI入門」のHPでも立ち上げようかな・・とか思ったりしてます（ｗ
ここまでやってきて思ったのは「初心者用」とか「入門」といううたい文句の本やWEBの説明も
所詮（失礼ですが）プログラマーの方が書いてるので、「ド素人が如何に無知か」という事がいまいち
理解されて無いようなので・・・

>>292
print $query->end_html
これで終れる

>「良く使うものをサブルーチンにして、それを別ファイルに纏めておく」
>と言うことで良いんでしょうか？

サブルーチンをファイルにしてメインからrequireするあたりがモジュール化の第一歩。
そこから名前空間の概念覚えて、別ファイルのほうpackage宣言してみて、って
少しづつ覚えていけばいいと思うよ。（その先がまだ長いんだけれど‥‥）
いきなり.pmモジュールなんていうとワケわかんなくなるからね。

で、商品ページの方はどうよ？

>>295
なるほど、そんな単純なものではなさそうですね＞モジュール

＞商品ページ
いかんせん仕事の都合で間があいちゃったんで全然出来てません。設計書を作ってる
最中だったんですが、今読み返してみるとようワカラン（ｗ
もう一度１からやり直しです。最初はフォームからHTML生成しちゃおうと思ったんですが、
在庫数をカウントしたいので、cgiからdatファイルから読み出してHTML表示させるしか無さそう・・・
HTMLにHiddenで入れようとも思ったのですが、商品が減る度にHTML書き直させなきゃならなそうだし。
ただ、全てをCGIにやらせると鯖の負荷も高くなりますよね？どうしたものか・・・・

>296

open (READ,$filename);
　@data = <READ>;
close (READ);
#@dataに対して必要な処理
open (WRITE,">$filename");
　print WRITE @data;
close (WRITE);

式でやると、.datの件数が増えると負荷もかかるしメモリも喰う。
これは鯖屋さんに嫌われる。（警告が来たり、いきなり垢止められたりする）

open (READ,$filename);
open (WRITE,">$tempfile");
　while($line = <READ>){
　　#$lineに対して必要な処理
　　print WRITE $line;
　};
close (WRITE);
close (READ);
rename ($tempfile, filename);

式でやるなら、1セッション中に（検索と在庫デクリメント程度であれば）
複数回処理かけても大した負荷（プロセス時間）にはならないし、メモリも
喰わない。この方式で数百〜1万件(行)程度の処理しつつHTMLを吐かせる
CGIを一般の複数件のレン鯖に置いているけれど、苦情は来たことがないぞ。

この場合、.datはTABまたはSPACE区切りテキストがいいな。
一般配布のCGIにはカンマ区切りが多いけど、UNIX育ちのPerlのsplitは/\t/
や/\s+/に対し最適化されているから、行数が大きくなったときの処理時間の
差は結構馬鹿にならない。

カンマ区切りだと例外処理がウザい（書き込み時にデータにカンマがないか
チェックするか、Excelなcsvにすべくクオート処理せねばならん。後者の場
合、単純にsplit出来なくなる）しね。

プチECとしてはデータ内に半角スペースも含まれるだろうから、TAB区切りが
一番いいだろう。

えーとパスワード認証してるCGIに直接アクセスするにはどうしたら？
フォームが
<input type="password" name="pass" size="10">
<input type="hidden" name="mode" value="login" >
になっていて、

&ReadParse(*form);
$pass=abc;
$fpass=$form{'pass'};
if ($fpass eq $pass){
＃−−−メニュ画面ーーーーー＃
}
ってなってるんですが、後の（他の）処理の中でその処理終了後
メニューに飛ばしたいんです。hogehoge.cgiになんかくっつけて呼び出す（?pass=とか？）
ような感じになるんじゃないか？というところまではたどり着いたんですが・・・・・

ﾊｧ？
メニューに飛ばす？
なんか意味わかんねぇ

すいません。書き方悪かったですね・・・・流れとしては
フォーム（HTML）からパスワード入力＞menu画面（menu.cgi)＞データ入力
＞データ入力後refreshでもう一度menu画面に戻る。
てのをやりたいんですが、戻り先をmenu.cgiにするのにパスワード
を渡す方法をがわからないんです。そもそもFORMのinputで渡すような項目を
Formを使わずに渡す方法ってどんなのがあるんでしょう？

>>300

方法としてアドレスに埋め込む（リフレッシュ先のアドレスに仕込む）
hoge.com/menu.cgi?id=hoge&pass=hoge

HIDDENを使う
データ入力の度に
<INPUT HIDDEN NAME=id VALUE=hoge><INPUT HIDDEN NAME=pass VALUE=hoge>
これを必ず仕込んでおく

なお、どちらの方法でもmenu画面で逐次パラメータを取得して次に渡す必要がある

的外れの返答かな？

自己訂正

当然ながらHIDDENを使うときはFORMタグを必要としますからね。

ありがとうございます。その辺を知りたかったんです。
つまり、通常フォームから
<input type="password" name="pass" size="10">
<input type="hidden" name="mode" value="login" >
と言う内容をsubmitボタンを押すことにより送信するんですが、
その内容をフォームを使わずに渡す方法を知りたかったんです。
>>301の説明だと
menu.cgi?mode=login?pass=123
とかで良いんですかね？
でスクリプト中で$loginpass=123とか指定しておけば、cgi内から上記のように
リンクかける場合は
menu.cgi?mode=login?pass=$loginpass
としておけば大丈夫って事ですよね？


とりあえずやってみます。

パラメータは&で繋ぐ

>>303
そのとおり。
あと老婆心ながらＨＴＭＬのタグを書くときに""（クオーテーション）はいらない。
""がいるのはスペースが含まれる場合のみ。
""を省略するだけで結構処理スピードがあがるよ。

ありがとうございました＞教えてくださった皆様・
うまくいきました。
ちなみにこれと同じ方法を使ってFORM内の
Submitボタンを画像とかに置き換える事は可能なんでしょうか？
ボタンの変わりに画像貼ってそれのリンク先をmenu.cgi?neme=submit
ってやるとsubmitボタンとして動作します？

>>306
<input>タグでできる。

http://tohoho.wakusei.ne.jp/html/input.htm

皆様いつもありがとうございます。
商品ページ作成部分が若干出来たのでｳﾌﾟしました。
ttp://cgitest.s7.xrea.com/cgi-bin/admin.htm
から入れます。パスワードは「123」です。
今のところ、商品カテゴリーの作成と商品の追加しか動きません。
カテゴリーを追加した後に商品を追加する事になります。既存のカテゴリーは
「商品群１」と「商品群２」です。
商品群１の内容は
ttp://cgitest.s7.xrea.com/cgi-bin/main.cgi?mode=show&fname=test
で
商品群２の内容は
ttp://cgitest.s7.xrea.com/cgi-bin/main.cgi?mode=show&fname=test2
で見られます。
カテゴリーを新規作成の際のファイル名は拡張子無しで。新しく作ったカテゴリーの
内容を見るときは
ttp://cgitest.s7.xrea.com/cgi-bin/main.cgi?mode=show&fname=”作成時につけたファイル名”
できるはずです。

あ、今現在新規商品作成時に指定したオプション項目は反映されません。
「,」で区切って入力してもらって、そこからセレクトボックス生成させる
のを今作ってます。

うーん、せっかく上手くいっているところに水を差すようだが、
URIでパスワード指定やっちゃうと、認証もクソもないぜ。
URIがバレた時点でｿｯｺｰで改ざんされっぞ。
googleツールバーの高機能版では閲覧中のURI自動通知されちまうしな。

「登録しました」のページに「メニューに戻る」ボタンをつけて、
hidden渡しじゃだめなんかい？
どうしてもrefreshでやりたいなら、refererとってCGIと認証ページからの
アクセスのみ許可するとかやってやんねーと。

>>311
確かにそれは思ったんですけど、一応pass入れたあとの管理者用画面だから
大丈夫かな・・・と考えてたんですが・・・・・
hiddenで入れてもソース見ればそのままpassが見えちゃうわけですし・・・・

>>312
postで(formから)passが入ってこないときadmin.cgiがエラーメッセージ吐いて
終了するようにすりゃいいんだよ。したら、URIがバレても簡単にはアクセスでき
ないだろ？
#!/usr/bin/perl
require 'cgi-lib.pl';
my $method=$ENV{REQUEST_METHOD};
$pass='123';
&ReadParse(*form);
if ($form{'pass'} ne $pass or $method ne 'post'){ #passミスマッチとGET拒否
print "Content-type: text/plain\n\nForbidden.";
exit;
}
#──以下処理。formを吐く場合は必ず
#<input type=hidden name=pass value=$pass>を仕込む

GET全拒否しちまってるけど、たとえば、こうよ。

>hiddenで入れてもソース見ればそのままpassが見えちゃうわけですし・・・・
上みたいな処置しときゃadmin.cgiにマトモにソースを吐かせるのに絶対にpostで
pass渡さなきゃいけねーから、過信は禁物だがpassを知らない限りソースも見れん
ワケよ。admin.htmにはpass書くわけじゃねーんだしさ。

#漏れはCGI.pm詳しくないんだが、CGI.pmでpostとgetの読み分けは出来んのかなあ。
#詳しい奴ﾌｫﾛｰﾀﾉﾑ

後、>>311でも書いたがrefererとって
ttp://cgitest.s7.xrea.com/cgi-bin/admin.cgi
ttp://cgitest.s7.xrea.com/cgi-bin/admin.htm
以外からのアクセスは弾いちまえばいいんだよ。

ちょっと機能追加
登録済み商品の修正が出来るようになりました。
＞商品登録テストしてくれて人
今のところ、文字置換やエラー処理全然いれて無いので、コメントのところで
改行入れるたり、新規ページ作成時に、ファイル名入れないと、データﾎﾞﾛﾎﾞﾛになります（汗
明日（今日か・・）必要フォーム項目未記入時のエラー処理と、改行その他、文字列の
置換処理を出来るようにします。

>>311=313
なるほど・・・・と入っても、いまいち管理用画面でのその辺のセキュリティの必要性が
理解できて無いんですが・・・・・
どっちにrefererとって弾く事だけはやっておいた方がよさそうですね。

ところで、今回、新規データ入力時に
@data=($no,$hoge,$mona,$gik)
$line=join("\t",@data);
open(FH,$file);
@logdata=<FH>;
close(FH);
open(WRITE,">$file");
print WRITE $line;
print WRITE @logdata;
close(WRITE);
として、新しいものが上に来るようにしました。
で商品修正時にココの前で教えてもらった方法2の応用で
@newdata=($no,$hoge,$mona,$gik);
$line=join("\t",@data);
open(IN,"$file");
open(TMP,">$temp");
print TMP "$line;
while(<IN>){
my @cell = split/\t/;
if($cell[0] ne "$no"){
print TMP;
}
}
rename($temp,$file)
ってやってるんですが、この方法だと、修正したファイルがデータの一番上（一行目）に
来ちゃうんですよね（そういう風にしてるんですが）
これって、たとえば4行目のデータだったら、また同じ所にかき戻す方法ってどうやれば良いんですか？
if($cell[0] ne "$no"){
print TMP;
の後に
if($cell[0] eq "$no"){
printTMP $line;
でうまくいかなかったです。書く位置がまずかったんでしょうか？

$noは数値だよね？
なら、

while(<IN>){
my @cell = split/\t/;
$_ = $line if $cell[0] == $no;
print TMP;
}

で数値評価したらどうかな？
なんとなくだけど、$cell[0]か$noに空白とか含まれてそうだったんで。

>>316
うまくいきました。ありがとうございます<IN>
で変数が$_に入ってるってのがすっかり頭から飛んでました・・

ところで、正規表現なんですが、たとえば$priceに半角数字以外（「,」とか）が入ってた場合に
エラーを表示させるのって
if ($price eq ~/\D/){
print "価格はカンマ無しの半角数字で入力してください";
}
で良いんですよね？

>>317
全然違う。検索は $scalor =~ /$hoge/;　だぞ。

if ($price =~ /\D/) {
print "価格はカンマ無しの半角数字で入力してください";
}

まあがんばれ。

↑の通りに書いてみたら,半角数字も弾かれちゃいました・・・・・

>319
\Dは数字以外じゃない？
http://tohoho.wakusei.ne.jp/wwwperl1.htm#Expr

そうだと思うんですが・・・・
だから
$price=~/\D/;
だと「$priceに数字以外のものが含まれていれば」
って事になりますよね？

だから半角数字だけならエラーにならないんじゃ？

のはずなんですが・・・・弾かれちゃうんですよ・・・
もう一度ソース見直してみます。

ってかさ、数字以外は取り除けばいいんでない？
そっちの方がユーザーライクだと思うが。

$price =~ tr/0-9//cd;

>>319
スペースも渡されてるとか

それも考えたんですが、全角数字入れられた時の対応も一緒に
やっちゃおうと思ったので。

＞３２５
そう思って
[\D\s\t]とかもやってみたんですが・・・ﾀﾞﾒ

適当なファイルに書き出して見てみたら？
CGI::Carpとかでハンドルしてるなら warnや dieで見てもいいけど。

もうめんどくせえから、全部最初からやり直せ！！

そうか、上手く逝ったか。漏れこのスレ、検証してないやつばっか（297とか^^;）
書いてるから、ちょっと心配してるんだな。

> で変数が$_に入ってるってのがすっかり頭から飛んでました・・
慣れると便利なんだよ、デフォルト変数$_。
はまると怖いけどね。

で、正規表現検索は相手が文字列でも
if ($price =~ /\D/)･･･
だよ。

えっと、上記の処理より前に
if ($price eq ""){
print"error"
}
・
・
＃その他変数の未記入チェック
・
・
ってやってから上の処理やってるんですけど、その辺は関係あります？
一応、未記入のエラーはちゃんと表示されます。
で、上記の検索を書くと、数値だろうがなんだろうが弾かれちゃう・・・

うわ、
if ($price =~ /\D/){
print "$price";
}
ってやったら、入力したのと違う数字が出てきた・・・・・
この数字どっから来たんだろ？？？
198000って入力したのに429467294って・・・たかどんな数字入れても
おんなじ数字が吐き出されてる？？？？何でだ？
ちなみに置換処理を無くして実行すると、ファイルにはちゃんと入力した
数字が書き込まれてます。

>>330
うわ、とっくに話題が過ぎ去ってやがる。ﾘﾌﾚ忘れた。鬱打

&jcode::tr(\$price, '０-９', '0-9'); #全角数字を半角に変換
if ($price !~ /0-9/){
　　print "価格はカンマ無しの半角数字で入力してください";
}
あたりではどうかな？

>>332
という事は、その処理以前にどこかで$priceに値が代入されてるんだよ。
探しなさい。

え〜〜〜〜
解決したっぽいです・・・
どうやら、使ってるエディタにバグがあるらしく、上書き保存するとなぜか
s-jisで保存されてたっぽい、のが原因みたいです。（設定はEUCにしてるのですが）
お騒がせして本当に申し訳ありませんでした・・・・m(__)m
エディタ変えようかな・・・・・

>>335
俺はいまだにメモ帳使ってるぞ。メモ帳最強。

あと、
＞&jcode::tr(\$price, '０-９', '0-9'); #全角数字を半角に変換
jcodeでこんな事も出来るんですね。フォームデータ受け取り時に
h2zでｶﾀｶﾅは全部置換させてるんですが、そこで数値にしなければならない
変数も全部変換掛けといた方がよさそうですね。
とりあえずご迷惑したお詫びに町内10周走ってきます。

皆様の暖かいご支援のおかげで、
新規ページの追加、商品の登録、編集、削除
までできるようになりました。また
「簡易商品ページメニュー」を作り、そこから商品ページにアクセス
出来るようにしました。（管理画面の中）
ココに表示されるURLをコピペすれば、使う人は、メニューページを
自由に作れるのでは無いかと・・・・
ttp://cgitest.s7.xrea.com/cgi-bin/admin.htm
パスワードは123です。
ある程度のエラー処理と文字列置換は入れたつもりなのですが・・・・

>>338
適当に弄ってれば誰でも使えそうなカンジですね。
って、弄ってみました。
感想：
どのページからでも管理画面に戻れると良いかなあ。
（ページ作る時に何回も戻ったので…）

>>314
>いまいち管理用画面でのその辺のセキュリティの必要性が理解できて無いんですが・・・・・
だーかーらー、http://うんちゃらかんちゃら/admin.cgi?mode=login&pass=xxxって
URIがばれちまったらｲｯﾊﾟﾂで商品ページ改ざんされちゃうだろっていってんの。
PasswordをGETに含めるのはヤバいんだって。直ﾘﾝオッケーだしな。

知り合いとはいえ金絡んでやってんだろ？しっかりしろよ。
商品価格書き換えられたところに注文とか去れちまったら大損害だろ？

URIバレた瞬間にPasswordもってかれちまうんだから、ほんとはPOSTがいいんだけどな、
せめてリファラチェック(GETメソッドはCGI自身からのアクセスみ許可)と、
本稼動のときは変な名前のディレクトリ作って、cgi本体の名前からは予想も出来ねー
よーな名前でrobotよけのMETAつけた認証ページ設置するぐらいの対策はぐらいはしとけよ。

>340
robotよけのメタは、誰も見ていないです。きっと。

＞３４０
詳しい説明ありがとうございます。リフレッシュを止めて、フォームボタンで
hiddenを渡し、リファラチェックも入れるようにします。
ところで、一つのサブミットボタンで二つ以上のアクションを指定する事って
出来るんでしょうか？たとえば
<form method=post action=hoge.cgi>
<form method=post action=hage.cgi>
<input ...
<input....
<input type=submit value=OK>
</form>
</form>
とかやっておけば、submit押した時に、両方にフォームの内容が送られるんでしょうか？

むり(やったことないけど)。
仮に出来たとして、ブラウザはどっちに応答すればいいのさ。

>>342
二つ以上アクションさせたい場合はhiddenでvalueを送ってスクリプト
のなかのifで受ける。
例：
<form method=post action=hage.cgi>
<input type=hidden name=action value=hoge>
<input type=hidden name=action value=hage>
<input type=submit value=OK>
</form>
〜hage.cgi〜
if ($DATA{'action'} eq 'hoge') {
*******************
}
if ($DATA{'action'} eq 'hage') {
*******************
}

>>343-344ありがとうございました。
今、注文受けたら在庫数を減らすってところを作ってるんですが
これが結構大変そうです・・・・・

う〜ん、注文が確定した時（メールを送信する直前）にカートに入ってる
各商品の注文数を、商品ごとに各商品ファイルと照合して、注文数＞在庫数
又は在庫数＝０ならエラー、もし注文数＜在庫数なら、「在庫数ー注文数」して
商品ファイル内の該当商品の在庫数を修正・・・・・
それぞれの処理は、今まで教えていただいた事でかけそうなんですが、データの抽出、条件分岐が非常に複雑になりそうです。

>>346
それって全然簡単じゃない？例としては
if ($ORDER{'mona'} > $ZAIKO{'mona'}) {
print "申し訳ありません。只今$ORDER{'mona'}は在庫を切らしております。\n";
} else {
$ZAIKO{'mona'} -= $ORDER{'mona'}
}
こんな場合こそ、パール独特の変数、ハッシュが力を発揮する時だよ。
ハッシュを上手く使ってね。

>347
えっと、カートの中身が複数だった場合商品によって、格納されているファイルがそれぞれ違うので
まずforeachとかで順にカートの中身を取り出しながら商品の格納されているファイルを、検索(hidenでファイル名を渡してある）して、見つかったファイル名をまたforeachなりwhileなりで
検索して、商品名がマッチしたら在庫数と注文数を比較、それで０か足りない場合は
エラー、もし大丈夫なら、在庫数から注文数を引いて、ファイルに書き直し・・・・

みたいな事をやらなければダメな気がするんですが・・・

@files=glob "$dir/*.dat"; # $dirはディレクトリ名。*.datのlistを得る
foreach $file(@files){
　open FILE,$file or &error;
　while(<FILE>){
　my($no, $hinmei, $zaiko・・・) = split /\t/; #左辺のmyのリストは適当に
　$zaiko{"$file::$hinmei"} = $zaiko;
　}
　close FILE;
}
とかやって%zaiko{"ファイル名::品名"}(%zaiko{"ファイル名::商品番号"}？)に
代入して、%zaikoに対しデクリメント。
>>347さんの言うとおりhashならサーチ用にループしなくてイイからね。
で、

foreach $file(@files){
　open FILE,$file or &error;
　open TMP,">$temp" or &error;
　while(<FILE>){
　my(@dummy) = split /\t/;
　　@dummy[2] = $zaiko{"$file::$hinmei"} if exists $zaiko{"$file::$hinmei"}; #$dummy[2]は適宜変更
　print TMP @dummy;
　}
　close FILE;
　close TMP;
　rename $temp,$file;
}

とかやって戻してやるってのはどうかな？

あ、ここまでやって思いついたが、カートの中身を
%cart{ファイル名::商品名}=注文数
ってハッシュにして、後者の書き戻しループで在庫チェックさせればイッパツだ。
そのほうがイイや。速いし。

えーと、ちょっとヒマがあったんで上の追記を。

カートの中身を
$cart{ファイル名::商品名}=注文数　(注文がない場合は0でなくハッシュを生成しない)
ってハッシュにしてあるとして、

@files=glob "$dir/*.dat";
foreach $file(@files){
　open FILE,$file or &error;
　open TMP,">$temp" or &error;
　while(<FILE>){
　　my(@data) = split /\t/;
　　my $key = "$file::$data[2]"; # $data[2]は商品名ね
　　if (exists $cart{$key}){
　　　if ($data[1] < $cart{$key}){ #$dummy[1]は在庫
　　　　print "$data[2]は在庫が不足しています";
　　　}else{
　　　　$data[1] -= $cart{$key};
　　　}
　　}
　　print TMP @data;
　}
　close FILE;
　close TMP;
　rename $temp,$file;
}

で、読み出し→在庫チェック→在庫デクリメント→書き戻し
が１回で終わると思うんだな。

まあ例によって書きなぐりだから、globでファイルリストを取り出し、
cartをexistsで調べて在庫チェックとデクリメント処理する、
という流れだけ理解してもらえれば。

>>350=297さん
いつもありがとうございます。
せっかく、頂いたんですが、違う方法で実装できました。
次は「在庫がありません」だけではちょっと不親切なので「在庫が無いので買物カゴから削除しました」
と「在庫が足りないので$cyumon個を$zeiko個に変更しました」と表示して
カートの中身を書き換える機能を作成中です。一度に商品ファイルとカートファイルを
の二つをハンドルするので、ループ中の何処で、書き込んで、何処でテンポラリーファイルを
リネームするのかが、書いててわからなくなる・・・・（苦笑
スクリプト一行書くごとに、print"処理結果"　and exit;で出力内容を確認しながら
進めてます

買物を途中で止められた場合、datファイルが残ってしまっているので、それを
定期的に消したいんですが、たとえば最終更新時間から$time以上経過したら
削除させるのって
@files=glob("./cart/*.dat");
foreach(@files){

@info=stat $_;
$deltime=time-60*60*$time
if ($info[9] >$deltime){
unlink $_;
}
}
で、大丈夫ですか？
これを、買物終了時かなんかに実行されれば、誰かが買物を完了してくれたら自動的に
入らないファイルが消える、というふうにしようと思うんですが・・・・
statで得られる時間って　time関数と同じで方式（1700年からの秒数？）ですか？

なんか誤字だらけ・・・
×入らないファイルが消える
○要らないファイルが消える

おお、自力で実装できたか。ガンガン腕を上げていますね。
あとは欲張って機能拡張しすぎてスパゲッティにならんようにね。

statで得られるのはtimeとおなじ*1970年からの*通算秒だよ。
最終更新からの経過だけ調べるだけなら、ファイルテスト演算子-Mで
最終更新からの*経過日数*が得られるよ。
foreach(glob("./cart/*.dat")){
　unlink if -M $_ > $time;　# $timeは日数、0.5なら12時間
}
とか。

画像のアップロードって、難しいですね・・・・

大人のCGI（書籍）
ttp://www.byakuya-shobo.co.jp/hj21/otona/main.html
あたり読んで、ﾊﾟｸれ。
今のお前ならもうこの本のスクリプトを解析、応用できるはずだ。

持ってたりします・・・＞大人のCGI
実は他でソースパクってUpload.cgi作ったら動いた事は動いたんですが
それを、admin.cgiにサブルーチンとして埋め込むと動かなくなります。
そのソースは、CGI.pm使ってたんですが、enctype="multipart/form-data" で受け取ったデータを
ReadParseかけちゃってるのが問題なのかな？とか思ってたりするんですが、関係あります？

そこだ。ファイルデータは生で扱え。
その動いたっちゅうUpload.cgiで、どこをパースしてどこを生で扱っているか
解析してみるのだ。この件に関して間違いのない文書はRFC1867。

ちょっと、頭の中がテンパって来たので、気分転換で、管理画面のUIを整理しました。
ttp://cgitest.s7.xrea.com/cgi-bin/admin.htm
各画面から必要なページに戻れるようにボタンをつけました。
あと、新規ページ作成時と、デザイン変更時に作成結果（変更結果）が確認できるようにしました。

うぷろだでわかんないってどの辺？よかったら書いてみ

なんか、今日xreaが調子悪くないですが？
私のPCのせいだろうか・・・・

しかし、1/10に
> Perlも、いやプログラミングさえ未経験。「必ずわかるCGI」と
> その他の入門書で何とか「掲示板」の仕組みがようやく理解できました。
んな事書いてた>>1が一ヶ月でここまで来るとは正直予想できなかった。

マジすごい！　無謀者さん
素直に感動しました

俺モジュール使え無い。つまり１にいつの間にか越された。ｳﾂｳﾂｳﾂｳﾂｳﾂｳﾂ。。

>356
そんなクソ本を紹介すんな。
誤字脱字だらけ＆ヘタレすぎ。立ち読みしてて叩きつけたくなった。

>>365
マジっすか？？
近くの書店で注文しましたが・・・・

>>365
あれがクソ本だと言うのは構わないから、具体的にどのあたりのコードがヤバいとか、
他にいい本や資料、URIがあったら教えてやってくれ。

実践的で単機能のコードの量、カバーするCGIの範囲では間違いなく現在トップ
クラスの良書だ。

O'REILLYが出してる本ならまず間違いない・・・・・・高い＆重いけど。

久々にレスが沢山ついててちょっとﾋﾞｸｰﾘ
さて、アプロダの件なんですが、今まではスクリプトの頭で
ReadParseかけちゃってて、multipart/form-data使うには
それがまずそう、というヒントを頂いたんですが、いまさら
ReadPaeseの前に
use CGI;
$query = new CGI;
$images=$query->param('gazou');
if ($images ne ""){

#処理
}
&ReadParse;
#今まで通り


で大丈夫なんですかね？要はReadparseはそのままでmultipart/form-dataで
受け取った特定の物だけCGI.pmで処理するというかんじになるかと思うんですが

また、日本語がおかしい・・・
×というヒントを頂いたんですが、いまさら
○というヒントを頂いたんですが、いまさらReadParse止められないので。

それだと後ろの&ReadPaeseがコケる。POSTデータをCGI.pmが先に拾って
まうんやないかな。そんな妙なコード組んだことないから、いざやったら
出来てしまうんかも知れへんけど。

もうこの際CGI.pmで逝きゃええやんと思ふ（書き直しも大した手間じゃない）
けど、まぁ何にせよcgi-lib.plで逝くと決めたんやから、動くコードが落ちて
たからといって場当たりで手を広げるもんやない。

cgi-lib.plを用いたファイルアップロードのサンプル
ttp://cgi-lib.berkeley.edu/ex/perl5/fup.html
と、そのソースや。
ttp://cgi-lib.berkeley.edu/ex/perl5/fup.cgi.txt

読め。ほどけ。取り入れろ。

>>1
ここにCGI.pmのサンプルあり。
http://www.harukaze.net/~mishima/perl/module/upload_by_CGI_pm.html

あぷろだはいまだ研究中で未実装ですが、今までずっと気になっていた
「同じ商品を買い足した場合」の処理を変更しました。
これで、あとはアプロダさえ実装できればほぼ完成かと・・・

ようやくアプロダ実装完了しました・・・
商品画像、ページ背景画像、ページバナー、それぞれあぷろど可能です。
但し、実サイズで表示されますので、あまり大きい画像は・・・・・


というわけで久々にageさせていただきます。
ページメニュー
ttp://cgitest.s7.xrea.com/cgi-bin/menu.cgi
管理ログイン画面 pass=123
ttp://cgitest.s7.xrea.com/cgi-bin/admin.htm

>374
トラフグ100円だったら買うよ。

いいかんじかな？
買い物かごの中をみる、を選択したときに、中身がある場合は常に
「精算する」というか、買い物フェーズに行くボタンが必要かなと思うけど。

reply-to:ﾂ蟆・
この度はご注文ありがとうございます。このメールはご注文いただいた方に自動的に送信
される

確認メールです。追って店主よりご連絡致しますので、ご注文の内容をご確認の上、今し
ばらく
お待ちください


・・・メールが文字化けしているかな？

menu.cgiが吐くMETA
<meta http-equiv=content-type content=text/html; chaset=EUC-JP>
になってるけど、
<meta http-equiv="Content-Type" CONTENT="text/html; charset=EUC-JP">
とクオートせんとばけちゃうよ。スペース入ってるから･･･

あと、「買い物を続ける」のリンク色が背景に溶けこんでて見にくいな。

ま、いずれも小さなことだ。よくやったね！

ほんとよく頑張ったよね。
見習わなきゃと思いました。

ページ作成時に既存の画像ファイルを使えるようにアプロダ以外にファイル名指定
を可能にしました。また、商品やページを書き換える際に画像を削除できなかったので
（てかそうしちゃうと弊害もありそうなので）画像管理用のメニューを用意して
必要無い画像ファイルを削除するプログラムを追加しました。
ひとまずこれで「完成」という事にさせていただこうかと思います。（V1.00)
ファイル名を変えたのでアクセス用URL変更になりました
ttp://cgitest.s7.xrea.com/cgi-bin/login.cgi
パスワードは123です。


さて調子に乗ってCGIZooあたりにシェアで登録してみようか・・とか思ってるのですが・・・・

顧客情報のファイルって、パーミッションを適切に設定しても覗けるんですか？
テキストじゃダメなんでしょうか。

頑張ってるとは思うがシェアで登録するほどのものではないだろ。
まだね。

perlで、画像貼り付け可能な掲示板を作ろうと思ってます。
ユーザに、画像のURLを入力させて、遠隔地にある画像を
表示するわけです。このような場合に、その遠隔地にある画像の
サイズ(ピクセルサイズ)を取得することはできますか？
小さいサイズの画像に制限したいのです。画像ファイル(GIF)の
ヘッダ数バイトを取得できればいいのですが、もし可能ならば、
方法を教えてください！

>>383
7〜8バイト目にwidthが、9〜10バイト目にheightが入ってる。
位置が固定だから楽。（JPEGは可変。）

画像はローカルじゃなくて別サーバーか。
一般的なサーバーにLWPは入ってないだろうから
単純にSocket開いてreadすればいいのでは。力技だけど。
あ、でもSocket自体普通のプロバイダじゃ使えなかったりするな･･･

そういえばPNGもサイズの位置は固定だね。

「フリー」ウェアの精神は最近廃れているのだろうか。
自分を育ててくれたネットに対しての貢献というか恩返しというか、
後塵のために自分も･･････まあいいや。

シェアで置くのか(笑)ひでえな。

設計から実装まで、果てはβテストからデバッグまでここで聞いてたのになぁ。

「フリーで配布しているものはない」「知人に頼まれて急いでいるがPerlは未経験」
というから、ちょっと調べればすぐ解るようなことも教えてきたのにな。

無謀者が苦労に相応した報酬を受け取ることに異論はないよ。
教わろうがなんだろうが今回のCGIは無謀者が作ったんだからさ。

だけどさ、なんか寂しいよな、こういうのって。＞^(無謀者)

このスレにいた人には無料で配ると、不満がでなくなる上テスターまで確保できるんだぜ(笑)
そういう腹芸をこなさないとだめだな。

ここまで作ったんだからシェアにしたいと思うのも人情でしょうけど、これまで
一から無償で教えてきて下さった人たちが、寂しい思いをするのも分かるような
気がします

Perl初心者なのに、ご友人のためにショッピングカートを作ろうと、頑張られて
いるのは偉いなぁ、と影ながら応援していましたが、ここに来て、突然にお金に
対する色気を出してくるのも、うーん、と思ってしまいます
シェアにするのが悪いとかでなく、無謀者さんが一生懸命作られたcgiを無償で
欲しかったからというわけでもなく、なんだか、うーん、なのです(^^;)

うーん、と思う他に、少し悲しいのは、これからこの板で質問する人たちが

「お前も、完成が近づいたらシェアにするとか言いだすんじゃないの？
　なんで、他人の金儲けに俺らがタダで協力しないといけないのよ？」

と思われることでしょうか
まあ、簡単なことも自分で調べない教えて君が減って、むしろ良かったりする
のかも知れませんが(^^;)

ただ、私なら、自分で作ったcgiなんて信用できないので、私用に使うのなら
ともかく、他人に使ってもらおうなんて、恐くてとても考えられないのですが、
無謀者さんはその点、勇気があるなぁ、と純粋に感心しました

ところで、自分は、欲しいcgiがあったら海外の物を探して、適当に日本語化して
使うのが主なので、よく知らないのですが、シェアのcgiって、そんなに需要の
あるものなのでしょうか？
無謀者さんのおっしゃってたcgizooを見ると、結構な数のシェアcgiがあるよう
ですが・・・

>391
実際あるよ。
というかね、個人に対する需要はともかく、やっぱCGIていうのは、Webデザインとか
設計の問題とかがあって「オーダーメイド」なものなんだよな。
んで、CGIとか出しておくと、オーダーが入る。
お金払うからこういうもの作ってくれ、とかね。
儲けというか、良い小遣い稼ぎにはなる。

115 ：参加するカモさん ：01/12/21 19:46
http://gotonext.cool.ne.jp/gazou/hiroyuki02.jpg
ひろゆき、歯まっ黄色！！
歯糞だらけ！！びっくり！！（･∀･）ｷﾀﾅｲ!!ﾋﾞｰｸﾘ!!

ひろゆきへ

歯みがきしましょうね・・・・

156 ：参加するカモさん ：02/01/08 14:08
>>115
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死
死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死死

157 ：参加するカモさん ：02/01/08 14:11
>>115
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪
呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪呪

卒業研究でショッピングシステムとか作るってのは今更というカンジかなぁ。

＞このスレにいた人には無料で〜

素人が作ったものなんかいらんよ

シェアで配布でもいいんでない？
その後いろいろな問題にぶちあたりまたこの板を利用して質問してくることだろう。
何度かそれを繰り返して一人前になったらここで同じような疑問をもった人間に教
える立場に変わってくれればいいんでない？

俺はオーダーメイドのものしか作らないけど、配布に耐えれるだけのものをつくる
にはかなり大変だからねぇ、まぁがんばれよってことだ。

ども。やはりシェアに関しては予想通りお叱りを受けてしまいましたね。
自分でもまだ迷っています。まシェアにしたからって必ず売れるというもんでも
ないでしょうし、何人かの方がおっしゃるとおり実用にどこまで耐えられるものなのか
まだ未知数ですし・・・
とりあえず、開発するきっかけとなった友人の所では取り合えず設置しておいた
フリーの奴で「使い方なれてきたからとりあえずこのままで」っていわれて
行き場がなくなってしまいました（ｗ　
現在は、デバッグしながら細かい機能実装してます。捕らえずサーバーパス以外の
ほとんどすべてをWEB上で設定できるようにしました。

「調子に乗るなボケ」って意見がひとつも出ないのは、素人が作ったこの程度のスクリプトでも
シェアとして成り立ってしまう可能性があるからなんだろうな。
実際ZOO見てみてもカートってカテゴリだと登録数少ないしな。
値段によっては結構売れるかも知れんぞ

まあ敢えて言わないだけなんだけどね

400get

金をとるなら、取れるなりのものを作ってからにしてほしいと思う。
フリーのモノのより落ちるんじゃあダメじゃないかと。
機能の数ということではなく、ね。

オープンプラットフォームということで、
アップローダーは最低でもサイズ制限、MacBinaryぐらいは対応していないと、
シェアのWebアプリとはいえないと、「個人的には」思います。

ＷＥＢショップを開店しようと思ってるので
無謀者さんのカートＣＧＩに興味あります。
でもどこまで実用に耐えられるものなのか不安があるので
シェアだと手が出ないです。
問題なく運用できて売り上げがあがったら
幾らか払っても良いですが。

>403
試用していただけるなら喜んでお出しします。もちろん無料で。
>402
マックバイナリーは一応対処してるつもりです。まだMACでの最終確認してないですが。
サイズ制限に関しては表示部の表示の自動縮小を含め研究中です。
KENT氏の&JpegSizeあたりを改造（ぱくり？）しようと思ってます

>>404
ここだけ無料で配っておいて、他で値段つけたりすると何かと問題になるような・・・

配るというか、モニターしていただけると助かるな・・・という感じでして。
ここの方々には何もない常態からおんぶに抱っこでお世話になっていますので。
万が一、間違って「使ってみたい」って人がいらっしゃれば是非試用していただいて
ご感想をいただきたいのです。その結果「ﾀﾞﾒだ使い物にならん」と思ったら
破棄していただければ良いですし。少しでも使えそうなら不満点を指摘していただき
改良の参考にさせていただければと。

なるほど、そこまで考えて改良を続けていくならシェアでも
いいと個人的には思う。シェアCGIなんてほとんどサポート代
みたいなもんだろうし。まあがんばりや。

送料について、「北海道/東北/関東/…」ていう地域のくくりは
固定にしていいの？
宅配業者の価格体系よく知らないからわからんけど、
もし「同じ関東でも東京・神奈川・千葉はxxx円、それ以外はyyy円」とか
いう体系がありうるなら、sub_soryo()関数内で固定で持ってる県名も
ユーザが指定できるようにするのがいいのではないかと思ふ。
(上のような細かい地域指定機能はサポートしないという仕様にする
or カスタマイズ別料金 つーのももちろんアリだとおもうが)

正直、送料はショッピングカートで一番面倒・・・

行き場がなくなったのは気の毒だね。
「使い方なれてきたからとりあえずこのままで」ってそれ、あるんだ。
「オレは何のために開発したんだよと小一時間‥‥」てヤツだよな。
ま、そーゆー事情ならいっちょシェアにでもして見るか、という気持ちもわかるわ。

そーゆーコトは先に言えよ、な。
>>380は明らかにチョーシぶっこいてるようにしか聞こえなかったんで一言
言いたくなったのさ。

　まぁせっかく作ったんだから、全く儲けちゃイカンとは言わないが……
　公共に還元って事でさ、売り上げの一定比率で2ch運営に寄付って
のはどうかね？

　イヤ、実際受け付けてくれるのかどうかは知らんのだが……

>>411
いや、寄付よりもオイスターのID買えば(･∀･)ｲｲ!!

俺らは利用されていたのかよ（；´Д｀）

ここは無神経な1に裏切られた気分の皆さんが
寒々しく愚痴るスレになりました

いや別にシェアウェアにするのは構わないと思うよ。
問題なのは、なぜここでそれを表明するか、なんだよな(笑)

こういう反応になっちゃうの、わかってるでしょうよ。もったないなぁ、いい雰囲気なすれだっただけに

お久しぶりです。年度末はつらいですなぁ・・・
いろいろ、不快な思いをさせて申し訳ございません。
とりあえず言い分けさせていただくと、自分としては
シェアを作ろうってつもりではじめたわけではないですし
そもそもここまでご協力いただけるとは、正直思いませんでした。
結果として「利用された」と思われるような発言をしたのは私の思慮不足
だったとは思いますが、しらばっくれて公開しちゃうってのは
さらに不義理な行為だと思ったので、たたかれるのを覚悟で表明させていただきました。
　ここは私がPerlを始めるにあたって挫折しない道を教えてくれた場所ですし、
まだまだわからないことだらけの自分に有益な情報が山ほどあります
ちょくちょく覗いてますし、またお力をお借りすることもあると思います。
今後ともよろしくお願いいたします

Perl始めようと思ってここにきたんだがこのスレ為になったYO！
読み物としては楽しかった。ただ>>1のシェアウェア化はいただけないが。

漏れだったら今回作ったものはフリーとしておいてこのスレで得た知識でで
もう１本気合いの入ったものをかき上げてそれをシェアウェアにするなぁとか思った。

儲けを一人占めですか？
さぞ満足でしょうね

そうだ！
ここにくるみんなをうまく利用して（おだてて）つくらせる。
これおいしいアルね！

おれかなり協力したけどシェアでええぞ
シェアでもフリーでも公開してみてわかることはたくさんあるからとにかく公開しろ
んでその問題などをここでまた相談しろ
どうせここまでボランティアやってきてやったんだから面倒みたる。
１が儲けてうらやましいやつは自分で作ってシェアにすりゃいいだろ、そいつらにも
惜しみなく協力してやるよ。

正直、あんなしょぼいCGIで儲かるとは思えない

シェアにするって事は、そのソフトに関して責任を持たなければいけない
って事だ。もしスクリプトの不具合が原因で利用者に損害が出た場合は
責任をとらなければいけない。
俺はそれが怖くてシェアなんかには出来ないけどな。
しかもショッピングカートなんて一番被害が大きくなりそうだし。

この無謀者のレベルでシェアって、とんだお笑い。

>>421-423
どうい
でも、そんなシェアが氾濫してるってのもまた現実

>>422 も言ってるが、
他人に聞きまくって作ったスクリプトで、
不具合とか出た時にサポートとか出来るんか？
つか、また聞きにくるんかな？ｗ

シェア　VS　フリー　論争は別スレたてれ

>>426
れすが３０個くらいついて、そのうち２０個が煽りで、しかもすぐに放置されて風化するような
スレッドは要らないよ。

>>420がいいこと言った！

ageちまった・・鬱打氏脳。。

長い間　本スレッドにおつき合い頂いた皆さん。　本当にありがとうございました。

私は、本日（有）無謀社　を設立。皆様にお手伝いいただいた、ショッピング
カートを主力商品に据え、アプリケーション・サービス・プロバイダーとして、
営業を開始いたしました。
思えば、１月の初旬にスレを立てて以来、こんなにも急速に成長できたのは、
ひとえに皆様の暖かいご支援と、数多の叱咤激励あればこそと痛切に感じます。
この場を借りまして御礼申し上げると共に、今後ともよろしくご指導いただけ
ますようお願い申し上げます。

　　　　　　　　　　　　　　　　　　　平成１ｘ年　４月１日　　無言某者






って、話ができるぐらいになったらいいなぁ　(ｗ
オイラもなんかシェアウェア作るか……

おれ、何回か質問に答えたけど。

べつに、シェアウェアでもいいんじゃないの？　公開したいなら。
気兼ねするこたないだろよ。

新規性のあるライブラリとかなら、フリーで使わせてほしいところだけど。
ショッピングカートは、よくあるジャンルだし。
ライブラリなら、>>1 もフリーで公開しただろう。

そもそも、みな、Perlを商売のタネにしてきたんじゃないの。
Perlはフリー。
Linux も Apache も BIND も Sendmail も
PHP も PostgreSQL もフリー。

おれら、そういうの使って商売してるんじゃないの？

>>1 のプログラムくらい、シェアで公開したがってるなら、
プレッシャーかけてやるこたないだろよ。

世の中、小物チンカス揃いだってことが良くわかる良スレだなあ。

保全age

ショッピングカートについて質問させてください。

DOS/Vパソコンショップ等で良くあるBuild to Order式の
ショッピングページは、作るのが難しいでしょうか？

ショッピングカートの質問に答えさせてください。

>>434は何が言いたいかわかりません。
技術的に問題が生じた場合はここで質問してください。
設置で問題が生じた場合は他の板へ逝ってください。

有難うございます。

たとえば１台のパソコンをWebショップで注文します。
ショップブランドＰＣだと、ＣＰＵは何GHzとか、
ハードディスクは何GBだとか、スペックの変更が
出来て、請求金額も自動計算されて・・・

ってことなんですが、スレ違いですね。ｽﾏｿ

>>436
そんな簡単なもの自分で考えろsage

>>437
かっ、簡単なんスか？！

パーツの価格は毎週1〜2回の価格更新が必要なので、
フリーorシェアウェアのショッピングカートで更新が
容易なものが見当たらないもので・・・

>>438
DBかDBもどきのクラスでも作れば簡単だろうが‥‥

全部をＷＥＢ上でやる必要があるかな？
更新・更新っていうけど、どっかでデータを入力する人が居るわけだ。
それをサイト上でやるか、ローカルでやるか……

Web制作板だけど
http://pc.2ch.net/test/read.cgi/hp/1021096525/l50

Ｍ＄製品の吐くHTMLはｳﾝｺだけど、こういうやり方なら、自分好みのHTMLを
吐くことも可能でしょ？
エクセルにデータ入れた側からHTMLになってるワケだし、PerlやPHPこねくり
回すより遼に簡単じゃないか？

>>440さん有難う。昔、Lotusアプローチでヤったことあります（爆

ところで、１さんはシェアウェアをはじめたの？
もうかってるのかどうか、知りたいです。
ぜひ、教えてください。

ｺﾉｽﾚなんか泣けた(w　>１以外の方々に敬礼!!

お久しぶりです。その節はお世話になりました。＞皆様
>>442さん
はい、いろいろ考えた末公開させていただいております。全然儲かってません。（ｗ
ダウンロード数、ページアクセス数は結構あるんですがね・・・

で公開してみて皆さんの言っている意味がいろいろわかってきました。
サブジェクトが「教えてください」のメール多数。
書き出しが「初心者なんですが」のメール多数。
BBSへのがいしゅつ質問多数。
etc・・・
それでも、このｽﾚで右も左もわからない私に色々教えていただいた皆様の事を思い出し
可能な限りのサポートをさせていただいております。スクリプトの方もバージョンアップを
重ね、当初のcgi-libを使ったものから、CGI.pmを使ったものに作り変えました。
まだまだ、perl/cgiに関しては初心者の域を出ない状態ですが、四苦八苦しながらも
考えたものを形にする（スクリプトに落とす）事が何とかできるようになって来ました。
全て、このｽﾚで親切に教えていただいた皆様のおかげです。
公開騒動で色々言われちゃったのと、しばらく仕事が忙しかったので、ご報告が大変遅れてしまいましたが、
とても気になっておりました。
この板、ｽﾚの住人の皆様がいなければ私がperl/CGIを作れるようになんてとてもならなかったでしょう。
改めて、皆様に御礼させていただきたいと思います。
本当にありがとうございました。m(__)m

>>444
何回か答えたものだけど。
スレッドたった当初は、本当に書けるようになるとは思わなかった。
あなたの努力の成果だと思うよ。

シェアでの公開も、俺は全然問題ないと思うよ。
Perlは奥が深いし、CGI以外でもいろいろな場面で使える言語なので、
今後も頑張って腕を上げていって下さい。

で、また2chとかで質問してる人がいたら、あなたの得たノウハウを
書いてあげればいいんじゃないかな。
べつにわざわざ返事は必要ないので、sage

>>445
(´-`).｡ｏＯ（sageはメール欄におながいします。)

保守

初めて来たけど、どれの事だろう？
http://www.i-say.net/cgi/listview.php3?category=19

ショッシーな質問でスマソ。
ECサイトで例えば指輪の種類がいっぱいあったとします。
それをサイズで分類して並べるのとダイヤ、パールとか石の種類ごと
にならべるのを簡単に実現するのはDBにしてCGIと連携するのが一番
でしょうか？
よろしくおねがいします。

そうだね。

>>449
　あんまり　簡単・簡単　言ってくれるな
　　手間を掛けない＝安価　ではない
　我々の商売は、むしろ省力化に対して金を取るんだから

　自分の手間の代わりに対価を払う気があるなら、案件をまとめて下請けに出すのが一番簡単。
見合う金さえ払えば、とにかく面倒なことは全部引き受けてくれる。

　安価に仕上げたいという意味なら、既存の販売システムで似たような機能の物を探すのが吉
その代わり、全てが望み通りというわけには行かなくなるだろう。

　生産性で言えば、その方法（適当なDB+CGI）で実現は可能なのだから、CGIでも
DBでも既得の技術を使うのが一番「簡単」だろう。
　他に効率的な手法があったとしても、未知の技術に手を出して、既知の技術で作る
何倍もの手間を掛けるなら、意味はない。
　ここの1氏が、既得のPerlを選んだことで、最終的に目的に達しているのがよい例だ。


　で、君は何が望みなのかな？

（＾＾）

効果が薄いsage保守。名スレだよこれ。

nazo

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

ソースが出ちゃってますが・・・
http://shop.sod.co.jp/shop/cargo.cgi

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

ここで人気No.1のＡＶ女優、及川奈央のオマ○コが見れました!!
うぉぉぉぉぉぉ！！！！素晴らしい！！！(*´Д`*)ハァハァ
http://plaza16.mbn.or.jp/~satchel/oikawa_nao/

なんかこのスレいいな・・かなり良スレだったみたいだね・・
俺も早く>>1みたいにperlでいろいろやりたいよ

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

　　　 　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

久々に来て見たらまだｽﾚが生きててﾋﾞｸｰﾘ
その節はお世話になりました＞皆様

只今はPHP＋MySQLを勉強中です。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

山崎に保守されている名スレ
必死ぶりに無謀者さん降臨。
でも、大分前だけど。

最近の研究成果の発表とシェアの売れ具合の報告希望。

http://www.web-terakoya.net/library/cargo.html

このサイト使えない？結構難しいけど。

俺も作りたい！！簡単なやつないの？

ええ

自分の過去を見てるみたいで懐かしい気持ちになった。

カートを作ったら、次は決済だけど...皆たまは、どうしてまつか？

そんなことはこの板には関係ない

でゅうく統合みたいでつね

会社の業務として精力剤のみの
ショッピングカートをPerlで作りました。
DBは一切使わず、テキストのみで注文を記録
してます。

はぁ、、、そうですか

デジカメがもらえるらしい
http://www.lucky-click.com/

>>472
商品と引き換えです

http://pc5.2ch.net/test/read.cgi/hp/1097762828/286

age

板とは直接関係ない話ですが
クレジットカード決済のショッピングサイトを建設しようと思っています。

オンラインでカード決済をするには各カード会社に加盟すれば
カード会社のサーバを通して決済ができるのでしょうか？

読みたいので保守

>>481
yes
keyもらって認証。

って半年前かよorz

2時間かけて読んだけど、このスレ、勉強になった。

入金システムとかはやっぱクレジットカードとかのほうが無難？
Webマネーを取り込みたいんだけどそれについて書いてあるいいサイトないかな？

     メール送信フォームを作っています。

      #名前
      <tr>
      <td class=r align=right width=110>名前 <font color=red>※</font></td>
        <td class=r width=440>
      <input type=text name=name size=30 style='ime-mode:active' value="$cnam"></td>
      </tr>


      # 項目1
      print "<input type=radio name=hoge value=\"A\" checked>A \n";
      print "<input type=radio name=hoge value=\"B\">B \n";


      リターンメールで
      $mbody .= "名  前 = $in{'name'}\n";
      はメールの本文にちゃんと出るのに

      $mbody .= "項目1 = $in{'hoge'}\n";
      は表示されません。。

      考えられるミスがわかる方ご指摘お願いいたしまするー

選択肢から複数選択し、ＯＫボタンを押すと、それら選択された
アイテムに対して、何らかの処理を施すといったことをやりたいのですが、
これらをperl CGIで書かれた例があれば教えて頂けないでしょうか？

>>488
アンケート系CGIのソース見れば一発だと思われ

なんだこのスレ、すげぇ為になった。

保守

ほっしゅ

星ゅ〜

てす

おお、まだこのスレ生きてたのか・・・・
懐かしい。

書き忘れたけど。>>495は「１」
このスレを建てた「無謀者」でした。

もう8年前の事なんだな・・・・・
この後PerlやPHPでいろいろ書きました。
おかげさまで仕事の幅も広がってたんですが、その後職を変えたんで
しばらくスクリプトも書いてないです。

久しぶりになんか作りたくなりました・・・・
読み返してみて、あらためて当時いろいろ教えてくれた皆様に感謝の気持ちで一杯です。

当時レスしてくれた皆様、今でもこの板にいらっしゃるんでしょうか？

>>496
お疲れ様。
まぁこのｽﾚでもｻｶﾅに一杯どうや？

時間かけて全部読んだよ。良いスレだなあ。

>>497
当時の方ですか？

このスレは自分のその後のキャリア形成にかなり影響を与えてくれました

今だったら、EC-CUBEやZen Cartがあるから、自分で作ろうなんて思わなかったろうなぁ・・・
当時本当に「はろーわーるど」だった自分が曲がりなりにもスクリプトを書けるようになったのは
このスレのお陰です。

いい時代になったものだ？
http://procart.web.fc2.com/

>>500
EC-CUBEってMVCフレームワークなんて則ってるの？

宣伝ブログかなんかかも知れ無いが、謎。

Lately, he's had no shame in comparing the Obama Administration and the Democratically-controlled Congress to the Third Reich. ,

>>1
ｼｮｯﾋﾟﾝｸﾞｶｰﾄCGIをパールで作って今も使ってるおれがきますたよと。

まだあるのか・・・・
ちょっと上げてみよう

八年前に俺が書いたレスと思われるものが・・・ﾅﾂｶｼｽ。みんあ元気かな

>>505さん
当時はお世話になりました。
今の自分があるのはあなたのおかげかもしれない・・・

やべえ、まだこのスレあるのか、、、
懐かしすぎる

なんだよこれ懐かしいんだけどｗ

ショッピングカートとか１９９０年代を思い出すよ

>>508
perlスレにもきてたね。

⊂二二二（　＾ω＾）二⊃

非政府組織

504:名無しさん＠お腹いっぱい。ichiichihannousichaundanebakawww2013/04/26(金) 10:25:44.64 ID:XTr4EGdyI
直接お店やカード会社に問い合わせすりゃいいのに、
安定の馬鹿ばっかwww
様々な不適合者共の巣窟。
クズの集団性乙www