我想知道如果 Web 应用程序有不同的用户名和不同的专辑,那么保存用户图像的最佳文件夹结构是什么。我正在使用 Amazon S3、文件夹和存储桶
我不希望人们能够预测像 FB 这样的用户/专辑的网址
也用于文件名。将文件名更改为编码的最佳信息类型是什么。(用户名、日期/时间、用户 ID)例如
原文:apple.jpg
编码:1263547483_56783929_3934736_943883.jpg
你会用什么来编码这些 Url 安全文件名?Base64,消息摘要?
我想知道如果 Web 应用程序有不同的用户名和不同的专辑,那么保存用户图像的最佳文件夹结构是什么。我正在使用 Amazon S3、文件夹和存储桶
我不希望人们能够预测像 FB 这样的用户/专辑的网址
也用于文件名。将文件名更改为编码的最佳信息类型是什么。(用户名、日期/时间、用户 ID)例如
原文:apple.jpg
编码:1263547483_56783929_3934736_943883.jpg
你会用什么来编码这些 Url 安全文件名?Base64,消息摘要?
我会创建“随机”文件名。这些文件可以保存在一个目录中,也可以保存在生成的目录结构中,如 dir01、dir02、dir03。单独的目录更适合大量文件。我认为您不应该在一个目录中存储超过 10K 的文件。如果您有更多文件,则每次计数器到达 10K 时创建新目录。
文件的所有元数据,包括文件系统中的物理路径,都应该存储在数据库中。Files 表可能包含用户表的外键,因此您始终可以知道文件的所有者。
这种设计是可扩展的:将来您可以将不同的目录存储在不同的磁盘上,甚至可以使用 CDN 系统。这足够安全。不可能猜测您如何将文件元数据编码为文件名,因为您不编码任何内容:您只是创建随机名称。它简单而强大。所有数据都在数据库中,因此您将来可以添加新功能并在数据库中的旧数据上运行它们。
使用 ex Base64 编码似乎是个坏主意。我只需用 GUID 替换文件名,并在数据库中有一个映射,将文件和 GUID 映射在一起。
就像是:
http://photos.site.com/{account-id}/{gallery-id}/{image-guid}.jpg
这将导致:
http://photos.site.com/23323/323/F66A80B2_007F_11E0_86C8_322ADFD72085.jpg