当您在 Twitter 等社交网站上查看个人资料图片时，它们会存储以下图像文件：
http://a1.twimg.com/profile_images/1082228637/a-smile_twitter_100.jpg
甚至在路径中的某处有一个日期，例如 20110912。我能想到的唯一直接好处是防止机器人以线性方式遍历并下载存储中的所有文件。我错过了任何其他好处吗？随机化它的最佳方法是什么？
我正在使用 Amazon S3，因此我将有一个子域服务于我的所有静态内容。我的计划是在我的数据库中存储一个整数 ID，然后将 URL 与 ID 连接起来以形成位置。
我对公共 URL 中的标识符进行加密加扰的一个原因是，业务的增长率并不总是公开的。
如果当前的 id 可以简单地通过创建一个新的用户帐户或上传图片来推断，那么外部人员可以通过定期执行此操作并查看在此期间使用了多少个 id 来计算增长率（或上限）。经过的时间。
无论是停滞不前，还是呈指数级爆炸式增长，我都希望能够控制这些信息的发布，而不是让竞争对手或业务分析师能够自行推断。
这方面的离线示例是发票和支票号码。如果您定期收到公司的账单或付款，那么您可以查看他们在该时间段内开出的发票或支票数量。
这是我维护的一个 CPAN (Perl) 模块，它使用基于 SkipJack 的两种加密方式对 32 位 id 进行加扰：
它是 Greg Rose 用 C 语言编写的 Skip32 算法的直接翻译：
使用这种方法将每个 32 位 id 映射为（有效随机）对应的 32 位数字，该数字可以反转回原始 id。您不必在数据库中保存任何额外内容。
我将加扰的 id 转换为 8 个十六进制数字，以便在 URL 中显示。
一旦您的 id 接近 42.9 亿（32 位），您就需要计划扩展 URL 结构以支持更多，但我喜欢尽可能长的 URL。
更改 URL 是一种使过时资产失效的安全方法。
如果您想允许用户存储私有图像，这也是必要的。一旦您将资产存储在 CDN 上，使用从用户帐户名称/ID/路径中扣除的路径将使隐私设置变得无用。
主要是防止名称冲突。例如，多人可能会上传“IMG_0001.JPG”。您还可以避免对一个目录中文件数量的限制，并且可以在多台服务器上分割图像 - 像 Twitter 或 Facebook 这样的大型网站无法将所有照片存储在一台服务器上，无论多大。