例を組み合わせてASPファイルのアップロードの原理を分析する

FileSystemObjectの制限により、ASPの最大の問題はファイルのアップロードですが、ほとんどの解決策はサードパーティのアップロードコンポーネントをインストールすることです。サードパーティ製のコンポーネントには多くの問題があり、いくつかのコンポーネントは登録されなければならず、いくつかのコンポーネントは彼の著作権情報をフォームに追加しなければなりません。 HTTPでファイルをアップロードするには、RFC 1867、PUT、およびWebDAVという3つのメカニズムがあります。一般的な実装は、RFC 1867で導入された新しいタイプ、FileおよびADO Streamオブジェクトを利用することです。本稿では、上記のアップロード方法と実装原理について説明し、具体的な解決策を示します。

ASPファイルオブジェクト

現在、/モードベースのアプリケーションが一般的です。ユーザーがファイルを転送する必要がある場合、一般的な方法の1つは、FTPを実行して各ユーザーのFTPデフォルトディレクトリをユーザーのWebホームディレクトリに設定し、ユーザーがFTPクライアントを実行して指定のWebディレクトリにファイルをアップロードすることです。 。これには、FTPクライアントの使用方法を知っておく必要があります。したがって、この解決策は、FTPに精通していて経験のあるユーザーにのみ実行可能です。ユーザーがWebのみを使用してアップロードタスクを完了できるように、ファイルアップロード機能をWebと統合できる場合は、非常に便利です。ただし、長い間、ファイルシステムオブジェクトはテキストファイルの制限事項しか送信できないため、ASPの最大の問題はファイルのアップロードの問題です。以下は、HTTPプロトコルに基づいてWebページにファイルアップロードを実装する方法です。

I. HTTP経由でアップロードするための3つのメカニズム

HTTP経由でアップロードするための3つのメカニズムがあります。RFC1867、PUT、WebDAVです。

PUTはHTTP 1.1で導入された新しいHTTP動詞です。 WebがHTTP PUTとオブジェクト名を受け取ると、ユーザーを認証し、HTTPストリームの内容を受け取り、それを直接Webに保存します。これはWebサイトに損害を与え、HTTPの最大の利点であるプログラマビリティを失う可能性があります。 PUTの場合は、要求を自分で処理します。CGIまたはASPアプリケーションが介入する余地はありません。アプリにPUTをキャプチャさせる唯一の方法は、下位レベルのISAPIフィルタ層で動作させることです。対応する理由から、PUTの適用は非常に限られています。

WebDAVでは、分散認証とWebコンテンツの翻訳が可能です。 HTTPを介したアップロード、ロック/ロック解除、およびWebコンテンツの登録/検証を可能にするいくつかの新しいHTTP動詞が導入されています。 Office 2000の「Webに保存」はWebDAVを介して実装されています。あなたが興味を持っているすべてがコンテンツをアップロードすることであるならば、WebDAVは素晴らしいアプリケーションです、そしてそれは多くの問題を解決します。ただし、Webアプリケーションにファイルをアップロードする必要がある場合、WebDAVは役に立ちません。 HTTP PUTと同様に、これらのWebDAV動詞はWebアプリケーションではなく解釈されます。これらのWebDAVの動詞にアクセスしてアプリケーションのコンテンツを解釈するには、ISAPIフィルタ層で作業する必要があります。

RFC1867は、HTML 3.2のW3Cによって承認される前に、ついに推奨標準として承認されました。これは非常に単純ですが強力なアイデアです。フォームフィールドに新しい型を定義します。

を使用し、フォーム自体にさまざまなエンコード方式を追加する：

を使用する代わりに：

このエンコード方式は、大量のデータを転送するときに使用されます。デフォルトの「application /x-url-encoded」形式のエンコードスキームよりもはるかに効率的です。 URLエンコードでは文字セットが非常に限られているため、文字セットを超える文字はすべて '％nn'に置き換える必要があります（nnは対応する2桁の16進数）。たとえば、通常の空白文字でも '％20'に置き換える必要があります。 RFC 1867は、電子メールメッセージで一般的に見られるように、大量のデータを転送するためのエンコーディングなしで、データの周囲にはシンプルで有用なヘッダーをほとんど持たないマルチパートMIMEエンコーディングを使用します。主要ベンダーは推奨されている[参照]ボタンを採用しており、ユーザーはローカルの[ファイルを開く]ダイアログを使用してアップロードするファイルを簡単に選択できます。

RFC 1867では、ほとんどのファイルアップロードの柔軟性は依然としてWebアプリケーションにあります。 PUTは非常に限られています。 WebDAVは、FrontPageユーザーなどのコンテンツの作成者には役立ちますが、Webアプリケーションにファイルのアップロードを追加したいWeb開発者によって使用されることはめったにありません。したがって、RFC 1867はWebアプリケーションにファイルアップロードを追加するための最良の方法です。

実際には、Posting Acceptorは無料で提供されています。 ＡＳＰは、「マルチパート／フォームデータ」符号化方式を理解していない。代わりに、Posting Acceptorが提供されています。これは、アップロードが完了した後でASPページへのREPOSTを受け入れるISAPIアプリケーションです。 Software ArtisansのSA-FileUpは、最初の商用Active Serverの1つです。純粋なASPとしていくつかの改良点がありました。

II。ASPに基づくファイルアップロードの原則の分析

基本原則は、ADO StreamオブジェクトのBinaryReadメソッドを使用してFORM内のすべてのデータを読み取り、そこから必要なファイルデータを抽出することです。バイナリファイルとして保存します。ファイルページ（upload.htm）をアップロードする例を次に示します。

ファイルオブジェクトはプログラムで使用されるため、Upload.aspのBinaryReadメソッドで読み取られる生データは、選択されたファイル自体だけではありません。データには、ユーザーのハードディスク上の送信されたページのパス、種類、および形式の説明も含まれているため、ファイルの特定のコンテンツを抽出する必要があります。解析によれば、データヘッダとデータの境界は2組の復帰改行であり、末尾にも区切り情報がありますので、以下の方法でファイルデータを得ることができます。

Dim FormData.FormSize、DataStart、CLStr、DivStr FormSize = Request.TotalBytes FormData = Request.BinaryRead（FormSize）CLStr = ChrB（13）& ChrB（10）DataStart = InStrB（FormData.CLStr& CLStr） +4 '4は、2組のキャリッジリターン改行の長さです。DivStr = LeftB（FormData、InStrB（FormData、CLStr）-1） 、DataStart、DataSize）前123ページ次のページ合計3ページ