繁体   English   中英

Web Api 2 RESTFUL图像上传

[英]Web Api 2 RESTFUL Image Upload

我是Web Api的新手,我正在研究我的第一个项目。 我正在为我们公司的移动CRM系统工作。

我想存储公司徽标,客户面对照片等。

我找到了一些关于这个主题的教程,但不幸的是其中一些是旧的(不使用异步)而其他的不起作用。

最后我找到了这个: http//www.intstrings.com/ramivemula/articles/file-upload-using-mpartpartformdatastreamprovider-in-asp-net-webapi/它工作正常,但我不明白一些的东西。

1)我应该使用App_Data(或任何其他文件夹,如/ Uploads)来存储这些图像,还是将图像存储在数据库中?

2)我可以只设置.jpg,.png等支持的图像并拒绝任何其他文件吗?

3)如何在上传方法中处理图像? 像调整大小,减少文件大小,质量等?

谢谢

1)我们将文件存储在与app_data不同的位置。 我们有几个客户组,我们给他们提供了一个从数据库中获取的唯一文件夹。 存储在数据库中也是一种选择,但是如果你走这条路,请确保你保存的文件不直接属于你需要经常检索的表。 没有对错,但请阅读这个问题并回答一些优点和缺点。

2)如果你搞砸了那个指南,你可以在循环中检查文件的结尾

List<string> denyList = new List<string>();
denyList.Add(".jpg");

foreach (MultipartFileData file in provider.FileData) 
{
    string fileName = Path.GetFileName(file.LocalFileName);
    if(denyList.Contains(Path.GetExtension(fileName))
         throw new HttpResponseException(HttpStatusCode.UnsupportedMediaType);

    files.Add(Path.GetFileName(file.LocalFileName)); 
}

3)调整图像大小是我从未亲自完成的事情,但我认为你应该看一下System.Drawing.Graphics命名空间。 找到一个链接,其中包含一个可接受的回复图片: ASP.Net MVC图片上传通过缩小或填充来调整大小

这些问题实际上都与Web API或REST无关。

  1. 如果您使用的是SQL Server 2008或更高版本,则答案是使用FILESTREAM列。 这看起来像数据库中的一个列,具有其所有优点(即备份,复制,事务),但数据实际上存储在文件系统中。 因此,您可以充分利用每个世界,即不会有人意外删除文件,因此数据库将引用不存在的文件,反之亦然,数据库中的记录将被删除,但文件不是这样,您最终会得到一堆孤儿文件。 使用数据库有许多优点,即元数据可以与文件相关联,并且权限更容易设置。
  2. 这取决于文件的上传方式。 即,如果使用多部分表单,则在保存部件之前检查每个部件的内容类型。 您甚至可以创建自己的MultipartStreamProvider类。 作为API,上传方法可能具有流或字节数组参数和内容类型参数,在这种情况下,只需在保存内容之前测试内容类型参数的值。 对于其他上传方法,根据输入的内容执行类似的操作。
  3. 您可以使用.Net的内置类(即Bitmap:SetResolution,RotateFlip,调整大小使用接受大小的构造函数),或者如果您不熟悉图像处理而是选择图像处理库。

以上所有工作都在Asp.Net,MVC,Web API 1和2中,自定义HTTP处理程序,基本上在任何.Net代码中。

@Binke从不对路径上的用户字符串操作。 即fileName.split('。')[1]如果文件名是这样的话,将不会返回扩展名:some.file.txt,如果文件没有扩展名,则会失败,索引超出范围错误。 始终使用文件API,即Path.GetExtension。

使用扩展来获取内容类型也不安全,尤其是涉及图片和视频时,只需考虑avi扩展,许多视频格式使用的是什么。

files.Add(Path.GetFileName(file.LocalFileName))应该是files.Add(fileName)。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM