如果文件直接用 base64 编码传，会怎么样

[frank1256]

修改一个上传文件的接口给同事，本能的就使用 form-data 。 原本是没有上传文件的需求，content-type 是 json ，现在我改成 form ，分 2 个 key ，一个是 attachments ，一个是 req ，req 是原来 json 的字符串。

同事说直接让我还用 json ，并且在它直接将文件转 base64. 跟图片一样的意思。

他说附件不大，我觉得这样有隐患，该怎么说呢，我认为我毕竟是接口，万一给我传个 500M 的字符串啥的，这 500M 我不就全部要吃到内存里。而通过 multiple/form-data 的话，应该是从 io 流里读的，不会一次性吃 500M 内存。

问下大佬们是这样的吗？

[crab]

主要区别不是直接支持二进制不需要编码增大文件吗，如果是大文件不切片也会遇到这情况啊。

[Pastsong]

你传 500M 的字符串你也可以从 io 流里读，看具体实现
问题在于编码解码的损耗，文件体积膨胀，和你的编码解码器可能不支持流式处理。

[eason1874]

脱裤子放屁，客户端转码要花时间，服务器转码要花时间，还增加 30%体积浪费流量

如果文件都是只有几百 KB 大小的，那还能凑合着用。要是文件是 MB 以上的体积，转 BASE64 纯属浪费资源

[zhangxh1023]

文件不大没关系，之前对接银行，他们的前置服务只能接受 json ，也是这么做的。又不是不能用.jpg🤓

[thinkershare]

你的接口 BODY 没有限制主体大小大小吗？如果有，直接编码为 Base64 没啥问题。不会有太大的问题。具体事情具体分析。

[wolfie]

不修改老接口。
新增一个 /v2/ 接口，form-data ，爱用不用。

[wbd31]

nginx 可以限制 body 大小吧

[lmshl]

form-data 里的文件可都是暂存文件系统的，你不主动调用不会全部读进内存。
但一个 JSON 字符串大概率你很难做流式解析（很复杂），严格解析完了可就全在内存里了。

参考：
The file contents are either stored in memory or temporarily on disk. In either case, the user is responsible for copying file contents to a session-level or persistent store as and if desired. The temporary storage will be cleared at the end of request processing.
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/multipart/MultipartFile.html

[lambdaq]

multiple/form-data 记得把文件放在最后，否则别的字段你得把文件读完了才能处理。

[duke807]

用 msgpack 取代 json

[yousabuk]

bade64 后再压一下？

[dcsuibian]

可以限制 http 大小的吧，比如：server.tomcat.max-http-post-size ?
个人觉得小文件用 base64 上传其实没啥问题（比如头像），大文件还是用二进制，再大就还要考虑断点续传。看你实际情况。


体积、流量问题我觉得见仁见智，有些人连字段长度都要省，base64 简直罪无可赦：
https://www.v2ex.com/t/868167

[wangritian]

不理解，传 multiple/form-data 要浪费他几天时间吗？

[adoal]

要不，开个 webscoket 吧

[ufan0]

@wangritian #13 就用这楼的话回复他吧

我就遇过对接方这么干，N KB 就忍了，后面传 N MB 的的过来，网关直接拦截，他们自己的业务全面受阻，呵呵～

[xuanbg]

不怎么样，就是体积变大而已。邮件的附件就是 base64 编码的。

[nkidgm]

浪费带宽。

[zhuweiyou]

有没有一种可能, 你同事不会.

[kkeep]

网络就是被这种垃圾程序占用的😅😅😅

[baobao1270]

我觉得可以直接 restrul put 吧，body 直接就是文件内容，json 和文件分成两个接口