与 AJAX 或 jQuery 上传相比，通过 JSON 上传 Base64 文件有何优缺点？

Question

我的任务是将图像上传到远程服务器并将这些图像保存在本地。通过 JSON 进行 Base64 传输并使用 Node.js 进行存储非常容易。但是，是否有理由不使用这种类型的文件上传，而使用AJAX或其他方式呢？（据我所知，除了 30% 的带宽增加之外。您仍然可以将其包含在您的答案中，以使其完整）。

Answer 1

Base64 编码的思想是避免基于文本的协议使用二进制数据。在这种情况之外，我认为这总是一个坏主意。

\n

优点

\n

\n
• 避免基于文本的协议使用二进制数据，并且独立于外部文件。
\n
• 避免分隔符冲突。
\n

\n

缺点

\n

\n
• 时间和空间增加了复杂性；对于空间来说，它是 33\xe2\x80\x9336%（编码本身占 33%，插入换行符最多增加 3%）。
\n
• API 响应负载较大/太大。
\n
• 除非调用某种延迟加载，否则用户体验会受到负面影响。
\n

\n

\n

通过将所有图像数据包含在一个 API 响应中，应用\n必须先接收所有数据，然后才能在屏幕上绘制任何内容。这意味着\n用户将在屏幕上看到加载状态的时间更长，并且应用\n在用户等待时会显得缓慢。

\n

\n

然而，使用Axios和一些惰性加载器（例如react-lazyload或lazyload等）可以缓解这种情况。

\n

\n
• CDN 缓存更难。与图像文件相反，API 响应中的 Base64 字符串无法通过 CDN 缓存传递。整个 API 响应必须由 CDN 传送。（参见Don\xe2\x80\x99t 在移动设备上使用 Base64 编码图像以及为什么使用 Base64“优化”图像几乎总是一个坏主意）
\n
• 设备上的图像缓存不再可能。
\n
• 服务器端的内容管理变得更加困难。大多数内容管理工具将图像作为二进制文件处理。但是当以二进制方式管理时，存在编码/解码的时间开销。
\n
• 没有安全增益和工程开销可以缓解（清理、输入验证、转义）。XSS 攻击示例：利用 Base64 编码预防 XSS：Web 应用程序安全的错误认识
\n

\n

\n

该网站的开发人员可能选择通过使用神秘的 URL 等方式使网站看起来更安全。然而，这并不意味着这是默默无闻的安全性。

\n

\n

\n

如果他们的网站容易受到 SQL 注入的攻击，并且他们试图通过对 URL 进行编码来隐藏这一点，那么它的安全性就靠默默无闻了。他们的网站是否能够很好地防止 SQL 注入；跨站脚本攻击；CSRF；等等，然后他们就这样对 URL 进行编码，那么这就是愚蠢的行为。

\n

\n

\n

• 它对文本编码图像（例如 svg）没有帮助（可能是 Don\xe2\x80\x99t Base64 SVG）

  \n
\n

• IE6 或 IE7 不支持数据 URI，7.2 之前的 Opera 也不支持数据 URI（哪些浏览器支持数据 URI，从哪个版本开始？）

  \n
\n

\n

参考

\n

https://en.wikipedia.org/wiki/Base64

\n

https://en.wikipedia.org/wiki/Delimiter#Delimiter_collision

\n

SO：base 64 编码有什么用？

\n

https://medium.com/snapp-mobile/dont-use-base64-encoded-images-on-mobile-13ddeac89d7c

\n

https://css-tricks.com/probously-dont-base64-svg/

\n

https://security.stackexchange.com/questions/46362/ Purpose-of-using-base64-encoded-urls

\n

https://bunnycdn.com/blog/why-optimizing-your-images-with-base64-is-almost-always-a-bad-idea/

\n

https://www.davidbcalhoun.com/2011/when-to-base64-encode-images-and-when-not-to/

\n