我正在使用cordova开发移动前端项目，我正在使用的后端开发人员坚持认为媒体文件（图像/视频）应该作为base64编码在json文件中传输。
现在，有了图像，到目前为止还在工作。虽然它冻结了UI几秒钟，但它可以以某种方式推迟。
然而，视频到目前为止还很难处理，传输的单个/简单视频的长度接近300,000。它让我可怜的笔记本电脑经过一个疯狂的旋转，并在完成代码约20秒后得到uri（它仍然无法正常工作，我不想调试它因为它几乎崩溃我的笔记本电脑每次刷新）。
所以我的问题是：
我应该提一下，这些视频应该由很多人（可能是数百人）一次查看，另一位开发人员表示他们的服务器无法处理此类流量。
非常感谢任何建议，我无法找到这些信息。 ：）
答案 0 :(得分：12)
[...]后端开发人员坚持认为媒体文件（图像/视频）应该以json文件中的base64编码方式进行传输。
这是一个非常糟糕（和愚蠢）的想法。您不想要将大量二进制数据作为字符串传输。特别是不是Unicode字符串。
在这里，你需要武装起来并说服你的后端开发者反叛改变他的想法，玩一些Biber或Nickelback，或甚至将他的背景图像改为Hello Kitty，或拍摄他的屏幕快照，将其设置为背景并隐藏所有图标和条形图。这应该可以帮助你改变主意。如果没有，请在办公室最大限度地放置一个webasto并锁定所有门窗。
base64编码是一种在移动开发中传播媒体的流行方式吗？
它很受欢迎，历史悠久，在Usenet上变得非常普遍，等等。然而，在那些日子里，与通过调制解调器传输的所有数据相比，数据量与今天相比非常低。
然而，仅仅因为它很受欢迎并不意味着它是适合一切的正确工具。它不是非常有效，因为它需要一个编码过程，将三个八位字节转换为四个字节，导致增加33％的大小。
最重要的是：在JavaScript中，由于Unicode字符集，每个字符串char都存储为两个字节，因此您的数据加倍并扩展了33％。您的300 MB数据现在是300 x 2 x 1.33 = 798 mb（显示到您的backdev！:)，因为如果服务器无法处理大量流量，这是一个真正的因素。）
这适用于较小的文件，但对于较大的文件，如在您的示例中，这可能会导致时间和内存使用量，当然还有带宽的显着开销。当然，在服务器端，您需要以自己的开销来反转该过程。
如果没有，您建议使用哪种替代方式来传输/展示这些视频？
我建议：
然后服务器只需要将JSON数据解析成后端的可食用数据，二进制数据就可以直接进入磁盘。
更新我忘了提及，正如Pablo在答案中所做的那样，您可以查看流式传输数据。
然而，流式传输几乎是缓冲的同义词，因此带宽将大致相同，只是以更强力的方式提供（通常是UDP与TCP，即丢失数据包）打破转移。流媒体限制你的选择，而不是在客户端缓冲。
我的2美分......
答案 1 :(得分：6)
不确定为什么＆＃34; 33％的开销＆＃34;总是被提及，当这完全是胡说八道。是的，它最初粗略地增加了这个数量，但是有一个叫做gzip的小东西（曾经听过吗？）。我做了大量的测试，差异通常可以忽略不计。实际上，有时gzip压缩的base64字符串实际上比二进制文件更小。看看这家伙的tests。所以，请，我们可以停止传播绝对的小说。
Base64是一种完全可以接受的检索视频的方法。事实上，它对于私人消息系统来说非常有用。例如，如果您使用的是AWS S3，则可以私下存储文件，这样就没有URL。
然而，使用gzip压缩base64视频的主要缺点（imho）是你需要等待整个视频加载，因此伪流是不可能的。
答案 2 :(得分：1)
Base64 是一种方便（但不高效）的二进制数据传输方式。它效率低，因为传输大小将比您最初传输的大33％。它不是一种流行的视频传输方式。如果您计划流式传输该视频，那么您应该寻找已建立的协议来实现这一目标。
我建议使用流媒体协议（有很多可以选择的地方）。
答案 3 :(得分：0)
我认为这是个坏主意，视频文件很大。但是您可以尝试使用小型视频文件。 尝试在线编码器https://base64.online/encoders/encode-video-to-base64 在那里，您可以将视频转换为Base64数据URI，然后尝试插入HTML
结果如下：
<video controls><source src="data:video/mpeg;base64,AAABuiEAAQALgBexAAABuwAMgBexBeH/wMAg4ODgAAA..."></video>