このページは
2007
年
07
月
17
日
21時46分59秒
に更新したキャッシュ情報です。
検索キーワード＝ データ入力代行
優先キーワード＝ データ入力
[ 129] フォームデータの送信 -- ごく簡単なHTMLの説明
[引用サイト] http://www.kanzaki.com/docs/html/htminfo32.html
ブラウザからのデータデータは、特別な形式でエンコードされて送信されることになっています。画面に表示されるフォームのコントロールで入力する以外にも、隠されたデータの情報を送ったり、フォームを使わずに送信するなど、いくつかの方法があります。
input要素などで用意する「コントロール」はユーザーがそれを操作してデータを入力するためのものです。しかし、場合によってはHTMLの制作者が指定したデータをプログラムに送信したい場合もあるでしょう。このようなデータはユーザーが操作する必要はなく、ユーザーの目に触れないほうが都合がよいものです。そのために、input要素のタイプの一つとしてhidden型が用意されています。
このような情報をフォームに書きこんでおくと、ユーザーの目に触れることなく「info」という名前と「secret」という値を持ったデータがプログラムに送信されます。汎用のプログラムに特定の動作をさせたい場合などに使います。
作者指定のデータが必要でも、それをユーザーから隠さず、きちんと表示しておく方が望まし場合もあるでしょう。そのためHTML 4.0では、input要素、textarea要素にreadonly属性を設定して、データを表示しつつユーザーによる変更を禁止できるようになりました。
このようにして用意したコントロールは、普通のコントロールと同様に表示されますが、内容を編集することができません。
ただしHTML 4.0に対応していないブラウザだと編集できてしまうので、作者の設定したデータを固定して送信したい場合は、hidden型のinput要素を使う方がよいでしょう。
フォームのコントロールを通して入力されたデータは、送信命令（submit型のinput要素）によってサーバーに送られます。そのとき、英数字以外のデータは利用者が入力したそのままの形ではなく、%と数字やアルファベットで構成されたURLエンコード形式という形に変換され、およそ次のようなイメージになります。
上記の例は、「住所」という変数名に対し「Tokyo」という値、「氏名」という変数名に対し「Masahide Kanzaki」という値がデータとして送信されたものです。
form要素のaction属性でプログラムの代わりにmailto:型のURIを指定すると、フォームの内容を直接メール送信させることができます。
このフォームを使うと、利用者がラジオボタンで選択した結果がURLエンコードされ、actionで示したメールアドレスに送信されます。アドレスのあとに ? に続けてSubject=...と記述することで、メールの件名が設定できます（対応しないブラウザもあるかも知れません。mailtoの記述方法についてはRFC 2368に定められています）。
この方法で送信したメールは、フォームの内容に日本語が含まれているとURLエンコードされて届くので、もとの日本語にデコードするツールが必要になります（Subjectには日本語を直接指定できません）。テキスト型inputやtextareaを使って文字を入力するフォームは、扱いにくいでしょう。
mailtoのようなHTTP以外のURIに対する挙動はHTML 4.01仕様書17.3 actionの定義においてundefinedとされているので、100%働く保証はありません。文字のエンコード以外に、次のような問題が考えられます。
送信してもページが更新されないので、利用者は何かエラーが生じたと思い、何度も送信してしまう可能性がある（適切な説明が必要）
CGIを必要としない手軽な方法なので、フォームの練習や「訪問記念」ボタンには手頃ですが、本格的なデータ送信にはあまり適さないでしょう。
input要素のtype属性をfileとすると、ファイルを選択するためのコントロールを用意することができます。このタイプを用いて、ファイルの中身をフォームのデータとして送信することができます。
ファイルの中身はバイナリファイルだったりテキストでもサイズが大きかったりするので、通常のURLエンコードでの送信は無理があります。この場合は、form要素のenctype属性をmultipart/form-dataに設定し、MIMEのマルチパートデータとしてファイルやその他の項目の内容を送ります。。
このエンコードで送られたフォームのデータは、URLエンコードではなく、次のようなMIMEのマルチパートデータとしてプログラムに届きます。
マルチパートのデータは、この例のように「境界（boundary）」となる行でデータ項目が区切られ、それぞれがContent-Dispositionという説明情報などのあとに実際のデータが続くという形を取ります。処理方法の詳細はここでは取り上げませんが、このようにするとユーザーにオンラインで情報を入力してもらわなくても、あらかじめ必要事項を書き込んだファイルを用意してもらい、それをアップロードしてもらうという手段が提供できます（MIMEのマルチパートの詳細についてはRFC 2045を参照）。
上記例の1行目でboundary=---AabbZと記述していましたが、ここで定義した境界線を使うときにその前に--を加えるのがMIMEの規則なので、定義行ではboundary=-AabbZでなければなりません。お詫びして訂正します。
このエンコードをmailtoアクションと組み合わせると、MIMEの添付ファイルの形式でフォームの内容をメール送信できることもあります。うまく機能すれば、CGIを使わなくても日本語を記述したフォームをメール送信させられそうですが、期待通りに働くかどうかはブラウザ次第で、文字化けする可能性もあります。
なお、URLエンコード形式のエンコードタイプはapplication/x-www-form-urlencodedとなります。通常はあえて指定する必要はありません。
前章では、form要素のmethod属性でpostもしくはgetを指定することを簡単に述べました。postメソッドの場合は、ブラウザはサーバーに接続して、URLエンコードした内容をプログラムに渡すように要求します。getメソッドを使うと、プログラムを呼び出すURLの後ろに、URLエンコードしたデータ（クエリ）を?でつないでサーバーに送信します。たとえばaction属性で /cgi-bin/htm-form を指定しているとき、getメソッドは次のような形でデータを送ります。
つまりgetを使うとデータはURLの一部として送られるわけです。「URLエンコード」とは、データをURLに埋め込んでも問題が生じないように、英数字以外の文字や/などの記号を安全な形に変換することを意味します。サーバーは受け取ったURLを ? を境に分割し、その前半に示されているプログラムを呼び出して、後半の値（フォームの内容＝クエリ）を処理データとして渡します。
POST, GETはフォーム送信だけのものではなく、ブラウザがサーバーに対して要求を送る（HTTPリクエスト）ときの一般的なメソッドです。通常、リンクを辿ったりアドレス欄にURLを入力したりしてHTMLページを呼び出すとき、ブラウザはGETを使ってサーバーにファイルを要求しています。例えば、/index.htmlというファイルを開く場合は
というリクエストを送信します。フォームのgetメソッドを使っても同様のリクエストで、/index.htmlの代わりにプログラムのURLとデータが送られます。
POSTの場合は、このリクエスト行にはデータの内容は書き込まれず、これに続く本体（エンティティ）にデータが入って送信されます。
postメソッドはメッセージの投稿、データベースへのデータの追加などを処理する方法として用意されており、必ずしもHTMLファイルのような情報を取り出すことを目的としていません。
※フォームのpost,getメソッドは大小文字を区別せず、ここでは他のタグの記述と合わせて小文字にしていますが、HTTPリクエストでは大文字を使います。
getはその名の通り、何かをゲットする（取り出す）のが本来の役割です。データベースにキーワードを送って検索結果を「取り出す」などのためにgetを用います。
getを使った場合、その結果はクライアントのディスクにキャッシュされ、次回以降はそのキャッシュの内容を利用することが期待されているので、（少なくとも短期的には）同じクエリによるリクエストに対しては同じ結果を返さなければなりません。また、getはクエリがURIの一部になるため、それがそのままブックマークされたり、リンク先として用いられたりする可能性もあります。
postは「投稿する」を意味します。メッセージの書き込み、新規データの登録など、何かをプログラムに送って内容を書き換えるような場合はpostを使わなければなりません。
getのクエリはサーバーの環境変数を経由してCGIに渡されるので、非常に長いデータを送るのには向きません。上限はサーバーによって違いがありますが、せいぜい数KB程度なので、texarea要素などで長いテキストを入力する場合はpostが適切です（一般的には、このようなケースはデータの登録であり、postの本来の定義に合致する使い方になるでしょう）。
getの場合はクエリの内容がURIの一部としてブラウザのアドレス欄などにも表示されたり、サーバーのログファイルに記録されたりします。プライバシーの保護上、postのほうが望ましい場合があるかもしれません（たとえばinput要素のtypeをpasswordとしているのに、getメソッドを使ってURIにその内容が残るのはまずいかも）。
getメソッドがURLの一部になることを応用すると、フォームを用いずにデータを直接CGIプログラムに送信することができます。たとえば、kwという名前で送ったデータをキーワードにデータベースを検索するプログラムdbase.cgiがあるとすると
という形のアンカーを用意することで、用語をクリックするとその説明をデータベースで検索して表示するような仕掛けを提供できます。
なお、この方法で複数の項目を送信するためのHTMLを記述する場合、項目を連結する&はそのまま記述するのではなく、&という形で文字参照を用いなければならないことに注意してください。
|
[ 130] フォームメール
[引用サイト] http://www.kent-web.com/data/postmail.html
ホームページの画面上で入力された内容を、指定した電子メールアドレスに送信する「フォームメール」です。
ホームページへの訪問者からの感想やアンケート、資料の請求、注文の受け付け等々、汎用的な用途に利用することができます。
送信形式は、sendmailのほかに Perlモジュール（IO:Socket）を使った送信も可能です（＊1）。このため、sendmailを利用できないサーバでもフォームメールの設置が可能です。
2つの入力項目の内容が同一かどうかをチェックすることができます。（メールアドレスの入力チェックやパスワードチェックなど）
各画面はテンプレート式になっているため、ユーザサイドで自由に文字修正やデザイン変更をすることができます。
＊1 : Perlモジュールによるメール送信とは、Perl5以上に標準で装備されるIO:Socketモジュールを使って直接送信サーバ（SMTPサーバ）へ接続して送信を行ないます。
Perlモジュールが使用できないサーバ（@niftyなど）や、CGIからのソケット通信が禁止されているサーバではご利用できません。
なお、HTMLページ側 ( postmail.html ) の「フォームタグ」の記述の仕方については、これはHTML文法上に従って変更していただくことになりますが、フォームタグの記述例については「補足事項」を参考にして下さい。詳しくは、「とほほのWWW入門」の「<FORM>タグのコーナ」などを見て各自で工夫していただくようにお願い致します。KentWebでは、「フォームタグ」の記述に関する質問はお受けできませんので、ご注意ください。
ホームディレクトリ（ここでは public_htmlディレクトリとします）の下に、postmailディレクトリを作成し、さらにその配下に libディレクトリを設置します。全体のディレクトリ構成とファイル位置の設置例は以下のとおりです。（かっこ内はパーミッションの設定値）
（MIMEエンコードライブラリを使う場合、mimier.pl をパス付きで指定します。これはメールヘッダの全角文字をBASE64エンコードする機能で、この機能の利用を推奨しています）
（送信後、単に完了メッセージを出すのであれば 0 を、所定のページへ自動ジャンプさせたい場合には、1 とします。後者の場合、ジャンプ先は $back で指定するURLとなります）
（メールの送信形式を指定します。「1」はsendmail送信、「2」はPerlモジュールを使った送信方法になります。「2」を利用する場合、プロバイダ側でPerlモジュールによるソケット通信が可能である必要があります）
（$send_typeで「1」の場合、メールプログラムまでのパスを指定します。プロバイダの指定するパスを確認してください）
以上、修正が完了したら各ファイルを所定のディレクトリへFTP転送し、以下のとおり アクセス権 (パーミッション) を設定します。
以上、設置が完了したらチェックモードで起動させてみましょう。チェックモードとする場合には、postmail.cgi の末尾に、「?mode=check」という引数を付けて直接呼び出します。
チェックモードで特にエラーが表示されないようであれば、最後にHTMLから postmail.htmlにリンクします。
フォームメールについては、フォームページ側 (postmail.html) のHTMLの「FORMタグ」の記述の仕方がポイントだと思います。以下のポイントを参考にしてみてください。（これ以降のコーナは「HTML」に関することであり、「質問」はお受けできませんのでご注意ください）
|
戻る
