Combine the example analysis ASP file upload principle

All along, due to the limitations of FileSystemObject, the biggest problem of ASP is file upload, most of the solution is to install third-party upload components. There are many problems with third-party components. Some components are registered, and some components have their copyright information added to the form. It is understood that there are three mechanisms for uploading files in HTTP: RFC1867, PUT and WebDAV. A common implementation is to take advantage of a new type introduced in RFC 1867: File and ADO Stream objects. This paper discusses the above uploading method and implementation principle, and gives specific solutions.

ASP FILE Objects

Currently, /mode-based applications are popular. When the user needs to transfer the file to it, one of the common methods is to run FTP and set each user's FTP default directory to the user's Web home directory, so that the user can run the FTP client and upload the file to the specified Web directory. . This requires the user to know how to use the FTP client. Therefore, this solution is only feasible for users who are familiar with FTP and experienced. If we can integrate the file upload function with the web, so that users can complete the upload task using only the Web, it will be very convenient for them. However, for a long time, because File System Object can only transmit the limitations of text files, the biggest problem with ASP is the file upload problem. The following is how to implement file upload in web pages based on HTTP protocol.

I. Three mechanisms for uploading via HTTP

There are three mechanisms for uploading via HTTP: RFC1867, PUT and WebDAV.

PUT is a new HTTP verb introduced in HTTP 1.1. When the web receives an HTTP PUT and object name, it will authenticate the user, receive the contents of the HTTP stream, and save it directly to the web. This can cause damage to a web site and lose the biggest advantage of HTTP: programmability. In the case of PUT, handle the request yourself: there is no room for CGI or ASP applications to intervene. The only way to get your app to capture PUT is to operate at a lower level, the ISAPI filter layer. For the corresponding reasons, the application of PUT is very limited.

While WebDAV allows distributed authentication and translation of web content. It introduces several new HTTP verbs that allow uploading via HTTP, locking/unlocking, and registering/verifying web content. "Save to web" in Office 2000 is implemented through WebDAV. If everything you are interested in is uploading content, WebDAV is a great application and it solves a lot of problems. However, if you need to upload files in your web application, WebDAV is useless to you. Like HTTP PUT, those WebDAV verbs are interpreted rather than web applications. You need to work in the ISAPI filter layer to access these verbs of WebDAV and interpret the content in your application.

RFC1867 was finally adopted as a recommended standard before being accepted by the W3C in HTML 3.2. It's a very simple but powerful idea: define a new type in the form field.

and adding different encoding schemes to the form itself, no longer using the typical:

but using:

This encoding scheme is used when transferring large amounts of data. It is much more efficient than the default "application/x-url-encoded" form encoding scheme. URL encoding has a very limited character set. Any character that exceeds the character set must be replaced with '%nn', where nn represents the corresponding 2 hexadecimal digits. For example, even ordinary whitespace characters should be replaced with '%20'. RFC 1867 uses multi-part MIME encoding, as is commonly seen in e-mail messages, without encoding to transfer large amounts of data, but with few simple but useful headers around the data. The major vendors have adopted the recommended "Browse..." button, and users can easily use the local "Open File..." dialog to select the file to upload.

RFC1867 still leaves the flexibility of most file uploads to your web application. PUT is very limited. WebDAV is useful for authors of content, such as FrontPage users, but is rarely used by web developers who want to add file uploads to web applications. Therefore, RFC1867 is the best way to add file uploads to web applications.

In practice, Posting Acceptor is provided free of charge. ASP does not understand the "multipart/form-data" encoding scheme. Instead, the Posting Acceptor is provided. The Posting Acceptor is an ISAPI application that accepts REPOST to an ASP page after the upload is complete. Software Artisans' SA-FileUp is one of the first commercial Active Servers. After several improvements, it now exists as a pure ASP.

II. Analysis of the principle of file upload based on ASP

The basic principle is: use the BinaryRead method of the ADO Stream object to read all the data in the FORM, and extract the required file data from it. , save as a binary file. The following is an example of uploading a file page (upload.htm):

The file object is used in the program, so the raw data read in the BinaryRead method in Upload.asp is not only the selected file itself. The data also contains a description of the path, type, and form of the submitted page on the user's hard disk, so that we need to extract the specific content of the file. According to the analysis, the boundary between the data header and the data is two pairs of carriage return line feeds, and the tail also has separation information. We can obtain file data by using the following method.

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 is the length of two pairs of carriage return line breaks DivStr=LeftB(FormData, InStrB(FormData, CLStr)-1) DataSize=InStrB(DataStart+1,FormData,DivStr)-DataStart-2 FormData=MidB(FormData ,DataStart,DataSize) Previous123Next page Total 3 pages