Php 为什么大多数网站的用户头像图像文件的url如此复杂？

我发现大多数用户头像图像文件的url都很长，并且合并了很多数据

例如，facebook：

https://fbcdn-profile-a.akamaihd.net/hprofile-ak-ash4/371533_1567227XXX_1135411XXX_q.jpg

我们知道

1135411XXX

是用户id，

q

是文件大小，但是

371533

和

156727xxx

代表什么

其他：

Linkedin

http://m3.licdn.com/mpr/mpr/shrink_60_60/p/4/000/165/0e4/3b2dcXX.jpg

Tumblr

http://24.media.tumblr.com/avatar_4de452cedeXX_64.png

我们只需按用户id命名文件名，它看起来更短更简单，如下所示：

---

但是为什么他们会让url这么长这么复杂呢？我没有考虑什么样的潜在问题？

保存照片时，通常会为其生成一个GUID

guid由数字、字母和符号组成。它们通常足够长，因此可以存储足够数量的图像。它们也是唯一的，所以图像大小和用户id是不够的

guid通常是根据上传时间生成的。与用户id一起，这保证了唯一性

• URL可能有图片id、相册id或用户id，也可能是时间 戳记（以int为单位，以便图像不会以相同的名称缓存）
• 该域非常复杂，因为它的内容交付网络非常复杂 Facebook是akamaihd，因此可能对其他人有不同的看法

---

它们是复杂的系统，可能对化身图片有很多用途。也许在不同的地方，他们需要不同的尺寸。也许他们需要一个只能从他们的站点访问的url

也许他们需要一个唯一生成的url，以便可以从服务器静态地提供文件，从而减少负载

Twitter的url看起来很简单，真的。有cdn域，然后是

avatar\uu

和唯一id，然后是图像大小（即

\u64

）

Linkedin的url中似乎有调整大小的参数，以启用不同的大小，然后是一些我不知道的其他参数，然后是一个唯一的id

---

Facebook有三个UniqueID来生成文件名，我认为他们再次这样做是为了能够快速提供静态文件。我猜其中一个是相册id，一个是个人资料id，最后一个可能是图片id。

可能有多种原因：

反矿工

暗箱操作

生成的UID

额外信息，如大小和像素

想象一下，如果我知道你使用的是5个字符的ID，我会开始在你的服务器上加载所有可能的ID，并从你的用户那里完全删除所有图片

你会有很多流量。 你的用户会因为你没有保护他们的隐私而起诉你

---

例如，对于用户“userone”的路径，最好有一个哈希算法。哈希值为“1236662231”，并将其用作路径，这样其他人就很难理解实际路径，也就不会在你的网站上挖掘信息和图片。

如果是这样，你就可以轻松编写脚本并从他们的网站提取所有用户头像。我认为这可能是一个安全问题。缓存和性能对于这么大的网站来说也是一个大问题，对于这样的常用图像。@Ivo如果只使用用户id，也可以进行缓存。Twitter是

用户id/上传文件名