每个用户只有 3 个图像，我需要费力创建一个巧妙的目录结构吗？
我读过几个关于将图像存储在数据库中而不是服务器上的文件夹中的问题，并且我决定使用文件夹，但我想知道我需要多聪明。我发现了很多关于存储数千张图像的问题，但我只想为每个用户存储三张图像（实际上是三种风格的一张图像）。
在这个问题中，首先是提问者提出了一个基于用户名的目录结构（在他的例子和我的例子中都是电子邮件地址）。他的目录看起来像这样：
/images/domain.com/user/imagename.png
在我的情况下可以使用吗？我不是这方面的老手，所以我想知道是否有一些我没有考虑到的安全或性能方面我应该关心的事情。我希望将所有图像保存在网络根目录之外的文件夹中，因此我认为用户访问他们无权查看的文件不会有问题，但是还有其他原因导致您可能想要对文件并使用它来生成目录结构或使用其他某种伪随机生成的官方语言而不是用户名的一部分来生成目录结构？
编辑：我正在使用 php，照片只是个人资料照片（如果这有什么不同的话）。在搜索其他用户时，任何用户基本上都可以看到它们，因此在安全性方面，我只是不希望人们能够热链接到用户的照片或通过输入以下网址直接导航到照片：导致它。除非，正如我所说，还有其他我应该考虑但不知道要考虑的安全问题。
I've read several questions about storing images in a database as opposed to folders on the server, and I've decided to go with folders, but I'm wondering how clever I need to be. I've found a lot of questions about storing thousands of images, but I just want to store three images per user (really one image in three flavors).
In this question the questioner first proposes a directory structure based on username (which in his case and in mine is an e-mail address). His directories would look something like:
/images/domain.com/user/imagename.png
Would that be ok to use in my case? I am not an old hand at this so I'm wondering if there's something I'm not thinking of in terms of security or performance that I should be concerned with. I'm hoping to keep all images in a folder outside the webroot, so I don't think there's an issue with users accessing files they aren't entitled to see, but are there other reasons why you might want to take a hash of the file and use it to generate the directory structure or use some other sort of pseudo-randomly generated gobbledegook instead of part of a username to generate directory structure?
Edit: I am using php and the photos are just profile photos if that makes any difference. They are basically visible to any user when searching for other users, so when it comes to security, I just don't want people to be able to hot link to a user's photo or to navigate to the photo directly by typing in a url that leads to it. That is unless, as I said, there are other security concerns I should be thinking about but don't know to think about.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不明白为什么对文件进行哈希处理会有用，除非您期望它们中有很多是相同的；那么你可以节省大量的存储空间。
如果用户能够编辑他们的用户名（并且你无法预测未来！），那么我不会在结构中使用它。使用数据库主键或永远不会改变的东西。
如果您确实想要更多的结构，您仍然可以跨结构级别拆分ID，例如：ID为1234的用户将图像存储在：
这至少意味着您没有'当你查看列表时，没有超过一百个目录......
I don't see why hashing the files would be of use unless you were expecting a good deal of them to be identical; then you could save lots of storage.
If users will ever be able to edit their usernames (and you can't tell the future!) then I wouldn't use that in the structure. Use a database primary key or something which will never change.
If you did want a bit more structure you could still split the ids across levels of structure, so for example: a user with an id 1234 would have images stored at:
Which would at least mean you didn't have more than a hundred directories when you look at the list...
简而言之，在大多数情况下，您说将图像存储在数据库中，数据库中实际存储的内容是图像的文件名或文件路径，而不是实际图像。
如果您已经了解这些差异并确信要使用文件夹结构，那么为文件夹结构创建哈希的主要原因是为了防止某人将目录更改为以下内容
并访问其他用户的文件进行未经授权的访问。
就我个人而言，我不会推荐为每个用户结构使用一个文件夹，因为我认为这是一个混乱的解决方案。我不会详细说明这一点，但您可以在这里检查之前的几个问题：
在数据库中存储图像 - 是还是否？
将图片存储为文件或数据库中网络应用程序？
Just in a quickie in most of the cases where you say store images in the database, the actual thing stored in the database is the filename or the file path of the image and not the actual image.
If you already understand the differences and are convinced to approach using a folder structure the main reasoning behind creating a hash for the folder structure is to prevent unauthorized access by someone altering the directory to:
and accessing another user's files.
Personally i wouldn't recommend a folder for each user structure since i believe it is a messy solution. I won't elaborate on this but you can check a couple of previous questions here:
Storing Images in DB - Yea or Nay?
Store pictures as files or in the database for a web app?