我的任务是将图像上传到远程服务器并将这些图像保存在本地。通过JSON进行Base64传输并使用Node.js进行存储非常容易。但是，是否有理由不使用这种类型的文件上传，使用 AJAX 或其他方式？(除了我知道的30%的带宽增加。您仍然可以将其包含在您的答案中，以便它已满)。
base64 编码的想法是避免基于文本的协议的二进制数据。在这种情况下，我认为这总是一个坏主意。
优点
- 避免基于文本的协议使用二进制数据，并独立于外部文件。
- 避免分隔符冲突。
缺点
时间和空间增加了- 复杂性;对于空间，它增加了33-36%(编码本身增加了33%，插入的换行符增加了3%)。
- API 响应有效负载更大/太大。
- 用户体验会受到负面影响，除非调用一些延迟加载。
通过将所有图像数据一起包含在一个 API 响应中，应用可以 在屏幕上绘制任何内容之前必须接收所有数据。这意味着 用户将在屏幕上看到更长时间的加载状态，并且应用程序将 在用户等待时显得迟钝。
然而，这可以通过 Axios 和一些惰性加载器(如 react-lazyload 或 lazyload 等)来缓解。
- CDN 缓存更难。与图像文件相反，API 响应中的 Base64 字符串无法通过 CDN 缓存传递。整个 API 响应必须由 CDN 提供。(参见，不要在移动设备上使用 Base64 编码的图像和为什么使用 Base64 "优化"图像几乎总是一个坏主意)
- 无法再在设备上缓存图像。
- 服务器端的内容管理变得更加困难。大多数内容管理工具将图像作为二进制文件处理。但是，在二进制管理时，存在编码/解码的时间开销。
- 在工程中没有安全增益和开销来缓解(清理、输入验证、转义)。XSS 攻击示例：使用 Base64 编码防止 XSS：Web 应用程序安全性的错误感觉
该网站的开发人员可能选择通过拥有神秘的URL等来使网站看起来更安全。然而，那 并不意味着这是默默无闻的安全。
如果他们的网站容易受到SQL注入的影响，并且他们试图通过编码URL来隐藏它，那么它就是默默无闻的安全性。如果他们的网站对SQL注入有很好的保护;XSS;企业社会责任;等等，他们想像这样对 URL 进行编码，那么这简直是愚蠢的。
它对文本编码的图像(如 svg)没有帮助(可能不是 Base64 SVG)
数据 URI 在 IE6 或 IE7 上不受支持，在 7.2 之前的 Opera 上也不支持(哪些浏览器支持数据 URI，从哪个版本开始？
引用
https://en.wikipedia.org/wiki/Base64
https://en.wikipedia.org/wiki/Delimiter#Delimiter_collision
SO：base 64 编码的用途是什么？
https://medium.com/snapp-mobile/dont-use-base64-encoded-images-on-mobile-13ddeac89d7c
https://css-tricks.com/probably-不要碱64-svg/
https://security.stackexchange.com/questions/46362/purpose-of-using-base64-encoded-urls
https://bunnycdn.com/blog/why-optimizing-your-images-with-base64-is-almost-always-a-bad-idea/
https://www.davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/
数据编码
每个数据编码和解码都可以用于各种原因，这带来了好处和缺点。
喜欢：
错误检测- 编码 ：可以检测错误但增加数据使用量。
- 加密编码：将数据转换为入侵者不会破译的密码。
编码算法可以改变数据 这样做有一些用处。
但与
Base64编码，它将每6位数据编码为一个字符(8位)。3 字节到 4 字节，但它只包括字母数字(62 位)和 2 个符号。
它的好处是它 剂量没有特殊的字符和符号
Base64 目的
它可以通过禁止我们拥有的渠道传输任何数据：
- 像
' " /这样的特殊字符... - 不可打印的 Ascii 如
n r t a - 8 位 ASCII 码(ASCII，带 1 MSB )
二进制文件通常包含任何数据，如果 ASCII 中可以成为任何 8 位字符。
在某些协议和应用程序中，有 I/O 接口，它只接受少量字符(带有一些符号的字母数字)。
二人组到：
防止代码注入(例如：SQL注入或任何类似语法的字符
;)或者只是某些字符在其协议中已经具有含义(例如：在 URI 中 QueryString 字符
&具有含义，不能在任何 QueryString 值中)或者输入可能不打算接受非字母数字值。(例如：它应该只接受人名)
但是使用 base64 编码，您可以对任何内容进行编码并传输 您想要的任何渠道。
例：
- 您可以使用SQL对图像或应用程序进行编码并将其保存在 DBMS 中
- 您可以在URI中包含一些二进制数据
- 您可以在协议中发送二进制文件，该协议旨在仅接受字母数字的人工聊天，如IRC频道
Base64 只是一种转换格式，HTTP 服务器无法接受内容中的二进制数据，除非 HTTP 标头类型是二进制或 Web 服务器定义的可接受格式。
您可能知道，JSON 可以包含各种格式和信息;因此，您可以包含诸如
{
IMG_FILENAME="HELLO",
IMG_TYPE="IMG/JPEG",
DATA="~~~BASE64 ENCODED IMAGE~~~~"
}
您可以通过 AJAX 或其他方法发送 JSON 文件。但是，正如我告诉你的，HTTP服务器有各种限制，因为它应该保持RFC2616(https://www.rfc-editor.org/rfc/rfc2616)。
简而言之，通过 JSON 发送可以包含各种数据。 AJAX 只是一种发送方式，就像其他方式一样。
我在我的一个项目中使用了相同的解决方案。
唯一关注的是请求正文大小。如果你的所有图像都很小，比如几个M，那么你应该没问题。
我的服务器是 asp.net 核心，其最大允许内容长度值为 30000000，约为 28.6MB。当图像大小超过此大小时，请求失败，并显示错误"请求正文太大"。
我认为node.js应该有类似的设置，请务必对其进行调整以满足您的需求。
请注意，当请求大小过大时，由于网络流量的原因，请求超时的可能性也会相应增加。这将是一个问题，特别是对于来自手机的请求。
我认为使用base64是有效的。
唯一的疑问是请求的大小，但是如果您在前端划分此base64，则可以避免这种情况，如果一个30mb的文件可以将每个请求分成5mb并在后端将部分放在一起，这甚至对于"继续下载"当您遇到网络问题并损坏某些部分时也很有用。
拥抱
Base64 将数据转换为二进制数据的 ASCII 表示形式。它允许您将数据嵌入到文本流中，例如 JSON。Base64 将传输的数据大小增加了 33%。
多部分/表单数据是在HTTP请求中传输二进制数据的标准方式。它允许您为要传输的每个部分使用特定的编码/内容类型。在我看来，您应该坚持分段上传，除非您有特定要求或设备/SDK 功能。
查看这些链接
Base64 和多部分有什么区别？
Base64 图像上传 VS 二进制图像上传？