我的网站处理用户上传的图片。关于我的图片文件名应该包含什么，我有点矛盾。我担心简单的可扩展性和可能的安全性？也许有人在那里处理相同的事情，可以告诉我他们在他们的网站上使用了什么？
目前，我的文件名约定是
{pictureId}_{userId}_{salt}_{variant}.{fileExt}
其中salt是一个令牌生成的服务器端（不知道为什么我决定把它放在这里，可能出于安全目的我不知道）和variant类似于{{1}它表示它是一个缩略图。所以它看起来像
t请指教，谢谢。
答案 0 :(得分：2)
除了之前的注释之外，您可能还需要考虑为文件创建目录层次结构。根据卷和托管文件的特定操作系统，您可以轻松地在单个目录中找到不合理的大量文件。每个文件夹允许的文件数可能有限制。如果您需要对文件进行任何手动QA或维护，这可能会有问题（特别是如果没有编写此类维护）。
我曾经参与过一个图像量很大的项目。除了每个文件的文件名外，我们决定在数据库中记录一个子路径。我们的文件夹名称如下所示：
a/e/2/f/9
3/3/2/b/7
基本上，我们使用单个十六进制值创建了文件夹5深度作为文件夹名称。深度可能过多，但有效。我想这可能导致我们达到了卷上文件夹数量的限制（不确定是否存在这样的限制）。
除了路径之外，我还会考虑存储一个驱动器（假设你有一堆磁盘用于存储）。这样，您可以移动图像，然后更新数据库（假设您有一个）作为移动的一部分。
答案 1 :(得分：1)
您可能想考虑用（例如）缩写替换下划线。 （下划线在SQL中用作通配符，因此在LIKE比较中有一天可能会遇到麻烦）。 （当然，下划线只是简单的邪恶： - ）
它看起来像你的例子，就像你避开空格和大写字符 - 好动。我会将所有内容保持小写并使用不区分大小写的比较来消除不同文件系统的任何潜在的区分大小写问题。
只要您可以处理用户，图片和类型ID中的任意位数，可扩展性就可以了。使用此方案，您不太可能达到任何文件名长度限制。
如果您使用顺序ID，安全性可能会成为问题，因为有人可能会调整数字并请求他们无法访问的图片 - 但是盐应该让人们几乎无法猜出正确的文件名另外一张照片。如果用户无法以任何方式查看/访问内部文件名，那么这可能是一项不必要的措施。
答案 2 :(得分：1)
我的2便士价值;我想说这个问题在可扩展性和安全性之间存在一点冲突。
相反，你应该至少有一个登录机制来创建客户端和服务器之间的会话，以确保你只有在经过身份验证后才能获得东西：即使这样东西也是可以嗅探的：如果安全真的是一个问题，那么我会说你必须使用SSL。
然后，您可以将您的网址映射到bin + image id：但是为了避免Jason Williams提到的问题（顺序编号，使其易于探测），您应该像第1点一样单独解决安全问题。
答案 3 :(得分：0)
要做的第一件事是设置一个为您的用例建模的目录结构。在您的情况下，您有一个用户上传图片。你可能会有这样的目录结构（可能在网络共享的某个地方）：
-Pictures
-UserID1
-PictureID1~^~Variant.jpg
-PictureID2~^~Variant.jpg
-UserID2
-PictureID1~^~Variant.jpg
-PictureID2~^~Variant.jpg
图片 - 只是以下的根目录。
UserID - 是数据库用户ID。
PictureID只是数据库中的图片ID（假设您在数据库中记录了每个上传图片的文件名。）
〜^〜 - 这只是一个分隔符。您可以使用一个字符或X字符序列。我喜欢三个字符，因为它可以使用split函数轻松处理，并且可以在文件名中轻松区分。
有时我喜欢用文件名.256.jpg或.1024.jpg添加图片的大小。
无论如何，所有这些都取决于您的使用案例。最重要的是正确设置目录结构。这样可以更轻松地访问/提供和管理图片。
只要不超过系统上的最大文件名长度，您就可以将所需的任何其他信息添加到文件名中。