구글와이드(336x280)_상단 2개


(영문)Advanced File Uploading - Uploading to a Database ASP, ASP.NET

Advanced File Uploading
By Jos Vernon
Basic File Uploads
File Upload or HTTP upload allows site visitors to send files to the Web server using standard forms. In the same way that there are form elements that allow you to enter text and others that allow you to choose items from a list, there is a form element that allows you to choose a file.
Like so many useful elements of HTML, file upload was not supported in Internet Explorer 3.0 but was added in version 3.02. It is available in Netscape Navigator from version 2.02 onward. Realistically, this means that you can rely on almost every visitor being able to upload files. What does it look like? Well, check out the (nonfunctional) form below that is much like any other form element, except that you can use the browse button to choose files.
Enter Some Text:

Choose A File:


Here's the code for the above.
 <form method="post" action="upload.asp" name="submit" enctype="multipart/form-data">
Enter Some Text: <input type="text" name="textfield"><br><br>
Choose A File: <input type="file" name="filefield"><br><br>
<input type="submit" name="submit" value="submit"><br>
</form> 

There are only a couple of real differences. The input type of the file upload is "file," rather than "text." The enctype of the form is multipart/form-data. Multipart form data is an Internet standard covered by RFC 1867. (Request For Comments [RFC] are used by the Internet Engineering Task Force [IETF] and other standards bodies.) Multipart form data allows many different types of information to be sent over the Internet as one bundle. It's not very complicated in theory, but the practicalities can be.
Different browsers implement a variety of nonstandard extensions to work around areas not covered by the RFC, and there are bugs that you must be aware of to make upload work reliably. And note that ASP doesn't support multipart form data as standard! It is a horrible truth that although Microsoft browsers have supported multipart forms since Microsoft became interested in the Web, the standard form components it supplies for Web serving do not. There are a number of third-party ASP extensions designed specifically to solve this problem. For instance, SoftArtisans produces SAUpload and Persits produces ASPUpload.
This article uses examples from ABCUpload, which is a free product from WebSupergoo. Using ABCUpload, you need to write the following code to save the uploaded file:

<% @Language="VBScript" %>
<%
Set theForm = Server.CreateObject("ABCUpload.XForm")
theForm("filefield")(1).Save "myupload.dat"
%>
<html>
<body>
File uploaded...
</body>
</html>


This will save the file into the current directory as myupload.dat. By default, the file path is assumed to be a URL rather than a physical file location.
The Duplicitous Nature of Macintosh Files
Multipart form data was written to deal with standard files. However, Macintosh files are different from Windows files in three main ways:
  1. Every file consists of two separate streams or forks. The data fork holds the basic file information that you would find in a Windows file. The resource fork contains a database of other associated information, such as picture previews, notes, and icons. So a bitmap (BMP) image might contain the BMP in the data fork and an icon, preview, and copyright note in the resource fork.
  2. Macintosh files do not contain a file-type extension. Instead, they have a hidden type and creator code.
  3. Macintosh file names can contain almost any character except for the colon character. This means that it is common to have Macintosh files containing slashes, question marks, and asterisks.
When Internet Explorer uploads a file from a Macintosh, it chooses to put all this information together into one big stream encoded as MacBinary. You can just rip out the data fork, and this is what most MacBinary-compatible upload components do.
However, if you do this, you lose all sense of what type of file was uploaded and any other associated information. In particular, some types of files,, such as Encapsulated PostScript Files (EPSFs) and QuickTime movies,, can be completely destroyed by this process.
If you have a number of Macintosh clients, this is an issue you will need to consider when developing your solution. For example, the publishing or design industries will have a significant number of Macintosh clients. First, you need to ensure that your solution supports MacBinary. If it does not, you will not be able to use files uploaded from Macintosh clients.. Also note that the MacBinary encoding that IE uses is nonstandard so unless you factor this into your solution, some uploads may fail.
Second, you need to determine what types of file you're being given. ABCUpload does this invisibly using the file-type information provided as part of the MacBinary encoding. Other solutions may use different methods or may not handle file types at all.
Third, you need to decide how to handle resource and data forks. Most MacBinary solutions just rip out the data fork and abandon the resource fork. This is often sufficient for simple processing. ABCUpload and SAUpload actually store the data and resource forks intact using the standard NT mechanism used by Services for Macintosh (SFM). If you look at such a file from Windows, it will look like a standard file (e.g., JPEG, DOC, etc.). However, if you serve this file to Macintosh users using Services for Macintosh (SFM), they will see the original file completely intact.
Dealing with the Deceptive Nature of File Names
Consider what kind of file names you want to use when saving uploaded files. Probably the simplest solution is to abandon the name of the file your visitor has provided and create a completely new one that you know is both valid and unique. However, sometimes you need to let people preserve the name of their file, and this is where you need to consider a number of issues.
First, a valid file name for one person is not necessarily a valid one for someone else. You will find that you need at least three types of file names -- Raw, Server Safe, and URL Safe. The Raw file name is the one used by the client on their system and may contain spaces, colons, slashes, and other illegal characters. The Server Safe name should be as similar to the original name as possible but exclude illegal characters so that it can be used on the server. URL Safe names are even more restrictive. They must exclude or encode any characters, such as spaces, that cannot be used in a URL.
For example, a Windows user may upload a file named "My Birthday.JPG." The Server Safe name might be "My Birthday.JPG" while the URL Safe name might be "mybirthday.jpg." As another example, a Macintosh client might upload a JPEG image named "My Birthday 2/2/2001." The Server Safe name might be "My Birthday 2-2-2001.JPG" and the URL safe name might be "mybirthday2-2-2001.jpg." Different components handle this problem in different ways. ABCUpload simply uses three different properties, each with a different file name. To save a file using the URL Safe, Server Safe, or Raw file names, simply use the respective methods:
theField.Save theField.FileName ' URL Safe
theField.Save theField.SafeFileName ' Windows Safe
theField.Save theField.RawFileName ' Original 
In addition, you may get Unicode uploads from clients in other countries.
Unicode is the format in which languages such as Japanese and Korean are encoded. In general, Internet Explorer browsers support Unicode uploads, while Netscape Navigator browsers do not.
Inadequate Progress Bars
Probably the biggest drawback of HTTP upload has been the pitiful progress bars shown on the browser. Problems start to arise when you want to upload large files or your users are on slow connections. When they submit their file, it may take seconds or minutes to send to the server. Because browsers don't give good feedback, your users may get confused or frustrated and give up before completing their upload. The obvious solution to this is to give the user a dedicated progress bar, but Java or ActiveX bring in all the problems of incompatibility that we were avoiding by using HTTP upload.
Recently a new class of progress bar has been innovated. This is a client-side HTML progress bar to chart upload progress. When the upload form is submitted, a progress window is spawned that auto-refreshes to keep track of progress while the upload is active. Only client-side JavaScript is required, not Java or ActiveX.
The key feature that enables this HTML progress bar is that a unique ID is assigned to both the upload and to the spawned progress window. The unique ID is used to update a server-side upload registry that can be accessed by the progress window.
If you require a progress bar, establish what kind of support is provided by your solution. ABCUpload uses a Pure HTML Progress Bar, while some other solutions may not have any progress support or rely on Java or ActiveX.
Uploading to a Database
Generally, it is a good idea to avoid putting images in databases. Databases often have problems holding the very large amounts of data involved, and it is preferable to save images to a file and then insert the unique file name into the database.
However, if you need to put images into a database, there are a variety of methods, some of which can be quite involved. This example shows a very simple method.
We installed SQLServer 7 on our CC2 server. We created a database called "mydbase" and inserted a table called "mytable" with an Image column called "myimage." Finally, we created a user called "myuser" with a password, namely"password," and read/write access to the database.
In the code below we first check to see that an image file has been uploaded. If it has, we connect to the database and then open a recordset. We add a new record and put the field data from the upload into the "myimage" column. Then we update the recordset and close the connection.
 <% @Language="VBScript" %>
<% 
Set theForm = Server.CreateObject("ABCUpload.XForm")
Set theField = theForm("filefield")(1)
If theField.FileExists and theField.ImageType <> 0 Then
Set cn = Server.CreateObject("ADODB.Connection")
theConn = "Provider=SQLOLEDB;Data Source=CC2;Initial Catalog=mydbase;User Id=myuser;Password=password"
cn.Open theConn
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open "mytable", cn, 1, 3
rs.AddNew
rs("myimage").Value = theField.Data
rs.Update
rs.Close
cn.Close
End If 
%>
<html>
<body>
File uploaded...
</body>
</html>  

The Mysteries of the Metabase
A number of ASP settings become relevant when performing uploads. These can be changed using ASP scripts or by editing the IIS Metabase, the location where all the IIS preferences are stored. Edit the IIS Metabase using the Microsoft Metabase Editor (MetaEdit), which is supplied as part of the Windows Resource Kits.
Please note that you can fatally damage your IIS installation using MetaEdit so make sure to edit carefully. Where possible, it is generally easier and safer to alter settings using the simple scripting commands given here. The script time-out refers to the number of seconds an Active Server Page is given before the script is assumed to have failed and the page terminated. If you are uploading a large file, the script that is receiving the transfer may time out before the file has been completely uploaded. To alter this setting you should insert the following code into your uploading page prior to creating any ABCUpload objects:
Server.ScriptTimeout = 360 ' six minutes  
The session time-out is similar to the script time-out but refers to the number of minutes before the user session is aborted. Again, if a large file is being uploaded, it is desirable to maintain the session state. The session time-out should always be longer than the script time-out. Note that this value is only relevant if you have session state enabled. To alter this setting you should insert the following code into your uploading page prior to creating any ABCUpload objects:
Session.Timeout = 30 ' thirty minutes
The UploadReadAheadSize property determines the number of bytes the Web server will read into a buffer and pass to IIS. For large uploads, a greater value may increase the speed of uploads at the cost of increased memory use. This property can only be altered by editing the IIS Metabase.

null



바보들의 영문법 카페(클릭!!)

오늘의 메모....

시사평론-정론직필 다음 카페
http://cafe.daum.net/sisa-1

바보들의 영문법 다음 카페
http://cafe.daum.net/babo-edu/

티스토리 내 블로그
http://earthly.tistory.com/

내 블로그에 있는 모든 글들과 자료에 대한 펌과 링크는 무제한 허용됩니다.
(단, 내 블로그에 덧글쓰기가 차단된 자들에게는 펌, 트랙백, 핑백 등이 일체 허용되지 않음.)

그리고 내 블로그 최근글 목록을 제목별로 보시려면....
바로 아래에 있는 이전글 목록의 최근달을 클릭하시면 됩니다.
그러면 제목을 보고 편하게 글을 골라 보실 수 있습니다.

그리고 내 블로그내 글을 검색하시려면 아래 검색버튼을 이용하시면 됩니다.


가가챗창

flag_Visitors

free counters