URL の一部としてのフォーム送信

このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。

今日は Fiddler を使ってフォームの動作を眺めてみよう。
サンプルとして、用語辞典の Web サイト e-Words を使う。

■ IT用語辞典 e-Words
http://e-words.jp

まず Fiddler を起動し、上記のページにアクセスする。
e-Words のトップページの左上には、
「IT 用語検索」のシンプルなフォームがあるので、
これを題材にすることにしよう。

まず、Web ページのソースを眺めてみる。
e-Words の HTML は shift_jis で書かれているので、
Internet Explorer でソースを表示しても読みやすい。

IT 用語検索フォームの重要な部分だけを抜粋してみると、
以下のような HTML の断片で構成されていることが分かる。

    <form action="/" method="get">
    <input type="text" name="w" />
    <input type="submit" name="headline" value="見出し語検索" />
    <input type="submit" name="fulltext" value="全文検索" />
    </form>

form 要素には幾つか属性がある。
action 属性は、フォームを送信する先の URL となる。
method 属性は、送信する際に利用する HTTP メソッドだ。
メソッドには、GET と POST が指定できるが、
HTTP メソッドによってデータの送り方が異なる。

この例では、フォームの送信先は、「/」、
送信時に利用する HTTP メソッドは「GET」となる。

form 要素内には、幾つかの input 要素がある。
input 要素は、入力フォームの項目となり、
type 属性によって役割が変わる。

最初の type="text" は、単一行用のテキストボックスだ。
非常に良く使われる汎用的な要素である。
type="submit" は、送信専用のボタンの役割を持つ。

さて、フォームの各入力項目は、名前と値を保持している。

名前は、フォームのデータを受け取ったサーバが、
どの項目のデータかどうかを識別するために利用される。
名前は name 属性を使って示され、
HTML 作成者が任意に指定することができる。
なお、この名前は画面の表示とは関係ない。

値は、フォームを送信する際に、
名前に関連付けられて送信される情報であり、
テキストボックスの場合は、利用者が入力した内容となる。

value 属性は入力項目に最初から表示しておく値であり、
テキストボックスの場合はよく省略される。
ボタンの場合は表示される文字になるので、
指定を忘れると、ボタンの役割が分かりにくくなる。

この例では、キーワードの入力ボックスの名前が「w」、
value 属性がないので初期は空欄だ。
また、見出し語検索の送信ボタンの名前は「headline」、
ボタンのラベルは、「見出し語検索」、
そして、全文検索の送信ボタンの名前は「fulltext」、
ボタンのラベルは、「全文検索」となっている。
実際に画面と比べて見ると関係が分かりやすい。

フォームの送信は、送信用ボタンを押すことで動作し、
名前と値の組み合わせが Web サーバに送信される。

では、このフォームを送信してみよう。
テキストボックスに「通信」と入力し、
「見出し語検索」ボタンを押して、
どのような HTTP 通信が走るか Fiddler で見てみよう。

フォームを送信したときの通信を写真に示す。
写真では、12 番の通信がそれだ。

さて、HTTP のリクエストを調べてみよう。
以前出てきたリクエストと大きくは変わらない。
違いがあるとすれば、意味不明な長い URL だろうか。
これは、「ユーザエージェントの要求」の日記で見た、
絶対パスとパラメータの部分である。

では、絶対パスとパラメータを抜粋して調べてみよう。

    /?w=%92%CA%90M&headline=%8C%A9%8Fo%82%B5%8C%EA%8C%9F%8D%F5

分かりにくいが、最初の「/」がパスである。
これは、form 要素の action 属性で指定されていた。
? はそれ以降が追加情報であることを示し、
その後の w 以降が追加情報の本体である。
この追加情報のことを、「クエリ文字列」と呼ぶ。

form 要素の method 属性は GET であった。
GET の場合は、URL の一部としてフォームが送信される。
上記のクエリ文字列は、フォームの内容を符号化したものだ。

フォームの符号化は、以下の手順で行われる。

まず、フォームの中から送信する名前と値を決める。
今回の例では、「w」と「通信」、
そして、「headline」と「見出し語検索」だ。
送信ボタンは、押したものだけが送信内容に含まれるので、
名前「fulltext」を持つ全文検索ボタンは含まれない。

次に、名前や値の URL 中で使えない文字列を符号化する。
これは、文字ではなく、バイト単位で行われる。

半角の空白文字は「+」に置き換えられ、
改行は（もしあれば）%0D%0A に置き換えられ、
それ以外で URL に使えない文字は、
% の後に、バイト値を 16 進数で表現した、
2 桁の文字を続けた、%XX という形に変換される。

これを「パーセントエンコーディング」と呼ぶ。
（URL エンコーディングや URL エスケープとも呼ばれる）
ややこしいのは、バイト単位ということだ。

URL (URI) は、ASCII を前提にしているので、
各国の文字を URL に含めて送信する場合は、
その文字列のエンコーディングによって符号化された、
単なる連続したバイトとして扱われる。

e-Words は、shift_jis を採用しているので、
フォームの内容も shift_jis で符号化される。

「通信」という文字は、shift_jis で表現すると
それぞれ 2 バイトずつの 4 バイトとなる。
文字コード表を使って調べて見ると、
「通」は、16 進表現で「92CA」、
「信」は、16 進表現で「904D」である。

なので、「通信」を shift_jis を使って
パーセントエンコーディングすると %92%CA%90%4D となる。
しかしながら、%4D は、ASCII の文字「M」に相当し、
URL で利用可能なバイトであるため、符号化せずに
「%92%CA%90M」とすることが推奨される。

同じように、「見出し語検索」も符号化すると、
%8C%A9%8Fo%82%B5%8C%EA%8C%9F%8D%F5 となる。

その結果、「w」と「%92%CA%90M」、
「headline」と「%8C%A9%8Fo%82%B5%8C%EA%8C%9F%8D%F5」となる。

最後に、入力項目の名前とその値が = 区切りで連結され、
各入力項目は & 区切りで連結されて 1 つの文字列となる。
これが送信先 URL に付加されて送信されたのである。