我在离子框架中工作。目前正在设计包含文字和图片的帖子页面。用户可以发布数据和图像，所有内容都是安全的。
因此，我使用base 64编码并将图像保存在数据库中。
encodeURIComponent($scope.image)
每当用户请求时，我从表中选择行并将其与文本一起显示并解码。
decodeURIComponent($scope.image)
使用HTML "data:image/jpeg;base64,_______"转换。
工作正常，但需要花费很多时间。因此，图像尺寸增大了33％，看起来看起来很凸显。
然后我决定继续使用cordova的文件上传插件。但我意识到，以这种方式维护文件是如此多的风险和收集。我也尝试将二进制数据保存到数据库中。但失败了。
没有base64数据的文本选择大大减少了时间。如果可以在另一个http调用中单独选择图像，则在选择其他列和显示之后。它是处理安全图像的正确机制吗？
答案 0 :(得分：4)
mysql手册有什么说法呢？ http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-optimization-tips.html
使用Web服务器，将图像和其他二进制资产存储为文件 存储在数据库中的路径名而不是文件本身。最 Web服务器在缓存文件方面比数据库内容更好，所以 使用文件通常更快。 （虽然你必须处理备份和 在这种情况下，存储会发生问题。）
工作正常，但需要花费很多时间。因此，图像是 尺寸增大33％，看起来看起来很凸起。
正如您所发现的，编码/修饰中不必要的开销+额外的空间用完了，这意味着来回传输额外的数据。
正如@ mike-m所说。 Base64编码不是压缩方法。为什么使用Base64编码也会被@ mike-m发布的链接回答什么是base 64编码用于？。
简而言之，base64编码图像在将它们存储在文件系统（无论是S3还是其他方式）之前，没有什么可以获得的，而且还有很多东西要放松。
Gzip或其他形式的压缩如何不涉及base64。答案是，没有什么可以获得，也没有什么可失去的。例如，我只是gzipped 1941980 JPEG图像并节省了4000个字节，节省了0.2％。
原因是图像已经是压缩格式。它们不能再被压缩。
当您在不压缩的情况下存储图像时，它们可以直接传送到浏览器和其他客户端，并且可以缓存它们。如果它们被压缩（或base64编码），则需要通过您的应用程序解压缩。
现代浏览器能够显示嵌入到HTML中的base64图像，但是它们无法缓存，数据大约比它需要的大30％。
用户可以发布数据和图像，所有内容都是安全的。
我认为您的意思是用户可以下载属于他或与他共享的图像。这可以通过将文件保存在文件系统中的网站空间并仅保存数据库中的路径来轻松实现。然后使用fpassthru
将文件发送到客户端（在执行所需的检查之后）他们如何照顾图像文件。在性能问题上，当大 用户参与，它接缝给我，我需要100000用户的100000文件夹 和他们的子文件夹。当大量用户浏览同一个根时 文件夹，文件系统如何处理每个唯一文件夹。
使用CDN或使用特别适用于此的文件系统，如BTRFS
数据库具有良好的搜索功能，良好的线程安全连接，良好的会话管理。当涉及大型操作时，此方案是否已更改
是的确如此。通过在数据库中保存有关文件及其文件路径的所有信息，充分利用它。然后将文件本身保存在文件系统中。你两个世界都是最好的。
答案 1 :(得分：1)
由于它只是个人文件，您可以将它们存储在S3中。
为了确保文件上传的安全，只需检查文件的mime类型，然后再上传您选择的任何存储空间。
http://php.net/manual/en/function.mime-content-type.php
只需快速检查上传的文件：
$mime = mime_content_type($file_path);
if($mime == 'image/jpeg') return true;
将文件保存在数据库上是不好的做法，它应该是您的最后一个资源。 S3非常适用于许多用例，但是对于高使用率来说它很昂贵，本地文件应该仅用于内部网和非公共可用应用程序。
在我看来，去S3。
Amazon的sdk易于使用，您可以获得1gb的免费存储空间进行测试。 您也可以使用自己的服务器，只需将其保留在数据库之外。
在文件系统上存储图像的解决方案
假设您有100,000个用户，每个用户都有10个图片。你如何处理在本地存储？ 问题： Linux文件系统在几十万张图像后中断，因此你应该让文件结构避免这种情况
<强>解决方案： 使文件夹名称为'abs（userID / 1000）* 1000'/ userID
这样，当您的用户ID为989787时，它的图像将存储在该文件夹中 九十八万九千七百八十七分之九十八万九/ img1.jpeg 九十八万九千七百八十七分之九十八万九/ img2.jpeg 九十八万九千七百八十七分之九十八万九/ img3.jpeg
并且你有它，一种为一百万用户存储图像的方法，它不会破坏unix文件系统。
存储空间大小如何？
上个月，我不得不为我工作的电子商务压缩130万个jpeg。上传图像时，使用带有无损标记和80％质量的imagick进行压缩。这将删除不可见像素并优化您的存储空间。由于我们的图像从40x40（缩略图）到1500x1500（缩放图像）不等，我们平均有700x700张图像，130万张图像，大约120GB的存储空间。
所以是的，可以将它全部存储在你的文件系统中。
当事情开始变慢时，你会雇用CDN。
这将如何运作？
CDN位于您的图像服务器前面，无论何时请求CDN文件，如果它没有在它的存储（缓存未命中）中找到它，它将从您的图像服务器复制它。之后，当再次请求CDN时，它将从它自己的缓存中传送图像。
这样就不需要代码来迁移到CDN图像传送，您需要做的就是更改站点中的URL并雇用CDN，对于S3存储桶也是如此。
这不是一种便宜的服务，但它比云端更便宜，当你到达需要它的时候，你可能负担得起它。
答案 2 :(得分：0)
我建议你继续使用base64字符串，你可以使用LZ字符串压缩技术来减少字符串大小。我一直在使用，而且效果很好。
我不知道我如何接近你的问题，但希望这会帮助你。 这是LZ压缩技术：https://github.com/pieroxy/lz-string/