From b56dbc33c6b87555fb6676f08a9877b28f93d287 Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Sun, 26 Sep 2021 11:57:14 +0900 Subject: Learn/Forms/Sending_and_retrieving_form_data を更新 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 2021/09/13 時点の英語版に同期 - Fix #2213 --- .../sending_and_retrieving_form_data/index.html | 141 +++++++++++---------- 1 file changed, 72 insertions(+), 69 deletions(-) (limited to 'files/ja/learn/forms') diff --git a/files/ja/learn/forms/sending_and_retrieving_form_data/index.html b/files/ja/learn/forms/sending_and_retrieving_form_data/index.html index 5ce2709ade..04c04c284a 100644 --- a/files/ja/learn/forms/sending_and_retrieving_form_data/index.html +++ b/files/ja/learn/forms/sending_and_retrieving_form_data/index.html @@ -2,26 +2,27 @@ title: フォームデータの送信 slug: Learn/Forms/Sending_and_retrieving_form_data tags: - - Beginner + - 初心者 - CodingScripting - - Guide + - ファイル + - フォーム + - ガイド - HTML - HTTP - - Web + - ヘッダー - セキュリティ - - ファイル - - フォーム + - Web translation_of: Learn/Forms/Sending_and_retrieving_form_data ---
{{LearnSidebar}}{{PreviousMenu("Learn/Forms/Form_validation", "Learn/Forms")}}
-

フォームがクライアント側で検証されたら、フォームの送信は大丈夫です。前の記事では検証をカバーしたので、送信する準備はできています! この記事では、ユーザーがフォームを送信したときに何が起こるか、つまりデータがどこへ行くのか、そこに来たときにどう扱うのかを見ます。また、フォームデータの送信に関連するセキュリティの考慮事項のいくつかも見てみます。

+

フォームがクライアント側での検証が終わったら、次はフォームの送信です。前の記事では検証を扱ったので、送信する準備はできています。この記事では、ユーザーがフォームを送信したときに何が起こるか、つまりデータがどこへ行くのか、そこに来たときにどう扱うのかを見ます。また、フォームデータの送信に関連するセキュリティの考慮事項のいくつかも見てみます。

- +
- + @@ -32,37 +33,37 @@ translation_of: Learn/Forms/Sending_and_retrieving_form_data

まずは、フォームが送信されたときにデータに何が起こるかを考えてみましょう。

-

クライアント/サーバー構成について

+

クライアント/サーバー構成

-

ウェブはごく基本的なクライアント/サーバー構成に基づいており、簡単に言うと次のようになります。クライアント (通常はウェブブラウザー) は HTTP プロトコルを使用して、サーバー (ほとんどの場合 Apache、Nginx、IIS、Tomcat などのウェブサーバー) にリクエストを送ります。サーバーは同じプロトコルを使用して、リクエストに応答します。

+

ウェブはごく基本的なクライアント/サーバー構成に基づいており、簡単に言うと次のようになります。クライアント (通常はウェブブラウザー) は、サーバー (ほとんどの場合 Apache、Nginx、IIS、Tomcat などのウェブサーバー) に HTTP プロトコルを使用してリクエストを送ります。サーバーは同じプロトコルを使用して、リクエストに応答します。

-

基本的なクライアント/サーバー構成

+

基本的なクライアント/サーバー構成

クライアント側において、HTML フォームはサーバーへデータを送信する HTTP リクエストを組み立てるのための、便利でユーザーに使いやすい手段でしかありません。フォームによって、ユーザーが HTTP リクエストで渡す情報を提供することができるようになります。

-

メモ: どのようにクライアント/サーバー構成が動作するかについてもっと知りたい場合は、サーバーサイド Web サイトプログラミング入門モジュールをお読みください。

+

メモ: どのようにクライアント/サーバー構成が動作するかについてもっと知りたい場合は、サーバーサイドウェブサイトプログラミング入門モジュールをお読みください。

-

クライアント側: データ送信方法の定義

+

クライアント側: データ送信方法の定義

{{HTMLElement("form")}} 要素で、データを送信する方法を定義します。その属性すべてが、ユーザーが送信ボタンを押すと送信されるリクエストを調整できるように設計されています。もっとも重要な属性は {{htmlattrxref("action","form")}} と {{htmlattrxref("method","form")}} の 2 つです。

-

action 属性

+

action 属性

action 属性は、どこにデータを送信するかを定義します。値は妥当な相対/絶対 URL でなければなりません。この属性が与えられなかった場合は、フォームが含まれているページの URL にデータが送信されます。

この例では、データを絶対 URL の http://example.com に送信します。

-
<form action="http://example.com">
+
<form action="https://example.com">

こちらは、相対 URL を使用しています。データは同一オリジン上の別の URL に送信されます。

-
<form action="/somewhere_else">
+
<form action="/somewhere_else">

以下のように属性を指定しない場合は、{{HTMLElement("form")}} 要素はフォームが表示されているページ自身に対してデータを送信します。

-
<form>
+
<form>

メモ: HTTPS (secure HTTP) プロトコルを使用して URL を指定することができます。このようにすると、フォーム自体が HTTP でアクセスされる安全ではないページで提供される場合でも、データはリクエストの残りの部分とともに暗号化されます。一方、フォームが安全なページ提供されていても、{{htmlattrxref("action","form")}} 属性で安全ではない HTTP の URL を指定すると、どのブラウザーでもデータを送信する際にユーザーに対してセキュリティの警告を表示します。これは、データが暗号化されないためです。

@@ -72,19 +73,19 @@ translation_of: Learn/Forms/Sending_and_retrieving_form_data

データがどう送られるかは method 属性に依存します。

-

method 属性

+

method 属性

-

method 属性は、どのようにデータを送信するかを定義します。HTTP プロトコルはリクエストを実行するための方法をいくつか提供しています。HTML フォームのデータは複数の方法で送信することができます。もっとも一般的なものは GET メソッドと POST メソッドです。

+

method 属性は、どのようにデータを送信するかを定義します。HTTP プロトコルはリクエストを実行するための方法をいくつか提供しています。HTML フォームのデータは複数の方法で送信することができます。もっとも一般的なものは GET メソッドと POST メソッドです。

これら2つのメソッドの違いを理解するために、一歩戻って HTTP の動作についてみていきましょう。ウェブ上のリソースにたどり着こうとするたびに、ブラウザーは URL へリクエストを送信します。HTTP リクエストは 2 つの部分で構成されます。ブラウザーの機能に関する包括的なメタデータのセットを持つヘッダーと、指定されたリクエストをサーバーが処理するために必要な情報を持つ本文です。

-

GET メソッド

+

GET メソッド

GET メソッドは、サーバーに対して指定したリソースを返すよう求めるためにブラウザーが使用するメソッドです。"やあサーバー、このリソースをくれよ。" この場合、ブラウザーは空の本文を送信します。本文が空であるため、フォームをこのメソッドで送信する場合はデータを URL の後に付加します。

以下のフォームについて考えてみましょう。

-
<form action="http://foo.com" method="get">
+
<form action="http://www.foo.com" method="GET">
   <div>
     <label for="say">What greeting do you want to say?</label>
     <input name="say" id="say" value="Hi">
@@ -100,7 +101,7 @@ translation_of: Learn/Forms/Sending_and_retrieving_form_data
 
 
GET メソッドが使用されているので、フォームを送信するときにブラウザーのアドレスバーに www.foo.com/?say=Hi&to=Mom という URL が見えるでしょう。

 
-
URL に追加されたデータは名前/値の組の連続です。URL の Web アドレスが終了した後、疑問符 (?) に続いて、名前/値の組が、それぞれアンパサンド (&) で区切られて入ります。この場合、2 つのデータの断片がサーバーに渡されます。

+
URL に追加されたデータは名前/値の組の連続です。URL のウェブアドレスが終了した後、疑問符 (?) に続いて、名前/値の組が、それぞれアンパサンド (&) で区切られて入ります。この場合、2 つのデータの断片がサーバーに渡されます。

 
 
    
  
  • say の値は Hi
    • 
@@ -109,20 +110,20 @@ translation_of: Learn/Forms/Sending_and_retrieving_form_data
 
 
    HTTP リクエストは次のようになります。
    
 
-
    GET /?say=Hi&to=Mom HTTP/1.1
+
    GET /?say=Hi&to=Mom HTTP/2.0
 Host: foo.com
    
 
 
    
 
    メモ: この例は GitHub にあります。— get-method.html を参照してください (ライブはこちら).
    
 
    
 
-
    POST メソッド
    
+
    POST メソッド
    
 
 
    POST メソッドは少し異なります。これは、HTTP リクエストの本文で提供したデータを考慮したレスポンスの要求を、ブラウザーがサーバーに送信するためのメソッドです。"やあサーバー、このデータを見て適切な結果を返してよ。" このメソッドを使用してフォームを送信する場合は、データが HTTP リクエストの本文の後に追加されます。
    
 
 
    例を見てみましょう。— これは前述の GET の節で見たものと同じフォームですが、{{htmlattrxref("method","form")}} 属性が post に設定されています。
    
 
-
    <form action="http://foo.com" method="post">
+
    <form action="http://www.foo.com" method="POST">
   <div>
     <label for="say">What greeting do you want to say?</label>
     <input name="say" id="say" value="Hi">
@@ -138,7 +139,7 @@ Host: foo.com
    
 
 
    フォームをが POST メソッドで送信されると、URL にはデータが追加されず、HTTP リクエストは次のように、リクエスト本文にデータが含まれた形になります。
    
 
-
    POST / HTTP/1.1
+
    POST / HTTP/2.0
 Host: foo.com
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 13
@@ -165,7 +166,7 @@ say=Hi&to=Mom
    
 
 
    これで下の画像にあるように、フォームデータを取得することができます。
    
 
-
    
+
    
 
 
    ユーザーに表示されるのは呼び出された URL のみです。前述のように、GET リクエストはユーザーが URL バーの中でデータを見ることができますが、POST リクエストではそうではありません。これは 2 つの理由でとても重要です。
    
 
@@ -174,15 +175,15 @@ say=Hi&to=Mom
    
  
  • 大量のデータを送信する必要があるなら、POST が好ましいメソッドです。これは、URL の長さ制限があるブラウザーが存在するためです。加えて、多くのサーバーは受け入れる URL の長さを制限しています。
    • 
 
 
-
    サーバー側: データの取得
    
+
    サーバー側: データの取得
    
 
 
    どちらの HTTP メソッドを選択しても、サーバーが受け取る文字列は、キー/値の組のリストとしてデータを取得するために解析されます。このリストにアクセスする方法は、使用する開発プラットフォームや、使用するであろう特定のフレームワークに依存します。
    
 
-
    PHP の例
    
+
    PHP の例
    
 
 
    PHP は、データにアクセスするためのグローバルオブジェクトを提供します。POST メソッドを使用したと仮定すると、データを取得してユーザーに表示する例は以下のとおりです。もちろん、データに対して何をするかはあなた次第です。データを表示したり、データベースに保管したり、メールで送信したり、他の手段で処理したりするでしょう。
    
 
-
    <?php
+
    <?php
   // $_POST グローバル変数は、POST メソッドで送信されたデータへ名前でアクセスを可能にする
   // GET メソッドで送信されたデータにアクセスするには、$_GET が使用できる
   $say = htmlspecialchars($_POST['say']);
@@ -193,19 +194,20 @@ say=Hi&to=Mom
    
 
 
    この例では送信されたデータを含むページを表示します。これはサンプルの php-example.html ファイル、つまり以前 method が POST で action が php-example.php の時に見たサンプルフォームを含むファイルアクションの中で見ることができます。送信されると、フォームデータは上記のブロックの PHP コードを含む php-example.php へ送信されます。コードが実行されると、ブラウザーの出力は Hi Mom になります。
    
 
-
    
+
    
 
 
    
-
    メモ: この例はブラウザーにローカルに読み込んだ時には動作しません。— ブラウザーは PHP コードを解釈できないので、フォームがブラウザーに送信されると、PHP ファイルをダウンロードしようとするでしょう。動作させるためには、この例を何らかの PHP サーバー経由で実行する必要があります。ローカルの PHP のテストには、MAMP (Mac および Windows) や AMPPS (Mac, Windows, Linux) がいいでしょう。
    
-
-
    MAMP を使って MAMP Pro がない (または MAMP Pro デモトライアルの有効期限が切れた)場合、動作させるのにトラブルが起こるかもしれません。再び動作させるには MAMP アプリを閉じて、MAMP > Preferences > PHPメニューから "Standard Version:" を "7.2.x" (x はあなたがどのバージョンをインストールしたかによります)にするといいことがわかっています。
    
+
    メモ: この例はブラウザーにローカルに読み込んだ時には動作しません。— ブラウザーは PHP コードを解釈できないので、フォームがブラウザーに送信されると、PHP ファイルをダウンロードしようとするでしょう。動作させるためには、この例を何らかの PHP サーバー経由で実行する必要があります。ローカルの PHP のテストには、MAMP (Mac および Windows) や AMPPS (Mac, Windows, Linux) がいいでしょう。
    
+ 
    
+ なお、MAMP を使って MAMP Pro がない (または MAMP Pro デモトライアルの有効期限が切れた) 場合、動作させるのにトラブルが起こるかもしれません。再び動作させるには MAMP アプリを閉じて、MAMP > Preferences > PHPメニューから "Standard Version:" を "7.2.x" (x はあなたがどのバージョンをインストールしたかによります)にするといいことがわかっています。
    
 
    
 
-
    Python の例
    
+
    Python の例
    
 
 
    この例は、同じこと (与えられたデータをウェブページに表示する) を Python で行います。これはテンプレートの表示やフォームデータの受付などのために Flask フレームワークを使用しています (python-example.py を参照してください)。
    
 
-
    from flask import Flask, render_template, request
+
    from flask import Flask, render_template, request
+
 app = Flask(__name__)
 
 @app.route('/', methods=['GET', 'POST'])
@@ -219,7 +221,7 @@ def hello():
 if __name__ == "__main__":
     app.run()
    
 
-
    次のように、上記のコードでは 2 つのテンプレートが参照されます。(自分の環境で実行する場合、これらは templates というサブディレクトリにあり、python-example.pyファイルと同じディレクトリにある必要があります):
    
+
    次のように、上記のコードでは 2 つのテンプレートが参照されます。(自分の環境で実行する場合、これらは templates というサブディレクトリにあり、python-example.pyファイルと同じディレクトリにある必要があります)。
    
 
 
      
  
    • form.html: 以前に {{anch("The POST method", "POST メソッド")}}の節で見たフォームと同じですが、action が \{{ url_for('hello') }} に設定されています (これは Jinja2 テンプレートで、基本的に HTML ですが、波括弧の中にウェブサーバーで実行されている Python のコードの呼び出しを含めることができます。url_for('hello') は基本的に、「フォームが送信されたら /hello にリダイレクトしてください」と言っています。)
      • 
@@ -227,18 +229,19 @@ if __name__ == "__main__":
 
    
 
 
    
-
    メモ: 繰り返しますが、このコードはブラウザーに直接読み込もうとしても動作しません。Python は PHP とは若干異なる動作をします。— ローカルでこのコードを実行するには、Python/PIP をインストールする必要があり、それから pip3 install flask を使用して Flask をインストールしてください。この時点で python3 python-example.py を実行し、ブラウザーで localhost:5000 に移動することで実行することができるでしょう。
    
+
    メモ: 繰り返しますが、このコードはブラウザーに直接読み込もうとしても動作しません。Python は PHP とは若干異なる動作をします。— ローカルでこのコードを実行するには、Python/PIP をインストールする必要があり、それから pip3 install flask を使用して Flask をインストールしてください。この時点で python3 python-example.py を実行し、ブラウザーで localhost:5000 に移動することで実行することができるでしょう。
    
 
    
 
-
    その他の言語やフレームワーク
    
+
    その他の言語やフレームワーク
    
 
-
    フォームの操作に使用できるサーバー側の技術は、Perl、Java、.Net、Ruby などたくさんあります。もっとも好きなものを選びましょう。しかしそれらの技術を直接使用することは、扱いにくいため一般的ではないことが特筆に値します。以下のような、フォームをより簡単に扱えるようにする多くの高品質フレームワークのひとつを使用する方がより一般的です:
    
+
    フォームの操作に使用できるサーバー側の技術は、Perl、Java、.Net、Ruby などたくさんあります。もっとも好きなものを選びましょう。しかしそれらの技術を直接使用することは、扱いにくいため一般的ではないことが特筆に値します。以下のような、フォームをより簡単に扱えるようにする多くの高品質フレームワークのひとつを使用する方がより一般的です。
    
 
 
 
 
    言うまでもなく、これらのフレームワークを使用したとしても、フォームでの作業が必ずしも簡単になるとは限りません。しかし、すべての機能を自分で 1 から書こうとするよりずっと簡単で、また多くの時間を節約できるでしょう。
    
@@ -247,11 +250,11 @@ if __name__ == "__main__":
 
    メモ: サーバー側言語やフレームワークまで説明することはこの記事の範囲を超えます。上記のリンクが参考になりますので、学習してみてください。
-

特別な場合: ファイル送信

+

特別な場合: ファイル送信

ファイルは HTML フォームで特別なケースです。他のデータがすべてテキストデータである中、ファイルはバイナリーデータ (あるいはそのように考えられるデータ) です。HTTP はテキストのプロトコルであるため、バイナリーデータを扱うための特別な要件があります。

-

enctype 属性

+

enctype 属性

この属性で Content-Type HTTP ヘッダーの値を指定できます。このヘッダーはサーバーに対して送信するデータの種類を伝えることから、とても重要です。既定値は application/x-www-form-urlencoded です。人間の言葉では、「これは URL 形式でエンコードされたフォームデータです。」という意味です。

@@ -265,7 +268,7 @@ if __name__ == "__main__":

例:

-
<form method="post" enctype="multipart/form-data">
+
<form method="post" enctype="multipart/form-data">
   <div>
     <label for="file">Choose a file</label>
     <input type="file" id="file" name="myFile">
@@ -279,13 +282,13 @@ if __name__ == "__main__":
 
警告: 多くのサーバーは悪用を防ぐために、ファイルや HTTP リクエストの長さを制限しています。

 
 
-
一般的なセキュリティへの配慮

+
一般的なセキュリティへの配慮

 
 
サーバーにデータを送信するたびに、セキュリティについて考える必要があります。HTML フォームはサーバーに対するもっともよくある攻撃の入口 (攻撃が行われる場所) になります。問題が HTML フォーム自身から発生することはありません — サーバーがどのようにデータを扱うかによります。

 
-
server-side の学習トピックの Website security の記事では、一般的な攻撃とその防御を詳細に扱っています。そちらへ行って記事を確認し、何が起こり得るかを理解してください。

+
ウェブサイトセキュリティ の記事が server-side の学習トピックにあり、一般的な攻撃とその防御を詳細に扱っています。そちらへ行って記事を確認し、何が起こり得るかを理解してください。

 
-
疑い深くあれ: ユーザーを信用してはいけません

+
疑い深くあれ: ユーザーを信用してはいけません

 
 
さて、これらの脅威に対してどう対抗するのでしょうか? これは本ガイドの内容を超える話題です。それでも、覚えておくとよいルールがいくつかあります。もっとも重要なルールは、自分自身も含めユーザーを決して信用してはならないことです。信頼されているユーザーでさえハイジャックされるかもしれません。

 
@@ -299,13 +302,13 @@ if __name__ == "__main__":
 
 
これら 3 つのルールに従うと、多くのあるいはほとんどの問題を避けられるでしょう。ただし、適格の第三者によるセキュリティレビューを受けることもよい考えです。発生し得る問題のすべてを見いだしたとは考えないようにしてください。

 
-
まとめ

+
まとめ

 
-
ご覧いただいたように、フォームデータの送信は簡単ですが、アプリケーションを安全にするのは容易ではありません。フロントエンドの開発者はデータのセキュリティモデルを定義すべき者ではないことを忘れないようにしてください。今後見ていくようにクライアント側でのデータ検証も可能ですが、クライアント側で実際に何が起きているかを知ることはできませんので、サーバー側でその検証内容を信用することはできません。

+
ご覧いただいたように、フォームデータの送信は簡単ですが、アプリケーションを安全にするのは容易ではありません。フロントエンドの開発者はデータのセキュリティモデルを定義すべき者ではないことを忘れないようにしてください。今後見ていくようにクライアント側でのデータ検証も可能ですが、クライアント側で実際に何が起きているかを知ることはできませんので、サーバー側でその検証内容を信用することはできません。

 
 
このチュートリアルを順番に終えた場合、フォームのマークアップとスタイル設定の方法、クライアント側での検証の方法、フォーム送信の理解ができているでしょう。

 
-
関連情報

+
関連情報

 
 
ウェブアプリケーションのセキュア化についてさらに学びたいのでしたら、次のリソースをよく読んでください。

 
@@ -315,27 +318,27 @@ if __name__ == "__main__":
  
  • Web Security by Mozilla
    • 
 
 
-
    {{PreviousMenuNext("Learn/HTML/Forms/The_native_form_widgets", "Learn/HTML/Forms/Form_validation", "Learn/HTML/Forms")}}
    
+
    {{PreviousMenu("Learn/Forms/Form_validation", "Learn/Forms")}}
    
 
-
    このモジュール
    
+
    モジュール内の記事
    
 
 
 
-
    上級トピック
    
+
    上級トピック
    
 
 
-- 
cgit v1.2.3-54-g00ecf
    前提知識:基本的なコンピューターリテラシー, HTML の理解, HTTP およびサーバーサイドプログラミングの基本的な知識。基本的なコンピューターリテラシー、HTML の理解、HTTP およびサーバーサイドプログラミングの基本的な知識。
    目標: