form

フォームの内容を送信するには、大きく分けて二つの方法があります。HTTPのGETメソッドを使う方法と、POSTメソッドを使う方法です。これらのメソッドは、フォームの送信の目的によって適宜使い分けます。詳しくはmethod属性を参照して下さい。

サクセスフルコントロール (Successful Control)という呼び方は奇妙に聞こえますが、要はフォームの送信ボタンが押された時に、名前と値のペアが送信されるコントロールの事です。例えば:

フォームの内容として送るべきデータを、action属性のプログラムに渡せるように整形するまでに、ユーザーエージェントは以下の手順を踏みます。

メソッドやエンコード方法などについて、現存する全てのものがサポートされている事は殆ど無いでしょうが、HTML4に対応していると謳っている(まともな)ユーザーエージェントは、次の二つの状況をサポートしています。

URLエンコードは、コンテントタイプapplication/x-www-form-urlencodedで識別されるエンコード方法です。GETメソッドを使う場合は常にこの方法が使われ、POSTメソッドを使う場合でも大抵はこれが使われます(enctype属性の既定値です)。

URLエンコードを使う場合、ユーザーエージェントはまず、コントロールの名前とその値をエスケープ (使ってはまずい、あるいは使えない文字を使っても良い文字の組み合わせで表現する事)します。例えばスペースは'+'で、その他の使用不可の文字はパーセントエンコード (Percent Encode)されて'%'+'HH'(2桁の16進数)で表されます。例えば、改行はキャリッジリターン (Carriage Return、CR)とラインフィード (Line Feed、LF)の組(CR+LFと短縮される)で表されますが、これは%0D%0Aになります。また、テキストボックスに~x means a bitwise NOT, or a ones' complement.と入力された場合、これは%7Ex+means+a+bitwise+NOT%2C+or+a+ones%27+complement.とエンコードされます。

エンコードが終われば、ユーザーエージェントは、サクセスフルコントロールが文書中に現れた順番に、コントロールの名前と値をペアにします。名前と値は'='で分けられ、ペア同士は'&'で分けられます。例えば、次のようなフォームがあったとしましょう。

ここで、Word欄に~x、Description欄にMeans a bitwise NOT, or a ones' complement.と入力し、Submitボタンを押します。すると、ユーザーエージェントは、HTTPのGETメソッドを使って、www.example.comサーバに

とリクエストします。ちなみに、最後のbutton要素はname属性が無い為、データセットは作られません(非サクセスフル)。

URLエンコードは、データ量が少ない場合には適切で、しかもGETメソッドならURIとして入力した情報を保存できる為、例えばGoogleの検索結果に対してリンクを張るという事が可能でした。しかし、ASCII文字でないものが多く存在する時、例えば一般のファイル、日本語の長い文字列などではやたらとデータが長くなってしまいます。こういう場合、multipart/form-dataで識別されるマルチパート方式を採用するべきでしょう。

POSTメソッドでmultipart/form-dataエンコードを使うと、エンコードされたデータセットはメッセージボディとして送られる事はフォームの内容の整形で触れましたが、そのメッセージボディの中でも、各サクセスフルコントロールごとに区分されて送られます。

例えば、次のフォームを、値を変えずにそのまま送信してみたとしましょう。

これに対して、ユーザーエージェント、例えばMicrosoft Internet Exproler 6.0の場合、次のようなHTTPメッセージを送ります。

見て大体感じは掴めるかと思いますが、説明を加えていきましょう。

大量の'-'の後に16進数が並んでいる行は、パートバウンダリ (Part Boundaries)などと呼ばれるもので、サクセスフルコントロールを区切る為に使われます。このバウンダリは、Content-Typeヘッダで、Content-Type: multipart/form-data; boundary=---------------------------7d636d1010340のようにプログラムに渡されています。パートバウンダリは送信の度に変わりますし、ユーザーエージェントによって生成方法も違うので、必ず毎回Content-Typeヘッダを見る必要があります。ただ、送信されるデータの中にパートバウンダリが含まれる事は一切無い事が保証されています(ユーザーエージェントは、そうなるようにパートバウンダリを作り出します)。

よく数を数えてみると判りますが、Content-Typeヘッダで示されるバウンダリがそのまま使われている訳ではありません。サクセスフルコントロールの区切りには先頭に二つのハイフンが、データの終わりには先頭と末尾にそれぞれ二つのハイフンが付きます。これらによって、プログラムはサクセスフルコントロールごとにデータを分けて受け取る事ができます。

パートバウンダリによって分けられた各パートを見てみると、Content-Dispositionヘッダがあります。これは大抵Content-Disposition: form-data; name="コントロールの名前"の書式を持っています。ヘッダとデータ(コントロールの値)の間はCR+LF二つで分けられます(一行の空行ができる)。プログラムは次のバウンダリが現れるまでデータを読み取っていき、バウンダリが現れた所で最後のCR+LFを取り去ればコントロールの値が取得できる訳です。

コントロールの値に非ASCII文字が含まれる場合、何らかの手法でデータがエンコードされて送られる事があります。この時は、各パートのContent-Transfer-Encodingヘッダを見て、然るべき手法でデコードをしなければなりません。あるいは、エンコードされずに、Content-Typeヘッダが(HTTPメッセージのヘッダにではなく、各パートのヘッダに)付いている場合があります。この時は、charsetパラメータを見て内容を判断してやります。

フォームの中にファイル選択欄が含まれる場合、そのパートの中身はファイルの内容になります。例えば、次のフォームを考えます。

このフォームで、remote-fileのファイル選択欄でvalid-xhtml11.pngと入力し(実際には絶対パスで入力する事になるでしょう)、アップロードボタンを押すと、例えばIEでは次のようにメッセージが送られます。

local-nameの方は特筆すべき事はありませんが、remote-fileの方は少し違います。

まず、Content-Dispositionヘッダにfilenameパラメータが追加されます。これは必ず付いている保証はありませんが(強制はされていない)、余程の事情が無ければ付いているでしょう。filenameパラメータの値にはその名の通りファイル名(あるいはパス)が与えられますが、非ASCII文字が含まれている場合、エンコードされているかも知れません。

次に、Content-Typeヘッダが追加されます。これも強制されている訳ではありませんが、大抵付いている事でしょう。ただ、これが信用に値するかどうかは疑問です。中身がテキストファイルであっても知らない拡張子であればapplication/octet-streamになったり、上の例ではきちんと拡張子pngが付いているにも拘らず古いimage/x-pngで送られています。大概、本当に安全なファイルかどうかは、内容を見て決めなければならないでしょう。

また、ファイルの内容がエンコードされている場合には同様にContent-Transfer-Encodingヘッダが付きます。そして、エンコードの有無に拘らず、パートバウンダリはファイルの中身にも含まれない事が保証されています。

生のマルチパート形式を扱う上で必要な事は、大体こんな所でしょう。実際にこれを解釈しようとすると、それなりに面倒です。Perlでは生のままプログラム側で加工しなければならないので、ライブラリを自作するか、既にそういうものがあれば借りてくるのが楽でしょう。PHPなら、勝手にスーパーグローバル$_FILES(連想配列)に必要な情報をまとめてくれるので、扱いが非常に楽になります。$_POSTと併せれば言う事無しですね。本当にPHPは楽です。