如何在 .NET Core WebApi 中处理 MultipartFormDataContent 中的文件

给你一逼兜

在上一篇文章（如何在 .NET Core WebApi 中处理 MultipartFormDataContent）中，我们有描述过如何以最简单的方式在 .NET Core WebApi 中处理 MultipartFormDataContent 。基于框架层面的封装，我们可以快速的从 Request.Form 中分别拿到文件内容和文本内容，但是这些默认的解析方式都是建立在前后端以标准的数据格式来进行构建和解析。

问题描述

上图示例展示了用户通过 IOS 客户端发送请求时，对应后端接口接收到的 Request 内容。从请求内容的整体结果，我们可以看出这是一个 multipart/form-data 的数据格式，由于这种数据是由多个  multipart section 组成，所以我们可以看出在这个请求体中，是包含3个 section ，name 值分别为 Agree，CultureCode，FingerSignature，每个 section 都会包含一个 Content-Disposition 字段，前面两个 section都是普通的数据格式，最后一个是图片类型的数据。当后端接口接收到这样一个请求体时，尝试使用 Request.Form.Files 的方式来获取目标文件时，发现无法获取 FingerSignature 对应的文件内容。
问题分析

通过和客户沟通，了解到FingerSignature 对应的文件是会被一起放到请求体中传给后端，客户表示前端APP这一块的逻辑在后端还没有升级成 ASP.NET Core（处于 Framework 阶段）的时候是可以正常工作的。通过查看ASP.NET Core 中对 Request.Form 的赋值逻辑： FormFeature 实现，找到了如下逻辑函数：

通过源码的逻辑，我们可以看出，只有当前的 section 对应的 Content-Disposition 同时包含 form-data 和 fileName (或 fileNameStar)，才会被作为文件来处理（示例：form-data; name="FingerSignature";  fileName=”xxxx.jpeg”），否则并不会把当起的 Section 添加到 Request.Form.Files 中。此时结合上面获取的请求内容，定位到  FingerSignature 部分的 Content-Disposition 中由于缺少 fileName 字段导致后端无法解析到对应文件为该issue 的 Root Cause。
解决方案

由于前端 APP 已经发布多个版本，所以让前端来补全这个字段显然不是一种稳妥的修复方案，因此后端需要做一个兼容性处理。当遇到这种不是标准格式的文件内容，需要通过 MultipartReader 对象来处理 MultipartFormDataContent 对应的 Section 内容（实际上 Request.Form.Files 底层逻辑就是通过 MultipartReader 来依次解析每个 Section 内容）。这里实现了一个方法来获取当前 MultipartFormDataContent 中的所有文件：

在这个方法中有2个细节地方需要注意。

• 默认情况下，Request.Body 中的内容只允许读取一次，所以我们需要在使用这个方法的路由地方启用 EnableBuffering 设置，这里可以自定义一个 Filter 来复用这种特性：
  

• 因为对 Request.Body开启 EnableBuffering 了，所以在调用 ReadFilesAsyns 方法的时候，不确定此时 Body 中的 Stream起始位置为 0。所以我们需要在读取 Body 之前和之后通过 Seek 方法将 Stream的 Position 重置归 0。
  

优化建议

从目前的修复方案来讲的话，后端只是提供了一种妥协的修复方案来适配前端的数据不完整，因此感觉比较完善的修复方案是前端在发送 multipart/form-data 的数据时，尽量以标准的方式来构建每个 Section 内容，尤其是文件类型。如果前后端都能以统一的数据格式来进行交互，自然也就不会出现上述所说的这种问题，潜在的风险自然也就变小了。

来源:https://www.cnblogs.com/hippieZhou/archive/2023/04/21/17316146.html
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！