Network Working Group E. Nebel
Request For Comments: 1867 L. Masinter
Category: Experimental Xerox Corporation
November 1995
Form-based File Upload in HTML
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
1. Abstract
Currently, HTML forms allow the producer of the form to request
information from the user reading the form. These forms have proven
useful in a wide variety of applications in which input from the user
is necessary. However, this capability is limited because HTML forms
don't provide a way to ask the user to submit files of data. Service
providers who need to get files from the user have had to implement
custom user applications. (Examples of these custom browsers have
appeared on the www-talk mailing list.) Since file-upload is a
feature that will benefit many applications, this proposes an
extension to HTML to allow information providers to express file
upload requests uniformly, and a MIME compatible representation for
file upload responses. This also includes a description of a
backward compatibility strategy that allows new servers to interact
with the current HTML user agents.
The proposal is independent of which version of HTML it becomes a
part.
2. HTML forms with file submission
The current HTML specification defines eight possible values for the
attribute TYPE of an INPUT element: CHECKBOX, HIDDEN, IMAGE,
PASSWORD, RADIO, RESET, SUBMIT, TEXT.
In addition, it defines the default ENCTYPE attribute of the FORM
element using the POST METHOD to have the default value
"application/x-www-form-urlencoded".
This proposal makes two changes to HTML:
1) Add a FILE option for the TYPE attribute of INPUT.
2) Allow an ACCEPT attribute for INPUT tag, which is a list of
media types or type patterns allowed for the input.
In addition, it defines a new MIME media type, multipart/form-data,
and specifies the behavior of HTML user agents when interpreting a
form with ENCTYPE="multipart/form-data" and/or <INPUT type="file">
tags.
These changes might be considered independently, but are all
necessary for reasonable file upload.
The author of an HTML form who wants to request one or more files
from a user would write (for example):
<FORM ENCTYPE="multipart/form-data" ACTION="_URL_" METHOD=POST>
File to process: <INPUT NAME="userfile1" TYPE="file">
<INPUT TYPE="submit" VALUE="Send File">
</FORM>
The change to the HTML DTD is to add one item to the entity
"InputType". In addition, it is proposed that the INPUT tag have an
ACCEPT attribute, which is a list of comma-separated media types.
... (other elements) ...
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
IMAGE | HIDDEN | FILE )">
<!ELEMENT INPUT - 0 EMPTY>
<!ATTLIST INPUT
TYPE %InputType TEXT
NAME CDATA #IMPLIED -- required for all but submit and reset
VALUE CDATA #IMPLIED
SRC %URI #IMPLIED -- for image inputs --
CHECKED (CHECKED) #IMPLIED
SIZE CDATA #IMPLIED --like NUMBERS,
but delimited with comma, not space
MAXLENGTH NUMBER #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
ACCEPT CDATA #IMPLIED --list of content types
>
... (other elements) ...
3. Suggested implementation
While user agents that interpret HTML have wide leeway to choose the
most appropriate mechanism for their context, this section suggests
how one class of user agent, WWW browsers, might implement file
upload.
3.1 Display of FILE widget
When a INPUT tag of type FILE is encountered, the browser might show
a display of (previously selected) file names, and a "Browse" button
or selection method. Selecting the "Browse" button would cause the
browser to enter into a file selection mode appropriate for the
platform. Window-based browsers might pop up a file selection window,
for example. In such a file selection dialog, the user would have the
option of replacing a current selection, adding a new file selection,
etc. Browser implementors might choose let the list of file names be
manually edited.
If an ACCEPT attribute is present, the browser might constrain the
file patterns prompted for to match those with the corresponding
appropriate file extensions for the platform.
3.2 Action on submit
When the user completes the form, and selects the SUBMIT element, the
browser should send the form data and the content of the selected
files. The encoding type application/x-www-form-urlencoded is
inefficient for sending large quantities of binary data or text
containing non-ASCII characters. Thus, a new media type,
multipart/form-data, is proposed as a way of efficiently sending the
values associated with a filled-out form from client to server.
3.3 use of multipart/form-data
The definition of multipart/form-data is included in section 7. A
boundary is selected that does not occur in any of the data. (This
selection is sometimes done probabilisticly.) Each field of the form
is sent, in the order in which it occurs in the form, as a part of
the multipart stream. Each part identifies the INPUT name within the
original HTML form. Each part should be labelled with an appropriate
content-type if the media type is known (e.g., inferred from the file
extension or operating system typing information) or as
application/octet-stream.
If multiple files are selected, they should be transferred together
using the multipart/mixed format.
While the HTTP protocol can transport arbitrary BINARY data, the
default for mail transport (e.g., if the ACTION is a "mailto:" URL)
is the 7BIT encoding. The value supplied for a part may need to be
encoded and the "content-transfer-encoding" header supplied if the
value does not conform to the default encoding. [See section 5 of
RFC 1521 for more details.]
The original local file name may be supplied as well, either as a
'filename' parameter either of the 'content-disposition: form-data'
header or in the case of multiple files in a 'content-disposition:
file' header of the subpart. The client application should make best
effort to supply the file name; if the file name of the client's
operating system is not in US-ASCII, the file name might be
approximated or encoded using the method of RFC 1522. This is a
convenience for those cases where, for example, the uploaded files
might contain references to each other, e.g., a TeX file and its .sty
auxiliary style description.
On the server end, the ACTION might point to a HTTP URL that
implements the forms action via CGI. In such a case, the CGI program
would note that the content-type is multipart/form-data, parse the
various fields (checking for validity, writing the file data to local
files for subsequent processing, etc.).
3.4 Interpretation of other attributes
The VALUE attribute might be used with <INPUT TYPE=file> tags for a
default file name. This use is probably platform dependent. It might
be useful, however, in sequences of more than one transaction, e.g.,
to avoid having the user prompted for the same file name over and
over again.
jspSmartUpload
需积分: 0 64 浏览量
更新于2008-07-07
收藏 123KB RAR 举报
`jspSmartUpload`是一个专为JavaServer Pages (JSP) 设计的上传组件,它使得在JSP应用程序中实现文件上传功能变得简单易行。在Web开发中,文件上传是常见的需求,例如用户可能需要上传个人照片、文档或多媒体文件等。`jspSmartUpload`通过提供一套完整的API和内置的功能,简化了这一过程。
该组件的核心功能包括:
1. **多文件上传支持**:`jspSmartUpload`允许用户同时上传多个文件,提高了用户体验,减少了多次点击的繁琐步骤。
2. **文件大小限制**:可以设置每个文件以及整个上传请求的最大大小,防止大文件或恶意文件的上传,保护服务器资源。
3. **文件类型检查**:支持对上传文件类型的检查,只允许特定格式的文件上传,增加了应用的安全性。
4. **进度显示**:组件提供了文件上传进度的显示功能,使用户了解上传状态,提升了交互体验。
5. **错误处理**:当文件上传过程中出现错误时,`jspSmartUpload`能捕获并处理这些错误,如文件过大、类型不符等,提供友好的错误提示。
6. **自定义回调函数**:开发者可以通过自定义的回调函数来处理文件上传成功或失败后的操作,比如将文件保存到特定位置,或者进行数据库记录等。
7. **兼容性**:`jspSmartUpload`通常与各种Web服务器和Servlet容器(如Tomcat、Jetty等)兼容,并且与主流的浏览器(如Chrome、Firefox、IE等)兼容。
使用`jspSmartUpload`,开发者需要在JSP页面中添加相应的标签库引用,然后在JSP代码中使用其提供的API来处理文件上传逻辑。例如,创建一个表单,包含`jspSmartUpload`的上传控件,然后在服务器端处理上传的文件。
```jsp
<%@ taglib uri="http://www.servletsuite.com/smartupload" prefix="ss" %>
<ss:html>
<ss:form action="uploadServlet" method="post" enctype="multipart/form-data">
<ss:file name="file" multiple="true" size="30" />
<input type="submit" value="上传" />
</ss:form>
</ss:html>
```
在对应的Servlet中,可以通过`SmartUpload`对象来获取上传的文件:
```java
import com.servletsuite.smartupload.SmartUpload;
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
SmartUpload smartUpload = new SmartUpload();
smartUpload.initialize(this, request, response);
try {
smartUpload.upload();
// 获取上传的文件集合
List<SmartFile> files = smartUpload.getFiles();
for (SmartFile file : files) {
// 处理每个文件
String fileName = file.getName();
byte[] fileBytes = file.getData();
// ... 保存文件到服务器、更新数据库等操作
}
} catch (Exception e) {
// 错误处理
} finally {
smartUpload.cleanup();
}
}
```
通过这样的方式,`jspSmartUpload`极大地简化了在JSP项目中实现文件上传功能的工作。然而,随着技术的发展,现在有许多其他更现代的替代方案,如使用HTML5的`FormData`对象配合Ajax进行异步上传,或是利用流行的前端框架(如React、Vue等)的上传组件,它们提供了更多的特性和更好的性能。但对一些旧项目或只需要基本上传功能的场景,`jspSmartUpload`仍然是一个实用的选择。