语境
我使用 .Net 技术开发了一个 Web Api,其中一项操作是上传图像文件。
API 将接收来自移动应用程序(Android 和 iOS)的请求。
API 必须满足以下两个条件之一:
- 使用 为每个请求上传一个文件
multipart/form-data
,即文件直接嵌入到请求中 - 为每个请求上传一个文件,将其发送到正文中,
string
编码为base64
这两个操作都起作用并接收文件(根据 API 接收文件的格式来处理它)。
问
在暴露的场景下使用multipart/form-data
而不是使用是否有优势或最佳实践?base64
base64
是将字节转换为ASCII字符。不建议您使用 base64,因为这会增加请求的权重。例如,将hola
4 个字节转换为 base64 的简单字符产生8 个字节(你好,在 base64 中它是aG9sYQ==
),正如您刚才所说,它将是一个发送数据的 android 应用程序,您将不必要地消耗更多的互联网数据给用户。另一件需要注意的是,base64 必须在服务器上进行解码,添加这个加处理。如果您发送 +10MB 的文件,您必须首先:
在 multipart 的情况下,这是 HTTP 协议的一部分,而 base64 不是。虽然它不压缩它们,但它确保了与所有 http 服务器的兼容性并发送任何类型的文件。
优势:
base64
这是一种将数据放大到 30% 的编码方式,multipart/form-data
它是标准的一部分http
并允许发送二进制数据,因为它multipart
更快并且消耗更少的带宽base64
将二进制数据转换为“可打印”的 ASCII 表示,8 位空间减少到 6 位并由字母和数字(加上几个符号)表示,因此整体大小增加。这在https://es.wikipedia.org/wiki/Base64#Example中得到了很好的解释由于 4 是 3 的 133%,因此通常说它将输入数据增加了 30%。
base64
它比任何用于SMTP
(有 7 位空间)的东西都要多,也就是说电子邮件服务器和中继,或者通过 url 传递它(减去=
将要转换为%3D
并且必须单独解码或计算的填充) in url 的常见示例base64
是将图像文件(二进制)插入 HTML、XML 或 CSS(仅文本)。在简单的 API 中,它可能是有意义的,例如,对编码的 json 进行 url
base64
,因此 URL 包含生成响应的所有信息(即使如此,对于 URL 的总长度也存在某些实际限制)。multipart
相反,它允许直接发送二进制数据(8位字节)Content-Transfer-Encoding: binary
作为一个 API
http
,你必须在两者之间做出选择,multipart/form-data
这是一个选择。如果上传带有元数据的大文件,例如在 YouTube API 中,它们提供的是一种额外的方法,它将过程分为两部分:您使用元数据进行 POST,然后您会收到(如果一切正常)
200
另一个带有 URI的那个location
,在哪里放置带有content-length
和 的文件content-type
,这个 URI 包括分配给文件的 id,因此您可以在网络不稳定的情况下恢复上传,检查它是否仍在进行中或是否已经上传之类的