The principle of no component upload
I am still 1.1 points with an example to illustrate the bar, the client HTML is as follows. To browse the upload attachment, we pass <input type= "file" > element, but be sure to note that the Enctype property of the form must be set to "Multipart/form-data":
<form method= "POST" action= "upload.asp" enctype= "Multipart/form-data" >
<label>
<input type= "File" name= "File1"/>
</label>
<br/>
<input type= "text" name= "filename" value= "Default filename"/>
<br/>
<input type= "Submit" value= "Submit"/>
<input type= "reset" value= "reset"/>
</form>
In the background ASP program, it is easy to get the ASCII data submitted by the form before. However, if you need to obtain the uploaded file, you must use the BinaryRead method of the Request object to read it. The BinaryRead method is binary read of the specified byte number for the current input stream, and it is somewhat noteworthy that once the BinaryRead method is used, the Request.Form or Request.QueryString collection can no longer be used. Combined with the TotalBytes property of the Request object, all the form submissions can be turned into binary, but the data is encoded. Let's start by looking at how the data is encoded, there is no law to follow, coding code, in the code we will binaryread read the binary into text, output out, in the background of the upload.asp (note that the example does not upload large files, or may cause the browser to die):
<%
Dim Bidata, PostData
Size = Request.TotalBytes
Bidata = Request.BinaryRead (Size)
PostData = binarytostring (bidata,size)
Response.Write "<pre>" & PostData & "</pre>" ' use pre, output format as-is
' Using a recordset to convert binary streams into text
Function binarytostring (bidata,size)
Const adLongVarChar = 201
Set RS = CreateObject ("ADODB.") Recordset ")
Rs. Fields.Append "Mbinary", adLongVarChar, Size
Rs. Open
Rs. AddNew
RS ("Mbinary"). AppendChunk (Bidata)
Rs. Update
BinaryToString = RS ("Mbinary"). Value
Rs. Close
End Function
%>
For simplicity, upload one of the simplest text files (G:\homepage.txt, content for "Baoyu:http://www.webuc.net ";) to experiment, the text box filename left the default value "FileName", submitted to see the output results:
-----------------------------7d429871607fe
Content-disposition:form-data; Name= "File1"; Filename= "G:\homepage.txt"
Content-type:text/plain
Bao Yu:http://www.webuc.net
-----------------------------7d429871607fe
Content-disposition:form-data; Name= "FileName"
Default filename
-----------------------------7d429871607fe--
As you can see, for the items in the form, they are separated into a piece with a boundary such as "-----------------------------7d429871607fe", and each piece has some descriptive information at the beginning, For example: Content-disposition:form-data; Name= "FileName", in the description information, through name= "filename" can know the name of the table item. If there is a filename= "G:\homepage.txt" Such content, the description is an uploaded file, if it is an uploaded file, then the Fang ⒒ Xiu psssssssssssst flurried 蠧 ontent-type:text/plain to describe the file content-type. The description information and the principal information are separated by a newline.
Well, basically clear, according to this law we know how to separate data, and then the separation of data processing, but almost ignore a problem is the boundary value (in the example of the "-----------------------------7d429871607fe") How did you know that? Each upload this boundary value is not the same, fortunately fortunately, the ASP can be Request.ServerVariables ("Http_content_type") to obtain, such as in the above example Http_content_type content is: " Multipart/form-data; boundary=---------------------------7d429871607fe ", with this, we can not only judge whether the client's form uses enctype=" Multipart/form-data "( If it is not used, then there is no need to execute it below, and you can get the boundary value boundary=---------------------------7d429871607fe. (Note: The boundary value obtained here is less than the threshold of the above boundary value "--", preferably added.) ）
As for how to analyze the process of data I do not repeat, nothing more than the use of such functions such as instr,mid to separate out the data we want.
Second, block upload, record progress
To reflect the progress bar in real time, the real thing is to know how much data the current server gets. Recall that we implement the upload process, we are through Request.BinaryRead (request.totalbytes) to achieve, in the process of Request we can not know how much data the current server gets. So only through the workaround, if we can get the data into a piece, and then based on the number of blocks already uploaded we can calculate how much of the current upload! In other words, if I 1K 1, then upload 1MB input stream is divided into 1024 pieces to get, for example, I currently have access to 100 pieces, then indicate that the current upload 100K. A lot of people think it's amazing when I make a chunk, because they ignore it. The BinaryRead method is not only able to read the specified size, but can be read sequentially.
Write an example to verify the integrity of the chunk read, on the basis of the example (note that the example does not upload large files, or it may cause the browser to die):
<%
Dim Bidata, PostData, TotalBytes, chunkbytes
Chunkbytes = 1 * 1024 ' chunking size 1K
TotalBytes = Request.TotalBytes ' Total size
PostData = "" to data after conversion to text type
readedbytes = 0 ' initialized to 0
' Chunk-Reading
Do While Readedbytes < totalbytes
Bidata = Request.BinaryRead (chunkbytes) ' current block
PostData = postdata & BinaryToString (bidata,chunkbytes) ' Converts the current block into text and stitching
Readedbytes = readedbytes + chunkbytes ' record read size
If readedbytes > TotalBytes Then readedbytes = totalbytes
Loop
Response.Write "<pre>" & PostData & "</pre>" ' use pre, output format as-is
' Convert binary stream to text
Function binarytostring (bidata,size)
Const adLongVarChar = 201
Set RS = CreateObject ("ADODB.") Recordset ")
Rs. Fields.Append "Mbinary", adLongVarChar, Size
Rs. Open
Rs. AddNew
RS ("Mbinary"). AppendChunk (Bidata)
Rs. Update
BinaryToString = RS ("Mbinary"). Value
Rs. Close
End Function
%>
Try uploading just the text file, the output proves that this chunk-read content is complete, and in the while loop, we can log the current state to application in each loop, and then we can dynamically get the upload progress bar by accessing the application.
Another: The above example is a string concatenation, if you want to stitch binary data, you can through the ADODB.stream object of the Write method, the sample code is as follows:
Set Bsourcedata = CreateObject ("ADODB. Stream ")
Bsourcedata.open
Bsourcedata.type = 1 ' Binary
Do While Readedbytes < totalbytes
Bidata = Request.BinaryRead (chunkbytes)
Bsourcedata.write Bidata ' writes the current file stream to the Bsourcedata directly using the Write method
Readedbytes = readedbytes + chunkbytes
If readedbytes > TotalBytes Then readedbytes = totalbytes
Application ("readedbytes") = Readedbytes
Loop
Third, save the uploaded files
by Request.BinaryRead to obtain submission data, separate the upload file, depending on the type of data, the storage mode is different:
For binary data, the binary stream can be saved as a file directly through the ADODB.stream object's SaveToFile method.
For text data, you can save text data to a file by TextStream the Write method of the object.
For text data and binary data, can be easily converted to each other, for uploading small files, the two basically no difference. But there are some differences between the two ways of saving, For a ADODB.stream object, all data must be loaded before it can be saved to a file, so using this method if uploading large files will be very memory, and for the TextStream object, you can create a file, a write part, several times write, the advantage is not to occupy the server memory Space, combined with the above analysis of the block to get the data principle, we can get a piece of upload data to write to the file. I have done experiments, the same machine upload a file of more than 200 MB, using the first way memory has been up, to the end directly prompted the computer virtual memory is not enough, the most hateful is even if the progress bar indicates that the file has been uploaded, but the final file is not saved. and using the latter method, the memory of the upload process basically does not change.
