模拟HTML表单上传文件（RFC 1867）

模拟HTML表单上传文件（RFC 1867）

2011-03-27 18:59 by 老赵, 10845 visits

现在使用HTTP协议定制API已是十分常见的事情，在普通的GET和POST请求中传递些参数估计人人都会，可是若是咱们须要上传文件呢？若是只是传递单个文件，那么将数据流POST给服务器端便可。但若是须要上传多个文件，或是在文件以外须要附带一些信息，那么又该怎么作呢？以前我遇到过一些朋友是这么打算的，他们说，不如就把文件流转化为文本，而后把它看成一个普通的字段传递。这么作天然能够“实现功能”，但缺点也不少。首先，将二进制流转化为文本会增大致积（例如最多见的BASE64编码会增大1/3的数据量）；其次，既然互联网上存在相关的协议，又为什么要自定义一套规则呢？其实这即是《RFC 1867 - Form-based File Upload in HTML》，它是咱们用HTML表单上传文件时使用的传输协议，虽然十分经常使用，但彷佛了解它的人并很少。

普通POST操做

提及HTML表单，你们绝对不会陌生。例以下面这样的HTML表单：

<form action="http://www.baidu.com/" method="post"> <input type="text" name="myText1" /><br /> <input type="text" name="myText2" /><br /> <input type="submit" /> </form> 

提交时会向服务器端发出这样的数据（已经去除部分不相关的头信息）：

POST http://www.baidu.com/ HTTP/1.1
Host: www.baidu.com
Content-Length: 74
Content-Type: application/x-www-form-urlencoded

myText1=hello+world&myText2=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

对于普通的HTML POST表单，它会在头信息里使用Content-Length注明内容长度。头信息每行一条，空行以后即是Body，即“内容”。此外，咱们能够发现它的Content-Type是application/x-www-form-urlencoded，这意味着消息内容会通过URL编码，就像在GET请求时URL里的Query String那样。在上面的例子中，myText1里的空格被编码为加号，而myText2，您看得出这是“你好世界”这四个汉字吗？

使用POST上传文件

不过以前的HTML表单是没法上传文件的，所以RFC 1867应运而生，它的目的即是让HTML表单能够提交文件。它对HTML表单的扩展主要是：

• 为input标记的type属性增长一个file选项。
• 在POST状况下，为form标记的enctype属性定义默认值为application/x-www-form-urlencoded。
• 为form标记的enctype属性增长multipart/form-data选项。

因而，若是咱们要使用HTML表单提交文件，则可使用以下定义：

<form action="http://www.baidu.com/" method="post" enctype="multipart/form-data"> <input type="text" name="myText" /><br /> <input type="file" name="upload1" /><br /> <input type="file" name="upload2" /><br /> <input type="submit" /> </form> 

为了实验所需，咱们建立两个文件file1.txt和file2.txt，内容分别为“This is file1.”及“This is file2, it's bigger.”。在文本框里写上“hello world”，并选择这两个文件，提交，则会看到浏览器传递了以下数据：

POST http://www.baidu.com/ HTTP/1.1
Host: www.baidu.com
Content-Length: 495
Content-Type: multipart/form-data; boundary=---------------------------7db2d1bcc50e6e

-----------------------------7db2d1bcc50e6e
Content-Disposition: form-data; name="myText"

hello world
-----------------------------7db2d1bcc50e6e
Content-Disposition: form-data; name="upload1"; filename="C:\file1.txt"
Content-Type: text/plain

This is file1.
-----------------------------7db2d1bcc50e6e
Content-Disposition: form-data; name="upload2"; filename="C:\file2.txt"
Content-Type: text/plain

This is file2, it's longer.
-----------------------------7db2d1bcc50e6e--

这段内容比较有趣，值得细细观察。首先，第一个空行以前天然仍是HTTP头，以后则是Body，而此时的Body也比以前要复杂一些。根据RFC 1867定义，咱们须要选择一段数据做为“分割边界”，这个“边界数据”不能在内容其余地方出现，通常来讲使用一段从几率上说“几乎不可能”的数据便可。例如，上面这段数据使用的是IE 9，而我在Chrome下则是这样的：

POST http://www.baidu.com/ HTTP/1.1
Host: www.baidu.com
Content-Length: 473
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryW49oa00LU29E4c5U

------WebKitFormBoundaryW49oa00LU29E4c5U
Content-Disposition: form-data; name="myText"

hello world
------WebKitFormBoundaryW49oa00LU29E4c5U
Content-Disposition: form-data; name="upload1"; filename="file1.txt"
Content-Type: text/plain

This is file1.
------WebKitFormBoundaryW49oa00LU29E4c5U
Content-Disposition: form-data; name="upload2"; filename="file2.txt"
Content-Type: text/plain

This is file2, it's bigger.
------WebKitFormBoundaryW49oa00LU29E4c5U--

很显然它们两个选择了不一样的数据“模式”做为边界——事实上，浏览器提交两次数据时，使用的边界也可能不会相同，这都没有问题。

选择了边界以后，便会将它放在头部的Content-Type里传递给服务器端，实际须要传递的数据即可以分割为“段”，每段即是“一项”数据。从上面的内容中你们应该都能看出数据传输的规范，所以便不作细谈了。只强调几点：

• 数据均无需额外编码，直接传递便可，例如您能够看出上面的示例中的“空格”均没有变成加号。至于这里您能够看到清晰地文字内容，是由于咱们上传了仅仅包含可视ASCII码的文本文件，若是您上传一个普通的文件，例如图片，捕获到的数据则几乎彻底不可读了。
• IE和Chrome在filename的选择策略上有所不一样，前者是文件的完整路径，然后者则仅仅是文件名。
• 数据内容以两条横线结尾，并一样以一个换行结束。在网络协议中通常都以连续的CR、LF（即\r、\n，或0x0D、Ox0A）字符做为换行，这与Windows的标准一致。若是您使用其余操做系统，则须要考虑它们的换行符。

实现

了解上述策略以后，使用编程来实现文件上传也是瓜熟蒂落的事情，例如我这里便编写了一段简单的代码实现这一功能。

首先，咱们定义一个Part类，表示每“段”，它的Write方法会写入整段数据。每段数据分为Header和Body两部分，使用WriteHeader和WriteBody两个抽象方法写入：

public abstract class Part { protected abstract void WriteHeader(StreamWriter writer); protected abstract void WriteBody(StreamWriter writer); public void Write(StreamWriter writer)
    { this.WriteHeader(writer);
        writer.WriteLine(); this.WriteBody(writer);
    }
}

接着即是表示普通字段的NormalPart和文件上传得FilePart：

public class NormalPart : Part { public string Name { get; set; } public string Value { get; set; } protected override void WriteHeader(StreamWriter writer)
    {
        writer.WriteLine("Content-Disposition: form-data; name=\"{0}\"", this.Name);
    } protected override void WriteBody(StreamWriter writer)
    {
        writer.WriteLine(this.Value);
    }
} public class FilePart : Part { public string Name { get; set; } public string FilePath { get; set; } protected override void WriteHeader(StreamWriter writer)
    {
        writer.WriteLine( "Content-Disposition: form-data; name=\"{0}\"; filename=\"{1}\"", this.Name, Path.GetFileName(this.FilePath));

        writer.WriteLine("Content-Type: application/octet-stream");
    } protected override void WriteBody(StreamWriter writer)
    { var data = File.ReadAllBytes(this.FilePath);
        writer.Flush();
        writer.BaseStream.Write(data, 0, data.Length);
        writer.WriteLine();
    }
}

最后即是统一写入各段的Write方法，我在这里使用新建的GUID做为“边界”：

static void Write(StreamWriter writer, IEnumerable<Part> parts)
{ var guidBytes = Guid.NewGuid().ToByteArray(); var boundary = "----------------" + Convert.ToBase64String(guidBytes); foreach (var p in parts)
    {
        writer.WriteLine(boundary);
        p.Write(writer);
    }

    writer.WriteLine(boundary + "--");
}

其实就是这么简单。不过在实际状况中可能会复杂一些。例如，因为HTTP协议须要先发送头信息，所以咱们须要提早计算出Content-Length再传输全部内容，不过我相信这对您来讲也不会是件难事。

其余

世界上已经有了足够多的协议，在我看来在绝大部分状况下都无所谓使用自定义的协议。协议在制定时，每每也会考虑到安全、性能等诸多方面，有时候咱们本身所谓的“顾虑”其理由也并不充分。更重要的是，使用现成的协议，咱们每每都有现成的实现，对于开发和测试都会有很大帮助。

RFC 1867是一个很简单的协议，固然再简单也不是我这短短一篇文章能够完整描述的，其中不少细节（例如在同一个“段”中上传多个文件）就要靠您本身去挖掘了。

广告时间：nBazaar技术会议的邮件列表已经正式启用，全部用户也已添加完成。目前已经发送了第一封邮件，建议您检查一下本身的收件箱或垃圾箱，确保能够收到将来的邮件。若有任何疑问，请发邮件至。

• Categories: 实践优化
• Tags: RFC 1867, 文件上传, HTML

本文基于署名 2.5 中国大陆许可协议发布，欢迎转载，演绎或用于商业目的，可是必须保留本文的署名赵劼（包含连接），具体操做方式可参考此处。如您有任何疑问或者受权方面的协商，请给我留言。

ADD YOUR COMMENT

19 条回复